持续交付模式当你有了持续集成需要的构建服务器和脚本之后，下一个问题肯定是：“我们该拿这些构建版本怎么办？”持续交付，以自动化或半自动化方式，将构建版本从一个环境提送(promote)到更接近实际生产的交付准备环境；这常常是公司在这方面演进的下一步。任何规模的公司都可以实施持续交付，但是具体流程会根据公司具体情况差异很大。显而易见，四人全能团队的需要，与大规模、多团队、配备正式 QA 和设备精良的产品支持部门这样的公司，二者一定有很大差别。本文没有试图提出万能方案，而是覆盖多种场景和选择。选择持续交付工具集为持续交付选择工具集，是最不重要的决策。当你制定出工作流程之后，只需要选择相匹配的工具集即可。考虑到初始设置和配置的工作量，花几天时间构建自己定制的工具也不是非理性选择。更重要的是，这样做没有锁定的风险。跟选择版本控制系统不同，你可以使用多种持续交付工具，而且可以互相之间自由切换。QA 团队从开发人员那里拉出构建版本使用一种工具，向准备服务器推送时使用另一种工具，这样的事情也有所耳闻。基线场景在基线场景中，我们要以有限的资源找出公司中的模式。像由 3 到 4 人构成的 IT 部门，常常兼做开发和系统管理。这样规模的团队常常支持中小型业务，特别是不以技术为主业务的公司。大型公司也有可能这样组织，把人分成多个、很可能是互相独立的小组，各小组之间也没有交互。在真正开始进行持续交付之前，需要做一些必要的设置工作。首先，最重要的是要有版本控制系统，以及与之匹配的构建服务器。这第一台构建服务器将会是你的持续集成服务器，它要保证每次签入动作都能成功构建。一般来说，你需要一个“现成”的构建服务器担当此任。能够监控签入动作还要自动初始化构建，要想手工开发这样的东西，真正操作起来常常要比听起来难得多。即使可以在版本控制系统中加入触发机制，完成诸如失败构建通知这样的功能也不值得花太多功夫。即使在资源有限的作坊式公司，交付准备服务器(stagingserver)也是持续交付的必要组成部分。交付准备服务器应该尽可能模拟出生产环境。“你有多少预算”常常是首要问题。如果你的生产环境有价值几十万美元的数据库服务器，很可能你无法负担搭建一个同样的交付准备服务器。而且可能你也不想这么做。在模拟生产环境时，有一个常见错误：过高匹配硬件环境。假如你的生产环境每秒处理 100 个请求，如果为交付准备服务器购买同样硬件，但测试时每秒只执行几...
