Be very careful in labeling "Breaking the Build" as a bad thing. It is something that needs immediate attention, but it is also a very normal and expected part of the development cycle. This is why Continuous Integration is so useful -- it tells you immediately when the build is broken, and what change set caused it. It helps you get back on track quickly.
If your culture penalizes "Breaking the Build", then you are in danger of cultivating a toxic work environment. Again, consider it to be something that needs immediate attention, but don't label it as "bad".
The whole point of working with CI is that you're always developing on a known stable base. It's not a bad thing for the mainline build to break, although if it's happening all the time it suggests people aren't being careful enough about updating and building locally before a commit. When the mainline build does break, however, it's important that it gets fixed fast.
It you break the build as has happend to me yesterday. When your team-mates try and use the sourcecode. It will not build. Therfore they will struggle to test the work that they are doing. It get worse the bigger your team.
Surely the whole point of continuous integration is to identify problems early. Daily or more frequent check ins are required to reduce conflicts to a manageable size.
You should get an up to date copy of the repository and build locally. This will tell you if your proposed check in will break the build. You resolve any issues and then check in.
In this way the integration issues are kept local and easy to fix.
Breaking the build has dire implications for the project schedule (and the blood pressure of team-mates) => Other developers who then get latest version can no longer build there own changes, delaying them => Continuous integration will break, meaning that formal testing can be delayed
Many version control tools (e.g. TFS) can prevent developers from checking in code which does not compile or pass unit or code analysis tests.
I don't think breaking the build is necessarily a bad thing, as long as there is a well-known, working branch or tag in the repository. That said, make your own branch in the repository if you know your code is going the break the build today, but you will fix it next week. Then later you can merge back into trunk.
Breaking the build means that you committed code to a shared repository that either (a) does not compile, or (b) does not work (fails unit tests). Anyone else who's developing from that shared repository is going to have to deal with the broken code you committed until it is fixed. That will cause a loss of productivity for the entire team.
发布评论
评论（11）
在将“破坏构建”标记为坏事时要非常小心。这是需要立即关注的事情，但它也是开发周期中非常正常和预期的一部分。这就是持续集成如此有用的原因——它会立即告诉您构建何时被破坏，以及哪些更改集导致了它。它可以帮助您快速回到正轨。
如果你的文化惩罚“破坏构建”，那么你就面临着形成有毒工作环境的危险。再次强调，将其视为需要立即关注的事情，但不要将其标记为“坏”。
Be very careful in labeling "Breaking the Build" as a bad thing. It is something that needs immediate attention, but it is also a very normal and expected part of the development cycle. This is why Continuous Integration is so useful -- it tells you immediately when the build is broken, and what change set caused it. It helps you get back on track quickly.
If your culture penalizes "Breaking the Build", then you are in danger of cultivating a toxic work environment. Again, consider it to be something that needs immediate attention, but don't label it as "bad".
因为如果其他人检查了您的损坏的更改，他们将无法工作，或者即使他们这样做，效率也会降低。
这也意味着您在提交之前没有正确测试您的更改，而这在 CI 中是关键。
Because if other people check out your broken changes, they won't be able to work, or if they do they will do so less efficiently.
It also means you're not properly testing your changes before you commit, which is key in CI.
来自 Martin Fowler http://martinfowler.com/articles/continuousIntegration.html
From Martin Fowler http://martinfowler.com/articles/continuousIntegration.html
因为如果其他人检查了更改，他们将无法工作......
该图片的版权归 Geek &根据知识共享许可
Because if other people checkout the changes, they won´t be able to work...
This image is copyrighted to Geek & Poke under a Creative Commons License
如果你破坏了构建，就像我昨天发生的那样。当您的队友尝试使用源代码时。它不会构建。因此，他们将努力测试他们正在做的工作。你的团队越大，情况就会变得更糟。
It you break the build as has happend to me yesterday. When your team-mates try and use the sourcecode. It will not build. Therfore they will struggle to test the work that they are doing. It get worse the bigger your team.
当然，持续集成的重点是尽早发现问题。需要每天或更频繁地进行检查，以将冲突减少到可管理的范围内。
您应该获取存储库的最新副本并在本地构建。这将告诉您建议的签入是否会破坏构建。您解决所有问题，然后签入。
通过这种方式，集成问题可以保留在本地并且易于修复。
Surely the whole point of continuous integration is to identify problems early. Daily or more frequent check ins are required to reduce conflicts to a manageable size.
You should get an up to date copy of the repository and build locally. This will tell you if your proposed check in will break the build. You resolve any issues and then check in.
In this way the integration issues are kept local and easy to fix.
破坏构建会对项目进度（以及团队成员的血压）产生可怕的影响
=>然后获得最新版本的其他开发人员无法再构建自己的更改，从而延迟了它们
=>持续集成将会中断，这意味着正式测试可能会被延迟。
许多版本控制工具（例如 TFS）可以阻止开发人员签入未编译或通过单元或代码分析测试的代码。
Breaking the build has dire implications for the project schedule (and the blood pressure of team-mates)
=> Other developers who then get latest version can no longer build there own changes, delaying them
=> Continuous integration will break, meaning that formal testing can be delayed
Many version control tools (e.g. TFS) can prevent developers from checking in code which does not compile or pass unit or code analysis tests.
一旦构建开始崩溃，人们就不愿意获得最新的更改，并且您开始走向大爆炸集成更改的致命螺旋。
Once builds start breaking, people get reluctant to get the latest changes, and you begin the deadly spiral towards Big Bang integration of changes.
我认为破坏构建不一定是坏事，只要存储库中有一个众所周知的工作分支或标签即可。也就是说，如果您知道您的代码今天会破坏构建，请在存储库中创建您自己的分支，但您将在下周修复它。然后你可以合并回主干。
I don't think breaking the build is necessarily a bad thing, as long as there is a well-known, working branch or tag in the repository. That said, make your own branch in the repository if you know your code is going the break the build today, but you will fix it next week. Then later you can merge back into trunk.
因为这意味着有人做了坏事（或者至少某些更改发生了冲突），并且您无法再构建和部署系统。
Because it means someone has done something bad (or at least, some changes have clashed) and you can no longer build and deploy your system.
破坏构建意味着您将代码提交到共享存储库，该存储库要么 (a) 无法编译，要么 (b) 无法工作（单元测试失败）。从该共享存储库进行开发的任何其他人都必须处理您提交的损坏的代码，直到它被修复。这将导致整个团队的生产力下降。
Breaking the build means that you committed code to a shared repository that either (a) does not compile, or (b) does not work (fails unit tests). Anyone else who's developing from that shared repository is going to have to deal with the broken code you committed until it is fixed. That will cause a loss of productivity for the entire team.