持续集成与部署

持续集成

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,测试,上线,运营的整个过程,包括执行信息的反馈。加速软件开发,减少软件开发到交付或上线的时间,并使开发、测试、运维几个角色协作的更紧密。