svn 部署策略，适用于在同一项目的不同组件上工作的多组开发人员（不位于同一地点）

Question

我们的项目是一个支持我们几十个网站的内容管理系统。开发小组从一个小地方开始，我们处理的是相当标准的编码/部署策略。

我们对后备箱进行了编码，并坚持使用干净的后备箱。每隔几天，我们就会标记主干并部署到测试服务器。如果一切顺利，我们将部署到生产环境并继续前进。

这在一段时间内运作良好，直到团队成长。我们经常遇到这样的情况，即标记的修订存在需要在投入生产之前修复的问题。当负责的开发人员正在处理这些修复时，我们让其他开发人员提交了对主干的更改。一旦原始开发人员的修复完成，添加的新提交将不得不顺其自然，进一步延迟构建，因为现在需要进行额外的验证。

为了解决这个问题，我们创建了一个单独的主干，严格用于发布。人们会在主干中工作，然后要求项目经理或开发负责人将他们的更改合并到发布主干中。

这工作了一段时间，直到团队变得更大、更分散。我们有 3 到 5 人的团队，在 4 个地理位置工作——一些在相同的组件上，另一些在不同的组件上，具有不同的优先级和发布时间表。这几乎是一份全职工作，对于管理构建的人来说是一场噩梦。

为了解决这个问题，我们开始使用最新的 Production 标签创建“发布分支”。人们只会承诺那些准备好进行测试并投入生产的东西。其他人会承诺使用主干，直到轮到他们合并。这将合并和解决冲突的负担从构建管理器转移到拥有代码的人身上。

这工作了大约一周，直到我们开始不得不进行几次“高优先级紧急”发布。这实际上意味着我们将：

1. 从最新的生产标签创建一个分支
2. 将紧急情况添加到该分支
3. 标记该分支并发布到生产环境
4. 将该分支中所做的所有更改合并到 QA 中的常规“发布分支”中。

这是每一天。有时一天两次。

我试图将其与一个开源项目联系起来，在该项目中，到处都有开发人员，他们甚至彼此都不认识，但他们似乎仍然过得去……但是当新项目出现时，这种比较就会分崩离析预计每周（或每天）多次“公共”消费的稳定、经过测试、值得生产的构建。例如，如果 Firefox 的日常构建是一团糟，至少用户可以回到以前的版本或使用最新的稳定版本。对于我们的用户而言，情况并非如此。如果我们的版本不完美，它们就无法工作。

背景故事完成，我现在提出问题：

给定一个环境......

1. 开发人员遍布各地，开发不同的组件。
2. 对某些组件的更改可能要等一周才能发布，而有些则甚至不能等一天。
3. 该应用程序是关键任务，必须在发布之前对更改进行测试并保持稳定。

...您可以推荐哪些建议或替代工作流程来促进一个更健全的流程，其中大部分负担不是由一个人承担？

Answer 1

合并的维护分支和发布分支

我认为您和我们的员工有类似的要求。 CI 可以帮助您实现自动化，但不能解决潜在的组织挑战。

所以你有两种签到类型：

• 正常的非紧急代码（计划每隔一段时间发布一次）
• 紧急“修补”代码（在发布后发生，如果某些东西没有经过足够的测试就漏掉了，或者当客户 X 打电话给他，因为他希望按钮粉红色而不是紫色并且他威胁要放弃合同：P）

两种情况不同，您需要将它们分开。你的方法已经接近我认为的答案，但你做的“太多”

让我描述一下我们的工作：

存储库布局

trunk (is our project with components and all)
branches
|
-- 1.0-stable-week-40
|
-- 2.0-stable-week-42
|
-- 3.0-stable-week-44
tags
|
-- 1.0.0
|
-- 1.0.1
|
-- 1.0.2
|
-- 2.0.0
|
-- 2.0.1
|
-- 3.0.0

如您所见，我们有一个用于所有主要开发工作的主干。我们还创建稳定的分支，用于每 2 周发布准备和测试，并在所有发布发布时对其进行标记。

发布生命周期（广义）

在新版本发布后，我们会维护分支（例如 1.0），直到推出下一个主要版本。 我们的政策是，在此期间，只能将关键修复程序签入该分支。它们只经过最少的测试，可以通过从我们的维护分支创建一个新标签在几分钟内发布。

在维护期的中途（发布后 1 周），我们从主干创建一个名为“2.0”的新分支。主干中所有不那么紧急的开发将自动在此版本中。可以“小心”添加更多内容，例如来自当前活动维护分支的紧急修复（从 1.0 合并到 2.0 到主干）。

又过了一周，所有测试都完成后，2.0 分支被标记为 2.0.0 并发布，没有出现重大问题。 1.0 维护分支最终将被废弃和删除。

通过这种方式，我们可以将紧急更改与非紧急更改分开，并获得相对轻松且稳定的版本。 你所做的几乎是一样的，但是你从一个标签分支，当你完成时你再次标签。那有点多:)。 从标签分支也是不好的风格。从分支分支。

---

分支机构政策

如果你为你的每个分支类型写下策略，使他们能够自己做更多的事情，而不需要一个发布人不断地坐在他们的脖子上并引诱他们的提交，这将对团队有所帮助；）

我们的政策可以这样描述：

• 主干：

  • 没有语法错误的提交
  • 从维护中接收合并
  • 此分支没有直接发布

• 分支/X.X-stable

  • 可能只接受紧急修复
  • 应始终“准备好发布”
  • 开发者必须将他的提交从这里合并到任何更年轻的稳定分支
  • 如果没有更年轻的稳定分支可用，则合并到主干

• 标签/*

  • 这里没有提交
  • 用于部署

一旦您尝试仅合并到一个“方向”，合并也不再是一种思维训练。 （你可能想用谷歌搜索豆腐规模，但现在有点过时了）。 看到合并是由开发人员连续完成的，而不是发布经理来限制瓶颈。 虽然一个版本已经上线并积极维护接收修补程序，但我们已经开始准备下一个版本，将其与主干中可能不稳定的变化隔离开来，并给它“成熟”的时间。

当然，您可能对代码孵化和测试的持续时间或发布迭代的长度有不同的要求。适应:)

Answer 2

我非常喜欢持续集成以及测试驱动开发。

以下是一些我建议查看的链接：

• CI 来自维基百科
• CruiseControl
• Xinc - PHP 的 CI（我的最爱，很简单）