我以前从未使用过CI工具，但是从我读过的内容来看，我不确定它是否会对每天都不编写代码的单独开发人员带来任何好处。

首先，CI可为任何项目带来什么好处？

其次谁应该使用CI？它对所有开发人员都有利吗？

解决方案

CI的优势在于能够在签入破坏了构建的情况下及早发现。我们还可以针对该版本运行一套自动化测试，以及运行任何类型的工具来提供指标等。

显然，当我们有一个提交者团队时，这并不是很有价值，因为不是所有的提交者都勤于检查重大更改。作为一个单独的开发人员，它并不那么有价值。据推测，我们可以运行单元测试，甚至可以运行集成测试。但是，我见过很多情况，开发人员忘记从文件集中检入文件。

CI构建也可以视为"发布"构建。环境应该是稳定的，并且不受刚刚添加到计算机中的任何开发gizmo的影响。它应该允许我们始终复制构建。
如果我们在项目中添加了新的依赖项，而忘记设置发行版构建环境以考虑到这一点，那么这可能很有价值。

如果我们忘记签入某些内容(因为该版本将被破坏)，则CI可以从一个单独的开发人员中受益。但是，当没有其他开发人员时，它的集成价值将降低。

CI的基本概念是，我们拥有一个可以在每次有人提交版本控制系统时构建代码并运行自动测试的系统。这些测试将包括单元和功能测试，甚至是行为驱动的测试。

好处是我们可以立即知道有人破坏了构建。这意味着A)他们提交了阻止编译的代码，这会搞砸任何执行"更新"的人，或者B)他们提交了破坏某些测试的代码，这意味着他们引入了需要修复的错误，或者测试需要进行更新以反映代码中的更改。

如果我们是一个单独的开发人员，那么如果我们习惯于在提交之前运行测试(这是我们应该做的)的良好习惯，则CI不会那么有用。话虽如此，我们可能养成让CI为我们进行测试的不良习惯。

作为一个单独的程序员，它主要归结为纪律。使用CI是一项有用的技能，但是我们要避免养成不会转化为团队环境的不良习惯。

事实是，在团队中持续集成最有意义。单一开发人员也可以获得一些优势，我们必须自行决定是否足以抵消我们花费时间建立CI系统的时间。

• 如果我们忘记签入某些需要的文件，则该存储库包含一个损坏的版本，即使它在计算机上也可以运行。 CI会检测到这种情况。
• 如果CI服务器在另一台计算机上运行，​​则它可以指示对构建环境的依赖性。意思是，构建和所有测试都可以在dev-box上运行，但是在另一台机器上，某些依赖关系无法满足，构建中断。
• 每日构建可能表明旧软件无法与OS /编译器/库的最新升级配合使用...
• 如果CI系统具有构建工件的存档，则可以轻松获取旧版本软件的分发。
• 某些配置项具有一个不错的界面，可向我们显示有关构建的指标，并具有指向自动生成的文档之类的链接。

如果我们需要支持多个编译器，那么只需在一个IDE中进行开发，便拥有一个CI构建系统即可完成所有这些工作。我的代码是使用Vc6到VS2008在x86上构建的，而x64是在VS2005＆8上构建的，因此每个项目配置的每个项目是7个构建...拥有CI系统意味着我可以在一个IDE中进行开发，并让CI系统证明所有我支持的编译器仍在构建。

同样，如果我们要构建供多个项目使用的库，则CI将确保它们可与所有项目一起使用，而不是仅与我们正在使用的项目一起使用...

我们使用CI系统进行发布版本(以及通常的自动"提交"版本)。

能够单击启动"发布"构建的按钮，该发布逐步完成所有过程以发布安装程序：

• 快速(我可以继续处理其他事情，并且它在单独的计算机上运行，​​因此不会降低我的速度)；
• 重复的(它不会忘记任何内容，包括将设置复制到发布文件夹并通知需要了解的所有人)
• 可靠(没有错误，不像人类！)。

在敏捷的环境中，我们希望每2-4周交付一次工作软件，即使是1人一组，这绝对是值得的。

正如其他人所指出的，CI对于单独开发人员确实具有优势。但是，我们必须问自己的问题是：值得开销吗？如果我们像我一样，可能需要一两个小时才能为一个项目设置一个CI系统，因为我将不得不分配服务器，建立所有网络并安装软件。请记住，CI系统一次只能为我们节省几秒钟。对于单独的开发人员来说，这些时间加起来可能不会超过完成CI设置所花费的时间。

但是，如果我们以前从未设置过CI系统，建议我们只是为了学习如何使用它而建议这样做。花费的时间不长，因此不值得学习。