预期“ AWS，Azure和Gitlab上的CI / CD”课程将开始，我们已为您准备了有用材料的翻译。
持续集成（CI）和持续交付（CD）是一种文化，是一组原则和实践，使开发人员可以更频繁，更可靠地部署软件更改。
CI / CD是DevOps的实践之一。它也适用于敏捷实践：部署自动化使开发人员可以专注于满足业务需求，代码质量和安全性。
CI / CD的定义
持续集成是一种开发方法论和一组实践，在这些实践中，频繁提交对代码进行小的更改。而且，由于大多数现代应用程序是使用各种平台和工具开发的，因此需要一种集成机制并测试引入的更改。
从技术上讲，CI的目标是提供一种一致，自动化的方式来构建，打包和测试应用程序。通过简化的持续集成过程，开发人员更有可能进行频繁的提交，从而有助于改善沟通和软件质量。
持续交付从持续集成结束的地方开始。它可以自动将应用程序部署到不同的环境：大多数开发人员都在生产环境以及开发和测试环境中工作。
CI / CD工具有助于设置在部署期间配置的特定环境参数。此外，CI / CD自动化还会对Web服务器，数据库和其他服务执行必要的请求，这些请求可能需要在部署应用程序时重新启动或执行一些其他操作。
持续集成和持续交付需要持续测试因为最终目标是开发高质量的应用程序。连续测试通常被实现为在CI / CD管道中执行的各种自动化测试（回归，性能和其他测试）的集合。
CI / CD的成熟实践允许连续部署：当代码成功通过CI / CD管道时，程序集将自动部署到生产环境。练习连续交付的团队可以负担每天甚至每小时的部署。但是，在这里值得注意的是，连续交付并不适合所有业务应用程序。
持续集成可改善沟通和质量
持续集成是一种基于规范流程和自动化的开发方法。实施持续集成后，开发人员通常会将其代码提交到源代码存储库。大多数团队遵循每天至少提交一次的规则。与长时间以来进行的大更改相比，小更改更容易发现缺陷和其他问题。此外，使用较短的提交周期可以减少多个开发人员更改同一段代码的可能性，这可能导致合并冲突。
实施持续集成的团队通常从建立版本控制系统和定义工作流程开始。尽管经常进行提交，但是实现功能和修复错误可能会花费很长时间。有几种方法可以控制准备好哪些功能和代码。
许多人使用功能标记-一种在运行时打开和关闭功能的机制。仍在开发中的功能被包装在功能标记中，并从master分支部署到生产中，但是在完全准备好使用之前被禁用。根据最近的一项研究使用标记功能的团队中有63％的团队报告了改进的可测试性和改进的软件质量。有一些用于处理功能标志的特殊工具，例如CloudBees Rollout，Optimizely Rollouts和LaunchDarkly，它们集成到CI / CD中，并允许您在功能级别执行配置。
使用功能的另一种方法是在版本控制系统中使用分支。在这种情况下，您需要定义一个分支模型（例如，Gitflow），并描述代码如何进入开发，测试和生产分支。对于开发周期较长的要素，将创建单独的要素分支。在完成功能工作之后，开发人员将更改从功能分支合并到主开发分支。这种方法效果很好，但是如果同时开发许多功能，可能会带来不便。
构建阶段是使所需软件，数据库和其他组件的包装自动化。例如，如果您正在开发Java应用程序，则CI将打包所有静态文件（如HTML，CSS和JavaScript）以及Java应用程序和数据库脚本。
CI不仅将打包所有软件组件和数据库，还将自动执行单元测试和其他类型的测试。通过此测试，开发人员可以获得有关所做的更改没有破坏任何内容的反馈。
大多数CI / CD工具允许您手动，按提交或按计划开始构建。团队需要根据团队规模，预期的每日提交次数和其他条件，讨论适合自己的构建计划。快速的提交和构建很重要，否则长的构建可能成为开发人员尝试快速频繁地提交的障碍。
持续测试不仅仅是测试自动化
自动化的测试框架可帮助质量检查工程师设计，运行和自动化各种类型的测试，以帮助开发人员跟踪构建成功。测试包括在每个冲刺结束时开发的功能测试，并结合到整个应用程序的回归测试中。回归测试会通知团队，如果他们的更改破坏了应用程序中其他地方的内容。
最佳实践是要求开发人员在其本地环境中运行全部或部分回归测试。这将确保开发人员提交已检查的代码。
回归测试仅仅是开始。性能测试，API测试，静态代码分析，安全测试-这些和其他类型的测试也可以自动化。关键是可以从命令行，通过Webhook或通过Web服务运行这些测试并返回执行结果的能力：测试是否成功。
连续测试不仅涉及自动化，而且还涉及将自动化测试集成到CI / CD管道中。单元测试和功能测试可以作为CI的一部分，并在启动CI管道之前或期间识别问题。需要完全环境部署的测试（例如性能和安全性测试）通常是CD的一部分，并且在将构建部署到目标环境后才运行。
CD管道可自动将更改交付到不同的环境
持续交付是将应用程序自动部署到其目标环境。通常，开发人员在一个或多个开发和测试环境中工作，在该环境中部署了应用程序以进行测试和审查。为此，使用了CI / CD工具，例如Jenkins，CircleCI，AWS CodeBuild，Azure DevOps，Atlassian Bamboo，Travis CI。
典型的CD管道包括构建，测试和部署步骤。更复杂的管道包括以下步骤：
- 从源代码管理中检索代码并执行构建。
- 通过基础结构即代码方法自动配置基础结构。
- 将代码复制到目标环境。
- 为目标环境设置环境变量。
- (-, API-, ).
- , , .
- .
- .
例如，在詹金斯传送带确定的文件Jenkinsfile中，它描述了各个步骤，例如组装（构建），测试（测试）和部署（部署）。它还描述了可以在管道阶段使用的环境变量，秘密密钥，证书和其他参数。帖子部分配置错误处理和通知。
在更复杂的CD流水线中，可能会有其他步骤，例如数据同步，归档信息资源，安装更新和补丁。 CI / CD工具通常支持插件。例如，Jenkins有1500多个插件，可与第三方平台集成，以扩展用户界面，管理，源代码管理和构建。
使用CI / CD工具时，开发人员必须确保通过环境变量在应用程序外部配置所有参数。CI / CD工具可让您设置这些变量的值，屏蔽密码和帐户密钥，并在部署过程中针对特定环境自定义它们。
CD工具中也有仪表板和报告。万一构建或交付失败，他们会通知它。通过将CD与版本控制和敏捷工具集成在一起，可以更轻松地找到构建中包含的代码更改和用户案例。
使用Kubernetes和无服务器架构实现CI / CD管道
许多在云中使用CI / CD管道的团队使用诸如Docker之类的容器以及诸如Kubernetes之类的编排系统。容器有助于标准化包装，交付，并简化缩放和破坏易变环境。
有许多选项可以共享容器，作为代码的基础结构以及CI / CD管道。您可以了解更多有关此内容的文章与詹金斯Kubernetes和Kubernetes与Azure中的DevOps。
无服务器计算是部署和扩展应用程序的另一种方法。在无服务器环境中，基础架构由云提供商完全管理，并且应用程序根据其设置根据需要消耗资源。例如，在AWS中，无服务器应用程序通过AWS Lambda函数运行，可以使用插件将其部署集成到Jenkins CI / CD管道中。
CI / CD使代码部署更加频繁
因此，让我们总结一下。 CI会打包，测试并在出现问题时通知开发人员。 CD会自动部署应用程序并运行其他测试。
CI / CD管道是为需要通过可靠的交付过程对应用程序进行频繁更改的组织而设计的。除了标准化构建，开发测试和自动化部署之外，我们还获得了用于部署代码更改的整体工作流程。实施CI / CD可使开发人员专注于改进其应用程序，而不会浪费时间部署它们。
CI / CD是DevOps的实践之一因为它旨在消除想要进行频繁更改和开发的开发人员之间的矛盾，而这需要稳定性。借助自动化，开发人员可以更频繁地进行更改，而操作团队则可以提高稳定性，因为环境配置是标准化的，并且在交付过程中进行了连续测试。此外，环境变量的设置与应用程序是分开的，并且有自动回滚过程。
可以根据DevOps关键绩效指标（KPI）来衡量实施CI / CD管道的影响... 通过持续测试的CI / CD部署，诸如部署频率，更改交付周期和平均恢复时间之类的KPI通常会得到改善。但是，CI / CD只是可以促进这些改进的一种过程。还有其他条件可以提高交货频率。
要开始使用CI / CD，开发和运营团队需要就技术，实践和优先级进行协作。团队需要就其业务和技术的正确方法建立共识，以便在实施CI / CD之后，团队始终遵循所选的做法。
CICD工具简介：Gitlab CI，Docker，Ansible