持续交付-发布可靠软件的系统方法

常规的软件部署的反模式如下

一、手工部署软件：

1.有一份非常详细的文档来描述各个执行步骤及每个步骤中易出错的地方。

2.以手工测试来确认该应用程序是否运行正确

3.发布时，常常会修正一些在发布过程中产生的问题

4.如果是集群环境部署，常常会发现在集群中各环境的配置都不相同，比如应用服务器的连接池设置不同或文件系统有不同的目录结构等

5.发布过程需要较长时间

6.发布结果不可预测，常常不得不回滚

7.发布之后凌晨一两点还睡眼惺忪地坐在显示器前想着怎么让刚刚部署的应用程序能够正常工作

如果有上述现象，就说明软件发布流程需要走向自动化。对于负责将应用程序部署到开发环境，测试环境或生产环境的人来说，应该只需要做两件事

（1）挑选版本及需要部署的环境

（2）按下"部署"按钮.

二、开发完成之后才向类生产环境部署

1.只有在向试运行环境部署时，运维人员才第一次接触到这个新应用程序

2.开发团队交付的正常安装程序、配置文件、数据库、配置文档等都未经类生产环境验证过，很容易出现问题

3.开发团队和执行部署任务的人员之间协作非常少

4.交付过程被划分到开发、DBA、运维、测试等部门之后，为了完成某个部署任务，各个部门的人员都会同时高举着问题单

正确的处理对策是讲测试、部署和发布过程也纳入到开发过程中，让它们成为开发流程正常的一部分

三、生产环境的手工配置

1.多次部署到试运行环境都非常成功，但当部署到生产环境时就失败

2.运维团队需要花比较长的时间为每次发布准备环境

3.系统无法回滚到之前部署的某个配置

4.不知道什么时候起，集群中的某些服务器所用的操作系统、第三方基础设施、依赖库或补丁级别就不同了

5.部署失败经常是因为某个人上次部署时为生产环境打了补丁，但却没有将这个修改记录下来。

正确的方式是测试环境、试运行环境和生产环境的所有方面，尤其是系统中的任何第三方元素的配置，都应该通过一个自动化过程进行版本控制。实际上，不应该允许手工修改，而只允许自动化过程来改变这些环境。

我们的目标是使用部署流水线，将高度自动化的测试和部署以及全面的配置管理结合在一起，实现一键式软件发布。

 以下三个标准很有用：

1.无论什么样的修改都应该触发反馈流程

2.反馈应该尽快发出

3.交付团队必须接收反馈，并依据它作出相应的行动。

构建自动化流程能很好地减小发布前的压力

良好建议：

1.将配置信息纳入版本管理系统，并让计算机直接使用这些信息，而不是通过人工手工输入

2.无论部署到什么样的目标环境，都使用相同的部署方法。

软件交付原则：

1.为软件的发布创建一个可重复且可靠的过程

2.将几乎所有事情自动化

3.将所有东西都纳入版本管理

4.提前并频繁地做让你感到痛苦的事情

5.持续改进，尽早改进

6.完成应意味着“已发布”，

第二章 配置管理

与项目相关的所有东西，都应纳入版本管理中，但二进制文件等中间产物无需纳入

频繁提交代码到主干

使用意义明显的提交注释（控制提交日志的格式）