持续集成对单独开发者重要吗？

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

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

第二-谁应该使用CI？它对所有开发人员都有利吗？

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

好处是您立即知道有人破坏了构建。
这意味着：

一。他们提交了阻止编译的代码，这会使任何人搞砸

乙。他们提交的代码破坏了一些测试，这意味着他们引入了需要修复的错误，或者需要更新测试以反映代码中的更改。

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

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

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

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

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

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

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

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

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

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

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

我们使用CI系统进行发布版本（以及通常的自动“提交”版本）。

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

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

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

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