2.CICD概述 软件发布流程

什么是CI（Continuous integration持续集成）

在传统的软件开发中，集成过程通常在每个人完成工作后的项目结束时进行。整合通常需要数周或数月的时间，可能会非常痛苦。持续集成是一种将集成阶段置于开发周期中较早的做法，因此，构建，测试和集成代码的时间安排更为规则。

开发人员通常使用称为CI Server的工具来进行构建和集成。CI要求自检代码。这是用于自我测试以确保其按预期工作的代码，这些测试通常称为单元测试。集成代码后，当所有单元测试通过时，将得一个最新的的代码版本。这表明他们已经验证了自己的更改已成功集成到一起，并且代码按测试期望的那样工作。

什么是CD（Continuous delivery持续交付）

持续交付意味着每次更改代码，集成并构建代码时，他们还将在与生产非常相似的环境中自动测试该代码。我们将此部署到不同环境并在不同环境上进行测试的过程称为部署管道。部署管道通常具有开发环境，测试环境和过渡环境，但是这些阶段因团队，产品和组织而异。

在每个不同的环境中，开发人员编写的代码都经过不同的测试。当代码在生产环境中部署时，它们将在生产环境中工作。至关重要的是，代码只提升到（上测试）在部署管道的下一个环境，如果出现故障，整个团队可以更轻松地了解问题可能出在哪里，并在代码进入生产环境之前予以解决。这个过程对我们这个行业的人来说非常强大。这意味着，如果代码的测试在所有环境中都通过了，团队负责人就会知道开发人员的代码在投入生产时可能会按预期工作。一旦测试在所有环境中通过，团队负责人就可以立即决定最终用户是否通过测试。我们现在要在生产中使用这种绿色产品吗？是! 因此，一旦开发人员完成构建，便可以立即为客户提供经过全面测试的全新工作软件。

什么是CD（Continuous deployment持续部署）

在这种实践中，团队负责人所做的每一项更改都通过了所有测试阶段，并自动投入生产。要实现连续部署，团队负责人首先需要进行连续交付，因此在开始练习连续部署之前，先决定哪个对您更合适，持续交付都是为了增强整个业务的能力，因此至少您应该参与确定是否应该使用持续部署。

持续集成，持续部署和持续交付之间有什么区别？

1）持续集成（Continuous integration）

这种做法是将团队中不同开发人员的变更尽早集成到主线中，最好每天进行几次。这样可以确保各个开发人员处理的代码不会转移太多。当您将流程与自动化测试结合在一起时，持续集成可以使您的代码变得可靠。

2）持续交付（Continuous delivery）

保持代码库随时可部署的做法。除了确保您的应用程序通过自动化测试外，它还必须具有将其投入生产所需的所有配置。然后，许多团队会进行推送更改，以立即将自动化测试传递到测试或生产环境中，以确保快速的开发周期。

3）持续部署（continuous deployment）

与持续集成密切相关，是指保持您的应用程序可随时部署，甚至在最新版本通过所有自动化测试的情况下，甚至自动发布到测试或生产环境。

4) 持续交付（Continuous delivery）与持续部署的关系

有时候，持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。
持续交付表示的是一种能力
而持续部署则是一种方式

CI/CD应用场景

1）开发人员将本地代码上传gitlab版本服务器

2）jenkins通过webhook插件自动到gitlab服务器拉取最新代码

3）通过docker-maven-plugin插件自动编译代码

4）将自定义镜像上传docker私服仓库

5）k8s集群自动拉取最新版本镜像

6）自动化部署整个项目

7）用户通过nginx负载均衡访问整个项目

为什么需要CI/CD

持续集成（CI）是一种开发实践，其中开发人员经常（最好每天几次）将代码集成到共享存储库中。然后可以通过自动构建和自动测试来验证每个集成。尽管自动化测试不是严格意义上的CI的一部分，但通常隐含了它。
定期集成的主要好处之一是，您可以快速检测到错误并更轻松地定位它们。由于引入的每个更改通常很小，因此可以快速查明引入缺陷的特定更改。
近年来，CI已成为软件开发的最佳实践，并遵循一系列关键原则。其中包括版本控制，构建自动化和自动化测试。
此外，持续部署和持续交付已成为最佳实践，可让您随时随地部署应用程序，甚至在每次引入新更改时甚至将主代码库自动推入生产环境。这使您的团队可以快速行动，同时保持可以自动检查的高质量标准。

docker CICD流程

kubernetes CICD流程

概念区分：灰度发布、蓝绿发布、滚动发布

背景
线上的项目最容易出现问题的时候就是发布的过程中。如果将某变化较大的版本一次全部线上发布给用户，遇到生产事故对用户的影响会非常大，甚至有时需要紧急回滚到前一版本。因此在发布的时候可以采取一些措施来防止问题的扩散。
常见的发布方案有：蓝绿发布、滚动发布、灰度发布

蓝绿发布

蓝绿部署，是指同时运行两个版本的应用。

在蓝绿部署时，蓝绿部署的时候，并不停止掉老版本，而是直接部署一套新版本，等新版本运行起来后，再将流量切换到新版本上。
例如发布前，在蓝色的系统上进行测试，测试完成后切换为蓝色系统，同时观察蓝色系统的运行状态，如果运行出现问题可以及时切回绿色系统。

优点
这样做可以减少发布影响的时间。例如某网站要进行后端升级，无需完全停掉服务更新，且出现问题后可以及时切回老版本。
缺点
需要两倍的硬件资源，需要额外进行付费；微服务架构很难这样进行迁移；要求蓝绿两套系统完全没有耦合；迁移后未完成的任务进行迁移需要一定的成本，如数据库的迁移。

滚动发布

一般是取出部分服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本。

如上图所示，先取出一部分的机器，执行更新逻辑；更新完成后，让流量流向此更新完成的机器。

优点：不需要准备两套完整的机器，节约资源
缺点：回滚困难，流量直接到新的机器上，出现问题后，无法实现快速回滚；更新时间长，带来额外的风险，如果80%完成更新后发生重大漏洞，回滚会比较耗时和困难。

灰度发布

灰度发布，又名金丝雀发布，是指在黑与白之间能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
17世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。

在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来。测试成功后，将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比。当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。

常见名词
灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。
流量切分：例如具体在部署的服务器上，给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数，然后逐渐提高权重、增加请求数。这个过程叫流量切分。

灰度策略
常见的灰度策略有：

按照比例划分

可以搭配负载均衡使用，如5%的用户首先使用新的版本，95%的仍然使用老版本。

按照用户属性划分

如限制IP、地域、性别、年龄或者浏览时间、客户等级等等用户画像，例如活跃度高的用户优先使用新版本

按照渠道划分

如内部客户优先使用新版本，大客户要保证服务稳定，使用旧版本
可以根据自己的业务情况以及变更情况修改自己的灰度策略。例如，某产品UI发生了变化，可以根据比例进行流量切分；某产品上线了新的接口，可以按照用户属性，优先内部客户和中小客户使用新版本。

但是，为了找到符合业务逻辑和需求的灰度发布，是需要开发人员进行额外的开发工作的，尤其项目如果同时涉及前端和后端，需要两边都要进行灰度发布的支持。