浅谈CICD与项目实战_cicd经验

---

曾几何时，研发、测试、运维各自为战，如战国之群雄割据，各领风骚，直至CI/CD横空出世，纵横捭阖，四海归一，实现了“车同轨 书同文 行同伦”，将开发环境、测试环境、预发环境、生产环境聚于统一战线，上传下达，流水作业，一荣俱荣、一辱俱辱。

一、什么是CI/CD

参考文章：
6 张图带你搞懂 CI/CD 流水线

1.CI（Continuous Integration，持续集成）

图片来源：https://blog.csdn.net/csdnnews/article/details/104624343

持续集成的重点是将各个开发人员的工作集合到一个代码仓库（如Gitlab）中。通常，每天会进行多次提交，主要目的是早发现，早更正，防患于未然，使团队更加紧密结合，更好地协作。

持续集成的本质是要自动化测试。如果研发部不具备自动化测试的能力，持续集成怎么做都是失败的。

持续集成里最重要的一点就是要推行单元测试、集成测试还有系统测试，单测是保证自己没问题，集成测试是保证跟上下游没问题，系统测试是保证整个系统没问题。

2.CD（Continuous Delivery，持续交付）

图片来源：https://blog.csdn.net/csdnnews/article/details/104624343

第一种解释

持续交付的目的是最小化部署或释放过程中固有的摩擦。频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。

持续交付里很关键的一点就是我们要解决它的环境一致性、配置一致性。环境一致性可以用Docker解决，Docker 本身就是一种标准化的东西。另外一个问题，配置是不是一致性，是不是动静分离。

持续交付是一种能力。只有具备持续交付的能力，才能够实现持续部署。

第二种解释（参考书籍《持续交付2.0——乔梁著》）

交付是一个业务决策活动，通常也被称为发布，也就是说，如果将新构建的特性交付到用户手中，他们就可以看到并使用它们。

3.CD(Continuous Deployment,持续部署)

持续部署是一种更高程度的自动化，无论何时对代码进行重大更改，都会自动进行构建/部署。

4.CICD的几个特点

• 以提高研发效率为目标
• 紧贴实际业务
• 以人为本，尽可能将一切繁琐的过程交给程序去执行

二、为什么要用CI/CD

如果一个团队缺乏统一标准的环境，再努力，也是事倍功半。而使用容器化技术、CI/CD，不仅能让开发环境、测试环境、预发环境、生产环境保持一致，同时也对测试和质量保证有至关重要的作用，能达到事半功倍的效果。

1.CI

原文链接：https://blog.csdn.net/csdnnews/article/details/104624343
开发人员每天都将自己的更改推送到主分支中进行集成，通常，这样的操作每天都会发生很多次。从更高的视角来看，CI 能使开发者更快的发现模块或功能中的错误。持续集成的整个流程如下：

1.开发者将代码提交到项目分支；
2.CI 服务器检测到更改并将最新代码拉下来；
3.CI 服务器编译更改后的代码，并给他们打个标签；
4.CI 服务器执行所有的单元测试、集成测试、端到端的测试；
5.实时将测试结果(成功或者失败)发送给对应的开发者
1
2
3
4
5

如果上述任何阶段，出现任何问题（包括测试用例失败），整个 CI 流程将会被停止，并且将错误信息发送给开发人员。

2.CD

持续交付在业界被简称为 CD ，是指在自动完成所有的自动化测试代码过后，将通过的代码进行直接部署。

从本质上来讲，这是软件发布的最佳实践。—— Jez Humble（译者注：Jez Humble，被誉为「持续交付之父」，《DevOps 实践指南》、《精益企业》、《持续交付》作者。）

持续交互包含以下几点：

1.在所有的测试通过后，自动创建一个版本，并使用脚本，将它自动部署到你所有的环境中去（测试环境、集成环境、生产环境等）。

2.作为整个流程的最后一个步骤，你还需要运行冒烟测试，来确保你所部署的服务正在顺利的运行。

3.设置监控报警，当出现问题时要第一时间通知开发者。

4.应该提供功能切换的功能，隐藏代码的具体实现细节。
1
2
3
4
5
6
7

在部署过程中，所有的修改都是单独提交的，因此由部署带来的风险和 Bug 也会相对较少。这意味着，企业能够根据需求，更加快速地开发并部署代码。如果能将 CD 与容器化技术（如 Docker、k8s）配合使用，在云平台上，甚至可以实现不停机部署,这样开发团队就可以在任何时间进行代码部署。

3.四个指标

正如 《Accelerate》一书中所说，软件团队的性能和效率可以通过四个指标来检查。而良好的 CI / CD 的实践可以大大改善四个指标的得分。

1.交付时间：

CI / CD 可以让开发人员编写的代码直接部署到生产环境中。如果一个团队有良好的 CI / CD 的流程时，可能只需要几个小时甚至是几分钟时间就能完成新需
求上线。
1
2

2.部署频率：

如果能够快速部署，小范围部署，那么团队可以频繁地进行部署，特别是那些“无关紧要”的部署。Amazon 曾公布数据表示，在他们全球所有的团队中，平均每
 11s 就会部署一次。推荐一本书《凤凰项目—一个IT运维的传奇故事》
1
2

3.平均故障恢复耗时：

举个例子，如团队中的某一个部署导致整个系统崩溃，有可能让整个系统停机好几个小时。那如果这个团队有良好的 CI / CD 的实践，那他们可以很准确地知道
是由于哪个更改造成，知道是由哪个产品线更新引起的。或许 15 分钟后，就能够开发出修复程序并将其重新部署到生产环境中。
1
2

4.变更失败率：

如果使用了 CI ，那么所有的修改都会在你的 CI 服务器进行集成并运行所有的单元测试，这些修改也会在与用户环境非常接近的环境中运行，当这些变更
呈现在用户面前时，都已经是经过了大量的测试验证过的版本，几乎不会出现任何隐藏的 Bug。
1
2

以上内容来自：https://blog.csdn.net/weixin_44903147/article/details/96291588和https://blog.csdn.net/csdnnews/article/details/104624343

三、怎么搭建一套CI/CD

PS：上面讲了这么多理论的东西，让人觉得有点模糊、遥远、不具体。下面是我根据CI/CD的基本理念，搭建的一套环境，里面的项目比较简单，在一些规划上也不太合理，主要的目的是能够对CI/CD有一个比较形象的了解。

GitHub地址：https://github.com/anqixiang/CICD_LNMP.git

第1集，环境搭建

第2集，LNMP项目准备

第3集，WebHook触发mvn打包

第4集，SonarQube实现CodeReview

第5集，build image

第6集，部署到测试环境，Selenium自动测试

第7集，模拟版本更新，在测试环境验证

第8集，部署到生产环境

第9集，流水线部署到测试环境