持续交付
持续交付通过自动化的方式，让每次开发提交代码后，自动化编译、测试和部署。持续交付细分的话，分为持续集成、持续交付和持续部署三个概念。
集成、部署和交付是伴随着软件工程一起发展的。在瀑布开发的早期开发阶段，大家各自开发，等到大家开发差不多了，一起提交代码到源代码管理工具，然后代码编译、打包部署到测试环境。但是因为是长时间在各自的开发环境运行，每次集成很痛苦，会遇到N多问题，例如编译无法通过，硬编码了开发环境地址、类库版本不一致、API格式不一致等等，通常需要持续好几天甚至好几周才能出来一个相对稳定的版本，下图很形象的说明了这点：
- 手动集成到自动化的持续集成
自动化集成就是持续的频繁的去做
瀑布模型开发的集成，或者说传统的集成，都是在开发阶段整体完成后才开始集成，但是持续集成的做法就是每次有代码合并入主干之前就进行持续的集成，代码集成到主干之前，必须通过自动化测试，只要有一个测试用例失败，就不能集成。好处显而易见：
- 配合自动化测试，保证主干的代码是稳定的
- 频繁集成可以让开发人员从主干获取最新的代码
但是持续集成主要问题就是搭建整个持续集成环境需要花很多时间，我们可以配合一些流程规范来辅助执行，比如一定自动化测试代码的覆盖率。
部署在早期是一件很麻烦的事情，需要手动获取最新源代码、编译、修改环境配置。
我们经历过手动部署到自动化部署，早期的自动化部署就是每日构建，每日构建程序自动从源代码管理器下载最新代码、编译、部署程序到测试环境，但是如果开发人员提交的代码有问题会导致当天的每日构建编译不过，第二天开发人员还需要去解决，于是又衍生了从脚本部署到持续交付，在功能合并到主干后，进行自动化测试、打包和部署到测试环境中，对于生产环境，可能需要人工确认，图如下：
从持续交付到持续部署，环节上就是缺少了人工确认。
那对于瀑布模型持续交付应不应该用呢？很显然，持续交付有如下特点：
- 尽快暴露问题
- 极大提升效率
- 提升软件质量
- 降低项目成本
虽然持续交付现在还不太普及，但我觉得会像源代码管理一样，成为软件开发的标配。
那我们如何搭建一套自己的持续交付环境呢？
- 源代码管理工具：git、svn
- 自己写自动化测试代码
- 持续集成工具：jenkins、Go CD、Travis CI、GitLab CI