对于小型项目来说持续集成值得吗？
自从 5 个月前加入公司以来，我一直在推动公司的持续集成，但是在看到我们正在开发的应用程序类型后，我开始认为，为每个项目设置一个项目可能不值得。持续集成。
如果您在开发部门工作，项目平均需要 2-3 周的时间，并且一旦部署，您就很少担心它，那么持续集成是否值得为设置它而烦恼？
I've been pushing for continuous integration at my company since I joined 5 months ago, but having seen the type of applications we work on I'm starting to think that it might not be worth the effort of setting up each and every project for continuous integration.
If you work in a development department where the average project takes 2-3 weeks and once it's deployed you seldom if ever have to worry about it, is continuous integration worth the hassle of setting it up?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
可能取决于你的流程。 如果您的单元测试涵盖了您的代码，那么持续集成是值得的。 我假设你们都从事单一工作模块，因为项目需要 2-3 周。
我认为人们不会为每一项提交运行每一项测试，持续集成在这里有很大帮助。
另一个原因是您的项目是否高度模块化。 我曾经在有很多模块的系统中工作过，开发人员在提交之前不会对整个网站进行功能测试。 事情甚至可能无法正确编译，因为其他模块甚至无法构建，因为开发人员没有签出完整的代码。
无论如何，我建议持续集成。 借助 Hudson 和 Cruisecontrol 等设置，无需花费大量时间即可设置并快速收回成本。
Probably depends on your process. If you have unit tests that cover your code, then continuous integration is worth every bit. I'm assuming that you guys all work on a single module of work as the projects are 2-3 weeks.
I don't think folks will run every test for every one of their commits and continuous integration helps a lot here.
The other reason would be if your project is highly modularized. I've worked in systems where there are lots of modules and a developer wouldn't be functional-testing the entire website before committing. Things might not even compile properly as the other module wouldn't even build because the developer did not checkout the complete code.
I'd recommend continuous integration anyway. With setups like Hudson and Cruisecontrol, it doesn't take a lot of time to set up and pays for itself quickly.
就我个人而言，我认为 CI 及其鼓励的各种流程总是有用的。 一旦服务器自行设置完毕，CI 设置就变得相当简单了。 您基本上只是从一个项目复制配置文件，对其进行编辑，然后创建一个新项目。 我不会因为“建立每个项目的努力”而不使用 CI。
Personally, I think CI and the various processes it encourages are always useful. Getting CI setup is rather trivial once you have the server set up itself. You're basically just copying a configuration file from one project, editing it, and creating a new project. I wouldn't not use CI because of the "effort of setting up each and every project".
持续集成不仅是一个工具问题，而且是一套流程（定期提交、拥有版本控制系统......）。
关于 IC 软件，您可以在 10 分钟内安装、配置并开始使用 Hudson！ 那么为什么不使用任何 IC 系统呢？
Continuous Integration is not only a tool matter, but also a set processes (commit regularly, have a version control system...).
Concerning the I.C software, you can install, configure and start to use Hudson in less than 10 minutes! So why would you go without any IC system?
这实际上取决于您设置自动构建然后将其连接到 CI 服务器的速度。
.NET
我已经看到我们使用 UppercuT 在几分钟内从不自动构建项目到自动构建项目。 我们使用它和 CruiseControl.NET（在配置中，我们为每个项目添加一行，因为我们利用了预处理器）。
http://code.google.com/p/uppercut/
这里有一些很好的解释： UppercuT
It really depends on how fast you can set up an automated build and then get that hooked up to a CI server.
.NET
I've seen us go from no automated build to an automated build for a project in a few minutes using UppercuT. We use that and CruiseControl.NET (in the configuration, we add a line per project b/c we take advantage of the preprocessor).
http://code.google.com/p/uppercut/
Some good explanations here: UppercuT
如果您的许多应用程序共享任何通用组件或模块，CI 和测试可能会帮助您发现某些问题。 如果它们真的都是一次性的、独立的脚本，那么您可能不需要 CI，但这是一个艰难的决定。
If your many apps share any common components or modules, CI and tests will likely help you notice something breaking. If they are really all little throw away, self contained scripts then you might not need CI, but it's a tough call.
正如其他人所指出的，一旦设置了 CI，那么添加一个新项目就很简单了，所以我会说继续吧。 您将看到的一个好处是，如果您的任何项目确实发生了变化，那么您已经获得了 CI，并且希望您的单元测试已准备就绪，这样您就不会遇到任何令人讨厌的意外！
As others have pointed out, once CI is setup then adding a new project is trivial so I'd say go for it. One benefit you're going to see is that if any of your projects do ever change you've already got CI and hopefully your unit tests ready to go so you won't get any nasty surprises!
持续集成不仅确保工作顺利进行，还允许您记录和测试发布过程，就像新开发人员完成的那样。
这可以确保客户获得经过测试的内容，而不是开发人员从硬盘中拼凑出来的内容。
这对于维护目的可能极其重要。
Continous Integration is not only ensuring stuff works, it also allows you to DOCUMENT and TEST the release process as it would be done by a new developer.
This ensures that the customer gets what has been tested, not what the developer just throws together from his harddisk.
This may be extremely important for maintainance purposes.