将 ISO 程序应用于代码更改
我正在寻找一种方法来对开发人员代码签入执行 ISO 标准。这归结为审核对代码库的每个更改，以便我可以知道：
- 谁进行了更改
- 何时进行了更改
- 哪个项目 更改与
- 哪些工作项相关 更改与哪些工作项相关
我们正在使用 Subversion 进行源代码控制进行 .Net 开发TeamCity 作为我们的 CI 服务器。理想情况下，我希望有工具来管理这些策略的执行，以便开发人员不必考虑它。
是否有人有通过 CI/门控签入或仅通过政策和程序强制执行此类跟踪的经验？
I'm looking for a way to enforce ISO standards on developer code checkins. This boils down to auditing each change to the codebase so that I can tell:
- who made the change
- when the change was made
- what project the change related to
- what work item the change related to
We're doing .Net development using Subversion for source control and TeamCity as our CI Server. Ideally I'd like tools to manage the enforcement of these policies so that devs don't have to think about it.
Does anyone have any experience of enforcing this kind of tracking either with CI/Gated Check-In or just with policies and procedures?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我不熟悉具体的 ISO 标准，但如果您遵循良好的开发流程，您确实应该拥有所需的所有工具。
Subversion 以及与错误跟踪器（如果存在）的集成应该可以处理所有这些问题。 Subversion 将记录谁在何时进行了更改。每个项目都应该在自己的存储库中，并有自己的错误跟踪器，并负责处理。这种情况下的工作项通常是源文件或配置文件 - Subversion 也应该跟踪这一点。
在工具方面，您可以使用 Subversion 来强制执行签入注释。您可能会喜欢并使用正则表达式强制执行模板，尽管我不会推荐它 - 会出现一些边缘情况，您的模板无法满足开发人员的需求，并且只会阻碍进度。
政策和开发人员纪律将在这方面发挥很大作用。定期审核您的提交日志，让变更控制委员会在将变更分配给开发人员之前批准变更，并跟踪提交、分配、修补和测试中的错误。
I'm not familiar with the specific ISO standards, but you really should have all of the tools you need if you are following a decent development process.
Subversion and integration with your bug tracker (if it exists) should handle all of this. Subversion will keep track of who made the change and when. Every project should be in its own repository with its own bug tracker, taking care of that. The work item in this situation is typically going to be a source file or configuration file - Subversion should also track this.
In terms of tools, you can use Subversion to enforce a check-in comment. You might be able to get fancy and enforce a template using regular expressions, although I wouldn't recommend it - there's going to be edge cases where your template won't fit the needs of the developer and will just hinder progress.
Policies and developer discipline will go a long way here. Audit your commit logs regularly, have change control boards to approve changes before they are assigned to a developer, and track bugs from submission, assignment, patch, and testing.