现在大家都利用着持续集成带来的便利，体会着它给我们带来的好处，但是我们也在不断提高自己的需求，人的欲望是无止境的啊。现在遇到了一个既要保证能每天给测试人员出可测试的build，又要让开发人员随时可以提交代码的问题。不知道大家是否遇到过?有没有好的方法可以解决?
研发人员(Developer)
1)研发人员希望随时可以check in源代码。尽快尽早的提交代码也是我们说提倡的，因为这样可以让别人更快的看到你的更改，同时避免了你本地文件丢失的风险。
2）研发人员希望随时可以触发构建，也许可能就是一提交代码，就可以触发构建；也许是按照需求去出发构建。比如有的时候，我紧紧希望构建服务器能编译，链接通过就OK了；而有的时候，我希望构建服务器不但能做这些，还要进行Full testing.
3)研发人员提交代码，触发构建之后，希望能尽可能快的得到反馈。
测试人员( Testing Engineer)
1)测试人员希望能尽早的得到build。因为一旦得到第一个build，测试人员就能得到一些在设计阶段没有表达，表达不清，或者甚至无法表达的信息。这样就非常有助于后续的测试。
2）测试人员希望每天（或者每隔几天，因为也许一个build的测试周期就需要几天）就能得到一个可测试的build。哪怕这个build里边自由很少的 feature。这个build必须是可测的。编译链接无有错误信息，可以安装上，俗称通过了smoke test。
项目经理
1）最后要发布的build，不能延迟，bug当然越少越好
2）如果有几轮测试的话，每轮测试都要能守住自己的时间，这样才能保证最后的项目发布期限。
现在我们就要想出一种分支模型来解决存在的问题，尽量满足项目的这些需求。研发人员关注的是时间和方便性；测试人员关注时间和质量；而项目经理不但关心时间也关心质量。
一个可能的方法是把研发和测试分成两条分支。
Main Branch (Trunk) －－－－－－－－－－－－－>
Testing Branch |－－－－－－－－－－－－>
Main Branch 也就是研发经常要提交代码的分支，出来的build也只给研发测试用
Testing Branch是给测试人员出build的分支。
为了能尽早的出build给测试人员,就要很早的建立出一个testing branch;而且要不段的把main branch上可以测试部分的代码merge 到testing branch上来.
这里就出现了几个和以前我们经常讨论的相矛盾的地方。我们以前一直认为1）分支只有的确有必要的时候才创建 2）只有在不能兼容的时候才创建分支 3）要在晚期才开出分支。
为什么要那样呢？因为，早期创建出分支来带来维护的上的工作量。因为Main Branch一直是活动着的，只要开出了testing branch那么以后在Main上的东西大部分都要Merge到 testing branch上来，这无疑会增加研发人员的工作量。
这个模型的确部分满足了上边的要求，但是同时大大增加了研发人员merge 代码，解决代码冲突的工作量。
不知道大家是否遇到过这种情况？有什么看法？
------解决方案--------------------------------------------------------
保持main branch的稳定，新加的功能、特性可以加在分支branch上，测试通过后再merge到main branch，同时删去这个branch。
------解决方案--------------------------------------------------------
你的公司还是很专业的～
我们在与测试团队合作的过程中肯定会有类似的问题
我们通过迭代控制了与测试团队的一起工作的节奏
Step1. Iteration1交给test group
Step2. 开发团队做Iteration2，同时在Iteration2中计划一段时间集中修改test出的bug，之后test group进行回归测试
Step3. Iteration2结束后交给test group
以此类推
Iteration1的时候打个tag就可以了，
做到那种纯实时性的提交修改测试，会比较混乱难以管理，效率也不是很高
我个人对打branch很慎重，我绝对test group只针对Iteration1结束时打的tag，Checkout出来进行测试就可以了
不用branch
持续集成可以在开发团队进行，我们也同样鼓励开发人员及早提交代码，当然谁的编译没有通过是要跟一下
我个人感觉你们公司很专业做的不错～～
一家之言仅供参考
祝你成功～～