DevOps实践：在工作中如何做好CI/CD

Devops其实是一个体系，而不仅仅是某个岗位，是从提高企业IT部门运作效率出发的
也不是单纯的指将以前手动的工作整合到一键自动化就是devops

如何提高运作效率这个事情比较复杂也比较抽象，所以很多人就把Devops具象成了建立一套有效率的开发运维工具，通过这个工具提升个体和团队协作的效率

一、持续集成

1.1 概述

所谓持续集成就是在向代码仓库提交代码后，会自动触发构建以及单元测试这两个动作，然后自动向开发团队反馈本次构建和测试的结果。
持续集成主要关注代码是否编译成功以及是否通过单元测试，并提供快速的反馈。因此，持续集成的关注对象是开发团队。

1.2 持续集成的作用

假设一个团队没有对开发的软件进行持续集成，那么开发人员就是一直在孤立的进行开发，只有在他们的工作完成后，才会将他们的更改合并到主分支中。

这就意味着，在整个开发过程中，软件都是处于不可运行的状态。这也就导致另一个问题：长时间积累bug，不能及时发现系统的缺陷。 只有在第一次运行时才会发现问题。

如果使用了持续集成，频繁的进行构建和单元测试，我们可以更快的发现bug并修复bug。

1.3 持续集成原理与实践

1.3.1 原理
前面讲过，持续集成就是在向代码仓库提交代码后，会自动触发构建以及单元测试这两个动作，然后自动向开发团队反馈本次构建和测试的结果。因此，我们首先需要一个代码仓库，如GitLab。开发人员就能不断地使用Git这种版本控制工具向代码仓库中更新代码了。

当代码更新到仓库后，持续集成系统就会自动构建和运行单元测试。这里也就需要一个构建工具和触发单元测试的工具，众所周知的Jenkins就是做这个事情的。也就是说，我们可以通过Git，GitLab，Jenkins这三个工具打造一个持续集成系统。

但是我们把代码通过Git工具提交到GitLab后，GitLab如何自动触发构建和单元测试动作呢？ 答案是使用Webhook技术。 关于Webhook，简单来说就是一种使用自定义回调来增强或改变网页或Web应用程序行为的方法。具体可以参考 https://en.wikipedia.org/wiki/Webhook ，这里不做过多赘述。

1.3.2 实践
既然知道了原理，那就行动起来吧。首先需要自己去部署一套GitLab和Jenkins，然后再打通GitLab和Jenkins互相访问权限即可。这里我就不自己配置然后截图贴在这里，没什么意义，其过程很简单。在这里，我就做一个小小的搬运工吧~~：

GitLab安装
https://about.gitlab.com/installation/ #centos-7
JenKins安装
https://jenkins.io/doc/pipeline/tour/getting-started/
持续集成系统
https://docs.bitnami.com/aws/how-to/create-ci-pipeline/

至此，我们已经通过开源工具GitLab和JenKins打造了一个可用的持续集成系统。下面，开始介绍持续交付。

二、持续交付

2.1 三个反模式

在定义持续交付之前，我们需要了解下软件交付时会遇到的三个反模式。如果我们能解决这三个反模式，那我们的持续交付系统，一定是做的十分成功的。

《持续交付》一书中提出了三个反模式，分别是：手动部署、开发完成后才向类生产环境中部署和手动管理生产环境的配置。

2.1.1 手动部署
所谓手动部署，就是在每次发布时，由运维手动将软件部署到服务器。手动部署有几个典型的特征：

• 开发给运维一份部署文档
• 开发、测试、运维团队之间频繁沟通
• 发布速度慢
• 熬夜想问题。一些重大发布基本都是放到凌晨的，脑子不清醒操作错误，导致发布时出了问题，得迷迷糊糊的解决问题
• 意想不到的环境不一致问题

做过手动发布的运维同学，应该都能体会到这几点。由此，手动部署的弊端也就十分明显：

部署时间长。尤其是微服务架构下，一个传统的单体应用拆分后，部署难度又有所增加
环境不一致导致发布失败。测试环境不能完全模拟生产环境
人工操作错误。人在疲劳时是十分容易出错的

……

手动部署的弊端如此之多，软件交付不再可靠。因此，应用部署应该做到完全自动化，做到一键发布——运维点点按钮即可，或者允许开发自发布。

2.1.2 开发完成后才向生产环境部署

第二个反模式主要有一个特征：

在开发、测试、运维团队完全独立的情况是，运维同学只会在第一次部署软件时参与
因此运维对其架构、所需环境不了解。只有当开发提出需求后，运维才会开始着手部署。

