放弃"Jenkins"的种种理由，期待更好赋能研发的持续交付平台

不完美的Jenkins

Jenkins，一个历史悠久的开源持续集成工具，源自Hudson，后由于商标争议产生了Jenkins分支。尽管Jenkins在DevOps和持续集成领域广受欢迎，但它存在历史遗留问题，包括单体结构、文件存储方式导致的性能问题，以及缺乏高可用方案。此外，Jenkins面临学习成本高、可维护性差、安全性和性能问题等挑战。用户在配置Jenkins时需要考虑插件选择、任务(job)数量、从节点(slaves)以及执行器(executor)等因素。

现实中持续交付对平台的要求

在现实场景中，持续交付平台需要充分自动化代码到服务最终用户的整个流程，包括构建、部署、环境变更等阶段。理想的部署系统应能解耦构建和部署过程，管理复杂的部署环境，支持多种部署策略，落实部署流程规范，获取研发过程数据，并服务化部署操作。这些要求超出了Jenkins及其插件的能力范围，因此即使在使用Jenkins的情况下，企业也可能需要独立的部署系统。

持续交付平台的特质

理想的持续交付平台需要连接项目涉及的人员、代码、制品库和环境，隐藏底层细节，对不同角色提供友好的自助式服务，少侵入多融合地控制外部系统集成，并聚焦流程框架。一个高效的持续交付平台应该引导用户正确地完成任务，赋能组织，而非造成困扰。

期待更好的持续交付平台

DevOps持续交付工具的多样性要求组织清晰理解自身需求和资源，合理搭配工具，并区分各工具的主次角色。如同搭建房子一样，组织需要考虑大小、豪华程度、工具组合以及主次角色分配等问题。通过明确这些问题，组织可以更合理、漂亮且实用地搭建持续交付平台，从而更好地赋能研发过程。

为什么必须要做极限编程？

了解更多

想要了解更多内容？

查看原文：放弃"Jenkins"的种种理由，期待更好赋能研发的持续交付平台

文章来源：

DevOps在路上

扫码关注公众号