FAQ

    持续集成（CI）在这个模式中如何使用？

    CI服务器应该针对哪个分支运行？这要根据具体情况，不过下面的叙述是一个好的起点。

    假定主干的方针是“完成而且可发布”，而每个工作分支的方针是“通过单元测试”：

• 对每个工作分支来说，CI服务器自动并持续地检查构建和运行所有单元测试的状况。

    如果有任何失败，就给出一个红色警告。让机器冒烟……

• 对每个工作分支来说，CI服务器自动并有规律地（如果不能持续地）运行集成测试和回归测试。

    如果有任何失败，就给出一个分离的警告。因为这不是当前分支的方针。

    当有人考虑从工作分支向主干发布代码时，要触发该手工测试，以检查故事是否“完成”。

• 对主干来说，CI服务器自动并持续地运行集成测试和回归测试。

    如果有任何失败，就给出一个红色警告。让机器冒烟、触发警笛、USB火箭发射器，再把国民防卫队叫来。

    该版本控制模型使用哪种工具最合适？

    不确定。我知道Perforce是可以的，我想subversion应该也没有问题，但是对于CVS我不敢打包票。欢迎任何新的建议。

    不过要记得一个重要的事情——切换工具的成本要比不能有效协作产生的成本低得多！所以搞清楚你想怎么做，然后找到合适的工具来支持。

    与用户故事无关的检入怎么处理？

    不是所有的代码变更都必须与某个用户故事相关的，在例子中，我只是为了描述的清晰才这样做。无论检入何种类型的代码（或文档之类），同样的模型也是可用的。

    合并代码很麻烦，所以我想做得越少越好！

    恭喜，你得了合并恐惧症——对于合并代码的非理性恐惧！合并让你觉得麻烦，是因为做的太少了。合并得越多，痛苦就越少。:o)

    我还有更多问题！

    看看后面的参考资源！我相信它们可以解决你大部分的问题。

参考资源

    如果你想了解更多，我强烈推荐下列资源。

《Practical Perforce》

    作者Laura Wingerd。这是一个样章，其中讲述了主线模型的大部分内容。
    这是一本关于Perforce的书，但是主线模型不仅限于Perforce。

《High level best practices in Software Configuration Management》

    由Laura Wingerd和Chirstopher Seiwald合写的关于版本控制的通用非常好的实践的摘要，非常有用。

《Branching and merging – an agile perspective》

    一篇由Robert Cowham所写的、与本文主题有关的有趣文章。

《The Flow of Change》

    又是由Laura Wingerd所作，对于主线模型的上佳摘要文章。“大图景”一节中绝大部分内容基于这些幻灯片。

关于作者

    Henrik Kniberg是位于Stockholm的Crisp公司的一名咨询师，专长于Java和敏捷软件开发。他建立了多个瑞典软件公司，而且对于学习、讲授和应用软件开发的艺术充满了热情。Henrik从事了多种类型的工作，并喜欢扮演诸如经理、开发人员、Scrum Master、教师和教练等多种不同角色。Henrik是流行的InfoQ迷你书“Scrum and XP from the Trenches: How We Do Scrum”的作者。