在面对构建和部署系统时,开发团队有许多选择。DevOps 和 CI/CD 管道不断改进,激发了大量商业或社区新产品的开发。Azure DevOps 和 Jenkins,想必大家并不陌生,是负责构建和发布管理两大系统。在本文中,我们将聚焦 Azure DevOps 和 Jenkins,分析利弊。
在对比 Azure DevOps 和 Jenkins 前,我们先花点时间来了解这些产品的起源。我们将比较其中一些共同点和不同点。重点针对各个系统的差异,因为这是影响团队决策的主要因素。
Azure DevOps 构建发布平台发展史
回顾 CI/CD 发展历程,细数多种多样化的辅助工具,我们才感受到技术的进步有多大。从开源到企业级产品,强大的用户社区孕育了创新型产品,并在市场中脱颖而出。此外,选择的多样化,也让每个开发团队更能灵活应变!
不久之前,许多公司的开发团队使用过 Team Foundation Server(TFS)。所以,这也不难理解,为什么许多项目不论过去还是现在都创建于微软架构。此外,许多团队也使用 Team Foundation Version Control (TFVC) 系统来管理、保护代码库。这些都是为什么 TFS 自动化功能内置于大多数团队工作流程的原因。
由于 GIT 在 TFS 2013 中获得了本地支持,这使得不使用微软堆栈的团队更容易利用其自动化功能。使用以代理为基础的构建系统可以定制构建环境,满足各种编译和打包需求。
顾名思义,Azure DevOps 旨在心境
值得注意的是,TFS 的最终发展会遵循云计算和其他集成的发展规律,提供在线服务。Visual Studio Online,最终成为了 Visual Studio Team Services,使用的是 Azure 平台提供简单路径,导向集中区域。其中这个区域包括工作项、代码存储库、构建和发布功能以及报告。
这些丰富功能的高潮,最终演变成 Azure DevOps。Azure DevOps 深受其后端的 Azure 平台的滋养,已经发展成为一个性能最好的构建和发布系统,一个耗时短,效率高的强大系统。
不过,当比较 Azure DevOps 和 Jenkins的使用数据时,可以发现 Jenkins 适应力极强。最近的一项调查,统计了工程师频繁使用的 CI 系统数据,其中 55% 的人选择 Jenkins,9% 的人选择 Azure DevOps。数据上下差异明显,但细想用户选择 Jenkins 而非 Azure DevOps 原因,这个结果也是预料之中。
同样,据报道,TeamCity 的使用率约为 8%。在之前关于 Jenkins 和 TeamCity 的文章中,我们比较了每个系统的功能及优劣。正如我们在那篇文章中的推论,Jenkins 和 Azure DevOps 各有所长,吸引着不同的开发群体。
以下是一些在日常运营中使用 Azure DevOps 的知名企业:
- Axonize ——智能物联网平台。拥有多个来源的数据分析和优化。
- 嘉吉——全球食品供应商。利用 Azure DevOps 保障安全性,促进迁移。
- 雪佛龙——世界能源领袖。使用 Azure DevOps 进行无缝云迁移和项目管理。
- Itron ——公用事业技术供应商。使用了 Azure DevOps 成功地缩短了发布周期,并整合了破碎的开发环境。
用户依赖 Jenkins 的高扩展性
工程师青睐 DevOps 原因之一,是在 CI/CD 系统中,不论任何情况发生,DevOps 都几乎能提供构建和部署解决方案。但这个功能在 Jenkins 由来已久,Jenkins 的使用率和第三方插件的数量就能证明。Jenkins 支持多种技术,这种能力是从第一步开始的,即访问你的代码库。
Jenkins 能够访问大量的源代码库,这对那些没有事先准备转换的团队尤其有利。GIT、Mercurial甚至像 Subversion 这样的旧系统都可以轻松访问,完成所需的各种构建和发布操作。随着 DevOps 的思维方式向“管道即代码”的概念转变,访问各种现有源代码控制系统的能力对一些团队来说是至关重要的。
除了能够以各种方式访问代码之外,Jenkins 还使用了专业构建代理、插件以及与 API 交互。这些构成了全量构建和部署的环境,使用 Jenkins 的人对此比较熟悉。由于 Jenkins 和 Azure DevOps 的社区参与度和总体使用率都很高,很多人都觉得这两个系统很不相同。话虽没错,但这两种产品也有相似之处。
Jenkins | Azure DevOps | |
价格 | 免费 | 基础使用免费/ 按用户数量收费 |
成立时间 | 2011
(前身是 Hudson,初创于 2005 年) |
2006 |
技术 | Java | .NET 基础架构(WCF) |
托管 | 自托管 / Jenkins X | 自托管/ SaaS |
许可证书 | MIT License | 商业 |
易用性 | 中等 | 基础 |
项目集成 | 依赖插件 | 本地 |
社区支持 | 强大 | 有限 |
云集成 | 借助插件/ Jenkins X | 本地 |
RESTful API | 是 | 是 |
可用语言 | C, C++, Fortran, Java, PHP, Python | .NET, Java, Node.js, PHP, Python |
容器支持 | 是 | 是 |
报告 | 是 | 是 |
项目管理整合不容忽视
可以肯定的是,组织有序的任务储备对任何开发团队来说,都有利于获得最佳工作效果。不管这些任务储备利用 Atlassian JIRA 进行管理,还是微软产品原生的服务。不论哪种方式,许多团队现在都要求,任何到达生产环境的更改都要有一个明确的解释,即代码更改的位置和原因。
例如,许多处理受保护个人信息(PPI)的公司,需要仔细进行大范围地变更管理。在这个过程中,要明晰一个关键项目代码更改的位置和原因。因此,每一次的新发布中,引入生产环境的所有内容都可以很容易地追溯到原始请求。这对于维护隐私至关重要,公司可以保留任何与安全相关的认证。
比较 Azure DevOps 和 Jenkins 的项目集成,Azure DevOps 优势明显。由于一个软件版本中涉及的所有主要因素都在一个产品中,因此不太需要额外配置的集成。但 Jenkins 需要,为了完成集成目标,Jenkins 用户可以选择许多与项目管理系统对应的插件。
社区参与 vs 商业支持
社区中有大量实用的开发技术,再加上有时在构建和发布自动化方面需要创新,因此许多人转而使用 CI/CD 系统,看中的就是坚实有力的社区力量。虽然 Azure DevOps 是商业化的,但是专设了一个在线区域方便用户找社区支持。此外,由于微软支持这个产品,随着时间的推移,我们很可能会看到使用率的增加。
Jenkins 的社区支持也是深受数千个开发团队青睐的主要原因之一。开源产品重在灵活性,灵活性提高,其应用于大量编程技术的能力也随之增强。
这就导致大量的插件和步骤涌现,不断扩展 Jenkins 的能力。在开源模式下,大众社区参与推动了技术发展。大量热门活动的增加,鼓励大家积极采取行动,而不是被动等待产品规划。这就是为什么与 Jenkins 相比,Azure DevOps 的商业产品黯然失色的原因。
从社交媒体巨头到提供共享单车和公共服务的公司,许多当今著名的服务提供商在开发管道中使用的都是 Jenkins:
- Netflix
- Lyft
- ebay
- Intuit
值得一提的是,另一个 CI/CD 产品也正在不断获得社区支持。对于崇尚“管道即代码”人,GitHub Actions 承诺将扩展那些已经托管在其站点上的功能,包括工作流程。这些工作流程让用户可以直接从 GitHub 或内部构建服务器编译、打包和部署代码。随着时间的推移,我们可能会看到 GitHub 使用率会不断增加。
仔细比较 Azure DevOps 和 Jenkins,慎重决策
与所有解决方案一样,Azure DevOps 和 Jenkins 各有所长。虽然指出这两种产品的劣势并不是本文的目标。不过可以肯定的是,这些劣势也是团队进行选择时的重要参考标准。或者,更明智的做法是根据需要选择合适的产品。
产品是否支持团队使用的编程技术?是否与代码库连接?考虑到与构建和部署系统相关的企业级系统运行时间,产品是否能提供支持?在选择 CI/CD 系统时,这些问题都应该认真考虑。
这两种产品都能很明显地满足需求。花时间测试并选择适合当前及未来需求的产品,是正确决策的关键。与所有好的决策一样,概念证明是最佳方法,帮助你验证每个系统如何适应开发环境。利用 Jenkins 与其开源模型,你和你的团队可以在决策中减少财务因素的考虑。
相反,商业方面的原因,可能是团队选择 Azure DevOps 淘汰 Jenkins 或其他同类产品的原因。商业化产品可以提供支持、更新和灾难恢复的正确组合,确保稳定的环境。有些团体更喜欢这种简单便捷的方法来管理 CI/CD 管道。现成的产品提供了一个系统,不用持续维护,让团队更能专注完成项目。
归根结底,是什么让你的团队能完成任务,同时激发更多的创新想法?有了创新和稳定的交付途径,许多开发团队才能专注于代码,无需顾虑如何交付代码。仔细看看 Azure DevOps 和 Jenkins,你一定会找到适合的方法。