共计 4175 个字符，预计需要花费 11 分钟才能阅读完成。
在 CI/CD 和 DevOps 畛域中，继续交付和继续部署是一个陈词滥调的话题。继续集成这个术语最早是在 1994 年由 Grady Booch 提出。微服务提出者 Martin Flower 在 2014 年发表的论文《Microservice》中也对软件开发继续集成提供了可参考准则。继续集成是借助工具对软件我的项目进行继续的自动化的编译打包构建测试公布，来查看软件交付品质的一种行为。而继续部署是基于继续交付的劣势主动将通过测试的代码推入生产环境的过程。下文从细节形容了继续集成和继续部署各阶段的关键步骤。
本文将探讨 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 阶段：了解参与者、流程、技术
企业应用程序开发参与者通常由开发人员，测试人员 /QA 工程师，运维工程师以及 SRE（站点可靠性工程师）或 IT 经营团队组成。他们严密单干，指标是高质量软件交付。CI/CD 是两个独立过程的组合：继续集成和继续部署。上面列出了每个步骤中的次要步骤：
继续集成
继续集成（CI）是构建软件和实现初始测试的过程。继续部署（CD）是将代码与基础设施相结合的过程，确保实现所有测试并遵循策略，而后将代码部署到预期环境中。当然，许多公司也有本人特有流程，但次要步骤如下。
CI：代码提交阶段
参与者：开发工程师，数据库管理员（DBA），基础架构团队
技术：GitHub，GitLab，SVM，BitBucket
流程：代码提交阶段也称为版本控制。提交是将开发人员编写的最新代码变更发送到代码存储库的操作。开发人员编写的代码的每个版本都被无限期地存储。在与合作者探讨和审查变更之后，开发人员将编写代码，并在软件需要、个性加强、bug 修复或变更申请实现后提交。治理编辑和提交变更的存储库称为源代码管理工具（配置管理工具）。在开发人员提交代码（代码推送申请）后，代码更改被合并到主线代码分支中，这些主线代码分支存储在 GitHub 这样的地方存储库中。
CI：动态代码查看阶段
参与者：开发工程师，数据库管理员（DBA），基础架构团队
技术：GitHub，GitLab，SVM，BitBucket
流程：开发人员编写代码并将其推送到存储库后，零碎将主动触发以启动下一个代码剖析过程。开发过程中存在这种状况：提交的代码能够构建胜利，但在部署期间构建失败。无论从机器还是人力资源的利用率而言，这都是一个迟缓而低廉的过程。因而必须查看代码中的动态策略。SAST（动态应用程序安全性测试）：SAST 是一种白盒测试方法，能够应用 SonarQube，Veracode，Appscan 等 SAST 工具从外部查看代码，以发现软件缺陷，破绽和弱点（例如 SQL 注入等）。这是一个疾速查看过程，其中查看代码是否存在语法错误。只管此阶段短少查看运行时谬误的性能，但该性能将在当前的阶段中执行。
将额定的策略查看退出自动化流水线中能够显著缩小流程中稍后发现的谬误数量。
CI：构建
参与者：开发工程师
技术：Jenkins，Bamboo CI，Circle CI，Travis CI，Maven，Azure DevOps
流程：继续集成过程的指标是提交的代码继续构建为二进制文件或构建产物。通过继续集成来查看增加的新模块是否与现有模块兼容，不仅有助于更快地发现 bug，还有助于缩小验证新代码更改的工夫。构建工具能够依据简直所有编程语言的源代码创立可执行文件或包（.exe，.dll，.jar 等）。在构建过程中，还能够生成 SQL 脚本，配合基础设施配置文件一起进行测试。简而言之，构建阶段就是编译应用程序的阶段。Artifactory 存储、构建验证测试和单元测试也能够作为构建过程的一部分。
构建验证测试（BVT）/ 冒烟测试 / 单元测试：
创立构建后立刻执行冒烟测试。BVT 将查看所有模块是否正确集成，以及程序的要害性能是否失常运行。这样做的目标是回绝重大损坏的应用程序，以使 QA 团队不会在装置和测试软件应用程序步骤浪费时间。
在实现这些查看后，将向流水线中执行 UT（单元测试），以进一步缩小生产中的故障。单元测试可验证开发人员编写的单个单元或组件是否按预期执行。
构建产物存储：
一旦构建就绪，程序包就会存储在称为 Artifactory 或 Repository 工具的地方数据库。随着每天构建量的减少，跟踪所有构建产物也会变得更加艰难。因而，一旦生成并验证了构建产物，就将其发送到存储库进行存储管理。诸如 Jfrog Artifactory 之类的存储库工具可用于存储诸如.rar，.war，.exe，Msi 等之类的二进制文件。测试人员能够从此处手动进行抉择，并在测试环境中部署构建产物以进行测试。
CI：测试阶段
参与者：测试人员、QA
技术：Selenium，Appium，Jmeter，SOAP UI，Tarantula
过程：公布构建过程后的一系列自动测试将验证代码的准确性。此阶段可帮忙防止生产中的谬误。依据构建的大小，此查看可能继续数秒至数小时。对于由多个团队提交和构建代码的大型组织，这些查看在并行环境中运行，以节俭贵重的工夫并尽早将谬误告诉开发人员。
测试人员（或称为 QA 工程师）基于用户形容的测试用例和场景设置自动化测试用例。他们执行回归剖析、压力测试来查看与预期输入的偏差。测试中波及的流动有完整性测试、集成测试、压力测试。这是一个高层次测试方法。在这个阶段，能够发现开发人员漠视的某些代码问题。
集成测试：
集成测试是应用 Cucumber、Selenium 等工具执行的，在这些工具中，单个利用程序模块被组合起来并作为一组进行测试，同时评估其是否合乎指定的性能需要。在集成测试之后，须要有人批准该组中的更新集应该移到下一个阶段，这通常是性能测试。这个验证过程可能很麻烦，但它是整个过程的一个重要局部。验证这个过程业界有很多优良的计划。
性能和压力测试：
Selenium、JMeter 等自动化测试工具也可执行性能和压力测试，以查看应用程序在面对高负载时是否稳固和性能良好。该测试流程通常不会在每个更新提交上运行，因为残缺的压力测试是长期运行的。当公布次要的新性能时，将对多个更新进行分组，并实现残缺的性能测试。在单个更新被转移到下一阶段的状况下，流水线可能将金丝雀测试退出作为可选。
继续部署：Bake 和部署
参与者：基础架构工程师，SRE，运维工程师
技术：Spinnaker，Argo CD，Tekton CD
过程：在测试阶段实现之后，能够部署到服务器的规范代码准备就绪。在部署到生产中之前，它们将被部署到产品团队外部应用的测试环境或 beta 环境。在将构建移至这些环境之前，构建必须通过 Bake 和 Deploy 的子阶段。这两个阶段都是 Spinnaker 所反对存在的。
CD：Bake
Baking 是指在生产时应用以后配置从源代码创立不可变的镜像实例。这些配置可能是数据库更改和其余根底构造更新之类的事件。Spinnaker 能够触发 Jenkins 执行此工作，并且某些组织更喜爱应用 Packer。
CD：部署
Spinnaker 主动将已 bake 的镜像发送到部署阶段。这是将服务器组设置为部署到集群的地位。与上述测试过程相似，在部署阶段将执行性能雷同的过程。首先将部署移至测试阶段，而后最终移至生产环境，以进行批准和查看。这个处理过程能够由 Spinnaker 等工具反对。
CD：验证
这也是团队优化整个 CI/CD 流程的要害地位。因为当初曾经进行了如此多的测试，所以失败很少见。然而，此时必须尽快解决所有故障，以最大水平地缩小对最终客户的影响。团队也应该思考使流程的这一部分自动化。
应用蓝绿部署、金丝雀剖析、滚动更新等策略部署到产品。在部署阶段，将监督正在运行的应用程序以验证以后部署是否正确或是否须要回滚。
CD：监控
参与者：站点可靠性工程师（SRE）、经营团队
技术：Zabbix、Nagios、Prometheus、Elastic Search、Splunk、Appdynamics、Tivoli
过程：为了使软件发行版具备故障安全性和健壮性，在生产环境中跟踪发行版的运行状况至关重要。应用程序监督工具将跟踪性能指标，例如 CPU 利用率和发行版提早。日志分析器将扫描由底层中间件和操作系统产生的大量日志，以辨认行为并跟踪问题的本源。如果生产中呈现任何问题，将告诉利益相关者以确保生产环境的安全性和可靠性。此外，监督阶段可帮忙组织收集无关其新软件更改如何为支出奉献的情报，帮忙基础设施团队跟踪零碎行为趋势并进行容量布局。
继续交付（CD）：反馈和合作工具
参与者：站点可靠性工程师（SRE）、经营和保护团队。
技术：JIRA、ServiceNow、Slack、电子邮件、Hipchat。
过程：DevOps 团队的指标是更快地继续公布，而后一直缩小谬误和性能问题。这是通过不断地通过发送电子邮件向开发人员、项目经理提供无关新版本的品质和性能的反馈。通常状况下，反馈系统是整个软件交付过程的一部分。因而，交付中的任何更改都会频繁地录入零碎，以便交付团队能够对它采取行动。
总结
企业必须评估一个整体的继续交付解决方案，该解决方案能够自动化或促成上述这些阶段的自动化。
写在最初
欢送大家关注我的公众号【 惊涛骇浪如码 】，海量 Java 相干文章，学习材料都会在外面更新，整顿的材料也会放在外面。
感觉写的还不错的就点个赞，加个关注呗！点关注，不迷路，继续更新！！！
