持续集成
CI ，Continuos Integration，持续集成。
什么是持续集成
每一次代码提交后，进行功能代码验证和软件部署包的构建等，来 第一时间发现质量问题并反馈给相关人员，时刻保证功能代码质量，提高功能集成与构建的效率。
持续集成发展历程：
- 手工命令：手工执行脚本命令，或工具插件，进行测试，构建打包和部署
- CI工具： 使用独立的CI工具进行构建，使用独立的部署控制台进行发布
- 自动化： CI 工具 对接代码仓库，提交后使用钩子自动触发CI构建，实现自动化构建
- 分布式： CI 应对大量的任务，支持分布式构建和独立的构建环境，如 jenkins 的slave
- 工作流： CI 工具支持 pipeline工作流，可以更灵活的编排CI到CD的每一个步骤
- 云原生： 更好的抽象，来集成对接更多CI工具 和 各种云平台进行集群管理和部署策略的应用。如 持续交付工具Spinnaker
- DevOps： 一站式打通开发到运维的每一个步骤
名词解释
持续：每一次变化触发持续集成，并获得反馈
集成：代码功能集成到一起，编译测试打包，并触发集成分支的CI流程，比如进行自动化集成测试
交付：部署到相应环境，交付给质量人员进行验证
部署：软件的部署，在持续部署中特指部署到线上生产环境
发布：功能变化对最终用户可见
持续集成做的事情或步骤
持续集成的一般步骤，或可选步骤行为如下
| 步骤 | 行为 |
|---|---|
| 编码 | 选择合适的分支，进行代码和单元测试的coding |
| 构建 | 编译，静态代码，代码规范检测，单元测试，测试覆盖率，打包, 镜像构建与上传。主要由构建工具支持如maven , gradle. |
| 测试 | 集成测试：自动部署到对应的环境，触发执行集成测试案例，一般是对外层接口编写的自动化测试案例 其它测试还有：端到端的自动化测试，性能测试，系统/人工测试，灰度测试等 因为需要部署到各种环境进行验证，所以，到这个过程也叫做持续交付 |
| 部署 | 通过测试，与代码审核后的版本，手工或自动部署到线上环境 |
| 发布 | 功能变化对最终用户可见，如灰度策略验证后的全量放开 |
玩法
一般CICD的具体步骤设置是对应代码分支的，所以可以为不同分支创建相匹配的流水线，比如特性分支仅做代码的构建。集成分支需要增加部署到集成测试环境，进行集成测试等。
分支的流水线
每条不同的分支都应该有与其作用相匹配的一条流水线来为它服务。
特性分支
用于日常需求隔离开发，提交后一般只进行代码的构建流程集成或发布分支
用于不同特性分支代码的集成，冲突的解决，在集成分支上构建部署集成测试环境，进行自动化集成测试；或部署预生产环境进行回归测试；版本验证通过后，经过安全检测，代码评审等，最后经人工确认或自动发布，部署到生产线上环境。
最后，用该分支归并到主干分支。
分支的玩法一般有这样几种：
自由模式
主干或者分支进行特性开发，或集成与发布git-flow模式(推荐)
master,develop模式，增加develop（dev）集成分支作为长期分支，所有的用户都在dev分支上开发，或建立特性分支进行开发，之后合并到dev分支并解决冲突，进入之前需要保证dev分支的质量，一般需要code review, dev分支集成测试与发布后，dev归并到master分支分支模式
集成与发布也需要创建独立的release分支，选择归并需要的特性分支到release分支，然后进行集成和发布；版本上线后，release分支归并到主干分支
一般有哪些环境：
本地开发环境 ： 自己的机器
集成开发环境 ： 微服务所有依赖的服务，系统在这个环境均有部署，供开发之间进行联调的日常环境
系统测试环境 ： 供质量测试人员使用的测试环境
性能测试环境 ： 用于压力测试的环境
预发生产环境 ： 所有系统在预发环境部署，配置项和数据与生产保持一致，预发往往与生产环境共享数据库，用真实的数据进行回归测试
线上生产环境 ： 最终部署到正式的用户环境，也可以经过灰度发布验证，再全量开放
持续集成工具:
| 工具 | 安装使用 | VersionControl | Pipeline | 原生容器 | 集成容器云平台 |
|---|---|---|---|---|---|
| Jenkins | master-slave,自建 | 插件均支持 | 支持 | 不支持 | 不支持 |
| Drone | 本地安装 | Github, Gitlab等 | drone.yml | 原生支持docker,每一个阶段在指定的image docker container下执行，支持service等 | 插件支持 |
| Gitlab CI | 托管，或自建 | Gitlab | .gitlab-ci.yml | 不支持 | 支持K8s |
| Spinnaker | 开源，自建 | 需集成CI工具 | 支持 | 支持 | 支持 |
| Crcle CI | 托管，免费和付费 | Github | yml | 支持 | 部分支持 |
其它工具：
- Travis 最老的托管解决方案之一，成熟的解决方案，提供托管和本地变种
- Bamboo 本地的持续集成和部署工具，云端解决方案Bitbucket pipeline。
- CodeShip近期也推出了Jet，这是一个对Docker应用进行测试与部署
- Piplin是一款免费、开源的持续集成与部署系统
- Codeship是一个强大的带有Docker支持的本地持续集成解决方案
- Codefresh是一个支持Docker的持续集成工具，它可以发布和建立本地环境的Docker镜像。
- Go CD 等
部署
上面总结了持续集成，也包括了持续交付delivery , 下面就说说部署deploy的事情
部署的方式
滚动
逐个进行服务器版本更新，启动一台新版本，停止一台老版本，一般可以设置间隔时间，升级时只需多占用1台服务器
缺点：新版本没有充分验证蓝绿
部署新版本，老版本同时在线，切换流量到新版本，验证通过删除老版本，反之则回滚切换流量到老版本
缺点：资源浪费金丝雀
可以部署一个独立的单元，通过负载均衡权重设置，部署和引入新的流量；一般作为发布的一环，安全生产环境的验证，通过后才发布正式环境
缺点：机器少，流量小，验证时间有限灰度
能够平滑过渡的一种发布方式。在代码中通过开关控制，全量发布到线上后，再通过灰度功能配置，让指定权重的流量和规则的用户使用到新版本，验证通过后，再逐步放量，反之则回滚
缺点：代码之后需要下线AB
需要根据人群得到不同版本的效果实验数据分析，从而提供精细化运营和最优的版本决策；No data , no BB
缺点：代码之后需要下线
部署依赖的功能平台
平台，需要管理云上的机器，和应用服务（容器实例），所以，基于这些功能，就简称他容器云平台好了。部署一个服务，平台最基本需要的功能具体如下：
资源/集群管理
首先，部署应用/服务，我们需要有机器资源，物理机，虚拟机，还是云主机，并对它们进行管理 :
给服务所在环境分配机器，把这些机器管理起来形成一个集群，并监控机器的状态，当应用需要部署资源时从这个集群中分配
调用
然后，就可以部署/调度我们的应用/服务 ：
服务部署或弹性伸缩时，把服务部署到集群合适的资源上
编排
编排也有调度的意思，这里特指将单个服务，或有依赖关系的多个服务进行yml文件配置，编排工具按照描述的配置，先后关系，依次调度到指定标签或合适的资源上，创建和管理这些容器/服务
弹性伸缩
根据autoscale配置的服务运行时状态，动态调整服务的数量
容器云平台/调度工具有哪些：
- Swarm mode
Docker开发的集群调度框架，上一篇“容器化”也介绍过，易于集成和设置，适合中小规模集群 - Kubernetes
目前最流行的容器调度平台，通用，开源，适合千节点集群 - Mesos
Apache Mesos 分布式资源调度管理，Marathon 服务管理，适合大型系统，万节点集群
集成云平台（调度）工具
- spinnaker CD 持续交付工具
更好的抽象，支持集成多种CI平台
支持集群多种云平台进行CD，可以对接k8s，提供在页面上进行蓝绿发布，金丝雀发布等策略的配置，自动化发布，能够更容易的进行回滚，和扩容，也可以轻松的实现服务的弹性伸缩 - Gitlab CI
GitLab CI提供持续集成服务，可以使用托管服务或自建。也支持集成k8s来做持续交付，部署
自动化
从CI到CD，从一次代码提交开始，触发流水线步骤执行，每一步都可以是自动化执行的，包括最终的版本部署，出现问题时的自动回滚。当然，有些步骤也需要人工确认，如代码评审，系统测试通过确认等行为，确认后才会触发自动化下一步的流程，(当然这些是自己定义的)。那么就需要有一个平台来集成CI到CD的整个过程
DevOps
这个平台，不仅仅可以做CI，CD的事情，它可以面向DevOps，Development - Operations 开发到运维的整个生命周期，通过一个平台来管理：项目需求，代码，应用，CI，CD，测试，上线，运营的整个过程，包括执行信息的反馈。加速软件开发，减少软件开发到交付或上线的时间，并使开发、测试、运维几个角色协作的更紧密。
