CM和Agile验证流程合并到Trunk？
我们是一家新的敏捷商店，我们遇到了一个问题，我希望其他人也看到了。
在我们的流程中，Trunk被认为是一个集成分支；它不一定是可发布的，但它必须稳定且功能齐全，可供其他人分支。我们创建主干的功能分支以进行新的开发。所有工作和测试都发生在这些分支中。单个分支根据需要拉起，以与接受并提交的其他功能保持与主干的集成。但现在我们有很多功能分支。每个分支都很专注，生命周期很短，并且在完成后被推到主干，因此我们不会争论分支的需要，并非常努力地实现敏捷。
我的问题就在这里：我要求分支在其生命周期结束时从主干中拉出，并在推送到主干之前完成验证、回归测试并处理所有配置问题。一旦重新集成到主干中，我要求至少进行一次构建和自动冒烟测试。然而，我现在在主干验证方面遇到了阻力。争论的焦点是开发人员可以合并代码并且不需要 QA 验证步骤，因为他们已经完成了功能分支中的工作。因此，不需要额外的测试。我曾试图提醒管理层，无数次“无脑”合并都失败了。他们的解决方案是让开发人员区分功能分支和新合并的主干，而不是构建和回归测试。他们心目中的这个过程将取代我要求的回归测试。那么，当您重新融入主干时，您需要什么？如果我们删除这一步并用 diff 替换，我们会遇到哪些问题？保持敏捷的成本是分支机构整合的额外工作吗？
感谢您的任何意见。 孤独CM
We are a new Agile shop and we are encountering an issue that I hope others have seen.
In our process, the Trunk is considered an integration branch; it does not have to be releasable, but it does have to be stable and functional for others to branch off of. We create Feature branches of the Trunk for new development. All work and testing occurs in these branches. An individual branch pulls up as needed to stay integrated with the Trunk as other features that are accepted and are committed. But now we have numerous feature branches. Each are focused, have a short life cycle, and are pushed to the trunk as they are completed, so we not debating the need for the branches and trying very much to be Agile.
My issue comes in here: I require that the branches pull up from the Trunk at the end of their life cycle and complete the validation, regression testing and handle all configuration issues before pushing to the trunk. Once reintegrated into the Trunk, I ask for at least a build and an automated smoke test. However, I am now getting push back on the Trunk validation. The argument is that the developers can merge the code and not need the QA validation steps because they already complete the work in the feature branch. Therefore, the extra testing is not needed. I have attempted to remind management of the numerous times "brainless" merges have failed. Thier solution is to instead of build and regression testing to have the developer diff the Feature branch and the newly merged Trunk. That process in thier mind would replace the regression testing I asked for. So what do you require when you reintegrate back to the Trunk? What are the issues that we will encounter if we remove this step and replace with the diff? Is the cost of staying Agile the additional work of the intergration of the branches?
Thanks for any input.
LoneCM
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不明白为什么“构建和自动化冒烟测试”应该是任何大量的额外工作，或者被视为“保持敏捷的成本”——当然，考虑到它都是自动化的。 （事实上，我通常会认为持续构建/集成和自动化测试是与敏捷开发相关的最佳实践集的一部分）。
diff一般来说不会削减它，因为可能存在永远不会比较相等的文件（例如，格式包括时间戳的二进制资源），并且只有测试才能确认差异（如果有）不损害正确性。如果多个开发人员（大概是成对的，如果你进行结对编程）都可以独立地提交到主干（即不允许“锁定主干”），那么强烈建议你提倡的那种最小的健全性检查 - 无论是底层开发是“敏捷的”，完全混乱的，或者其他什么;-)。
I don't see why a "build and automated smoke test" should be any substantial extra work, or be accounted as a "cost of staying Agile" -- given it's all automated, of course. (Indeed I normally would consider a continuous build/integration and automated testing to be part of the set of best practices associated with Agile development).
diffin general doesn't cut it as there may be files that will never compare equal (binary resources whose format includes time stamps, for example) and only testing can confirm that the differences, if any, do not impair correctness.If multiple developers (presumably pairs thereof, if you do pair programming) can all be committing to trunk independently (i.e., no "locking of trunk" allowed), then the kind of minimal sanity check you advocate is highly recommended -- whether the underlying development be "agile", totally chaotic, or whatever else;-).