通过持续集成来保持不断增长的多样化代码库
我需要有关连续集成设置的概念和设计的帮助。 我们当前的CI设置使用buildbot。当我开始设计它时，我继承了一个定制的CI构建器（不是严格地说，因为我一年前参与了它的设计），该构建器经过定制可在一夜之间一次运行整个构建。一段时间后，我们认为这还不够，并开始探索不同的CI框架，最终选择了buildbot。我过渡到buildbot的目标之一（除了享受所有额外的乐趣）是要克服我们定制的夜间构建器的某些不足之处。 幽默一下，让我解释一下我继承的东西。我公司的代码库是将近150个独特的c ++ Windows应用程序，每个应用程序都依赖于十几个内部库中的一个或多个（以及许多第三方库）。其中一些库是相互依赖的，并且具有依赖的应用程序（尽管它们彼此无关）必须使用该库的相同内部版本来构建。这些应用程序和库中的一半被认为是“旧版”且不可移植，必须使用IBM编译器的几种不同配置（我已经为其编写了独特的子类Compile）构建，而另一半则使用Visual Studio构建。ShellCommands，因为不支持VSS）。 我们最初的每晚构建器只是简单地收集了所有内容的来源，并按一定顺序构建了东西。没有办法只构建一个应用程序，选择版本或对事物进行分组。它将启动虚拟机来构建许多应用程序。它不是很健壮，也不是可分发的。它不是非常可扩展的。我希望能够克服buildbot中的所有这些限制。 我最初执行此操作的方式是为我们要构建的每个应用程序创建条目（它们全部包含150个），然后创建可以将各种应用程序构建为组的触发调度程序，然后将这些组包含在整个夜间构建调度程序下。它们可以在专用的从属服务器上运行（不再需要虚拟机），如果我愿意，我可以简单地添加新的从属服务器。现在，如果我们要按计划进行完整构建，只需单击一下即可，但是如果需要，我们也可以只构建一个应用程序。 但是，这种方法有四个缺点。一种是源代码树的复杂依赖关系网。为了简化配置维护，所有构建器都是从大型词典生成的。检索依赖关系的方式并非十分稳健（即，在我的构建目标字典中删除某些内容）。第二个原因是每个构建都有15到21个构建步骤，这很难在Web界面中浏览和查看，并且由于有大约150列，因此需要永久加载（从30秒到几分钟）。第三，我们不再能够自动发现构建目标（尽管，尽管我的一位同事为此而烦恼，但我最初并不认为这对我们有什么帮助）。最后， 现在，转向新开发，我们开始使用g ++和subversion（请注意，不要移植旧的存储库-只是为了新的东西）。另外，我们也开始进行更多的单元测试（“更多”可能会给出错误的图片……更像是任何东西），以及集成测试（使用python）。我很难弄清楚如何将它们适合我的现有配置。 那么，我在哪里从哲学上错了？我怎样才能最好地继续前进（使用buildbot-这是我有许可证可以解决的唯一难题），以便实际上可以维护我的配置？如何解决设计中的某些弱点？对于大型（可能是过度）复杂代码库的CI策略，真正起作用的是什么？ 编辑： 我以为我解释了我的问题，但显然我还不够清楚。我不是在寻求有关更改CI平台的建议。它不会发生，答案表明那将不会被接受。我想知道的是其他人如何使用CI管理复杂的代码库。我有十几种平方的不同产品，而且我的依赖项随风而散，它们都是不同的。这就是我想知道的处理方法。