对于小型项目来说,持续集成是否值得?

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

我不认为人们会为他们的每一个提交运行每一个测试,持续集成在这里帮助很大。

另一个原因是如果您的项目是高度模块化的。我在系统中工作过,那里有很多模块,开发人员在提交之前不会对整个网站进行功能测试。因为开发人员没有签出完整的代码,所以其他模块甚至无法构建,所以可能无法正确编译。

无论如何,我建议持续集成。使用Hudson和CruiseControl这样的设置,不需要花费太多时间来设置,并且很快就为自己支付了费用。

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

持续集成不仅是一个工具问题,而且是一组过程(定期提交,有一个版本控制系统…)。

关于I.C软件,您可以安装、配置和开始使用 Hudson 不到10分钟!那你为什么不带集成电路系统呢?

这真的取决于你能以多快的速度建立一个自动构建,然后把它连接到一个CI服务器上。

.NET

我见过我们在几分钟内使用大写字母从没有自动构建到一个项目的自动构建。我们使用它和CruiseControl.net(在配置中,我们为每个项目添加一行b/c,利用预处理器)。

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

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

如果您的许多应用程序共享任何公共组件或模块,那么CI和测试可能会帮助您注意到一些破坏。如果这些脚本真的都是一些自包含的脚本,那么您可能不需要CI,但这是一个艰难的过程。

正如其他人所指出的,一旦设置了CI,那么添加一个新项目就很简单了,所以我想说,开始吧。你将看到的一个好处是如果你的项目 做 一旦改变,你已经有了CI,希望你的单元测试准备好了,这样你就不会得到任何令人不快的惊喜!

持续集成不仅确保了东西的工作,还允许您像新开发人员那样记录和测试发布过程。

这样可以确保客户得到已经测试过的内容,而不是开发人员从硬盘中收集到的内容。

这对于维护来说可能非常重要。