小型项目的持续整合是否值得？

Question

自从我5个月前加入以来，我一直在推动我公司的持续集成，但是看到我们工作的应用程序类型后，我开始认为可能不值得设置每个和每个持续整合的项目。

如果你在一个平均项目需要2-3周的开发部门工作，一旦部署你很少担心它，那么持续整合值得设置它的麻烦吗？

Answer 1

可能取决于您的流程。如果你有单元测试覆盖你的代码，那么持续集成是值得的。我假设你们都在单个工作模块上工作，因为项目是2-3个星期。

我不认为大家会为他们的每一个提交运行每个测试，并且持续集成在这里有很多帮助。

另一个原因是你的项目是高度模块化的。我曾经在有很多模块的系统中工作过，开发人员在提交之前不会对整个网站进行功能测试。事情甚至可能无法正常编译，因为其他模块甚至无法构建，因为开发人员没有检查完整的代码。

无论如何，我建议持续集成。使用像Hudson和Cruisecontrol这样的设置，它不需要花费很多时间来快速设置和支付。

Answer 2

就个人而言，我认为CI及其鼓励的各种流程总是有用的。一旦您自己设置了服务器，获取CI设置就相当简单了。您基本上只是从一个项目复制配置文件，编辑它，以及创建一个新项目。我不会因为“设置每个项目的努力”而使用CI。

Answer 3

持续集成不仅是一个工具问题，也是一个集合流程（定期提交，有一个版本控制系统......）。

关于I.C软件，您可以在不到10分钟的时间内安装，配置并开始使用Hudson！那你为什么没有任何IC系统呢？

Answer 4

这实际上取决于您设置自动构建的速度，然后将其连接到CI服务器。

<强> .NET

我看到我们使用UppercuT在几分钟内从无自动构建转变为项目的自动构建。我们使用它和CruiseControl.NET（在配置中，我们为每个项目添加一行b / c，我们利用预处理器）。

http://code.google.com/p/uppercut/

这里有一些很好的解释：UppercuT

Answer 5

如果您的许多应用程序共享任何通用组件或模块，CI和测试可能会帮助您发现有问题。如果他们真的都扔掉了，自包含的脚本那么你可能不需要CI，但这是一个艰难的电话。

Answer 6

正如其他人所指出的那样，一旦设置了CI，那么添加一个新项目是微不足道的，所以我会说去吧。您将看到的一个好处是，如果您的任何项目做有所改变，您已经获得了CI，并且希望您的单元测试准备就绪，这样您就不会有任何令人讨厌的惊喜！ / p>

Answer 7

持续集成不仅可以确保工作正常，而且还可以让您按照新开发人员的方式进行文档和测试发布过程。

这可以确保客户获得经过测试的内容，而不是开发人员从硬盘中获取的内容。

这对于维护目的而言可能非常重要。