CICD流程
CI/CD 是⼀种通过在应⽤开发阶段引⼊⾃动化来频繁向客户交付应⽤的⽅法。CI/CD 的核⼼概念是持续集成、持续交付和持续部署。
什么是持续
频繁发布
⾃动化流程
可重复
快速迭代
CI 持续集成
持续集成（CI）可以帮助开发⼈员更加频繁地（有时甚⾄每天）将代码更改合并到共享分⽀或“主⼲”中。⼀旦开发⼈员对应⽤所做的更改被合并，系统就会通过⾃动构建应⽤并运⾏不同级别的⾃动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应⽤造成破坏。这意味着测试
内容涵盖了从类和函数到构成整个应⽤的不同模块。如果⾃动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。
持续集成是启动管道的环节（尽管某些预验证 —— 通常称为上线前检查pre-flight checks —— 有时会被归在持续集成之前）。
持续集成的基本思想是让⼀个⾃动化过程监测⼀个或多个源代码仓库是否有变更。当变更被推送到仓库时，它会监测到更改、下载副本、构建并运⾏任何相关的单元测试。
监测变更
监测程序通常是像 Jenkins 这样的应⽤程序，它还协调管道中运⾏的所有（或⼤多数）进程，监视变更是其功能之⼀。监测程序可以以⼏种不同⽅式监测变更。这些包括：
轮询：监测程序反复询问代码管理系统，“代码仓库⾥有什么我感兴趣的新东西吗？”当代码管理系统有新的变更时，监测程序会“唤醒”并完成其⼯作以获取新代码并构建/测试它。
定期：监测程序配置为定期启动构建，⽆论源码是否有变更。理想情况下，如果没有变更，则不会构建任何新内容，因此这不会增加额外的成本。
推送：这与⽤于代码管理系统检查的监测程序相反。在这种情况下，代码管理系统被配置为提交变更到仓库时将“推送”⼀个通知到监测程序。最常见的是，这可以以 webhook 的形式完成 —— 在新代码被推送时⼀个挂勾hook的程序通过互联⽹向监测程序发送通知。为此，监测程序必须具有可以通过⽹络接收 webhook 信息的开放端⼝。
CD 持续交付（Continuous Delivery）
完成 CI 中构建及单元测试和集成测试的⾃动化流程后，持续交付可⾃动将已验证的代码发布到存储库。为了实现⾼效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的⽬标是拥有⼀个可随时部署到⽣产环境的代码库。
持续交付（CD）通常是指整个流程链（管道），它⾃动监测源代码变更并通过构建、测试、打包和相关操作运⾏它们以⽣成可部署的版本，基本上没有任何⼈为⼲预。
持续交付在软件开发过程中的⽬标是⾃动化、效率、可靠性、可重复性和质量保障（通过持续测试）。
持续交付包含持续集成（⾃动检测源代码变更、执⾏构建过程、运⾏单元测试以验证变更），持续测试（对代码运⾏各种测试以保障代码质量），和（可选）持续部署（通过管道发布版本⾃动提供给⽤户）。
持续交付管道
将源代码转换为可发布产品的多个不同的任务task和作业job通常串联成⼀个软件“管道”，⼀个⾃动流程成功完成后会启动管道中的下⼀个流程。这些管道有许多不同的叫法，例如持续交付管道、部署管道和软件开发管道。⼤体上讲，程序管理者在管道执⾏时管理管道各部分的定义、运⾏、监控和报告。
管道⼯作流程
有许多程序可⽤在管道中，⽤于源代码跟踪、构建、测试、指标采集，版本管理等各个⽅⾯。但整体⼯作流程通常是相同的。单个业务流程/⼯作流应⽤程序管理整个管道，每个流程作为独⽴的作业运⾏或由该应⽤程序进⾏阶段管理。通常，在业务流程中，这些独⽴作业是以应⽤程序可理解并可作为⼯作流程管理的语法和结构定义的。
这些作业被⽤于⼀个或多个功能（构建、测试、部署等）。每个作业可能使⽤不同的技术或多种技术。关键是作业是⾃动化的、⾼效的，并且可重复的。如果作业成功，则⼯作流管理器将触发管道中的下⼀个作业。如果作业失败，⼯作流管理器会向开发⼈员、测试⼈员和其他⼈发出警报，以便他们尽快纠正问题。这个过程是⾃动化的，所以⽐⼿动运⾏⼀组过程可更快地到错误。这种快速排错称为快速失败fail fast，并且在抵达管道端点⽅⾯同样有价值。
“快速失败”是什么意思？
管道的⼯作之⼀就是快速处理变更。另⼀个是监视创建发布的不同任务/作业。由于编译失败或测试未通过的代码可以阻⽌管道继续运⾏，因此快速通知⽤户此类情况⾮常重要。**快速失败指的是在管道流程中尽快发现问题并快速通知⽤户的⽅式，这样可以及时修正问题并重新提交代码以便使管道再次运⾏。**通常在管道流程中可通过查看历史记录来确定是谁做了那次修改并通知此⼈及其团队。
所有持续交付管道都应该被⾃动化吗？
管道的⼏乎所有部分都是应该⾃动化的。对于某些部分，有⼀些⼈为⼲预/互动的地⽅可能是有意义的。⼀个例⼦可能是⽤户验收测试user-acceptance testing（让最终⽤户试⽤软件并确保它能达到他们想要/期望的⽔平）。另⼀种情况可能是部署到⽣产环境时⽤户希望拥有更多的⼈为控制。当然，如果代码不正确或不能运⾏，则需要⼈⼯⼲预。
有了对“持续”含义理解的背景，让我们看看不同类型的持续流程以及它们在软件管道上下⽂中的含义。
CD 持续部署（Continuous Deployment）
对于⼀个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付——⾃动将⽣产就绪型构建版本发布到代码存储库——的延伸，持续部署可以⾃动将应⽤发布到⽣产环境。由于在⽣产之前的管
道阶段没有⼿动门控，因此持续部署在很⼤程度上都得依赖精⼼设计的测试⾃动化。
实际上，持续部署意味着开发⼈员对应⽤的更改在编写后的⼏分钟内就能⽣效（假设它通过了⾃动化测试）。这更加便于持续接收和整合⽤户反馈。总⽽⾔之，所有这些 CI/CD 的关联步骤都有助于降低应⽤的部署风险，因此更便于以⼩件的⽅式（⽽⾮⼀次性）发布对应⽤的更改。不过，由于还需要编写⾃动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很⼤。
什么是“单元测试”？
单元测试（也称为“提交测试”），是由开发⼈员编写的⼩型的专项测试，以确保新代码独⽴⼯作。“独⽴”这⾥意味着不依赖或调⽤其它不可直接访问的代码，也不依赖外部数据源或其它模块。如果运⾏代码需要这样的依赖关系，那么这些资源可以⽤模拟mock来表⽰。模拟是指使⽤看起来像资源的代码存根code stub，可以返回值，但不实现任何功能。
在⼤多数组织中，开发⼈员负责创建单元测试以证明其代码正确。事实上，⼀种称为测试驱动开发test-driven develop（TDD）的模型要求将⾸先设计单元测试作为清楚地验证代码功能的基础。因为这样的代码可以更改速度快且改动量⼤，所以它们也必须执⾏很快。
由于这与持续集成⼯作流有关，因此开发⼈员在本地⼯作环境中编写或更新代码，并通单元测试来确
保新开发的功能或⽅法正确。通常，这些测试采⽤断⾔形式，即函数或⽅法的给定输⼊集产⽣给定的输出集。它们通常进⾏测试以确保正确标记和处理出错条件。有很多单元测试框架都很有⽤，例如⽤于 Java 开发的 JUnit。
什么是“持续测试”？
持续测试是指在代码通过持续交付管道时运⾏扩展范围的⾃动化测试的实践。单元测试通常与构建过程集成，作为持续集成阶段的⼀部分，并专注于和其它与之交互的代码隔离的测试。
除此之外，可以有或者应该有各种形式的测试。这些可包括：
集成测试 验证组件和服务组合在⼀起是否正常。
功能测试 验证产品中执⾏功能的结果是否符合预期。
验收测试 根据可接受的标准验证产品的某些特征。如性能、可伸缩性、抗压能⼒和容量。
所有这些可能不存在于⾃动化的管道中，并且⼀些不同类型的测试分类界限也不是很清晰。但是，在交付管道中持续测试的⽬标始终是相同的：通过持续的测试级别证明代码的质量可以在正在进⾏的发布中使⽤。在持续集成快速的原则基础上，第⼆个⽬标是快速发现问题并提醒开发团队。这通常被称为快速失败。
除了测试之外，还可以对管道中的代码进⾏哪些其它类型的验证？
除了测试是否通过之外，还有⼀些应⽤程序可以告诉我们测试⽤例执⾏（覆盖）的源代码⾏数。这是⼀个可以衡量代码量指标的例⼦。这个指标称为代码覆盖率code-coverage，可以通过⼯具（例如⽤于 Java 的 JaCoCo）进⾏统计。
还有很多其它类型的指标统计，例如代码⾏数、复杂度以及代码结构对⽐分析等。诸如 SonarQube 之类的⼯具可以检查源代码并计算这些指标。此外，⽤户还可以为他们可接受的“合格”范围的指标设置阈值。然后可以在管道中针对这些阈值设置⼀个检查，如果结果不在可接受范围内，则流程终端上。SonarQube 等应⽤程序具有很⾼的可配置性，可以设置仅检查团队感兴趣的内容。
在完全部署到所有⽤户之前，有哪些⽅法可以测试部署？
由于必须回滚/撤消对所有⽤户的部署可能是⼀种代价⾼昂的情况（⽆论是技术上还是⽤户的感知），已经有许多技术允许“尝试”部署新功能并在发现问题时轻松“撤消”它们。这些包括：
蓝/绿测试/部署
在这种部署软件的⽅法中，维护了两个相同的主机环境 —— ⼀个“蓝⾊” 和⼀个“绿⾊”。（颜⾊并不重要，仅作为标识。）对应来说，其中⼀个是“⽣产环境”，另⼀个是“预发布环境”。
在这些实例的前⾯是调度系统，它们充当产品或应⽤程序的客户“⽹关”。通过将调度系统指向蓝⾊或绿⾊实例，可以将客户流量引流到期望的部署环境。通过这种⽅式，切换指向哪个部署实例（蓝⾊或绿⾊）对⽤户来说是快速，简单和透明的。
当新版本准备好进⾏测试时，可以将其部署到⾮⽣产环境中。在经过测试和批准后，可以更改调度系统设置以将传⼊的线上流量指向它（因此它将成为新的⽣产站点）。现在，曾作为⽣产环境实例可供下⼀次候选发布使⽤。
同理，如果在最新部署中发现问题并且之前的⽣产实例仍然可⽤，则简单的更改可以将客户流量引流回到之前的⽣产实例 —— 有效地将问题实例“下线”并且回滚到以前的版本。然后有问题的新实例可以在其它区域中修复。
⾦丝雀测试/部署提交的东西不能更改
在某些情况下，通过蓝/绿发布切换整个部署可能不可⾏或不是期望的那样。另⼀种⽅法是为⾦丝雀canary测试/部署。在这种模型中，⼀部分客户流量被重新引流到新的版本部署中。例如，新版本的搜索服务可以与当前服务的⽣产版本⼀起部署。然后，可以将 10％ 的搜索查询引流到新版本，以在⽣产环境中对其进⾏测试。
如果服务那些流量的新版本没问题，那么可能会有更多的流量会被逐渐引流过去。如果仍然没有问题出现，那么随着时间的推移，可以对新版本增量部署，直到 100％ 的流量都调度到新版本。这有效地“更替”了以前版本的服务，并让新版本对所有客户⽣效。
功能开关
对于可能需要轻松关掉的新功能（如果发现问题），开发⼈员可以添加功能开关feature toggles。这是代码中的 if-then 软件功能开关，仅在设置数据值时才激活新代码。此数据值可以是全局可访问的位置，部署的应⽤程序将检查该位置是否应执⾏新代码。如果设置了数据值，则执⾏代码；如果没有，则不执⾏。
这为开发⼈员提供了⼀个远程“终⽌开关”，以便在部署到⽣产环境后发现问题时关闭新功能。
暗箱发布
在暗箱发布dark launch中，代码被逐步测试/部署到⽣产环境中，但是⽤户不会看到更改（因此名称中有暗箱dark⼀词）。例如，在⽣产版本中，⽹页查询的某些部分可能会重定向到查询新数据源的服务。开发⼈员可收集此信息进⾏分析，⽽不会将有关接⼝，事务或结果的任何信息暴露给⽤户。
这个想法是想获取候选版本在⽣产环境负载下如何执⾏的真实信息，⽽不会影响⽤户或改变他们的经
验。随着时间的推移，可以调度更多负载，直到遇到问题或认为新功能已准备好供所有⼈使⽤。实际上功能开关标志可⽤于这种暗箱发布机制。
参考资料

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。