CI 对于高度模块化项目的好处
由于我们的项目有些分散，关于放弃我们的 CI 系统（Hudson FWIW）存在一些讨论。无需透露太多，您可以将每个项目视为类似于网站项目：它具有依赖项、自己的单元测试等。CI
的主要好处之一似乎是确保项目的每个组件可以一起工作，但除了项目继承之外，我们的大多数项目都是独立的，并且单元测试得相当好。
鉴于我在这里所解释的（我们项目组织中的奇怪之处）；谁能解释一下 CI 对于分段\模块化\许多项目的好处？
据我所知，这是我发现的唯一好的理由：
“错误也是累积的。错误越多，消除每一个错误就越困难。部分原因是您会遇到错误交互，其中故障显示为多个错误的结果 - 使得每个错误更难找到。这也是心理上的——当错误很多时，人们就没有那么多精力去发现和消除错误——务实的程序员将这种现象称为“破窗综合症”。
从这里：http://martinfowler.com/articles/continuousIntegration.html#BenefitsOfContinouslyIntegration
There has been some discussion in abandoning our CI system (Hudson FWIW) due to the fact that our projects are somewhat segmented. Without revealing too much, you can think of each project as similar to a web site project: it has dependencies, its own unit tests, etc.
It seems like one of the major benefits of CI is to make sure that each component of a project works together, but aside from project inheritance most of our projects are standalone and unit tested fairly well.
Given what I have explained here (the oddity in our project organization); can anyone explain any benefits of CI for segmented\modular\many projects?
So far as I can tell, this is the only good reason I've found:
“Bugs are also cumulative. The more bugs you have, the harder it is to remove each one. This is partly because you get bug interactions, where failures show as the result of multiple faults - making each fault harder to find. It's also psychological - people have less energy to find and get rid of bugs when there are many of them - a phenomenon that the Pragmatic Programmers call the Broken Windows syndrome.”
From here: http://martinfowler.com/articles/continuousIntegration.html#BenefitsOfContinuousIntegration
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我会使用 Hudson 的原因如下：
如果项目数量稳步增加，您会发现需要能够有效地管理每个项目，特别是考虑到上述这样做的原因。
I would use Hudson for the following reasons:
If the number of projects steadily increases, you will find the need to be able to manage each one effectively, especially considering the above reasons for doing so.
在您的情况下，您可以（至少）通过以下两种方式从 CI 中受益：
您可以让 CI 服务器在每次 subversion/... 签入后自动运行某些较大的测试套件。尤其是那些测试不同模块交互的测试，因此称为连续集成。这消除了开发商在考虑入住时的维护工作和等待时间。某些 CI（例如 Hudson）还可以配置为在构建依赖模块时自动构建模块。通过这种方式，您可以让它自动测试依赖的模块是否与更改后的新版本兼容。
您可以让 CI 服务器将新工件发布到依赖项解析器（例如 Ivy、Maven）的存储库。这样，各个模块就可以自动下载它们所依赖的模块的最新（稳定）版本。将这一点与前一点结合起来，想象一下可能性（!!!）。
In your situation, you can benefit from CI in (at least) these two ways:
You can let the CI server run certain larger test suites automatically after each subversion/... check-in. Especially those which test the interaction of different modules, hence the name continuous integration. This takes away the maintenance work and waiting time from the developers when they consider a check-in. Some CI (e.g. Hudson) also can be configured to automatically build modules when a depending module is build. This way you can let it automatically test if depending modules are compatible with the new version of the changed one.
You can let the CI server publish the new artifacts to the repository of a dependency resolver (e.g., Ivy, Maven). This way, the various modules can automatically download the latest (stable) revisions of the modules they depend on. Combine this point with the previous one and imagine the possibilities (!!!).