持续交付的实践与思考

【编者的话】一直以来都在做团队里的基础性工作，直到最近，成果开始慢慢展现，尤其是上周刚看完《持续交付》这本书后，总结已经做的工作，又有了些新的感悟。

过去一段时间，我都是围绕着 Gitlab 的一些功能来开展的，从最开的代码与应用配置管理，然后到 CI 系统，提升代码质量，到最后完整的持续交付流程提升团队工作效率。

那么我就结合《持续交付》这本书的内容，正文开始。

不敢发布新功能：每次发布都会心惊胆战，因为一下子发布了太多功能，测试又没做好，而这时候产品催着要上线。另外按照以往的经验，由发布而出问题的的概率最高；
线上事故处理时间长：每次出线上事故，不能很快定位问题，如果是由于同事线上改动了什么，就更难定位问题了，而在之后大家可能会狠狠责怪那个同事，事实上，他也很无辜，因为没有人告诉他什么能做，什么不能做，或者该怎么做；
发布周期太长：由于每次功能完全开发完之后才会发布上线，而如果涉及到数据库更改或者迁移，发布周期可能会拖得太长；
协作问题：比如新人来到团队时，由于被限制了各种线上的权限，尤其是发布权限，会导致很多工作开展不顺利，而每次发布求助于其他同事的话，会造成沟通问题，进一步造成了协作上的问题。另一个，往往由于习惯于口头上说下要发布了，然后发布过程对其他人而言是不可见的，若是线上还需要操作些什么的话，几乎对其他人是更不可见的；

让软件构建、部署、测试和发布过程对所有人可见：由此，大家可以学习过程，了解其他人做了什么，在一个规范的流程中工作，促进协作；
改善反馈，更早发现问题：在一个完整的流水线中，可以设置多个『检查点』，简答来说，就是加入多个测试环节，保证代码质量，而在这个过程中，越早发现问题，修复的成本越低；
通过一个完全自动化的过程在任意环境上部署和发布软件的任意版本：在陈浩大神的《从 Gitlab 误删除数据库想到的》这篇文章里，提到： 人管代码，代码管机器，其实持续交付就能达到这个效果。并且在一种极端情况下，假如你使用的云服务商挂了，你也能在其它云服务商上面快速重建你的整个线上系统（当然，没那么简单）。

在目前的团队持续交付流程中，我们在每个环节的实践如下：

提交：单元测试 Mocha/AVA，以及测试覆盖率 nyc；
编译打包：即打包 Docker 镜像，推送到 Registry ，目前还没有完全引入 Docker 集群，因此部署过程省略；
部署文档：用 Ansible 脚本自动将 API 文档以及测试覆盖情况部署至静态网页文档服务器，这个时候可以直接将分支对应的文档给客户端开发，还可以直接查看测试覆盖率情况，确认与改进单元测试；
Review：即提交 Merge Request，大家一起 Code Review；
部署应用：需要 Review 通过后，将代码合并至 master 分支，然后手工点击按钮部署；
回滚：假如应用出问题，可以点击按钮一键回滚；

可以看到，目前主要是缺失预发布环境，这一步还需要将环境搭建脚本完善之后才能做到，而目前公司运维团队还是与我们开发团队分离的，因此达到相要的效果还是得做些努力。

###总结
目前我已经做到：将应用配置单独管理起来，以及部署相关的脚本都已经实现，因此才能很快地将持续交付流程跑起来。其实可以这么说：应用配置管理与自动部署脚本是持续交付流程的前提与基础。

而持续交付流程一旦完善了，能极大改善我们开发团队的交付能力，甚至倒逼产品与运维团队提高他们的效率：