04.Jenkins学习笔记–基于Jenkins构建企业持续集成环境
持续发布版本所面临的问题
产品迭代过程
一般情况下产品迭代发布过程分为以下几个阶段：
编码 –> 构建 –> 集成 –> 测试 –> 交付 –> 部署
但随着敏捷开发模式与微服务架构的盛行，导致整个链路实施过程变得越来越复杂沉重。 为了解决这一问题，大牛们分别提出了持续集成、持续交互、持续部署的概念，但实践时对团队的技能水平提出了过分的要求，所以现在并没有完全运用起来，但是未来的技术发展趋势整体是朝这个方向走的。了解持续集成、持续交互、持续部署的概念很有必要。
持续集成（Continuous Integration）
持续集成是指个人研发软件的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。
持续交付（Continuous Delivery）
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的类生产环境 (production-like environments) 中。
持续部署 (Continuous Deployment)
持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
企业如何做到持续集成、交互、部署呢？大量的私有云厂商通过容器化技术已经打通整条链路：无论是自动化测试、持续集成、持续交付、自动化部署都有较成熟的解决方案。
如果企业不愿意购买现成的解决方案，那就只能自己动手来实践，当然这个摸索过程会长一些，但也会更贴近企业的实际环境。接下来介绍一个真实的企业产品集成部署解决方案。
版本快速迭代流程设计
知识点
- 整体流程设计
- 发布窗口机制
- 发布计划与实施计划
- 时间节点
开发环境 –> 测试环境 –> 预演环境 –> 生产环境
整体流程设计
发布窗口机制
上述的发布流程还是比较重的，不可能每天都走一遍。可以设定一个固定的发布时间，一般是设在周四。下午 4 点准时发布，如果这个点还没有来得及实现或满足测试的需求，则需要到下一个窗口才能发布。这样做的目的是为了让团队中每个人清晰有一个时间概念，知道什么时候该干什么事，避免手脚乱的随意发布上线。
发布计划
很多时候我们迭代的需求之间有依赖关系，还有需求的工作量也不一样，有的下个窗口就能完成，有的则需要更长时间，为此我们需要提前计划好下个窗口能上线的需求，避免 A 需求发布时，他所依赖的 B 需求不能发布的情况发生，或者中间随意添加需求，从而让发布变得难以控制。
通常我们会在周五前由产品经理或测试人员与开发人员协商后制定下个窗口期的发布计划表。包含以下内容：
| 需求说明 | 需求编号 | 应用系统 | 开发负责人 | 测试负责人 | 对应版本号 |
|---|---|---|---|---|---|
实施计划
有了发布计划并不意味着我们就可以拿着计划更新上线了，到了发布时间计划的项目不一定能够如期实现，更重要的是发布计划中并没有包含实施更新说明，如：需要更新哪些 SQL 脚本、哪些配置文件等。而这些都是测试人员在更新环境的时候所必需的。所以在发布之前需要开发人员填写一个部署说明文档，包含以下内容:
- 需求说明
- 需求编号
- 应用系统
- 依赖系统
- 项目文件
- 变更脚本
- 变更配置
- 开发负责人
- 测试负责人
- 版本编号
- 发布时间
一般由各个开发来共同编写这个文档，所以我们需要可以在线共同协作的文本编辑系统来实现，而不是采用桌面软件来编辑。
目前有很多这类的文档系统，例如：
当然某些企业可能禁止访问公网，或者对信息安全非常敏感，那么就需要安装购买：Confluence 这类的协同软件。
时间节点
整个过程涉及多方团队协作，只要一方延误，就会造成其它方等待或工作推迟的情况发生。比如开发的 A 需求延迟半天提测，这就会导致测试的工作延期，从而影响上线时间。为避免这种情况需要设计精细的时间节点：
