如果您使用软件，您可能已经意识到软件交付的实践在今天远非完美。查看我们上个月关于自世纪之交以来软件开发演变的文章，原因有些。在那篇文章中，我们解释了导致我们进入当今软件世界的道路，以及为什么这个世界可能达不到我们的期望。

这篇文章是我们关于进入詹金斯后世界的系列文章的第二篇。在这里，我们更详细地看一下流行的工具和流程，包括但不限于Jenkins，它们阻碍了我们从软件的必杀技。

我们喜欢詹金斯！

需要明确的是，我们并未将Jenkins视为当今软件交付领域的唯一问题。我们实际上认为詹金斯是一个很棒的工具。但是，Jenkins和其他持续集成（CI）服务器并不总是正确使用。软件交付团队倾向于在如何部署Jenkins和类似工具时犯错误。结果，他们采用低效的做法，削弱了他们获得或保持敏捷性的能力，并失去了采用最新技术创新所需的灵活性。

詹金斯的问题

最终，这些问题的根源不是来自特定工具，而是来自文化错误。

问题1：詹金斯插件太多了

插件不一定是坏事。实际上，当它们被正确使用时（这意味着将功能扩展到软件平台所需的核心功能之外），它们就是很好的资源。它们为用户提供了为他们使用的工具添加额外功能的选择，而不需要他们在不希望使用这些功能的情况下将资源专用于这些功能。

但对于Jenkins而言，插件不提供对可选功能的访问，这些功能超出了使用该平台所需的核心功能。相反，Jenkins要求团队使用插件来实现在许多情况下非常基本的任务。

例如，如果你想为Docker环境构建 – 这是一个非常常见的用例 – 你需要一个插件。如果你想从GitHub（另一个非常常见的任务）拉，那么你需要一个插件。如果您需要PAM支持，则需要一个插件。

可以肯定的是，Jenkins的1,500个插件中的许多都提供了并非每个人都需要的功能。它通过插件提供完美的意义，例如，PagerDuty或Azure存储兼容性，因为许多用户可能不需要这些功能。

但是你需要在Jenkins中插件来做任何事情都是有问题的 – 而且这不仅仅是因为它意味着软件交付团队必须花时间安装和配置它们才能开始工作。这里更大的问题是Jenkins的大多数插件都是由第三方编写的，质量各异，可能会在没有通知的情况下失去支持。

构建基于第三方插件的软件交付链并不是确保可用性或稳定性的好方法。

问题2：Jenkins不是为Docker时代而设计的

虽然CI服务器通常是现代DevOps会话的一部分（并且确实是DevOps工程师的许多重要工具之一），但它们实际上是一种相对古老的技术，可以追溯到2000年代中期 – 早在任何人想象容器之前和微服务作为软件部署的首选基础设施。

因此，传统的CI服务器无法帮助团队充分利用Docker容器等下一代基础架构。他们通过多个插件很笨拙地与Docker集成。实际上，Jenkins 在其名称中使用Docker的插件不少于14个。许多用于特定供应商的Docker相关平台，但其中六个用于核心Docker平台。

从许多方面来说，Jenkins与大多数其他CI服务器一样，是在裸机服务器和虚拟机时代构建的。事实上它支持Docker支持。在越来越多的Docker本地环境中，这不是CI服务器运行的好方法。

问题3：Jenkins不能很好地支持微服务

就像Jenkins和大多数其他CI服务器诞生于Docker之前的时代一样，它们也在微服务变得流行之前出现。

当然，有些人在2000年代使用面向服务的架构（SOA），同时Jenkins首次使用。自20世纪80年代以来，微内核等概念就已存在。但是直到Docker出现并使微服务易于实现，实际上已经部署了很少的微服务平台。

所以你可能不会期望Jenkins能够很好地支持微服务 – 事实上，它并没有。Jenkins缺乏对同时集成和测试多个服务的支持。这是微服务环境的基本功能。

除非您计划投资多个管道的开销（每个微服务一个），Jenkins在帮助您开发下一代微服务应用程序方面做得很差。

问题4：CI！= CD

Jenkins和CI服务器的最大问题很可能是软件交付团队有时会将持续集成与持续交付（CD）混为一谈。

事实上，CI和CD是不同的东西。CI是CD流程的一部分，但要实现完整的CD – 这应该是任何旨在优化其工作流程的软件交付团队的目标 – 您需要的不仅仅是CI服务器。

CD还需要将自动释放自动化到您正在使用的环境中，无论是什么。它需要可以自动执行不属于CI服务器范围的软件交付任务的工具，例如步骤。CD需要通信工具和渠道，以使软件交付团队能够无缝协作。

当组织设置CI服务器并立即考虑他们的软件交付现代化工作完成时，他们犯了一个大错误。

改变詹金斯世界的文化

为什么熟练的软件工程团队会犯这样的错误？这并不是因为他们没有智能或无法跟上最新的创新。

相反，问题在于错误的尝试模仿最大，最有效的软件交付操作，如谷歌和Netflix。这些组织着名地利用开源工具链和大型基础架构，构建令人难以置信的敏捷软件交付管道。

是什么使这些公司能够构建这些管道不仅仅是他们部署的工具，还有他们的文化。仅使用与Google相同的工具，您无法像Google一样高效。

较小的组织并不总是意识到这一点。只有当他们拥有正确的文化理念和流程时，他们才能克服像Jenkins这样的工具的局限性，并优化他们的软件交付管道。

没有工具链是完美的，但是当您实施正确的文化时，您可以实现完美的软件交付（或至少接近它）。

如果您的软件交付方法仍然只围绕Jenkins构建，那么您无疑会错失更好的机会。实现这些机会需要文化变革。在本系列的下一篇文章中，我们将研究具有前瞻性思维的公司如何将新工具与新的软件交付文化相结合，以超越我们长期努力解决的以Jenkins为中心的世界的低效率。

https://thenewstack.io/many-problems-jenkins-continuous-delivery/