DevOps系列---【持续集成与持续部署解决方案】

持续集成与持续部署解决方案

文章不长，请耐心读完全文，文末有福利哦!

一、项目的生命周期

在聊持续集成与持续部署之前，我们先来了解一下项目的生命周期，如图:

早期所采用的软件交付模型，称之为“瀑布模型（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脚本部署到指定的云服务器或物理机上也行。

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