多组开发人员(不在同一地点)在同一项目的不同组件上工作的svn部署策略

我想你和我们的人有相似的要求。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合并到trunk)。

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

这样我们就可以把紧急的和非紧急的变化分开,并且有相对无痛和稳定的释放。 你所做的几乎是一样的,但你从一个标签分支,当你完成你再次标记。有点过分:)。 从标签分支也是不好的风格。一枝接一枝。

分支机构策略

如果你为你的每一个分支类型写下策略,让他们自己做更多的事情,而不让一个发布人员一直坐在他们的脖子上,引诱他们的承诺,这对团队是有帮助的;)

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

• 后备箱:

  • 从维护接收合并
  • 此分支没有直接释放

• • 可能只会收到紧急修复
  • 如果没有新的稳定分支可用,则合并到主干

• 标签/*

  • 这里没有承诺
  • 用于部署

一旦你试图只合并到一个“方向”,合并也就不再是一种思维训练了。(你可能想在谷歌上搜索豆腐秤,但现在已经有点过时了)。 请注意,合并是由开发人员连续完成的,而不是由发布经理来限制瓶颈。

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

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

• CI 来自维基百科
• CruiseControl
• Xinc -PHP的CI(我最喜欢的,很简单)