前言

hello~~各位~~先做个专题小介绍：我们一伙6人是深圳某公司的项目管理小组，从去年开始我们就有了个定期分享的机制。为了能促进分享，共同进步，所以我们要把平时的分享内容也转到简书。话不多数，开始正文。

自去年中旬开始，项目管理小团队逐步开始组织级别的敏捷转型，即从原本的立项型项目管理模式过渡到目前的多敏捷小组的阶段。由于目前敏捷小组管理范围以需求-测试阶段为主，一般测试完成后进入投产阶段成了个“黑盒子”，我们一般只能了解投产的结果而对其中的过程不甚了解。所以这个分享是站在项目组的角度，厘清概念，了解业界在做的一些实践操作。

热身练习

来吧! 开始我们的小练习，请按以下流程发生的先后顺序进行排序。参考答案放在全文的最后。。一行。

建分支顺序

合并分支顺序

人人都谈CI/CD

人人都谈CI/CD，那为什么互联网公司要持续往这里投入力量呢？下面从四个角度来分析一下：

1. 基础建设能力是一个公司能走多远的一个决定性因素。下图是从网络获取的一幅图画，企业在年初制定的美好计划在具体实施的时候就要看基础建设是否能长期有效的支撑这个目标的达成，这也是为什么持续交付是一件很“技术”的工作。在敏捷实践中，基础运维甚至不作为一个主要角色提出。但在实际的项目落地过程中，我们发现这一环不可或缺。

为什么要持续交付1

2. 从批量交付进化为持续交付：当前提高生产效率的方法还是简单的批量交付，即打包、部署的流程以需求为单位，批量进行部署。理想情况下是建立交付流水线，完成代码-部署的流程自动化，而非每个环节都等待人工手动处理。

持续交付

3. 技术中心的组织框架不再各自为政，围绕持续交付的两个核心让各个职位合作交付。目前有很多成熟的持续交付软件可以实现以上需求：版本管理Gitlab，集成部署Jenkins，阿里云效等。

为什么要持续交付2

4. 技术开发过程中的四个部署环境在这里说明一下，因为开发过程中经常提及却没有清晰分明。开发环境即开发自己的本地环境，用于联调；集成环境即集成服务器进行打包、单元测试后部署；验证环境是集成成功后即自动部署到验证环境供QA和PO进行验收；生产环境即应用最后开放给用户的操作环境。

持续交付的4个环境

持续交付的理念

本章将从框架性来探讨持续交付涵盖的4个流程：持续集成、持续交付、持续部署、持续发布。

持续交付总览

版本管理是对源代码、SQL脚本、配置项等进行版本的持续集成，分支类型如下四种：Master主干、Dev开发主干、Feature特征分支以及release分支。Master分支是整个项目的主心骨，从项目开始一直延续至项目结束，属于protected分支。当需要开始开发任务时，开发负责人从Master分支拉出Dev分支作为本次开发的管理分支。各开发即可从Dev分支中，根据自己的开发任务拉取特征分支。