【译闻】Jenkins与持续交付的若干问题

今天我们和大家详细聊一聊一直非常受欢迎的开源工具——Jenkins。

众所周知，Jenkins在软件开发流程中非常有用，是一款很棒的工具，但Jenkins和其他CI服务器一样，在软件交付过程中也会或多或少出现一些问题。软件交付团队往往在部署Jenkins以及这类工具的时候会犯错，使得开发效率变低，削弱了团队的敏捷开发能力，同时也失去了使用最新技术创新所需的灵活性。

使用Jenkins会出现的若干问题

问题1：Jenkins的插件太多

插件不一定是坏事，当它们都使用正确时，确实是很好的资源。用户可以向其使用的工具中增加额外的功能，这当然是最好的。但Jenkins的插件并不能为平台提供核心功能以外的任何可拓展功能，相反，在大多数情况下，使用Jenkins插件，团队只能完成基础的开发工作。 例如，要Docker一个构建环境，你需要一个插件。你从GitHub下载，同样，你需要一个插件。你想PAM提供支持，你也需要一个插件。 但可以肯定的是，Jenkins的 1500个插件并不是每个人都需要。所以通过插件提供帮助，这很有意义，就比如PagerDuty或Azure Storage兼容性，有一部分用户可能并不需要这些功能。 但如果你想通过Jenkins插件来做任何事情，这都是欠妥的。因为这就意味着交付团队要花更多的时间来安装和配置插件，如此才能开始愉快的工作。然而还有一个更大问题，那就是大多数Jenkins的插件都由第三方编写的，质量不一样，而且在没有详细描述的情况下可能会不支持。 可见，构建基于第三方插件的软件交付链，并不是一个保证可用性或稳定性的好办法。

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

早在2000年上半年，在设想容器和微服务作为软件部署的首选基础设施之前，CI服务器就已经存在。它确实是一种相对较老的技术，通常是DevOps的一部分。 因此，传统的CI服务器不能帮助团队使用像Docker容器这样的基础架构，他们只能通过大量插件与Docker进行不恰当的整合。然而事实上，大部分插件由第三方提供，并在与Docker相关的平台上使用。虽然Jenkins为Docker提供了14+个不同的插件，但其中六个是针对Docker的核心平台使用。 Jenkins与大多数其他CI服务器一样，都建立在裸机服务器和虚拟机时代。后来，在Docker的支持下才进行了处理。所以在这个倾向于Docker的大环境下，这并不是CI服务器运行的好方法。

问题3：Jenkins不能较好的支持微服务

Jenkins和大多数CI服务器一样出现在Docker之前，也出现在微服务流行之前。 有些人早在2000年的时候就在开展SOA工作， Jenkins在那时也首次被使用。而在二十世纪八十年代初，微服务的概念就已经存在。但直到Docker出现，微服务才开始真正实现。 看到这里，或许你能猜到Jenkins并不能很好支持微服务， 而事实上也是如此。因为Jenkins缺乏对集成和一次测试多个服务的支持，而这些都是微服务环境下的基本功能。 除非你计划多个流水线的开发，否则Jenkins在帮助开发下一代微服务应用程序方面做得并不是太好。

问题4：CI!=CD

Jenkins和CI服务器最大的问题是，有时交付团队会将持续集成（CI）与持续交付（CD）混在一起。而事实上，这两者是不同的。 CI是CD的一部分，但是要实现完整的CD，需要的不仅仅是CI服务器。 无论什么时候，CD都需要自动发布到当前使用环境中。这需要如“Steps”之类的工具来实现，将软件交付任务自动化到CI服务器的范围之外。CD这一过程需要工具和渠道，使软件交付团队达到无缝协作。 当建立一个CI服务器时，就马上考虑软件交付工作完成，这本身就是在犯一大错误。

改变Jenkins思路

为什么经验丰富的软件工程团队会犯这样的错误？这不是因为他们不了解，亦或是无法跟上最新的创新。问题在于团队被误导去尝试效仿大企业，并使用最有效的软件交付手段，想要做成和Google、Netflix一样。这些企业着力于利用开源工具链和大量基础设施，构建出非凡的敏捷软件交付通道。 然而，这些公司之所以能做到这些，绝不仅仅是因为他们的部署工具，而是他们的思路。这就像是你能使用像Google一样的工具，但你不能像它那样的高效。较小的企业并不能意识到这一点。只有当他们真正拥有正确的思路和过程时，才能克服Jenkins这类工具带来的局限性，并优化他们的软件交付流程。

没有工具链是完美的，但当你有这样思路时，同样可以实现软件交付完美（或至少与其相近的东西）。如果你的软件交付方式仍然围绕Jenkins建立，你无疑会错失做的更好的机会。要实现这些仍需要研发思路与过程的革新。

原文链接： https://thenewstack.io/many-pr … very/