什么是 持续集成 与 持续部署？

项目的生命周期

早期所采用的软件交付模型，称之为“瀑布模型（Waterfall）”。​​瀑布模型​​​，简而言之，先制定开发计划，然后按照计划等一个阶段所有工作完成之后，再进入下一个阶段。这种模型适合条件比较理想化（用户需求非常明确、开发时间非常充足）的项目。大家按部就班，做好自己的工作即可。但是，实际工作中需求往往是不断变化的，没有人能一上来就把产品设计的非常完美。随着用户对系统的需求不断增加，与此同时，用户给的时间周期却越来越少。在这对矛盾中，大家发现，笨重迟缓的​​瀑布式开发​​​已经不合时宜了。于是，衍生出了一个新的开发模式，那就是大名鼎鼎的—“​​敏捷开发​​​（​​Agile Development​​）”。

​ ​​敏捷开发​​​是以用户的需求进化为核心，把大项目变成小项目，把大时间点变成小时间点，快速给客户响应。敏捷开发极大地提高了软件开发的速度，但它注重的是软件的开发阶段，并未兼顾到运维阶段。在开发人员与运维人员进行交接的时候，并没有体现出敏捷的价值，因此开发与运维之间仍有很高的协作成本。这时​​DevOps​​​就应运而生了，​​DevOps​​​促进开发、运维、测试之间的高效协同，集开发、运维、测试于一体，范围扩大到软件的完整生命周期，从而真正做到持续交付并更快地解决问题。​​DevOps​​​包含​​CI​​​和​​CD​​​，​​CI​​​是​​Continuous Integration​​​（持续集成），而​​CD​​​对应多个英文，​​Continuous Delivery​​​（持续交付）或​​Continuous Deployment​​（持续部署）。

持续集成
1. 什么是持续集成？
​ ​​持续集成​​​英文名Continuous Integration，简称CI，在开发人员向代码仓库提交代码后，会自动（或手动）触发​​构建​​​和​​单元测试​​​这两个动作，然后自动向开发团队反馈本次构建和测试的结果。通过集成流程自动化，减少人为操作，从而达到降低开发成本的目的。因此，持续集成的解放的是​​开发人员​​。

2.持续集成能解决什么问题？
假设一个项目没有使用持续集成，那么开发人员会一直独自开发自己负责的功能，只有在他们的功能完成后，才会把新功能合并到主分支中。这就会导致，在整个开发过程中，项目都处于不可访问的状态。进而导致长时间积累bug，不能及时发现系统的缺陷，等到上线时出现各种意想不到的问题，此时再去修改bug成本太大。如果使用了持续集成，频繁的进行构建和单元测试，我们可以把很多低级的bug扼杀在摇篮中。

持续部署
1. 什么是持续部署？
​ ​​持续部署​​​英文名是Continuous Delivery，简称CD，又叫Continuous Delivery（持续交付），它是对持续集成的补充，在构建完成后，​​自动部署​​​到​​测试环境​​​或者​​生产环境​​。持续部署的核心是部署流水线，实际上就是一个应用从构建、测试、到发布这整个过程的自动化实现。

2.持续部署能解决什么问题？
运维工程师和开发工程师有着完全不同的想法，运维团队的座右铭，很简单，就是“稳定压倒一切”。运维的核心诉求，就是不出问题。所以运维工程师非常排斥改变，而敏捷开发带来的频繁部署，注定了运维和开发之间的矛盾愈演愈烈。此时，CD持续部署的出现，解决了二者之间的矛盾。持续部署使运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。持续部署一般采用docker部署系统应用，解决人工手动部署容易带来的环境原因导致部署失败的问题。



如上图，业务人员提出需求，开发人员开发完成后推送到远程代码仓库，同时触发webhook钩子，通知jenkins去代码仓库拉取最新的代码，自动构建，测试，打包，通过dockerfile自动打成docker镜像，并上传到docker镜像仓库，K8s去镜像仓库拉去对应的镜像部署成pod运行，当然，项目如果不是很大或使用的人不是很多的话，可以不使用K8s，自定义jenkinsfile脚本部署到指定的云服务器或物理机上也行。

使用这种开发模式，开发人员开发完新的功能后只用把代码提交到代码仓库，项目后面的启动工作自动触发，这种开发模式能快速的响应需求，大大降低运维成本，节省项目成本。