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