敏捷开发与Gitlab CI/CD持续集成

敏捷开发的流程分为几个阶段：编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署。而CI/CD是实现这一理念的方法。

一：持续集成CI(Continuous integration)

    持续集成(Continuous integration)，简称CI，是一种软件开发实践。开发人员提交代码后，系统自动进行构建、（单元）测试，通过自动化测试保障所有的提交在合并主线之后不会出现质量问题，对可能出现的一些问题进行预警。

 需要具备的条件

     需要为每个新功能、代码改进、或者问题修复创建自动化测试用例。你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。尽可能快地提交代码。

 带来的效益

        通过自动化测试可以拿到测试结果，避免将一些问题提交到交付生产中。发布编译将会更加容易，因为合并之初已经将所有问题都规避了。减少工作问题切换，研发可以很快获得构建失败的消息，在开始下一个任务之前就可以很快解决。  测  试成本大幅降低，你的CI服务器可以在几秒钟之内运行上百条测试。团队花费在测试上面的时间会大幅缩短，将会更加侧重于质量方面的提升上面。

二：持续交付CD(Continuous Delivery)

 持续交付(Continuous Delivery)，简称CD：是一种软件工程的手法。持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中，也就是我们通常说的预发布环境。交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。

需要具备的条件

需要有强大的持续集成组件和足够多的测试用例满足代码的需求。部署需要自动化。触发是手动的，但是部署一旦开始，就不能人为干预。团队可能需要接受特性开关，没有完成的功能模块不会影响到线上产品。

带来的效益

繁琐的部署工作没有了。开发团队不再需要花费几天的时间去准备一个发布。你可以更快的进行交付，这样就加快了与需求方之间的反馈环。轻松应对小变更，加速迭代。

三：持续部署CD(Continuous Deploymen)

持续部署(Continuous Deployment)，也是简称CD：指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。

需要具备的条件

研发团队测试理念比较完善。测试单元的健壮性直接决定着交付质量。文档和部署频率要保持一致。特征标志成为发布重大变化过程的固有部分，以确保您可以与其他部门（支持，市场营销，公关…）协调。

带来的效益

发布频率更快，因为你不需要停下来等待发布。每一处提交都会自动触发发布流。在小批量发布的时候，风险降低了，发现问题也可以很轻松的修复。客户每天都可以看到我们的持续改进和提升，而不是每个月或者每季度，或者每年。

四：Gitlab CI/CD介绍

         Gitlab CI/CD是Gitlab一个简洁好用的的持续集成/持续交付/持续部署的框架。为项目配置一个或者多个 GitLab Runner，然后添加一个  .gitlab-ci.yml

         文件到项目根目录，进行提交或者推送代码到Gitlab服务器，就可以很方便地持续集成/部署代码。

      Gitlab CI/CD运行原理

          开发者推送、提交代码到Gitlab，Gitlab通过项目的 .gitlab-ci.yml

         文件配置，找到指定的项目gitlab runner，runner运行相关的命令，进行编译、 集成、测试、交付、部署，一切顺利地话会分发到各个服务器（测试服务器、预发布服务器、正式服务器等），此时一个迭代开发上线流程走完。流程图如下。

    执行流程

默认情况下，它运行有三个流水线阶段stage：

build，test，和deploy，可以在.gitlab-ci.yml的stages自定义，多个阶段是按顺序执行的，可以修改顺序，如果其中一个阶段失败，则后续的阶段不会被执行，整个过程被认为失败。

五：具体在代码中怎么实现

   1)创建一个简单的.gitlab-ci.yml（参考文档https://docs.gitlab.com/ee/ci/yaml/README.html）

.gitlab-ci.yml是用来配置CI在我们的项目中做些什么工作。它位于项目的根目录。在任何的push操作，GitLab都会寻找.gitlab-ci.yml文件，并对此次commit开始jobs，jobs的内容来源于.gitlab-ci.yml文件。因为.gitlab-ci.yml是存在于我们的项目仓库中，并且受版本控制的，所以旧版本也可以执行成功，且使用CI可以让forks更容易，分支可也以拥有不同的pipelines和jobs，而且对于CI来说只会拥有单一的来源

2) 推送.gitlab-ci.yml到GitLab

    git push origin branch