DevOps 与 CICD 的关系
DevOps 就是开发（Development）、测试（QA）、运维（Operations）这三个领域的合并。虽然名字中没有体现，但是DevOps仍包括测试。.
DevOps 是一种方法论，是一组过程、方法与系统的统称，用于促进应用开发、应用运维和质量保障（QA）部门之间的沟通、协作与整合。以期打破传统开发和运营之间的壁垒和鸿沟。其本质就是人员一体化。
大家经常见到的对DevOps的说明是下面这张图：
这张图的本质是说DevOps是涵盖各个阶段的、一套流程闭环的体系。
DevOps需要通过实现自动化的工具来进行理论与实践的结合。CICD本质上是一组工具集，因此，DevOps与CICD紧密相连。
CICD里有几个概念：持续开发、持续集成CI、持续交付、持续部署CD。分别对应着开发流程的某些阶段，咱们来具体看看。
持续开发(Agile Development)
目的意义
Agile Development 直译过来是敏捷开发，但是在国内这个概念含义太多，容易歧义。公司里叫持续开发，觉得更为贴合。指的是从需求开发到合并到主干之前的过程。对应的下图主要是第1到第4步：
那持续开发到底需要多agile(敏捷、迅速)呢？
Kent Beck在《解析极限编程》里提到：不超过2小时就对改变的地方做一次集成和测试。团队编程并不是分而治之，而是分、治以及集成。集成的步骤是不可预知的，但很容易就花费比原始编程更多的时间。等待的时间越长，花费就越多，越不可预知。
代码一提交，是不是就意味着QA同学需要进行测试了呢？
威廉.爱德华兹.戴明说：产品质量不是检测出来的，从产品生产出来后质量就已经在那里了。
对于问题，发现得越早，修复成本越低。所以需要在生产阶段自我进行质量保障。这就是测试驱动开发的重要意义。所以咱们现在开发程序都需要有单元测试。
规范
CICD的流水线在持续开发阶段都会做单元测试检查和静态代码质量检查。静态代码质量检查常用工具是sonar。咱们很多公司里的工具为CICD做了下面必要的保证：
-
只维护一个源代码仓库
-
自动化构建
-
构建时自行测试
-
要设立Code Review环节把控
在这个阶段对提交代码的人有如下要求：
-
CICD状态失败时，禁止提交新代码。
-
CICD失败不能过夜，要么快速修复，要么回滚。
持续集成(Continuous Integration)
目的意义
持续集成是指将代码频繁的集成到主干上进行代码测试。
集成到主干之后做的事情也要进行构建、测试和质量检查，很多公司还添加了测试环境部署验证等其他环节。
持续开发与持续集成两个阶段的区别在于一个是针对从本地提交到仓库的代码，一个是针对合并到主干之后的代码。两者针对的对象不同。
谷歌在解决工程效能问题时提出主干开发的口号。即针对一般的需求，代码直接合并到主干上，而不是独立拉分支。这样做的优势：
-
分支模型简单高效，开发人员易于掌握，不容易出现错误操作
-
避免了分支合并、冲突解决的困扰
-
随时拥有可发布的版本
这种主干开发模式，对持续集成工具有很高的要求：
-
基础架构要求高：合入到主干的代码若质量不过关将直接阻塞整个团队的开发工作，因此需要高效的持续集成平台进行把关。
-
自动化测试要求高：需有完备单元测试代码，确保在代码合入主干前能获得快速和可靠的质量反馈。
规范
一般情况下采用主干开发，但是对于一些周期特别长或者风险高的特性还是可以进行特性分支开发，但是一般特性分支不超过3个。
持续交付(Continuous Delivery)
概述
持续交付是指在持续集成基础上将集成后的代码发布到类生产环境(staging)中。
很多公司在持续交付阶段集成了冒烟测试和自动化回归测试。
冒烟测试，是版本验证测试，主要确认新的版本是否存在致命性bug，功能可以正常运行（不会出现跑不通的状况）。
自动化回归测试就是制作可以覆盖生产环境所有场景的测试案例进行验证或者直接将生产的案例通过流量回放等方式进行验证。
因为持续交付阶段不仅交付了原有的功能，还有一些新特性，所以QA测试也建议在这个阶段进行。如果类生产环境和生产环境足够类似，还可以自动化的进行全链路的压力测试、疲劳测试。
持续部署(Continuous Deployment)
概述
持续部署是在持续交付的基础上将部署到生产环境的过程自动化。
但是实际情况是，目前我知道的针对大多数情况时，部署过程都是手动的。
公司里为部署生产代码提供了灰度发布工具。但是需要人工去点，确保每一步都符合预期。
很多公司也基于docker等工具做了蓝绿部署：
蓝绿部署中，一共有两套系统：一套是正在提供服务系统(也就是上面说的旧版)，标记为“绿色”；另一套是准备发布的系统，标记为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。正在对外提供服务的老系统是绿色系统，新部署的系统是蓝色系统。
蓝色系统不对外提供服务，用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。
蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统, 切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。
当确信对外提供服务的蓝色系统工作正常，不对外提供服务的绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。
总结
工作常听到的一些概念：敏捷开发Scrum、极限编程，包括今天的讲的DevOps和CICD之间是什么关系呢？
敏捷开发Scrum有12条原则(这个在大学的软件工程课上有介绍)：
1、最优先要做的是：通过尽早的、持续地交付有价值的软件使客户满意。
2、即使到了软件开发后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
3、经常交付可工作的软件，交付周期越短越好。
4、在项目开发期间，业务人员和开发人员必须天天一起工作。
5、给他们提供所需的环境及支持，并信任他们可以完成他们所承担的工作。
6、在团队内部最有效的传递信息的方法是面对面交流。
7、首要的进度完成度量标准就是工作的软件。
8、敏捷过程要可持续发展。
9、不断关注优秀的技能和设计，增强敏捷能力。
10、简单是根本
11、最好的体系结构、需求和设计，出自自己的团队。
12、强调自省。
12条原则的理念，毕竟不容易记忆和遵守。极限编程XP作为敏捷开发的一种，更轻量级：
标准到了一定阶段，要通过工具来保证，于是出现了CICD。CICD更强调工具，把人员包含进来就形成了DevOps。
我在15年的工作过程基本上算是见证了它们的发展演进过程。可能很多朋友已经习惯于公司的规定和工具，想要把这些规定和工具变成自己的技能还是需要多了解其来龙去脉的。
