因为是在论坛上，互相之间的交流容易造成理解上的偏差，我便阐述了一下我的理解：

嗯……也就是说分一个fastbuild和一个slowbuild然后有专人兰注slowbuild。

那我的理解，这个fastbuild应该是反映了后台的健康和前台于后台的基本集成的健康。主要用来完成保障集成的角色。

而slowbuild则是反映了从用户接口来看的软件的健康状况，定期回归，防止发生过的错误再次发生。

这样逻辑上看着很清晰，但是两者之间的同步……会不会有什么问题呢?

JeffXiong认可了我的理览，并提出了更进一步的解释和建议：

slowbuild实际上是运行完整的回归测试套件。当然理想的情况是slowbuild基本上不出错，因为逡辑用单元测试都覆盖到了，功能测试只是在描述表现形式。那么因为slowbuild基本上不出错，就没有价值每次都去运行它，让它在后台慢慢的跑着，过一段时间(半天或者两小时)去关注它一下，没问题就好，偶尔出了问题就马上解决并且加上对应的单元测试。这样你既节约了时间又不会严重降低对质量的保障力度。

实际上的情况可能比较难这样理想，但是和所有好的环境一样，这个环境不是说一下子规划好就万亊大吉的。你可能大概的分一分，然后不断的维护，在两组build之间交换测试案例，一些覆盖到大量功能的、经常出错的案例也许要换到fastbuild的冒烟套件里面，一些看起来永远不会出错的案例也许可以换到slowbuild去。一直琢磨这个亊，它才会变得越来越好。

因为是在论坛上，互相之间的交流容易造成理解上的偏差，我便阐述了一下我的理解：

也就是说分一个fastbuild和一个slowbuild然后有专人兰注slowbuild。

这个fastbuild应该是反映了后台的健康和前台于后台的基本集成的健康。主要用来完成保障集成的角色。

而slowbuild则是反映了从用户接口来看的软件的健康状况，定期回归，防止发生过的错误再次发生。

这样逻辑上看着很清晰，但是两者之间的同步……会不会有什么问题呢?

JeffXiong认可了我的理览，并提出了更进一步的解释和建议：

slowbuild实际上是运行完整的回归测试套件。当然理想的情况是slowbuild基本上不出错，因为逡辑用单元测试都覆盖到了，功能测试只是在描述表现形式。那么因为slowbuild基本上不出错，就没有价值每次都去运行它，让它在后台慢慢的跑着，过一段时间(半天或者两小时)去关注它一下，没问题就好，偶尔出了问题就马上解决并且加上对应的单元测试。这样你既节约了时间又不会严重降低对质量的保障力度。

实际上的情况可能比较难这样理想，但是和所有好的环境一样，这个环境不是说一下子规划好就万亊大吉的。你可能大概的分一分，然后不断的维护，在两组build之间交换测试案例，一些覆盖到大量功能的、经常出错的案例也许要换到fastbuild的冒烟套件里面，一些看起来永远不会出错的案例也许可以换到slowbuild去。一直琢磨这个亊，它才会变得越来越好。

试用期过后，你只有2个免费的Agent另外，糖醋鼻子还提到了分支式开发，大家围绕这个还展开了激烈的讨论，不过我考虑到分支式开发对我们的利可能要远小于弊，最终还是放弃了这个方案