关于错误生命周期和发布管理的建议
我们的小组目前正在分析管理正式软件版本并与 bug 生命周期集成的程序。
您使用什么错误生命周期模型？为什么？
例如，假设每周为 QA 生成一次正式版本。您在什么时候将错误标记为已解决？
- 开发人员何时提交更改？
- 更改何时被审查并合并到发布分支中？
- 正式候选版本何时创建？
您使用什么流程或错误跟踪软件的功能来跟踪此问题？
您有什么可以分享的提示/建议/建议吗？
Our group is currently analysing our procedures for managing formal software releases and integrating with a bug lifecycle.
What bug lifecycle model do you use? And why?
For example assume a that formal releases are generated for QA once per week. At what point do you mark bugs as resolved?
- When the developer has committed their changes?
- When the changes have been reviewed and merged into the release branch?
- When the formal release candidate has been created?
And what process, or features of your bug tracking sofware, do you use for tracking this?
Are there any tips/suggestions/recommendations that you can share?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您足够幸运，有一个可以捕获错误的单元测试，或者如果您能够添加专门测试错误的新测试，那么它可以提供良好且客观的分辨率测量。
如果您通过回归测试进行连续构建，那么只要您的主分支上相应的测试通过，就可以认为该错误已经解决。这样做的优点是，可以很容易地考虑在一个分支上已解决但在另一个分支上未解决的错误，从而使您尽早尝试集成并衡量成功程度。
根据您的文化，您可能只想将错误标记为真正解决（如果它在所有分支中通过了自动构建）。
另一个好处是，如果错误在将来再次出现，例如由于某人恢复某些内容或合并灾难，您可以捕获该错误。
If you are lucky enough to have a unit test that catches the bug, or if you are able to add a new test that specifically tests for the bug, it offers a good and objective measurement of resolution.
If you do continuous builds with regression testing, then as long as the corresponding test passes on your primary branch, the bug can be considered resolved. The advantage of this is that it makes it easy to consider a bug resolved on one branch but not resolved on another, leading you to attempt integration early and have a measurement of success.
Depending on your culture, you may want to only have a bug marked as truly resolved if it passes automated builds in all branches.
A side advantage is that you can catch the bug if it reappears in the future, for example due to someone reverting something or a merge catastrophe.