如何选择基于云的持续集成(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)/持续交付(CD)至关重要。除了作为签入和测试过程的端点之外，软件存储库还是存储持续集成(CI)/持续交付(CD)脚本和配置文件的首选位置。许多持续集成(CI)/持续交付(CD)平台可以在内部存储脚本和其他文件，但最好将它们保存在工具之外的版本控制中。几乎任何持续集成(CI)/持续交付(CD)工具都可以与Git交互。有些还直接与GitHub、GitHubEnterprise、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)工具具有不同级别的支持和文档。对于其他产品，组织可能需要调查文档和支持论坛以及付费支持选项，作为组织在选择工具时尽职调查的一部分。组织不应假定一个平台是其所有软件开发项目的最佳选择。大多数组织使用多种编程语言和环境，并不是每一个持续集成（CI）/持续交付（CD）平台都能很好地支持它们。组织需要选择最适合其每个项目的持续集成(CI)/持续交付(CD)平台，而不是寻找折衷的平台。持续集成(CI)/持续交付(CD)的原则是从一个平台迁移到另一个平台，即使组织为它们编写的脚本并不总是可移植的。虽然组织的DevOps团队可能需要一些时间来学习和熟悉每个新平台，但这可能比需要持续集成(CI)/持续交付(CD)工具的广泛定制成本更低。规划未来的CI/CD迁移同样，组织不应假设给定的CI/CD平台将始终满足其项目需求。例如，将脚本存储在存储库中而不是持续集成(CI)/持续交付(CD)工具中。在适当的情况下更喜欢无服务器持续集成（CI）/持续交付（CD）通常，容器部署比云服务器实例部署便宜，无服务器云部署比容器部署便宜。如今，很少有持续集成(CI)/持续交付(CD)平台可以无服务器运行。无服务器意味着运行感兴趣的进程的容器在必要时被实例化，通常只是为了响应一个事件。对于持续集成(CI)/持续交付(CD)，触发事件通常是将代码签入到特定的存储库分支；存储库webhook然后启动无服务器进程。当该过程完成时，将释放这些资源。ServerlessCI/CD是为数不多的可以无服务器运行的持续集成(CI)/持续交付(CD)平台之一，它是ServerlessFramework的增强版本。ServerlessCI/CD针对部署Serverless应用程序进行了优化，目前仅在AWS云平台上运行。组织必须确定它在使用时是否为他们的应用程序提供了充分的支持。您当前的云资产在哪里？要优化基于云的持续集成(CI)/持续交付(CD)配置，如果您的所有资产彼此“更接近”，它会有所帮助。而“邻近”是指彼此在地理上的邻近性或指网络位置彼此的邻近性。例如，如果一个组织的数据库存储在澳大利亚，而应用程序位于北美，则每次应用程序需要读取或写入数据时都可能出现明显的延迟。在较小的规模上，如果组织的应用程序和数据库位于同一云平台可用性区域(AZ)，则它们之间的延迟会最小化。如果是同一地区的不同可用区（AZ），延迟会增加，但不会像不同地区一样高。同样，如果一个组织的数据库位于弗吉尼亚州的谷歌云平台上，而其应用程序位于弗吉尼亚州的MicrosoftAzure云平台上，则延迟将高于数据库和应用程序位于同一可用区的同一云平台上。所有这些也适用于组织的存储库、持续集成(CI)/持续交付(CD)软件、实际应用程序以及开发人员和测试人员。如果所有这些都彼此“更接近”，那将会有所帮助，尽管在这种情况下，延迟的影响不像实时互动游戏那样明显。如果开发人员能够在没有明显延迟的情况下可靠地将代码提交推送到主存储库，他们通常会获得良好的体验。同样，如果用户和测试人员在亚秒级响应时间内“接近”应用程序，他们也会这样做。对于持续集成(CI)/持续交付(CD)软件，关键是与部署点的可靠连接。只要不导致超时或数据包丢失，一点延迟是可以容忍的，一旦CI/CD完全实施，它将成为您基础设施的重要组成部分。随着组织加速实施，需要牢记这一点。在开始推出持续集成(CI)/持续交付(CD)管道之前执行严格的概念验证非常重要。在开始持续交付(CD)阶段之前，请注意持续集成(CI)部分。在将任何持续集成(CI)/持续交付(CD)管道连接到生产实例之前，您需要确保练习测试套件和回滚功能，并让您组织的员工参与，直到您非常确定您的自动化是可靠的。原标题：如何选择基于云的CI/CD平台，作者：MartinHeller
