我在一个组织中从事一个大型项目，该组织正在（缓慢地）升级我们的开发流程，使其更加现代化。我们目前正在考虑转向持续集成模型；作为这一举措的一部分，我们正在考虑编写自己的持续集成服务器。我们有一个非常成熟（有些僵化）的构建过程；我们还有大量的测试，我们希望将它们作为构建验证测试运行。
我们研究了几个商业 CI 服务器，似乎根据我们的个人需求定制其中任何一个所涉及的工作量相对较高；如此之高以至于我们可能值得花时间自定义编写我们自己的 CI 服务器。但是，我觉得我们可能遗漏了这个过程的一些潜在陷阱。已经提出并考虑了我们实施中的错误问题；在评估我们的选择时，我们还应该牢记其他主要考虑因素（当然，除了编写 CI 系统所涉及的工作量）吗？从任何实施过自定义 CI 服务器的人那里，有什么特别的麻烦？从任何使用过商业 CI 系统的人那里，有没有你希望自己做的事情，或者你特别高兴你没有做的事情？
我强烈反对这种 NIH 的想法。
为什么不构建您需要的定制部分，而不是一个成熟的 CI 服务器？尽可能多地重复使用，而不是定制所有东西，你至少可以制作一些现成的零件。
（顺便说一句，我不会将其描述为“NIH”）
请注意，即使您花费与构建自己的 CI 服务器一样多的时间来配置构建以使用现有的 CI 服务器（可能在这里很慷慨），您也只需要维护每个自定义位 - 而不是整个框架。
看看你可以利用什么，并使用它。另请查看似乎有希望朝着您前进的方向前进的工具。开箱即用的 CI 服务器不会在您的环境中完美运行。它们都必须进行调整并“半途而废”。
做好这件事根本不是一件小事——开源社区至少在第三代开源 CI 服务器上——在此过程中吸取了很多教训。
我当然会鼓励您查看允许轻松扩展的现成 CI 服务器之一，并构建那些缺少的部分。在大多数现有 CI 服务器中，您的问题中没有任何事情没有完成（并且做得很好）。
在转向开源解决方案之前，我确实实施了一个“穷人的”内部 CI 系统，并且发现开源系统更好、更完整、更强大，以至于我的努力毫无意义。
特别是，如果您正在寻找可扩展性，Hudson将是一个不错的选择 - 它具有出色的插件架构，并且作者可用于付费咨询工作 - 可能比滚动您自己的资源更好地利用您的资源。
顺便说一句，在我参与构建过程之前，产品构建需要 14.5 小时，没有自动化测试、打包或 CM。多亏了一些努力，并遵循现有 CI 社区制定的最佳实践，相同的项目构建时间缩短到 7.5 分钟，包括自动化测试、打包和 CM。根据我的经验，绝对值得付出一些努力来使您的构建符合经验丰富的 CI 社区的现有最佳实践，而不是试图让 CI 屈服于您现有的构建。
我会考虑的事情：
我也走过这条路。我已经为我工作过的各种公司编写了 3 次内部自动构建系统。一直很有趣，我是那种喜欢写工具的人。
然而，归根结底，它从来都不是一个专业的系统。它总是一个足够好的系统，为我们工作，让我们度过难关。当然，除非我去度假，或者去另一个城市开会，等等。以至于每当我出城时，构建都会失败，失败，失败。不是因为我们的代码有问题，而是因为我每天都会在构建系统中处理一些小事情。当我不在那里处理它们时，没有其他人知道该怎么做。
所有这一切都从我们的主要关注点——我们自己的软件开发——转移了时间。
最后，我们（在我的敦促下）放弃了我编写的手工构建的 perl 脚本系统，我们购买了一个商业系统：Zed Builds and Bugs
现在，当出现问题时，就是我们自己的代码有问题。供应商的构建系统有效。当我们有问题时，我们会问他们，或者询问用户社区。当我们需要了解如何做某事时，他们会有人回答我们的问题。
最重要的是，我又可以休假了 :-)
我仍然是使用构建系统处理大部分任务的人，但这不再是编写它的问题。这是一个使我们现有的 makefile、Visual Studio 项目、Ant 构建脚本等适应新系统的问题。
Believe me, it's much easier to buy versus build in this case. Your core business isn't creating a build system (or you wouldn't have asked the question). Focus on your core business, and buy the tools you need for everything else.
我可能会尝试从我的角度给出一些提示。在我们公司，我们使用不同的构建环境配置和不同的目标环境。不同的配置是指不同的系统架构。这是我想描述的一点。（虽然我不知道这是否是你的实际问题）。
产品的构建是在构建环境上完成的，为了运行测试，产品本身必须转移到目标环境。因此它涉及交叉编译。我们没有使用商业或开源的持续集成解决方案，但我们使用了一组 bash 脚本（没有时间创建合理的解决方案 :( ）运行测试（无论单元、集成、健全性、组件等..）必须在目标上完成。
所以你可能会问的问题是——什么是开发环境？您想在哪里运行测试？（我们一直在目标上运行测试，并且在构建环境上也进行了一小部分测试）目标环境与开发环境相同吗？您是否需要针对不同的配置（平台、软件等）进行构建？
你还没有说明你使用的是什么语言。我知道这可能无关紧要，但事实并非如此 :) （即使 java 在不同平台上的行为也不同（x86 vs x86-64）
任何其他的东西，比如用测试覆盖代码，在编译期间完成的一些静态代码分析（之前..）运行文档任务我认为不是很有趣，因为这些任务可以作为单独的插件完成。