Jenkins CI工具决策-多学科组织

在我们的组织中，我们离线工作（与Internet断开连接）。我们使用的大多数工具都安装在一台服务器上，该服务器应该为所有用户（大约500个并发用户）提供服务

我们使用以下所有操作系统：Linux（所有版本）、Windows（2000、XP、7、10）、VxWorks、Solaris和一些内部开发的系统。 我们使用了几乎所有的开发语言：C、C++、C语言、java、JavaScript、Python、Ruby、Visual Basic以及一些较老的语言（我们有很多遗留代码）。 考虑到我们必须维护所有这些平台，您是否建议使用Jenkins或Gitlab CI作为主要CI工具

我们需要的是集成许多软件（旧软件！）的选项，而且由于我们目前正在迁移到Gitlab作为我们的源代码管理系统，因此我们仍然对更改CI工具犹豫不决。为了能够使用来自不同团队和项目的脚本/流，我们不想同时使用这两种工具

关于这个问题，我们公司的主要考虑因素是什么？考虑到这个决定，我们可能会在未来5到10年使用基础设施

---

如果需要更多信息，我很乐意提供

我认为这个问题没有明确的答案，但您可以考虑的是

Jenkins

的采用率和社区支持，这可能适合您，因为您有多种编程语言的项目。另一方面，

GitLab CI

使用起来更简单，而且更干净，因为您是以

YAML

格式编写管道的。

---

就我而言，我开始比Jenkins更喜欢GitLab CI，但这只是一个机会。

我从2013年开始使用Jenkins。事实证明，这是一种需要大量维护的可靠工具

我构建的最后一个实现是在容器中运行并在多个代理上处理管道和UI作业的主实现：用于linux构建的容器和用于windows等的普通VM主机

每个团队都拥有这个奴隶，并在詹金斯拥有自己的空间，而不干涉他人，也不成为詹金斯的管理员。这让我有时间维护它，让他们可以自由地以不同的速度和知识水平进行实验和工作。此外，JCASC可能会有所帮助（我仍然需要尝试）。您可以为每个团队提供docker compose、vagrant和脚本来安装他们自己的代理

竹、TFS、Gitlab和cruisecontrol过去极大地限制了我代表团的可能性。

忘记“Jenkins的采用率和社区支持”。。。想想你自己工作场所的采用率。有了如此不同的软件、操作系统等组合（如Jeknins这样的集中式构建系统），它可能会变成实施或采用的噩梦。您的CI考虑独立于源代码管理，但有时现成的解决方案更容易让他们自己管理。考虑PREM成本-许可加HW成本vs云+使用。