在云中托管CI/CD既可以加快开发管道和源代码存储库之间的交互，也可以使开发人员的工作更轻松。

如果你的目标是高速软件开发和将工作构建频繁交付到生产环境，则你需要至少自动化部分测试和交付过程。

理想情况下，这意味着为你的项目实施 CI/CD 管道，以及在客户看到软件之前捕获错误的测试套件，以及实现管道步骤的脚本。

持续集成 (CI) 是一种以一致的方式自动化软件构建、打包和测试的方法。CI 有助于让团队相信他们检查到源代码版本控制中的更改不会破坏构建或将错误引入软件。

CI 的端点通常是对软件存储库主分支的完整签入。

持续交付 (CD) 自动将经过测试的软件交付到基础设施环境。这通常并不意味着将其直接投入生产以查看客户是否抱怨。

通常，组织首先将构建推送到开发环境。在开发人员自己击败并发布新版本后，它通常会进入一个测试环境，在那里它被更广泛的用户群体使用（有时只是专门的内部测试人员，有时更多的用户注册了 beta 测试或“狗食”）并密切监控。

最后，如果一切顺利，测试人员会签字并将新版本推送到生产环境。

在 CD 的每个阶段，都有选项可以快速恢复到旧版本并生成错误报告票供开发人员在新版本中解决。目标不是将大量构建投入生产，而是在不引入回归的情况下不断改进和增强软件。这些实践的另一个术语是“devops”。

为什么要在云中托管 CI/CD？

在你自己的数据中心托管 CI/CD 平台是一个可行的选择，特别是对于要求在防火墙内托管其应用程序和数据的公司。这样做的缺点是你需要一个专门的团队来维护基础设施，并且你将承担一些服务器资本支出。

如果允许你在云中托管，通常是更好的选择。在云中托管的成本适中，运营费用由提供的服务抵消：入职、基础设施维护、安全维护、支持和 CI/CD 软件维护。在云中托管 CI/CD 软件通常会使管道与源代码存储库交互更容易、更快，如果它们也在云中。

如果你的开发人员和测试人员分布在不同的地理位置，与在防火墙后面的远程服务器中托管相比，在云中托管你的存储库通常会给开发人员带来更好的体验。

还可以在本地和云服务器的混合上部署 CI/CD。一些最新的 CI/CD 产品在 Kubernetes 集群上的容器中运行，这些集群在本地和云中运行同样愉快。在混合部署方案中，你可以将每个组件放置在考虑到开发人员本身的物理位置以及开发基础结构中其他服务器的网络位置最有意义的位置。

CI/CD 必须与你的存储库集成

正如你在阅读“CI 的端点通常是对软件存储库的主分支的完整签入”时可能已经收集到的那样，存储库对于 CI 和 CD 至关重要。

除了作为签入和测试过程的终点之外，软件存储库还是存储 CI 和 CD 脚本和配置文件的首选位置。是的，许多 CI/CD 平台可以在内部存储脚本和其他文件，但通常最好将它们置于工具之外的版本控制中。

几乎所有 CI/CD 工具都可以与 Git 交互。有些还直接与 GitHub、GitHub Enterprise、GitLab 和/或 Bitbucket 集成。一些还支持 Subversion 和/或 Mercurial。

你的 CI/CD 工具需要支持你的编程语言和工具

每个编程语言或语言组（JVM 语言、LLVM 编译语言、.NET 语言等）往往都有自己的构建工具和测试工具。为了对你有用，CI/CD 工具必须支持作为给定项目一部分的所有语言。否则，你可能需要为该工具编写一个或多个插件。

Docker 镜像对于分布式、模块化和微服务软件部署变得越来越重要。如果你的 CI/CD 工具知道如何处理 Docker 镜像，包括从源代码、二进制文件和先决条件创建镜像，以及将镜像部署到特定环境，那么这将大有帮助。

同样，如果没有这个，你可能需要编写插件或脚本来实现你需要的 Docker 功能。同样，你希望 CI/CD 工具支持 Kubernetes 和你在环境中使用的任何其他容器编排系统。

你的开发人员是否了解 CI/CD 和你正在考虑的工具？

CI 和 CD 的原理看似显而易见，但细节却并非如此。各种 CI/CD 工具具有不同级别的支持和文档。有很多关于 Jenkins 的书，这并不奇怪，因为它是最古老的书。

对于其他产品，你可能需要调查文档和支持论坛以及付费支持选项，作为你在选择工具时尽职调查的一部分。

关于CI的一般背景，请考虑Addison-Wesley的书《持续集成》(Continuous Integration)，作者是Duvall等人。同样，对于CD的一般背景，可以参考Humble和Farley的Continuous Delivery。两本书出版时都获得了Jolt奖。

你可以为不同的项目选择不同的 CI/CD 工具

虽然本指南是关于选择 CI/CD 平台的，但请不要假设一个平台对于你的所有软件开发项目都是最佳的。大多数商店使用多种编程语言和环境，并不是每个 CI/CD 平台都能很好地支持所有这些。

随意选择最适合你的每个项目的 CI/CD 平台，而不是寻找一个折衷的平台。CI 和 CD 的一般原则从一个平台转移到另一个平台，即使你为它们编写的脚本可能并不总是可移植的。

虽然每个新平台的额外入门时间可能会让你的 DevOps 团队花费一些时间，但这很可能比需要广泛定制 CI/CD 工具更便宜。

规划未来的 CI/CD 迁移

同样，请不要假设给定的 CI/CD 平台将永远满足你的项目需求。始终对冲你的赌注，例如通过将脚本存储在存储库中而不是在 CI/CD 工具中。

在适当的情况下首选无服务器serverless CI/CD

一般来说，云容器部署比云服务器实例部署便宜，无服务器云部署比容器部署便宜。 不幸的是，在撰写本文时，很少有 CI/CD 平台可以无服务器运行。

无服务器意味着运行感兴趣的进程的容器在必要时被实例化，通常是为了响应一个事件。 对于 CI/CD，触发事件一般是代码签入到特定的存储库分支；然后存储库 Webhook 启动无服务器进程。当该过程完成时，资源被释放。

少数可以运行无服务器的 CI/CD 平台之一是无服务器 CI/CD，它是无服务器框架 Pro 的一部分，是开源无服务器框架的增强版本。无服务器 CI/CD 针对部署无服务器应用程序进行了优化，目前仅在 AWS 上运行。你必须确定它是否足够支持你的应用程序以供使用。

在提交之前做一个概念证明

一旦完全实施 CI/CD，它就会成为基础设施的重要组成部分。在你加快速度时请记住这一点。

在开始推出 CI/CD 管道之前执行严格的概念验证非常重要。在开始 CD 阶段之前，先将 CI 部分放下。在将任何 CI/CD 管道连接到生产实例之前，请确保练习测试套件和回滚功能，并让人工参与其中，直到你非常确定自动化坚如磐石。

原文链接：https://www.infoworld.com/article/3620932/how-to-choose-a-cloud-based-cicd-platform.html

云管理服务专家新钛云服 黄豪杰翻译