# 关于CI/CD的介绍


## 关于CI/CD的介绍
CI 是Continuous Integration 持续集成的简称。持续交付 Continuous Delivery 和持续部署 Continuous Deployment 都简称CD。

远古时代的软件编程，是没有所谓持续集成和持续交付的概念的。那时候的软件系统基本都运行在单台服务器上，系统的功能也没有那么复杂。人们在完成软件系统的编写后，本地做好测试，就打包部署到客户订购的服务器上了。

那么当软件系统出现了问题怎么办？那个时候要派技术运营人员到客户端，收集问题信息，再拿回到开发组处，希望复现改该问题，解决系统内部的bug。待测试稳定后，再打包部署给客户。如此循环往复。

但随着IT行业的发展，客户的业务需求变得越来越大，功能模块叠加的越来越多，所需要部署测试的服务器也不再是单台了，而是几十台、上百台，软件系统的复杂度、灵活性上升，所需的开发组成员也越来越多，其内部出现bug的问题可能性也多来越大，显然再像从前那样，派技术运营人员收集问题，带回解决，这种解决周期带来的时间成本是不可接受的。

## CI的出现
项目组开发团队规模越来越大，代码质量问题的把控越来越难，多个项目组Group1、Group2、Group3向主干合入代码，最后在测试时出现问题，需要长时间排查，到底是哪个组的代码引发的bug。为了避免这种情况，最好在每个Group合入主干前，就完成其负责的基本测试。通过所有测试后，才允许质量合格的代码进入主干。

如果每次项目组合入代码，都需要等待测试组人员一项一项测试，开发效率会受到极大大影响。于是自动化的测试方案呼之欲出，用其应对代码频繁合入时的场景，对合入代码自动构建执行包，并执行测试用例。如果发现不合格信息，即可回滚到上以稳定版本。

## CI包含的步骤
一般来说，CI这种持续集成并没有标准答案。简单的步骤就是编译构建--> 自动化测试。对于较复杂的系统CI，则可能需要包括:静态代码检查 --> 编译 --> 冒烟测试 --> 接口测试 --> 性能测试 --> 异常测试等等，前述种种集成，都需要结合不同工具在CI的平台上，由专业的CI项目组进行配置监督。

## CI的工具 
CI的工具很多，业内用的较多的是Jenkins。


## CD的概念
持续交付 Continuous Delivery 和持续部署 Continuous Deployment 都简称CD。

持续交换：持续交换是在通过CI之后，持续把代码交换出去，可以是部署到测试环境，也可以交付给产品进行验收，但在持续交互阶段不会把代码部署到生产环境中

持续部署：持续部署和持续交付的区别是，持续部署是把测试通过的代码真正的部署到生产环境中，而不是测试环境


持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

![持续集成](/pics/持续集成.png "持续集成")


持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中

![持续交付](/pics/持续交付.webp "持续交付")

持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。

![持续部署](/pics/持续部署.webp "持续部署")