代码之家  ›  专栏  ›  技术社区  ›  Michael Moussa Tejay Cardon

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

build-process deployment version-control svn
  •  5
  • Michael Moussa Tejay Cardon  · 技术社区  · 15 年前

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

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

    这在一段时间内很有效,直到团队成长。我们经常遇到这样的情况,即被标记的修订版在投入生产之前有需要修复的问题。当负责的开发人员正在处理这些修复时,我们让其他开发人员将更改提交给trunk。一旦原始开发人员的修复完成,添加的新提交将不得不继续进行,从而进一步推迟构建,因为现在需要进行额外的验证。

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

    为了解决这个问题,我们开始用最新的产品标签创建“发布分支”。人们只会承诺那些准备好测试并投入生产的东西。其他人则会在轮到他们合并之前一直致力于主干。这样就把合并和解决冲突的责任从构建管理器转移到了拥有代码的人身上。

    1. 从最新的生产标记创建分支
    2. 把紧急的东西加到那个分支上
    3. 标记该分支并发布到生产
    4. 将该分支中所做的所有更改合并到QA中的常规“release分支”中。

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

    我试着把这和一个开源项目联系起来,在这个项目中,到处都有开发人员,他们甚至都不认识,而且似乎还过得去。。。但是,当新的稳定的、经过测试的、值得生产的构建预计每周(或每天)几次用于“公共”消费时,这种比较就不成立了。例如,如果Firefox的日常构建是一团乱麻,那么至少用户可以回到以前的版本或者使用最新的稳定版本。我们的用户不是这样的。如果我们的版本不完美,他们就不能工作。

    背景故事完成后,我现在提出一个问题:

    在这样一个环境下。。。

    1. 开发人员到处都在开发不同的组件。
    2. 对某些组件的更改可能要等一周才能发布,而其他组件甚至不能等一天。
    3. 应用程序是任务关键型的,在发布之前必须对更改进行测试和稳定。

    ... 您可以推荐哪些建议或替代工作流程来促进一个更理智的流程,其中大部分负担不在一个人身上?

    2 回复  |  直到 15 年前
        1
  •  7
  •   Christoph Strasen    14 年前

    我想你和我们的人有相似的要求。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维护分支最终将被放弃和删除。

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

    stable branches for release & maintenance

    分支机构策略

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

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

    • 后备箱:

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

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

    • 标签/*

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

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

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

        2
  •  1
  •   Stephen Holiday    15 年前

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

    推荐文章
    关于  
    代码之家 - 一站式码农服务社区
    沪ICP备11025650号