持续集成对于一个独立开发人员来说很重要吗?

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

好处是,当有人破坏了建筑时,你马上就会知道。这意味着要么a)他们提交了阻止编译的代码,这会搞砸任何进行“更新”的人,要么b)他们提交了破坏某些测试的代码,这要么意味着他们引入了需要修复的错误,要么需要更新测试以反映代码的更改。

如果你是独立开发人员,那么CI不是 相当地 如果你有在提交之前运行测试的好习惯,这是很有用的,这就是你 应该 正在做。也就是说,你可能会养成一个让CI为你做测试的坏习惯。

作为一个独立的程序员,它主要归结为纪律。使用CI是一项很有用的技能,但是您希望避免养成任何不能转化为团队环境的坏习惯。

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

但是,如果您以前从未设置过CI系统,我建议您这样做只是为了学习如何设置。花不了多长时间就不值得学习了。

CI的好处在于能够在签入破坏了构建时及早发现。您还可以针对构建运行您的自动化测试套件,以及运行任何类型的工具来为您提供度量标准等。

显然,当您有一个委员会团队时,这是非常有价值的,不是所有人都会努力检查破坏性的变更。作为一个独立开发人员,它并没有那么有价值。大概,您运行单元测试,甚至可能运行集成测试。但是,我看到过许多这样的情况:开发人员忘记从集合中签入文件。

CI构建也可以被认为是您的“发布”构建。环境应该是稳定的,不受您刚添加到机器上的任何开发小发明的影响。它应该允许您始终复制一个构建。 如果您向项目添加新的依赖项,并且忘记设置发布构建环境来考虑这一点,那么这将是非常有价值的。

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

同样,如果您正在构建由多个项目使用的lib,那么CI将确保它们与所有项目一起工作,而不仅仅是您现在正在处理的项目……

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

• 如果忘记签入某些所需的文件,则存储库包含一个损坏的版本,即使它在您的计算机上工作。CI会发现这个情况。
• 如果您的CI服务器运行在另一台计算机上,它可以指示对构建环境的依赖性。也就是说,构建和所有测试都可以在您的开发盒上工作,但是在另一台机器上,一些依赖性没有得到满足,构建就中断了。
• 每日的构建可以表明,旧的软件不适用于最新升级的操作系统/编译器/库…
• 如果您的CI系统具有构建工件的存档,那么您可以轻松地获得软件的旧版本的分发。
• 一些CI有一个很好的界面,可以向您显示有关构建的度量,有指向自动生成文档的链接,以及类似的东西。

我们使用我们的CI系统进行发布构建(以及通常的自动“提交”构建)。

可以单击一个按钮来启动一个版本构建,该版本构建逐步通过所有流程来发布一个设置,这是:

• 快速(我可以直接做其他事情,它在一台单独的机器上运行,所以它不会减慢我的速度);
• 重复性(它不会忘记任何事情,包括将设置复制到发布文件夹并通知所有需要知道的人)
• 可靠(没有错误,不像人!).

在一个敏捷的环境中,您期望每2-4周交付一次工作软件,这绝对值得拥有,即使是在一个1人的团队中。

如果忘记签入某些内容(因为构建将被破坏),那么CI有利于单独开发人员。但是,当没有其他开发人员时,它的集成价值会降低。