反对使用持续集成的理由有哪些？
我可以想出很多使用它的充分理由； 然而，它有什么缺点呢？
（除了购买另一台服务器）
使用每日构建代替它有哪些优点？
I can think of plenty of good reasons to using it; however, what are the downsides to it?
(Apart from buying another server)
What are some advantages to using a daily build instead of it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
（值得注意的是，“持续集成”是指与自动构建过程的自动集成，并且自动运行测试并自动< /strong> 检测每个部分的故障。
还值得注意的是，“持续集成”仅意味着主干或测试服务器，并不意味着“实时推送每个更改”。
）
我想不出有什么理由不进行持续集成测试。 我想我假设“持续集成”包括测试。 仅仅因为它可以编译并不意味着它可以工作。
如果您的构建和/或测试需要很长时间，那么持续集成可能会变得昂贵。 在这种情况下，请在提交之前运行与您的更改明显相关的测试（覆盖率分析工具，例如 Devel::CoverX::Covered 可以帮助发现哪些测试与哪些代码相匹配），在提交后使用类似 SVN::Notify，如果失败则提醒开发者。 使用诸如 Smolder 之类的工具存档测试结果。 这使得开发人员能够快速工作，而不必坐下来观看测试套件的运行，同时仍能及早发现错误。
也就是说，只需做一些工作，您通常就可以加快构建和测试过程。 很多时候，缓慢的测试是由于每次测试都必须进行太多的设置和拆卸，导致系统耦合性太强，需要设置整个系统来测试一小部分。
解耦通常会有所帮助，将子系统分解为独立的项目。 较小的范围更容易理解并更快地构建和测试。 每次提交都可以进行完整的构建和测试，而不会给程序员带来不便。 然后可以将所有子项目收集在一起进行集成测试。
在每次提交时运行测试套件的主要优点之一（即使是在提交之后）是您知道是什么破坏了构建。 不是“我们昨天做的某件事破坏了构建”，或者更糟糕的是“我们昨天做的四件事以不同的方式破坏了构建，现在我们必须解开它”，而是“修订版 1234 破坏了构建”。 您只需检查该修订版即可发现问题。
进行每日构建的优点是至少您知道每天都会进行完整、干净的构建和测试运行。 但无论如何你都应该这样做。
(It's worth noting that by "continuous integration" I mean automated integration with an automated build process and automatically runs tests and automatically detects failure of each piece.
It's also worth noting that "continuous integration" just means to a trunk or test server. It does not mean "push every change live".
There are plenty of ways to do continuous integration wrong.)
I can't think of any reason not to do continuous integration testing. I guess I'm assuming that "continuous integration" includes testing. Just because it compiles doesn't mean it works.
If your build and/or tests take a long time then continuous integration can get expensive. In that case, run the tests obviously related to your change before the commit (coverage analysis tools, like Devel::CoverX::Covered can help discover what tests go with what code), do your integration testing after the commit using something like SVN::Notify, and alert the developers if it fails. Archive the test results using something like Smolder. That allows developers to work quickly without having to sit around watching test suites run, while still catching mistakes early.
That said, with a little work you can often you can speed up your build and test process. Many times slow tests are the result of each test having to do too much setup and teardown pointing at a system that's far too coupled requiring the whole system to be setup just to test a small piece.
Decoupling often helps, breaking out sub-systems into independent projects. The smaller scope makes for easier understanding and faster builds and tests. Each commit can do a full build and test without inconveniencing the programmer. Then all the sub-projects can be collected together to do integration testing.
One of the major advantages of running the test suite on every commit, even if it's after the commit, is you know just what broke the build. Rather than "something we did yesterday broke the build", or worse "four things we did yesterday broke the build in different ways and now we have to untangle it" it's "revision 1234 broke the build". You only have to examine that one revision to find the problem.
The advantage of doing a daily build is that at least you know there's a complete, clean build and test run happening every day. But you should be doing that anyway.
我认为它没有任何缺点。 但为了论证，这里是 Eric Minick 的文章关于 UrbanCode （“这是关于测试而不是构建。” 他批评基于 Martin Fowler 的作品 表示他们没有留出足够的时间进行测试。
“为了在 CI 领域取得真正的成功，Fowler 断言构建应该是自测试的，并且这些测试包括单元测试和端到端测试。同时，构建应该非常快 - 理想情况下更少不到十分钟 - 因为它应该在每次提交时运行，如果有大量的端到端测试，那么在构建时执行它们同时将整个过程保持在十分钟以内是不现实的。
再加上每次提交都需要构建的需求，这些需求开始让人感觉不太可能。 选项要么是更慢的反馈，要么是删除一些测试。”
I don't think there are any downsides to it. But for the sake of the argument, here is Eric Minick's article on UrbanCode ("It's about tests not builds.") He criticises the tools that are based on Martin Fowler's work saying that they don't let enough time for tests.
"To be truly successful in CI, Fowler asserts that the build should be self-testing and that these tests include both unit and end-to-end testing. At the same time, the build should be very fast - ideally less than ten minutes - because it should run on every commit. If there are a significant number of end-to-end tests, executing them at build time while keeping the whole process under ten minutes is unrealistic.
Add in the demand for a build on every commit, and the requirements start to feel improbable. The options are either slower feedback or the removal of some tests."
James Shore 有一系列精彩的博客文章，讨论了认为使用像 CruiseControl 这样的 CI 工具意味着进行持续集成的危险：
设置 CI 服务器的一个危险是目标偏移，认为重要的是“保持构建通过”而不是“确保我们拥有高质量的软件” ”。 因此人们不再关心测试需要多长时间运行。 然后他们在签入之前需要很长时间才能运行所有这些程序。 然后构建不断中断。 然后构建总是被破坏。 因此人们注释掉测试以使构建通过。 软件的质量下降了，但是嘿，构建正在通过......
James Shore had a great series of blog entries on the dangers of thinking that using a CI tool like CruiseControl meant you were doing continuous integration:
One danger of setting up a CI server is goal displacement, thinking that the important thing is to "keep the build passing" as opposed to "ensuring we have high quality software". So people stop caring about how long the tests take to run. Then they take too long to run all of them before checkin. Then the build keeps breaking. Then the build is always broken. So people comment out the tests to make the build pass. And the quality of the software goes down, but hey, the build is passing...
我发现持续集成通常在两种情况下没有真正意义。 请记住，我是 CI 的大力倡导者，并尽可能尝试使用它。
第一个是当投资回报率没有意义时。 我目前开发了几个小型内部应用程序。 应用程序通常非常琐碎，整个开发生命周期约为一两周。 正确设置 CI 的所有内容可能会加倍，而且我可能再也看不到这笔投资了。 你可以说我会在维护中将其恢复，但这些应用程序很可能在更新时被丢弃。 请记住，您的工作可能是交付软件，而不是达到 100% 的代码覆盖率。
我听说过的另一种情况是，如果您不打算对结果做任何事情，那么 CI 就没有意义。 例如，如果您的软件必须发送给 QA，并且 QA 人员只能每隔几天查看一个新版本，那么每隔几个小时进行一次构建是没有意义的。 如果其他开发人员不打算查看代码指标并尝试改进它们，那么跟踪它们就没有意义。 当然，这并不是 CI 不是一项好技术的错，而是你的团队缺乏愿意拥抱 CI 的原因。 然而，在这种情况下实施 CI 系统是没有意义的。
There are generally two cases where I've seen continuous integration not really make sense. Keep in mind I am a big advocate of CI and try to use it when I can.
The first one is when the roi just doesn't make sense. I currently develop several small internal apps. The applications are normally very trivial and the whole lifecycle of the development is about a week or two. To properly setup everything for CI would probably double that and I probably would never see that investment back again. You can argue that I'll get it back in maintenance, but these apps are as likely to be discarded as they are updated. Keep in mind that your job is probably to ship software, not reach 100% code coverage.
The other scenario that I have heard mentioned is that CI doesn't make sense if you're not going to do anything with the results. For example, if your software has to be sent to QA, and the QA staff can only really look at a new version every couple of days, it makes no sense to have builds every few hours. If other developers aren't going to look at code metrics and try to improve them, it makes no sense to track them. Granted this is not the fault of CI not being a good technique, it is a lack of your team willing to embrace CI. Nevertheless, implementing a CI system in such a scenario doesn't make sense.
开始时，需要一段时间来设置所有内容。
如果添加测试、覆盖率、静态代码检查、重复搜索、文档构建和部署，可能需要很长时间（数周）才能正确完成。 之后，维护构建可能会成为问题。
例如，如果您向解决方案添加测试，您可以让构建根据某些条件自动检测它们，或者您必须手动更新构建设置。 正确进行自动检测要困难得多。 覆盖范围相同。 与文档生成相同...
When starting, it takes a while to set everything up.
If you add tests, coverage, static code inspections, duplicate search, documentation build and deploys, it can take a long time (weeks) to get it right. After that, maintaining the build can be a problem.
e.g, if you add tests to solution, you can have the build detect them automatically based on some criteria or you have to manualy update build settings. Auto detection is much harder to get right. Same for coverage. Same of documentation generation...
不进行持续集成的唯一充分理由是，当您的项目运行到集成测试在很长一段时间内没有发现任何缺陷并且每次执行时都花费太多时间来运行时一个构建。 换句话说：您已经做了足够多的持续集成，您已经向自己证明您不再需要它。
The only good reason not to do continuous integration comes when you've gotten your project working to the point where your integration tests hadn't identified any defect in a good long while and they're taking too much time to run every time you do a build. In other words: you've done enough continuous integration that you've proven to yourself that you no longer need it.