什么是CICD
CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。
CI/CD 的核心概念是持续集成、持续交付和持续部署。它是作为一个面向开发和运营团队的解决方案，主要针对在集成新代码时所引发的问题。
CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。
这些关联的事务通常被统称为 CI/CD 管道，由开发和运维团队以敏捷方式协同支持。
CI 持续集成（Continuous Integration）
协同开发是目前主流的开发方式，也就是多位开发人员可以同时处理同一个应用的不同模块或者功能。但是因为代码冲突是难以避免的，如果开发人员本地的环境和线上不一致的话，那么这个问题就更加复杂了。
持续集成（CI）可以帮助开发者更加方便地将代码更改合并到主分支。
一旦开发人员将改动的代码合并到主分支，系统就会通过自动构建应用，并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。
CD 持续交付（Continuous Delivery）
CI 在完成了构建、单元测试和集成测试这些自动化流程后，持续交付可以自动把已验证的代码发布到企业自己的存储库。
持续交付旨在建立一个可随时将开发环境的功能部署到生产环境的代码库。
在持续交付过程中，每个步骤都涉及到了测试自动化和代码发布自动化。
在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。
CD 持续部署（Continuous Deployment）
对于一个完整、成熟的 CI/CD 管道来说，最后的阶段是持续部署。
它是作为持续交付的延伸，持续部署可以自动将应用发布到生产环境。
实际上，持续部署意味着开发人员对应用的改动，在编写完成后的几分钟内就能及时生效（前提是它通过了自动化测试）。这更加便于运营团队持续接收和整合用户反馈。
总而言之，所有这些 CI/CD 的关联步骤，都极大地降低了应用的部署风险。
总结
CI/CD 中的“CI”始终指持续集成，它属于开发人员的自动化流程。成功的 CI 意味着应用代码的新更改会定期构建、测试并合并到共享存储库中。该解决方案可以解决在一次开发中有太多应用分支，从而导致相互冲突的问题。
CI/CD 中的“CD”指的是持续交付和/或持续部署，这些相关概念有时会交叉使用。两者都事关管道后续阶段的自动化，但它们有时也会单独使用，用于说明自动化程度。
持续交付（第一种CD）通常是指开发人员对应用的更改会自动进行错误测试并上传到存储库（如 GitHub 或容器注册表），然后由运维团队将其部署到实时生产环境中。这旨在解决开发和运维团队之间可见性及沟通较差的问题。因此，持续交付的目的就是确保尽可能减少部署新代码时所需的工作量。
持续部署（另一种“CD”）指的是自动将开发人员的更改从存储库发布到生产环境，以供客户使用。它主要为了解决因手动流程降低应用交付速度，从而使运维团队超负荷的问题。持续部署以持续交付的优势为根基，实现了管道后续阶段的自动化。
归根结底，我们没必要纠结于这些语义，您只需记得 CI/CD 其实就是一个流程（通常形象地表述为管道），用于实现应用开发中的高度持续自动化和持续监控。
环境
开发环境
开发人员自己书写代码并可以简单测试的环境，一般是开发人员自己的笔记本或台式机
测试环境
用于给开发进行初步测试的环境，由开发人员自己维护和部署，一般是公司内部的机房，物理服务器或虚拟机
预生产环境
用于测试人员模拟运维人员进行部署和配置的测试，服务配置几乎与生产环境一致，用于正式部署前的最后一轮测试。为了让测试效果更加真实，会连接生产环境的数据库，但是要注意避免破环数据库和生产脏数据。
生产环境/线上环境
直接给用户提供服务的环境，由运维进行维护，其他人没有权限去改动。
生产环境和预生产环境的区别：
- 预生产环境中新功能为最新代码，其他功能代码和生产环境一致
- 预生产环境和生产环境的访问域名不同
- 预生产环境的业务可能会访问到在线真实数据，尽量不要产生脏数据，从而影响在线环境
- 用户不能访问到预生产环境
发布策略
目前被业界广泛采用的服务发布策略包括：蓝绿发布、A/B 测试以及金丝雀发布。
不同发布策略的目的都是一样的：尽量不影响用户使用的前提下，完成测试并发布
蓝绿发布
蓝绿发布需要对服务的新版本进行冗余部署，就是需要准备两套设备，一套是旧版本，另一套用于部署新版本。新版本的机器规格和数量与旧版本保持一致，相当于该服务有两套完全相同的部署环境，只不过此时只有旧版本在对外提供服务，新版本作为热备。
当服务进行版本升级时，我们只需将流量全部切换到新版本即可，旧版本作为热备。由于冗余部署的缘故，所以不必担心新版本的资源不够。
如果新版本上线后出现严重的程序 BUG，那么我们只需将流量全部切回至旧版本，大大缩短故障恢复的时间。待新版本完成 BUG 修复并重新部署之后，再将旧版本的流量切换到新版本。
蓝绿发布通过使用额外的机器资源来解决服务发布期间的不可用问题，当服务新版本出现故障时，也可以快速将流量切回旧版本。
蓝绿发布的优点：
- 部署结构简单，运维方便；
- 服务升级过程操作简单，周期短。
蓝绿发布的缺点：
- 资源冗余，需要部署两套生产环境；
- 新版本故障影响范围大。
AB测试
A/B 测试基于用户请求的元信息将流量路由到新版本，这是一种基于请求内容匹配的灰度发布策略。只有匹配特定规则的请求才会被引流到新版本，常见的做法包括基于 Http Header 和 Cookie。
基于 Http Header 方式的例子，例如 User-Agent 的值为 Android 的请求 （来自安卓系统的请求）可以访问新版本，其他系统仍然访问旧版本。基于 Cookie 方式的例子，Cookie 中通常包含具有业务语义的用户信息，例如普通用户可以访问新版本，VIP 用户仍然访问旧版本。
通过在监控平台观察旧版本与新版本的成功率、RT 对比，当新版本整体服务预期后，即可将所有请求切换到新版本 v2，最后为了节省资源，可以逐步下线到旧版本 v1。
A/B 测试的优点：
- 可以对特定的请求或者用户提供服务新版本，新版本故障影响范围小；
A/B 测试的缺点：
- 仍然存在资源冗余，因为无法准确评估请求容量；
- 需要构建完备的监控平台，用于对比不同版本之间请求状态的差异。
- 发布周期长。
金丝雀发布/灰度发布
在蓝绿发布中，由于存在流量整体切换，所以需要按照原服务占用的机器规模为新版本克隆一套环境，相当于要求原来1倍的机器资源。
在 A/B 测试中，只要能够预估中匹配特定规则的请求规模，我们可以按需为新版本分配额外的机器资源。
相比于前两种发布策略，金丝雀发布的思想则是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的机器。验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本，期间可以根据设置的流量比例，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源得到最大化利用。
如图，某服务当前版本为 v1，现在新版本 v2 要上线。为确保流量在服务升级过程中平稳无损，采用金丝雀发布方案，逐步将流量从老版本迁移至新版本。
金丝雀发布的优点：
按比例将流量无差别地导向新版本，新版本故障影响范围小；
发布期间逐步对新版本扩容，同时对老版本缩容，资源利用率高。
金丝雀发布的缺点：
- 流量无差别地导向新版本，可能会影响重要用户的体验；
- 发布周期长。
代码发布和上线
以下是一般的代码发布流程
- 提交代码：开发人员根据需求完成代码编写，自测通过后提交到托管平台
gitlab/gitee等 - 代码审核：审核人员从托管平台上拉取代码进行审核，代码审核是代码上线过程中不可或缺的一步，它的目的是确保代码质量和安全性。
- 构建：使用
Jenkins或maven等工具将代码打包成可执行文件或者其他形式的部署包，以便于部署到测试环境以及生产环境。 - 测试：将代码部署到测试环境，在IDC机房测试环境中测试通过；
- 部署：将打包好的代码部署到预生产环境，此过程的目的是进行预发布测试，确保部署成功和不会影响到用户的正常使用。
- 上线：当代码在预生产环境测试通过后，将代码上线到生产环境，并对线上服务进行监控，确保代码正常运行。
一个完整的代码上线流程
- 上线的业务介绍 （知道上线的是什么业务）
- 数据备份方案
- 上线时间（ 时间定下来方便提前发通知，诸如见到的网站提醒XX日进行业务升级）
- 相关人员 （开发，运维，测试齐上阵，做好合理分工）
- 上线失败后的回滚方案（回滚是应急方案）
- 上线后的测试(开发人员对系统进行测试，运维人员对系统进行测试和监控）
- 正式完成，进行邮件通知
- 撰写测试报告，项目总结