jenkins持续集成-前期准备-1

参考: 持续集成CI/CD ， 一文秒懂CI, CD AND CD ， Jenkins持续集成之前期准备

一、简介

持续集成指的是，频繁地（一天多次）将代码集成到主干，比如java编写的程序，需要上线提供服务，就需要如下准备工作

1. 准备一个代码仓库(svn\git)，提交代码
2. 团队单个开发创建分支，而不是主干
3. 对分支进行拉取，编译，打包构建成war包，测试软件能否正常提供服务
4. 正常则合并分支到主干
5. 对主线代码进行拉取，编译，打包构建成war包，复制到线上服务器，替换旧的项目启动

为什么使用持续集成

1. 减少操作风险
2. 减少开发、运维重复操作过程
3. 任何时间、任何地点生成可部署的软件
4. 增强项目的可见性

二、持续

持续集成

持续集成(Continuous integration，简称CI)，持续集成指的是，频繁地（一天多次）将代码集成到主干

需要具备哪些条件:

1. 你的团队需要为每个新功能，代码改进，或者问题修复创建自动化测试用例。
2. 你需要一个持续集成服务器，它可以监控代码提交情况，对每个新的提交进行自动化测试。
3. 研发团队需要尽可能快的提交代码，至少每天一次提交。

能获得什么呢？

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

持续交付

持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。

需要具备什么条件？

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

能收获什么？

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

持续部署

持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。

需要具备的条件:

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

可以获得什么？

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

三、部署流程

对于现今来说，为了保证web的可用性，代码的部署方式有很多，比如常见的蓝绿部署、金丝雀部署、滚动更新；

蓝绿部署

蓝绿部署指的是不停老版本代码(不影响上一个版本访问)，而是在另外一套环境部署新版本然后进行测试，测试通过后将用户流量切到新版本，其特点为业务无中断，升级风险相对较小

实现流程

1. 正在运行的业务不切换(v1)
2. 新部署一套环境(v2)， 修改某增加某些功能
3. 测试v2通过将用户请求切换切新环境(nginx\dns)
4. 如有异常直接切换旧版本
5. 下次升级，将v1升为v3，然后循环递进

适用环境

1. 不停止老版本，额外部署一套新版本，等测试发现新版本OK后，删除老版本； (需要增加设备成本)
2. 蓝绿发布是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用；
3. 蓝绿发布对于增量升级有比较好的支持，但是对于涉及数据表结构变更等等不可逆转的升级，并不完全合适用蓝绿发布来实现，需要结合一些业务的逻辑以及数据迁移与回滚的策略才可以完全满足需求；

金丝雀/灰度发布

金丝雀发布也叫灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式，灰度发布是增量发布的一种类型，灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”(小白鼠)，测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题；

实现流程

1. 准备好部署各个阶段的工具，包括：构建工具，测试脚本，配置文件和部署清单文件；
2. 从负载均衡列表中移除掉“金丝雀”服务器；
3. 升级“金丝雀”应用（排掉原有流量并进行部署）；
4. 对应用进行自动化测试；
5. 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）；
6. 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器，否则就回滚，灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度；

应用场景

• 不停止老版本，额外新增一套新版本，不同版本应用共存；
• 可以按照用户地区或者权限设置权重，按批次进行切换，如 北京80%，深圳20%
• 经常与 A/B 测试一起使用，用于测试选择多种方案；

滚动更新

滚动更新，循环递进，按批次停止服务并升级，周而复始，直到集群中所有的实例都更新为新版本；

实现流程

1. 停止集群中N个服务器，并从集群中删除这几台服务器
2. 升级集群中的这几台服务器程序；
3. 与原有的同时使用，或者按地区访问
4. 如果没有问题在升级下一批，直到集群中实例都为最新版本， 如有问题就回滚那几台服务器

应用场景

• 不停止老版本，与新版本同存一段时间
• 也可以按照地区或权限设置权重，让一批用户优先体验最新的版本

额外说明

        A/B 测试也是同时运行两个 APP 环境，但是蓝绿部署完全是两码事，A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等，蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚，即蓝绿部署是一套正式环境环境在线，而A/B 测试是两套正式环境在线；

持续部署流程

1. 开发者往仓库提交代码(git\svn)，后续所有步骤都始于本地代码第一次的commit

2. 代码测试， 代码仓库对commit操作配置钩子(hook)，只要提交或合并主干，就会跑自动化测试，测试有如下几种

测试类型	说明
单元测试	针对函数或模块测试
集成测试	针对整体产品的某个功能的测试，又称功能测试
端对端测试	从用户界面直达数据库的全链路测试

3. 构建，当测试通过，就能交付了，交付后可以先进行构建(build), 指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。

        常见的构建工具如： jenkins、Travis、Codeship、Strider

4. 部署，当通过全部测试，这个代码就是可被部署的版本了，将这个war发至生产环境，生产环境打包解包至本地，在通过符号链接(symlink)指向该目录，就能重新启动应用了

           常见构建工具如： Ansible、Chef、Putty

5. 回滚、指当前版本如果有问题，需要回归上一版本的构建成果，修改一下符号链接指上上一个版本即可