更好的发布管理策略？

Question

更好的发布管理策略？

5

我在一家开发基于web的工具的公司工作。作为我的工作的一部分，我被指派负责产品的发布工程（这是我以前从未做过的事情）。我使用SVN搭建了如下系统（很抱歉，在有人建议切换到GIT或Perforce或其他无数选项之前，我们不能使用另一个代码库！）：

- Trunk是始终在生产服务器上的内容。 - 同时有2个分支处于打开状态: - 维护版本。每周三发布一次。 - 冲刺分支。每周发布一次（与当周的维护分支一起发布）。

在发布之前，我将那周的分支合并到主线上。

我发现，运行svn merge通常会在合并时创建大量问题。因此，我们已经切换到手动合并会议，每周一次，需要花费10分钟到1小时的时间，我要在我的系统上比较这两个目录并问每个开发者：“这是你的更改吗？我们应该保留哪个版本的代码？”

这个系统明显不是理想的。有人能提出更好的建议吗？

- llaskin

嗯...好吧，你可以使用git-svn来帮助手动合并... - John Gietzen

1

那么，嗯，你没有读帖子吗？不能使用Git。 - llaskin

1

你使用哪个版本的SVN？最新版本的svn（客户端和服务器）有一个合并跟踪功能。它不是很好，但可以解决一些问题。 - David

1

@llaskin：git-svn 可以让你在连接 svn 服务器的同时在本地使用 git。因此，你不需要更改 svn 服务器。你只需要在客户端安装 git 和 git-svn。顺便说一下，我不确定这是否是一个好的解决方案：它只是另一层… - David

@llaskin: 是客户端还是服务器版本？ - David

哦，等等，那是客户端版本。我们正在使用JIRA Studio来托管我们的SVN实例。 - llaskin

4个回答

3

“在任何给定时间都有2个分支处于开放状态”这个说法让我感到困扰。至少在我的实践中，分支是为了发布前的稳定或修复错误而创建的，它们通常存在时间很短。

我的问题是-你用主干做什么？它不应该是生产环境上的内容，而是生产环境应该运行一个已经打好标签（因此发布）的版本。

据我所见，你的合并问题是自己造成的。

- Otávio Décio

让我澄清一下：生产环境正在运行主干代码。生产环境从不直接更改代码。相反，主干代码会被更改，然后推送到生产环境。版本本身并没有被标记。 - llaskin

2

生产环境正在运行主干版本，就我而言这是一个问题。对我来说，主干版本是开发实际发生的“激进”阶段，不适合于稳定的生产环境。生产环境必须运行标记版本 - 再说一遍，这是我们的做法，有些人可能会持反对意见。 - Otávio Décio

是的，代码库中的“bleeding edge”，也被称为“这里编译不了！谁提交的？” - David

所以在这里，Sprint 是最前沿的版本，而维护版本则是我们修复主干中已识别的错误的地方。 - llaskin

@David - 同意。@llaskin - 我可能错了，但也不会感到惊讶。 - Otávio Décio

1

我认为两种范式都是有效的 - 你可以将主干用作生产环境并在分支上进行开发（当可能存在多个并行开发流时，这种方法在这里很有效），或者将主干用作最新版本，并使生产环境运行已标记的内容。两种方法都有其优缺点，但我不认为任何一种方法本质上是错误的... - Owen Blacker

2

首先，非常抱歉！我不羡慕你的处境。

我曾为一家国际银行工作，在联邦卡法案的网站重新设计方面做了很多工作。和你的情况一样，只是规模可能更大。我们有三个人专门进行发布管理，时间表也非常相似。让这件事变得可行的是，开发人员将代码合并到主干，然后将主干复制部署到生产环境中......我们没有直接将代码提交到生产环境。因此，从发布的角度来看，你可能需要帮助开发人员将他们的工作提交（更新还是回答“这是正确的版本”有什么区别呢？），但你不需要盲目地选择哪些更新应该上线，这似乎是一个很大的问题。当然，开发人员可能会抱怨一点，但是我曾经就是那个位置，这真的不太糟糕。而且，如果你可以随时回答任何可能出现的问题，那就没问题了。这对我们在全国4个地点工作的1200多名开发人员都起作用。

另一个好处是它给了你测试的时间。如果代码在上线之前没有合并，那么它如何在更大的系统上进行测试呢？我真心希望答案不是它没有被测试！

- bpeterson76

这不是我问题的答案，而是一个很好的描述为什么我这样做。 - llaskin

1

这种情况下的理想分支策略是：在主干中进行最新开发，并为每个发布版本从其中切出一个分支，并将其称为维护版本分支。但是，在您的情况下，维护版本的发布发生在主干中，而最新的开发则在分支中进行。

撇开分支策略不谈，以下是一些改善当前情况的建议。

由于您所说的与生产相关的更改首先发生在主干上，我认为这将是最小的。那么，为什么不经常将每个与生产相关的更改合并到其他几个开放分支中呢？我建议一天一次，也可以更频繁或不太频繁，由您自行判断。这也将使开发人员更好地了解正在进行的生产变化，减少冲突。此外，如果有冲突，开发人员将在分支上处理。
您可以考虑设计某种框架
- 应该能够定义哪些分支需要提交主干中的提交。
- 可以有一个后提交钩子脚本，它会检查提交是否在主干中，并立即对分支进行svn合并，并查看是否存在冲突。
- 如果合并成功，则提交更改。否则，将信息发送给您和适当的开发人员（这取决于您如何处理此问题）。

- Version Control Buddy

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Bernard · Accepted Answer

你的主干分支应包含所有最新的开发代码，其中包括来自其他分支的新的和未经测试的功能和任何代码。非常重要的是，所有的代码都要合并到这个分支中。

当你准备好（或认为你准备好）进行测试时，请从你的主干分支创建一个稳定分支。仅将此分支用于测试和修复错误。不要在此处添加任何新功能或改进您的应用程序，否则可能会破坏现有的代码。不要忘记将在此分支中进行的更改合并到主干分支中。

当你准备好发布（测试完成），请从你的稳定分支创建一个发布分支。这是你发布到生产环境并维护/支持的分支，如果在生产环境中发现了错误/问题。与稳定分支一样，不要在此分支中添加任何新内容。通常会对此分支进行标记以便在生产环境中识别它。不要忘记将在此分支中进行的更改合并到稳定分支中，以便从稳定分支创建的其他发布分支获得任何错误修复的好处。

分支层次结构将如下所示：

trunk
|-- stable 1.0
  |-- release 1.0
  |-- release 1.1
|-- stable 2.0
  |-- release 2.0

使用这种层次结构，您的开发团队可以在主干分支中自由开发，而稳定和发布分支可以维护您应用程序的当前和先前版本。