持续集成：如何将构建与需求/任务/错误联系起来？
您如何回答团队中的经理、测试人员和其他人员提出的以下问题：
bug #829 是在哪个版本中修复的？ 我们当前的测试版本已经完成了哪些任务？
简而言之，如何实现从报告到部署的需求、任务和错误的可追溯性？ 您使用哪些流程、工具和技术来实现这一目标？
How do you answer the following questions from managers, testers and other people in your team:
In what build is bug #829 fixed? What tasks have been completed in our current test build?
So simply put, how do you achieve traceability of your requirements, tasks and bugs right from them being reported reporting through to deployment? What processes, tools and techniques are you using to achieve this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我们使用 TRAC 和 SVN 在我们公司中执行每日滚动构建到 DEV / STAGING & 稳定的环境，定期计划部署（每月一次......左右）到生产环境。
当错误被报告时，它会被输入到 TRAC 并给出一个票证号（例如#1001）
。当错误被修复时，代码将被重新签入 SVN，并在 SVN 签入注释中显示票证号（#1001）。
开发人员记下 SVN 变更集编号（例如 [5000]）并打开 TRAC Web UI。 关闭票证时，他们将变更集编号放入票证的注释中。
这样，SVN 签入会引用票证...票证会引用 SVN 签入。
然后，我们的日常构建针对 SVN 变更集执行（例如，今天的构建是变更集 [5050] 之前的所有内容），并在我们的部署通知中对此进行了注释。
这样，测试人员在检查测试修复时就可以通过票证注释中的变更集知道他们正在查看的构建是否包含修复。
We use TRAC with SVN in our Company and perform daily rolling builds to DEV / STAGING & STABLE environments with regular scheduled deployments (once a month... ish) to a PRODUCTION Environment.
When a bug is reported, it's entered into TRAC and given a Tickets number (e.g. #1001)
When the bug is fixed, the code is checked back into SVN with the ticket number(#1001) in the SVN Checkin notes.
The developer takes a note of the SVN Changeset number (e.g. [5000]) and opens the TRAC web ui. When closing the ticket, they put the changeset number in the notes of the ticket.
This way, the SVN checkin reference the ticket... and the ticket references the SVN Checkin.
Our daily builds are then performed against an SVN Changeset (e.g. todays build is everything up to changeset [5050]) and a note is made of this in our deployment notice.
That way the testers when reviewing fixes for testing know by the changeset in the ticket comments if the build they're looking at includes the fix.
我们将 TFS 与 JetBrains 的 TeamCity for CI 结合使用。
将签入与任务关联时，我们的自定义签入策略会将关联的任务和错误及其 ID 和标题添加到签入注释中。
然后，这些评论用于生成发行说明，该发行说明会为每个构建自动生成。
We use TFS in conjunction with JetBrains' TeamCity for CI.
When associating check-ins with tasks, our custom check-in policy prepends the associated tasks and bugs with their ID's and titles to the check-in comments.
These comments are then used to generate the release notes, which are automatically generated for each build.
我们使用已修复的缺陷编号或已实施的增强编号来标记源代码控制签入。
通过检索两个构建之间的签入日志，您可以确定已实施或修复的内容。
We are tagging the source control check-in with the defect number that has been fixed or the enhancement number that has been implemented.
By retrieving the check-in log between two builds, you can determine what has been implemented or fixed.
我们使用名为 Beanstalk (http://www.beanstalkapp.com/) 的托管 SVN 服务，该服务允许您轻松与许多错误/功能管理系统配合。 在我们的例子中，我们使用 Fog Creek 的 FogBugz 来完成这一任务。 SVN/Beanstalk 允许您在签入构建时做笔记，这反过来会影响一个或多个 FogBugz 案例。
在客户端，我们使用Tortoise SVN和Visual SVN来管理本地客户端和Beanstalk SVN服务器的交互（Tortoise提供实际服务，Visual SVN提供Tortoise SVN和MS Visual Studio之间的集成）。
我强烈推荐这两种服务和 Tortoise/Visual SVN 客户端。
We use a managed SVN service called Beanstalk (http://www.beanstalkapp.com/) that allows you to easily tie in with a number of Bug/Feature management systems. In our case, we use Fog Creek's FogBugz for that end of things. SVN/Beanstalk permits you to make notes when you check in a build that will, in turn, affect the status of one or more FogBugz cases.
On the client end, we use Tortoise SVN and Visual SVN to manage the interaction of the local client and the Beanstalk SVN server (Tortoise provides the actual service, Visual SVN provides the integration between Tortoise SVN and MS Visual Studio).
I highly recommend both services and the Tortoise/Visual SVN client.
我们正在使用具有内置颠覆集成的 Fogbugz。 基本上，Fogbugz 有一个插件可以在后台检查 SVN 签入。 因此，如果您在签到时提供 Fogbugz-case ID，它会自动与本次签到链接。
据我所知，您不需要任何特殊的应用程序（例如 Beanstalk）。
反过来就有点棘手了。 我们公司有一个约定，即对于每个（未来或过去）构建，Fogbugz 中都会有一个“版本”。 如果您修复错误或实现功能，则可以将案例分配给正确的版本。
然后很容易获得构建 X 的所有已实现功能的列表。
We are using Fogbugz which has build-in subversion integration. Basically there is a plugin for Fogbugz which checks for SVN check-ins in the background. So if you supply a Fogbugz-case id at your check-in, it gets automatically linked with this check-in.
As far as I know you don't need any special application (like Beanstalk for example).
The other way round is little tricky. In our company there is a convention that for every (future or past) build there is a "release" in Fogbugz. If you fix a bug or implement a feature you assign the case to the right release.
Then it's quite easy to get a list of all implemented features of build X.