我再补充一点：
应用没有在真实环境运行过，而生产环境和测试环境有所出入，导致应用部署失败。即使测试环境配置百分百模拟了生产环境。但是上线后会有其他问题，如网络延迟不在开发人员的考虑因素之类，因此对网络异常情况的处理，其程序健壮性不够。

要解决这个问题，我们就需要将测试、环境部署和应用发布纳入到整个开发流程。这样就能降低运维不熟悉的风险，降低环境不一致的风险。

所以，我现在开发一个新系统时，当我完成一个小功能后，我就会着手把系统部署上去，这样一来，既能把环境部署后，还能检测出更多问题。

2.1.3 手动管理生产环境的配置
这个反模式，应该也是所有开发、运维碰到的一个比较难搞得一点。无论是基础设施的配置还是应用的配置，经常由于手动更改而导致线上服务异常，用户不能正常访问。

该反模式的特征如下：

• 测试环境正常，一上生产环境就出幺蛾子
• 运维团队准备周期长
• 配置不能回滚
• 直接修改生产配置产生异常情况，应用停服

对于解决这个问题的办法，《持续交付》中提出引入版本控制。 个人认为这是可行的，但是实施难度稍微有点大，什么都通过版本控制系统来管理，维护版本控制系统反而也成为了一个负担。其实，我们还可以通过变更系统(多人审核)加强审核、CMDB 来帮助维护这些配置信息。也可以通过SaltStack来进行配置的管理。

软件交付的三个反模式介绍就到此结束，在做持续交付时，只要心里想着不要违背这三个反模式，持续交付部署流水线是可以做到十分完善的。

2.2 持续交付原理

开发一个软件，最终的目标是为用户提供服务。因此有了持续集成还不行，持续集成只能做到更快的发现系统缺陷，我们还需要另外一种机制来帮我们快速的将软件交付给用户，这种机制就是持续交付。

要知道，一次完整的发布流程中，还需要测试团队和运维团队的紧密协调。软件的发布流程中，很多浪费是来自于测试和运维环节。因此只有打通了这两个环节，才能真正的做到持续交付。

持续交付的定义：所谓持续交付对持续集成的补充，在单元测试完成后，自动部署到测试环境/生产环境。
持续交付的中心模式是部署流水线，本质上讲就是一个应用程序从构建、测试、到发布这整个过程的自动化实现。

部署流水线是指软件从版本控制库到用户手中这一过程的自动化表现形式。流水线的输入是版本控制系统中的某个版本，输入是一个二进制包

注意：持续交付不是说不要人的干预，而是加快了交付速度以及提高了交付质量，减少出问题的概率

2.3 持续交付实践

2.3.1 持续交付实践探索之路

上面已经介绍了持续集成和持续交付的概念，并且也给出了持续集成的一个比较流行的实践。但是在持续交付的实践中，我并没有完全按照其理论来做。

其实，我是十分认同该理论的，但是在真正的实践过程中，需要开发、测试、运维团队的配合。而且，测试也要尽可能的自动化测试。这就要求在研发上投入更多的资源，这已经不是我所能控制的事情。

持续集成和持续交付是DevOps的两个实践，这些实践可以由普通的工程师从技术上来推动。但是在团队文化上，个人认为应该是由上至下推动，这样能减轻很多阻力。

当然，也可以由工程师自己推动，但是这样面临的阻力要大很多。也是加快了软件的交付速度，在管理上也更加的向标准靠近。

在自己的实践中，使用GitLab和JenKins做持续构建系统。
使用SaltStack做配置管理和主机管理的基础组件。由于是自己研发发布系统，因此可以做到很多个性化的定制，如增量发布，版本回滚；还规范了线上环境的标准。

2.3.2 持续交付实践总览

如果应用第一次上线，按照标准输入相关数据，如包名、需要的基础环境等
应用上线审核通过后，提交的数据自动成为CMDB数据的应用属性
使用GitLab 和 JenKins做持续构建系统
测试完成后，使用JenKins再次构建，将二进制包发送至二进制仓库
研发提工单，申请部署应用。录入本次发布的相关信息：如增量/全量，部署主机等
审核通过后，运维在平台上点击相关按钮即可部署应用

三、总结

本篇先写介绍了持续集成和持续交付的概念，并说明他们要解决的问题。 并给出了持续集成的详细实践经验。持续交付的实践我只给出了一个大致做法，重点是介绍自研发布系统如何和持续集成系统集成起来以构造持续交付系统。