敏捷开发-持续部署（CI/CD们）

本篇带领大家走入研发内部来看看，首先介绍下这几个英文单词：CI、CD、CD

CD还是重复的，介绍下他们是什么的缩写：

1. CI----Continuous Integration（持续集成）
2. CD---Continuous Deployment（持续部署）
3. CD---Continuous Delivery（持续交付）

 

 软件开发过程上，有个很著名的模型---瀑布开发模型，如下：

 

主张的是一个过程节点完整走完后，再进入下一个过程节点，一个项目一个大过程。

这个过程的问题就是太大了，导致无法敏捷，并且到编码阶段转入测试阶段时，由于一次性构建了太多，这个时候想要集成，就会出现很多问题，导致测试也进行不下去，更别说交付、运营了。

后来，又引进了敏捷开发，都是用来解决大瀑布模型导致的太重问题，无法敏捷。

怎样才能敏捷起来呢？先来分析分析大瀑布为啥就不不能敏捷呢，问题在哪？

• 大瀑布模型里，需求一次性全部梳理清晰，所花费的时长肯定长，而且由于整个过程长度长，因此等到反映过来不是想要的，那就很麻烦了
• 分析节点里，同样的道理，由于分析内容多，所以容易遗漏，时间长，如果稍有问题，后面的环境再进行一放大，再去整改会更麻烦
• 编码到测试环节里，由于工件是需要交付的，需要部署的，然后才能进行测试。但是部署牵涉到环境配置、服务部署等，都容易出错，因此这2个节点之前的迁移也是个麻烦事
• 测试环节里，由于先前要花很长时间才能进行一整个的测试，可想而知，脱节比较严重，如果代码质量再不行的话，测试人员就别提有多么痛苦了，测试这关过不了，就别提上线时间了

研发一般都是根据需求来评估以及进行日常开发行为的，是不是把需求分割小点，多批次进行开发，或者说分多个批次进行上述的瀑布模型？ 似乎行

产品经理、测试工程师，是不是也可以通过切分需求，分批次来进行需求分析、测试呢？似乎行，能敏捷吗？可以相对快速的调整方向上的问题吗？似乎行

scrum就是来解决这个问题的框架之一

 

总体思想是分批次进行开发，这样有利于整体的敏捷性，快速响应，以及优先级的调整（关键在需求如何拆分、如何管理需求、以及各环节之间如何自动化）。

打住，我们的主题CI/CD。对于scrum来说（乃至敏捷开发来说）CI/CD是个内建特性（必须项），有了CI/CD，scrum才可能敏捷，先切入CI/CD。

持续集成

持续集成上，需要落地的是怎样把写好的新代码集成到主干上，commit后会不会导致broken、会不会导致需求意义上的broken，这些新代码是不是存在质量问题，是不是存在安全问题，等等。

最常见的实现方式，就是jenkins配好特性分支，针对这个特性分支进行各种管道处理，比如：sonar静态代码扫描、mvn单元测试的运行、单元测试覆盖率验证、zab安全扫描等等。

从上面的单词可以看出，要内建质量，CI这个过程很重要，是需要重点抓的，如：单元测试的编写、sonar规则需要根据项目乃至公司自定义部分的配置、等保安全等等。

引申出来的地方其实挺多的，比如单元测试怎么写，为了写单元测试，需要做到OO，代码架构也要跟着变、对于开发人员来说，要求其实高了很多很多的。 

 

持续部署

持续部署比较容易理解，就是持续的部署代码到各种环境中（除了生产环境外），部署后，测试工程师过来验证，UAT的话，用户也会过来验收。

现代服务一般都是微服务，code+配置+数据库，都是需要考虑到的，code部分经过了CI步骤，可以比较平滑的部署到后续环境，但是配置、数据库呢？其实也是需要寻找自动化工具来解决的

这里介绍个名词：GitOps，既：所有的变更全部进git版本控制系统中，没有人工操作，这样的好处是，一键即可构建整个环境、并且也方便了回滚，如：k8s生态圈

 

持续交付

持续交付，生产环境的发布一般是很谨慎的，早期是手工发布，手工核对的较多。但是随着自动化能力的提高，发现自动化发布的越多，对生产环境越顺畅，人工发布反而会导致不稳定性。

因此生产环境的自动化部署，也是门很深的学问，并不是简单的持续部署延续。

prd发布，需要考虑工件的版本（经过测试的工件版本，比如在prd分支下再次打包，这个行为其实是存在引入和test环境不一致因素的操作，最好的办法是原封不动的拷贝镜像，不做重复工作）；

是不是考虑api的版本化，兼容性 ，以及灰度发布，都是要考虑的。

 

CI/CD部分就简要介绍到这里，希望能带领大家用研发的视角来看待需求的交付，当然本篇说的还只是需求交付的一部分，本篇关注于研发内部。

感谢大家的聆听。