前言
hello~~各位~~先做个专题小介绍：我们一伙6人是深圳某公司的项目管理小组，从去年开始我们就有了个定期分享的机制。为了能促进分享，共同进步，所以我们要把平时的分享内容也转到简书。话不多数，开始正文。
自去年中旬开始，项目管理小团队逐步开始组织级别的敏捷转型，即从原本的立项型项目管理模式过渡到目前的多敏捷小组的阶段。由于目前敏捷小组管理范围以需求-测试阶段为主，一般测试完成后进入投产阶段成了个“黑盒子”，我们一般只能了解投产的结果而对其中的过程不甚了解。所以这个分享是站在项目组的角度，厘清概念，了解业界在做的一些实践操作。
热身练习
来吧! 开始我们的小练习，请按以下流程发生的先后顺序进行排序。参考答案放在全文的最后。。一行。
人人都谈CI/CD
人人都谈CI/CD，那为什么互联网公司要持续往这里投入力量呢？下面从四个角度来分析一下：
1. 基础建设能力是一个公司能走多远的一个决定性因素。下图是从网络获取的一幅图画，企业在年初制定的美好计划在具体实施的时候就要看基础建设是否能长期有效的支撑这个目标的达成，这也是为什么持续交付是一件很“技术”的工作。在敏捷实践中，基础运维甚至不作为一个主要角色提出。但在实际的项目落地过程中，我们发现这一环不可或缺。
2. 从批量交付进化为持续交付：当前提高生产效率的方法还是简单的批量交付，即打包、部署的流程以需求为单位，批量进行部署。理想情况下是建立交付流水线，完成代码-部署的流程自动化，而非每个环节都等待人工手动处理。
3. 技术中心的组织框架不再各自为政，围绕持续交付的两个核心让各个职位合作交付。目前有很多成熟的持续交付软件可以实现以上需求：版本管理Gitlab，集成部署Jenkins，阿里云效等。
4. 技术开发过程中的四个部署环境在这里说明一下，因为开发过程中经常提及却没有清晰分明。开发环境即开发自己的本地环境，用于联调；集成环境即集成服务器进行打包、单元测试后部署；验证环境是集成成功后即自动部署到验证环境供QA和PO进行验收；生产环境即应用最后开放给用户的操作环境。
持续交付的理念
本章将从框架性来探讨持续交付涵盖的4个流程：持续集成、持续交付、持续部署、持续发布。
版本管理是对源代码、SQL脚本、配置项等进行版本的持续集成，分支类型如下四种：Master主干、Dev开发主干、Feature特征分支以及release分支。Master分支是整个项目的主心骨，从项目开始一直延续至项目结束，属于protected分支。当需要开始开发任务时，开发负责人从Master分支拉出Dev分支作为本次开发的管理分支。各开发即可从Dev分支中，根据自己的开发任务拉取特征分支。
自动化构建中是经由CI服务器完成整个构建流程。该流程具体为：版本控制服务器自动检测到代码变化并进入构建流程，经过单元测试检查并进行构建打包，打包后部署在集成环境交付到QA部门进行测试验收。过程中任何一步有问题都会退出流程并向开发负责人、开发本人、项目管理以及其他同事自动发送通知。
接下来会说明两个“CD”流程，一个是持续交付，一个是持续发布。持续交付即在完成自动集成后交付给QA团队进行测试管理并尽快完成测试后部署到生产环境的流程，而持续发布即远远不断向真实用户发布新功能/修复缺陷的过程。
持续部署中关注以下四点：
1.脚本代替手工，如编写脚本完成一些需要手工执行、手工配置的部分；
2.使用容器进行部署，如Docker的容器化服务可使服务独立部署，提高部署、回退的灵活度；
3.构建自动化流水线可将各流程节点及相关角色通过流水线串联在一块儿以提高部署的效率；
4. 建立持续部署的架构可促使微服务的高效落地，使得服务的投产可以随时进行；
page1 ：顺序 1 - 3 - 2
page2 ： 顺序 3 - 2 - 1
