持续集成工具在一个单独项目中提供什么优势？

如果您正在做一个单独的项目-您是否会使用CI工具从存储库中进行构建？我在团队环境中使用了Hudson和Cruise Control，在该环境中，任何人只要签入任何东西就必须立即构建。

我认为版本控制的价值仍然显而易见，但是我是否需要在每次提交后进行构建，就像我只是在本地计算机上进行构建一样，没有人提交？

好吧，我计划在项目上使用持续集成工具，并且我是唯一的开发人员。需求之所以来是因为

1. 一个目标是使其跨平台，拥有集成工具可以帮助您在集成存储库（或中心存储库）中进行更改后（基本）在多个平台上隐式（基本）检查您的应用程序。将用作权威）。
2. 该项目是长期的，因此以后我需要与团队合作。我不打算在2012年之前招募任何人，因此持续集成工作可以等待片刻，直到1.成为优先事项。

除了跨平台和团队合作准备，我认为没有必要。最主要的是要拥有某种源代码控制软件并具有几个用于保留备份的存储库。这将帮助您在需要时围绕它设置构建工具。

关于构建时间，我正在使用Mercurial并设置一个不是团队协作存储库的集成存储库。因此，推动团队仓库中的更改，直到我觉得是时候尝试构建集成系统了。然后，我从团队协作存储库推送到集成存储库，这将触发构建。然后，我还添加了一个脚本，该脚本将每天一次将团队协作存储库拉入集成存储库。

在这里，我假设我几乎每天都在我的项目上工作，但这并不总是正确的。您必须设置与您需要构建的频率有关的构建时间。在我之前工作的一家游戏公司中，我们使用了CruiseControle，并且每小时都会构建一个完整版本。如果需要，我们还可以在需要时强制构建。

对于家庭项目，一天一次可能已经很“频繁”了。主要要求是轻松允许用户强制启动构建。

经过短暂的思考之后，我建议对于单人开发人员而言，这甚至比团队更重要。

在最基本的级别上，CI服务器证明您可以从提交的源头开始重新构建应用程序-结合一组不错的测试，它应证明您可以从头开始构建并运行。

因为我要尝试做的一件事情就是确保我的构建包括一个可部署的程序包，所以您也知道可以进行部署（从已知状态/版本中清除代码）。

实际上，现在，当您执行File | New Project时，您可能应该包括创建或添加到存储库并设置CI构建脚本和部署设置（即使那只是压缩一堆东西以进行xcopy部署）

附录（2016）-如今，我的CI系统也将成为部署过程中不可或缺的一部分，因此它的价值已经提高，如果没有它，我绝对不会运行任何可交付的项目。自动化的按钮部署可以减轻流程的压力，并且在某种程度上，构建服务器或构建服务器是必不可少的。

当我是唯一的提交者时，我只是在实际提交之前进行构建和测试。我通常使用makefile目标，例如：

make sense

这样可以配置，构建，运行所有测试（了解Valgrind的测试），运行皮棉等。据我所知，我将是唯一的推动者，我实际上并不需要Hudson这样的功能。

此外，在有多个分支供主要存储库使用的环境中，如果每个人都在提交或推送之前遵循始终拉动，则CI服务器可能会被淘汰。一个写得很好的规则是，凡是破坏了最后一个版本的作者都在星期五购买了比萨饼，通常可以使事情顺利进行:)

如果遇到将项目明确划分为拥有自己领导者的子系统的情况，那么您确实需要考虑使用Hudson之类的东西。有人可能会在本地进行测试，在与另一个子系统的竞争中败北，最终导致产生有毒物质。

另外，如果您正在维护一个快速发展的项目的分支（例如，您自己的Linux内核补丁集），那么即使您是该项目的“独奏”，您也应该考虑使用Hudson之类的东西。如果直接从主线分支/重新建立基础，尤其如此。

我不会说这只是一个不错的奖励，我想这对我们这里的独奏艺术家来说对于高质量软件工程至关重要。如果他们急于在以后解决问题时急于求成，我们大多数人都会让他们的质量标准有所下滑。如果您以这种状态提交软件，则实际上您的源代码管理中将存储着毫无价值的代码库。

如果正确遵守（也就是说，您不会跳过测试，并且确保每次提交时都进行构建），CI会强制您遵守更高的质量标准，这要比无论如何都要提交它都要高。

重要的是，如果您想减少等待时间，看一切是否还顺利。尽管您可以在保存后立即让IDE为其编译内容，但它不会自动运行单元测试，因此我让CI服务器尽快运行单元测试和测试用例覆盖率报告以及其他代码质量分析。我推。

我唯一要做的触发器就是将当前所做的更改推送到版本控制中，然后回到编码。在考虑编码的同时，CI系统正忙于编写冗长的质量报告，当我的大脑停滞不前时，我会不时查看这些报告。

我在同一台笔记本电脑上有一台单独的VMWare计算机，该计算机为我推送的代码进行构建。为此，我只获得了Turnkey Linux VMWare映像，并使用apt-get安装了jenkins，并做了一些小的配置更改。