持续交付的实践与思考

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

【3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站】本次培训围绕基于Docker的CI/CD实战展开，具体内容包括：持续集成与持续交付（CI/CD）概览；持续集成系统介绍；客户端与服务端的 CI/CD 实践；开发流程中引入 CI、CD；Gitlab 和 CI、CD 工具；Gitlab CI、Drone 的使用以及实践经验分享等。

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

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

为何要有持续交付

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

持续交付能作到什么

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

持续交付的几个原则

1. 为软件发布建立一个可重复且可靠的过程：一键发布与回滚，若是发布出了问题，你几乎能够肯定不是发布脚本自己的问题，由于这个脚本已经通过屡次检验；
2. 将几乎全部的事情自动化：手工发布及漫长又不可靠，采用自动化脚本，节省时间，节省精力；
3. 把全部的东西归入版本控制：采用变动管理，方便审计，将全部的变动都在掌控之中，出问题能够快速定位问题；
4. 提交并频繁作让你感到痛苦的事情：小步快走，分散痛苦与风险；
5. 提升内建质量：越早发现问题，修复成本越低，等 QA 或者用户告诉你应用有问题的时候，修复成本很是高，也增长了你计划外的工做；
6. 『Done』意味着『已发布』：没有完成百分之多少这种说法，反推着你将任务分解，将功能尽快发布到生成环境中去，减小了产品反馈时间，提升了竞争力，也减小了风险；
7. 交付是每一个成员的责任：流程标准，每一个人均可以参与到流程的每个部分，促进协做，也帮助新人适应与提升；
8. 持续改进：不断演进，改善发布流程，这个流程须要持续的改进，提升吞吐，增长产量，提升质量；

持续交付的实践

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

1. 提交：单元测试 Mocha/AVA，以及测试覆盖率 nyc；
2. 编译打包：即打包 Docker 镜像，推送到 Registry ，目前尚未彻底引入 Docker 集群，所以部署过程省略；
3. 部署文档：用 Ansible 脚本自动将 API 文档以及测试覆盖状况部署至静态网页文档服务器，这个时候能够直接将分支对应的文档给客户端开发，还能够直接查看测试覆盖率状况，确认与改进单元测试；
4. Review：即提交 Merge Request，你们一块儿 Code Review；
5. 部署应用：须要 Review 经过后，将代码合并至 master 分支，而后手工点击按钮部署；
6. 回滚：假如应用出问题，能够点击按钮一键回滚；

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

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

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

• 对于产品团队，咱们能要求他们将需求拆分尽量的细，一旦开发完成咱们能快速部署，因而他们能更快获得反馈，从而提升产品的试错能力。
• 对于运维团队，咱们已经将部署流程优化了，因而他们能更专心于基础设置的维护与改善，同时也能够促进协做，推行全面的配置管理。

Reference

• about.gitlab.com/direction/
• about.gitlab.com/2016/08/26/…
• github.com/everpeace/c…
• docs.gitlab.com/ce/ci/envir…
• about.gitlab.com/2016/08/05/…

原文连接：持续交付的实践与思考