防止构建中断 - 使用预提交构建
有哪些方法可以防止马虎的开发人员破坏构建。
是否有任何版本控制系统具有防止签入破坏构建的代码的系统。
谢谢
What methods are available for preventing sloppy developers from breaking builds.
Are there any version control systems which have a system of preventing check-in of code which breaks the build.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Microsoft TFS Build 有一种称为“门控签入”的功能，它通过执行私人签入（称为搁置）来提供此功能，如果构建成功，则将其提升为正常签入。
http:// /blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-erated-check-in.aspx
TeamCity 有“延迟提交”的概念
http://www.jetbrains.com/teamcity/features/delayed_commit.html
我可以全心全意地推荐 TeamCity ！
Microsoft TFS Build has something called "gated check-ins" which provides this, by performing a private check-in (called Shelving) which is promoted to a normal check-in if the build succeeds.
http://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated-check-in.aspx
TeamCity has the concept of "delayed commit"
http://www.jetbrains.com/teamcity/features/delayed_commit.html
I can wholeheartedly recommend TeamCity!
老实说……为什么人们如此热衷于“让开发人员做某事”。告诉他们这是流程，如果他们不遵守就解雇他们。
编辑：因为以下评论太长。
我所在的团队有 12 名左右的开发人员。有些人认为大，有些人认为小。
我们有一个大屏幕（6 英尺支架上的 32 英寸平板电视），每个人都可以看到，它告诉我们各种信息 - 包括（在屏幕上最大的盒子中） “提交构建”的状态。
我们的流程是在提交之前从 SVN 更新并在本地运行提交构建（大约 2-3 分钟），如果没有，请在本地修复并重复。 TDD，这种情况通常只有在您从 SVN 中取出的内容破坏了您正在处理的内容时才会发生，
如果它在 CI 中失败，您要么忽略了该过程，要么您的提交与其他人的提交发生了严重冲突。屏幕变红，有人大喊大叫。你，你修复它并继续前进，这种情况通常大约每周发生一次；大多数情况下它会变红，因为人们试图走捷径;-)
没有人需要“强迫开发人员”做任何事情。 ，艺术人士，他们通常足够成熟和专业，可以遵循某个流程（如果该流程有意义）。在这种情况下，请在本地构建，并且仅在通过后才提交。
谁会在乎 CI 中的构建是否出现问题，只要能够快速修复并且不会妨碍团队工作即可？
Honestly... why do people get so hung up on "making developers do X". Tell them it's the process, and fire them if they don't follow it.
EDIT: because the following was too long for a comment.
I work on a team with 12 or so developers. Some people consider that large, some consider it small
We have a large screen (32" flat screen TV on a 6 foot stand) that everyone can see that tells us all sorts of information - including (in the biggest box on the screen) the state of the "commit build".
Our process is to update from SVN and run the commit build locally (about 2-3 mins) before committing. If it passes, ship it. If not, fix it locally and repeat. Since we do TDD, this generally only happens if something you pulled out of SVN broke something you were working on.
If it fails in CI you either ignored the process or your commit collided with someone else's in a bad way. The screen goes red, someone shouts at you, you fix it and move on. This generally only happens to us about once a week or so; mostly it goes red because people try and cut corners ;-)
Nobody needs to "force developers" to do anything. We're creative, artistic individuals who are generally adult and professional enough to follow a process if that process makes sense. In this case, build locally and only commit if that passes.
Who cares if the build breaks in CI, as long as it's fixed quickly so it doesn't prevent the team from working?