编写自己的Continuous Integration服务器时需要考虑的事项？

Question

我在一个组织中开展一个大型项目，该项目正在（缓慢地）升级我们的开发流程，使其更加现代化。我们目前正在考虑转向持续集成模式;作为此举的一部分，我们正在考虑编写自己的持续集成服务器。我们有一个非常成熟（有点僵化）的构建过程;我们还有一大堆测试，我们希望将它们作为构建验证测试运行。

我们已经研究过几个商业CI服务器，看来根据我们的个人需求定制其中任何一个的工作量相对较高;如此之高，以至于我们可以自定义编写自己的CI服务器。但是，我觉得我们可能会错过这个过程的一些潜在缺陷。我们已经提出并考虑了我们实施中的错误问题;在评估我们的选择时，我们应该记住是否还有其他主要考虑因素（除了编写CI系统所需的工作量之外）？任何实施自定义CI服务器的人都会遇到什么特别的麻烦？对于那些使用商业CI系统的人来说，有没有你希望自己做过的事情，或者你特别高兴的事情，你不需要自己做？

Answer 1

我强烈反对NIH的想法。

• 考虑修改像CruiseControl.NET
这样的开源CI服务器
• 考虑编写自定义Nant任务
• 考虑修改您的项目以使其更适合现有选项
• 您不想从事持续集成业务，只想使用它并看到好处

Answer 2

为什么不构建您需要的定制产品，而不是完整的CI服务器？尽可能多地重复使用，而不是拥有一切定制，你至少可以制作一些现成的零件。

（顺便说一句，我不认为这是“NIH”）

请注意，即使您花费尽可能多的时间来配置构建以使用现有的CI服务器，就像构建自己的CI服务器一样（这里可能很慷慨），您只需要维护每个自定义位 - 而不是整个框架。

了解您可以利用的内容，并使用它。还要看看哪个工具似乎有希望朝着你前进的方向前进。开箱即用的CI服务器无法在您的环境中完美运行。他们都必须进行调整并“中途遇到”。

Answer 3

做好这一点根本不是一件小事 - 开源社区至少是第三代开源CI服务器 - 在此过程中吸取了大量经验教训。

我当然会鼓励您查看一个现成的CI服务器，它允许轻松扩展，并构建缺少的那些部分。您的问题中没有任何内容在大多数现有CI服务器中没有完成（并且做得很好）。

在迁移到开源解决方案之前，我确实实现了“穷人”的内部CI系统，并发现开源系统更加完善，功能强大，我的努力毫无意义。

特别是，如果您正在寻找可扩展性，Hudson将是一个很好的选择 - 它有一个很棒的插件架构，并且作者可用于付费咨询工作 - 可能更好地利用您的资源而不是滚动你自己。

另外，在我参与构建过程之前，产品构建是14.5小时的事情，没有自动化测试，打包或CM。由于付出了一些努力，并遵循现有CI社区制定的最佳实践，同样的项目构建时间缩短到7.5分钟，具有自动化测试，打包和CM。根据我的经验，使用您的构建以符合经验丰富的CI社区的现有最佳实践绝对是值得的，而不是试图使CI弯曲到您现有的构建。

Answer 4

我会考虑的事情：

• 我们对该领域的团队有什么样的经验？
• 时间表是否让团队成员能够花时间了解CI服务器的设计？
• 是否有预算雇用具有此领域知识的人来补充团队？
• 为什么你认为你能比现有的解决方案做得更好？

Answer 5

我也一直走在这条路上。我已经为我工作过的各种公司编写了3次内部自动构建系统。它总是很有趣，我喜欢写作工具的人。

但是，在一天结束时，它从来就不是一个专业系统。它始终是一个足够好的系统，为我们工作，并让我们通过。当然，除非我去度假，或去另一个城市的会议等等。我得到的结论是，每当我出城时，构建都会失败，失败，失败。不是因为我们的代码存在问题，而是因为我每天都会在构建系统中处理很少的事情。当我不在那里处理它们时，没有其他人知道该怎么做。

所有这些都需要时间远离我们的主要关注点 - 我们自己的软件开发。

最后，我（在我的催促下）抛弃了我编写的手工构建的perl脚本系统，我们购买了一个商业系统：Zed Builds and Bugs

现在，当出现问题时，我们自己的代码就会出现问题。供应商的构建系统有效。当我们有问题时，我们会问他们，或者询问用户社区。当我们需要了解如何做某事时，他们会让人们回答我们的问题。

最重要的是，我再次休假： - ）

我仍然是使用构建系统处理大部分任务的人，但这不再是编写它的问题。这是一个使我们现有的makefile，Visual Studio项目，Ant构建脚本等适应新系统的问题。

相信我，在这种情况下购买与构建要容易得多。您的核心业务不是创建构建系统（或者您不会问这个问题）。专注于您的核心业务，并购买其他所有工具。

Answer 6

我可能会尝试从我的角度给出一些提示。 在我们公司，我们使用了不同的构建环境配置和不同的目标环境。通过不同的配置，我的意思是不同的系这是我想描述的一点。 （虽然我不知道这是否是你的实际问题）。

产品的构建是在构建环境上完成的，并且要运行测试和产品本身，它必须转移到目标环境。因此它涉及交叉编译。我们没有使用商业或开源持续集成解决方案，但我们使用了一组bash脚本（没有时间创建合理的解决方案:(） 运行测试（无论是单位，整合，理智，组件等）都必须在目标上完成。

所以您可能会问的问题是 - 什么是开发环境？ 你想在哪里进行测试？ （我们一直在构建env上对目标和小部分测试进行测试） 目标环境是否与开发环境相同？ 你需要构建不同的配置（平台，sw等）吗？

您尚未说明您使用的语言。我知道它可能是无关紧要的，但它不是:)（即使java在不同的平台上表现不同（x86 vs x86-64）

其他任何事情都像测试代码的覆盖，在编译期间（之前......）运行文档任务时完成的一些静态代码分析我认为这不是很有趣，因为这个任务可以作为单独的插件完成。