持续整合对于独奏开发者来说是否重要？
我以前从来没有使用CI工具，但是从我读过的内容来看，我不确定它会为每天不写代码的独立开发人员提供什么好处。
首先 – CI为任何项目提供什么好处？
其次 – 谁应该使用CI？ 是否有利于所有的开发者？
CI的基本概念是，您有一个构build代码的系统，并在每次有人提交版本控制系统时运行自动化testing。 这些testing将包括单元和functiontesting，甚至包括行为驱动的testing。
好处是，你知道 – 立即 – 当有人打破了构build。 这意味着要么A）他们提交的代码阻止编译，这将使任何一个谁做了“更新”，或B）他们提交的代码打破了一些testing，这意味着他们引入了一个错误，需要修复，或者testing需要更新以反映代码的变化。
如果你是一个独立的开发者，如果你在一个提交之前运行你的testing的好习惯，那么CI就不是那么有用，这就是你应该做的。 这就是说，你可能养成一个不好的习惯，让CI为你做testing。
作为独奏程序员，主要归结于纪律。 使用CI是一种有用的技能，但是您希望避免形成任何不能转化为团队环境的坏习惯。
正如其他人所指出的那样，CI对于独奏开发者来说确实有优势。 但是你必须问自己的问题是， 这是值得的开销？ 如果你和我一样，可能需要一两个小时才能build立一个项目的CI系统，只是因为我必须分配一个服务器，build立所有的networking，并安装软件。 请记住，CI系统一次只能节省您几秒钟的时间。 对于一个独立的开发者来说，这些时间不可能超过CI设置的时间。
但是，如果你以前从未设置CI系统，我build议只是为了学习如何去做。 不需要太长的时间，这是不值得的学习经验。
CI的好处在于能够在签入时打破构build的早期发现。 您也可以针对构build运行您的一套自动化testing，并运行任何types的工具为您提供指标等。
很明显，当你有一个团队的时候，这个团队是非常有价值的，并不是所有的人都在努力去检查变化。 作为一个独立的开发者，这不是很有价值。 据推测，你运行你的unit testing，甚至可能是集成testing。 不过，我曾经在很多场合看到开发者忘记从一个集合中签出一个文件。
CI构build也可以被认为是你的“发布”构build。 环境应该是稳定的，不受任何你刚添加到你的机器上的开发技术的影响。 它应该允许你总是重现一个构build。 如果您向项目添加新的依赖项，并且忘记设置发布版本环境以将其考虑在内，这可能很有价值。
如果您需要支持多个编译器，那么只需在一个IDE中开发一个CI编译系统即可完成所有这些工作。 我的代码使用Vc6通过VS2008在x86和x64上构build，在VS2005＆8上构build，所以每个项目configuration每个项目有7个构build…具有CI系统意味着我可以在一个IDE中开发，让CI系统certificate我支持的编译器仍然在构build。
同样，如果您正在构build多个项目使用的库，那么CI将确保它们与所有项目一起工作，而不仅仅是您正在使用的那个项目。
事实是，持续的整合对于团队来说是最有意义的。 单个开发者也可以获得一些优势，你必须决定自己是否足以抵消你投入设置CI系统的时间。
- 如果您忘记签入一些需要的文件，则存储库中将包含损坏的版本，即使它在您的机器上运行。 CI会检测到这种情况。
- 如果您的CI服务器运行在不同的机器上，它可以指示您的构build环境的依赖关系。 手段，构build和所有的testing可以在你的开箱，但在另一台机器上的一些依赖没有履行，构build中断。
- 每日构build可以表明，您的较旧的软件不能与最新的操作系统/编译器/库升级…
- 如果您的CI系统具有构build工件的存档，则可以轻松获得旧版本软件的分发。
- 一些CI有一个很好的界面来显示你的构build指标，有自动生成的文档和类似的东西的链接。
我们使用我们的CI系统来执行发布版本（以及通常的自动“提交”构build）。
能够点击一个button，启动一个Release版本，通过所有进程来释放一个设置：
- 快（我可以直接与其他东西，它运行在一个单独的机器，所以它不会放缓我）;
- 重复的（它不会忘记任何东西，包括将设置复制到发布文件夹并通知所有需要知道的人）
- 可靠（没有错误，不像人类！）。
在一个敏捷的环境中，你希望每2-4周就能提供一个工作软件，即使在一个1人的团队中，这也是值得的。
CI对于独立开发者是有益的，因为你意识到如果你忘记检查某些内容（因为构build将被打破）。 但是，没有其他开发者的时候，它的整合价值就会降低。
