编写我们自己的连续集成服务器时需要考虑的事项?

我强烈反对NIH的这种想法。

• 考虑修改开源CI服务器,如CraceSealTr.NET
• 您不想从事持续集成业务,您只想使用它并看到其好处

与其使用成熟的CI服务器,为什么不直接构建所需的定制部分呢?尽可能地重复使用,而不是让所有东西都定制,你至少可以从货架上制造一些零件。

请注意,即使您花在配置构建以与现有CI服务器配合使用的时间与构建自己的CI服务器的时间一样多(这里可能很慷慨),您也只需要维护每个自定义位,而不是整个框架。

做好这一点绝非易事——开源社区至少在第三代开源CI服务器上——在这一过程中,我们学到了很多经验教训。

我当然鼓励您查看一个现成的CI服务器,它允许轻松扩展,并构建缺少的部分。在您的问题中,没有什么是在大多数现有CI服务器中做得不好(而且做得很好)的。

特别是,如果您正在寻找可扩展性, Hudson

顺便说一句,在我参与构建过程之前,产品构建需要14.5个小时,没有自动测试、打包或配置管理。经过一些努力,并遵循现有CI社区制定的最佳实践,同一项目构建时间缩短到7.5分钟,并实现了自动化测试、打包和配置管理。根据我的经验,在构建过程中遵循经验丰富的CI社区的现有最佳实践,而不是试图使CI适应现有构建,这绝对值得付出一些努力。

• 我们团队在这个领域有什么样的经验?
• 时间线是否允许团队成员投入时间来了解CI服务器的设计?
• 是否有预算雇佣具有此领域知识的人员来补充团队?

我也曾走过这条路。我已经为我工作过的各个公司编写了三次内部自动构建系统。这一直都很有趣,我是那种喜欢写作工具的人。

所有这些都使我们的主要关注点——我们自己的软件开发——失去了时间。

最后,我们(在我的敦促下)抛弃了我编写的手工构建的perl脚本系统,并购买了一个商业系统: Zed Builds and Bugs

现在,当出现问题时,是我们自己的代码出了问题。供应商的构建系统工作正常。当我们有问题时,我们会问他们,或者问用户社区。当我们需要了解如何做某事时,他们会有人回答我们的问题。

最重要的是,我又可以休假了:-)

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

相信我,在这种情况下,购买和建造要容易得多。您的核心业务不是创建构建系统(否则您就不会问这个问题)。专注于你的核心业务,购买其他一切所需的工具。

在我们公司,我们使用不同的构建环境配置和不同的目标环境。不同的配置意味着不同的系统架构。这是我想描述的一点。(虽然我不知道这是否是你的实际问题)。

产品的构建是在buildenv上完成的,为了运行测试和产品本身,必须将其传输到目标env。因此,它涉及交叉编译。我们没有使用商业或开源的持续集成解决方案,但我们使用了一组bash脚本(没有时间创建合理的解决方案:() 测试的运行(不管单元、集成、健全性、组件等等)必须在目标上完成。

所以你可能会问的问题是-什么是开发环境? 您是否需要针对不同的配置(平台、软件等)进行构建?

你还没有说明你在用什么语言。我知道这可能无关紧要,但事实并非如此:)(甚至java在不同平台上的行为也不同(x86与x86-64)