模型的变种

    “版本控制模式”一节描述了一个如何实施主线模型的范例。

    “大图景”一节以更通用的方式描述了主线模型。

    本节中，我将针对如何实施该模式提出一些典型的变种。

    “完成”的定义不必一定是“可发布的”

    先确定“完成”一词的任何定义，然后确保有一个分支可以容纳根据该定义已经“完成”的故事。不过还是要注意别遗漏重要的内容。如果集成测试没有包含在“完成”中，那什么时候进行集成测试呢？

    主干不必是主线

    这个模式需要一条主线才能进行下去，不过不必是主干（虽然在大多数情况下，使用主干是很自然的选择）。

    团队不一定必须有自己的分支

    当然可以有多个团队共享同一分支，甚至直接在主线上展开工作。只要保证遵循分支的方针即可。

    通常，团队希望有自己的分支，以避免未完成的故事在多个团队之间造成干扰。

    不必每次都创建一个全新的发布分支

    可以使用同样的发布分支，而不是在每个sprint结束后都创建新分支。那个分支可以称为“最新生产系统”或其他类似的名字。如果在生产系统中总是保持只有一个版本，这当然是很好的模型。

    不必在每个sprint结束后都进行发布

    可以在每个故事完成后进行发布。或者每三个sprint完成后发布一次。确定你自己的步伐。

    不必针对每个故事都运行回归测试

    如果在你的环境中，回归测试或集成确实很难实际操作，那么可以在sprint接近尾声时进行。这样就可以针对一批故事进行测试和集成的工作。你自己要承担相关风险。如果回归测试和集成属于“完成”的定义，这可能意味着你在sprint末尾时可能会遇到问题，导致没有任何故事完成的风险。