持续交付模式(2)

　　从构建服务器提送

　　将构建版本从构建服务器直接提送是更好的选择。这可以消除我上面提到的那种方式中的多种时间冲突。而且，人们更容易知道被推送的是哪个版本。

　　这种方法也有弱点：人们很容易选择错误的版本推送到生产环境中。

　　重新构建并推送

　　第三种选择是为持续集成服务器创建新的构建选项，其中包括推送到生产环境这一步。我提醒大家要小心这种方式。虽然理论上重新构建的代码与你测试的代码没有区别，但还是有某些东西增加了出错的可能性。

　　另一个问题是：这让你可以选择多种编译选项。如果你可以选择，你可能希望在交付准备服务器上使用调试构建版本，在生产环境上使用发布构建版本。如果有些行为在两个构建配置中有变化，这会产生灾难性后果。

　　虽然使用持续集成服务器做配置很容易，但我再次强调：我不推荐人们选择这种方式。

　　场景2：加入QA

　　如果QA加入进来，事情就变得非常复杂了。因为你现在必须处理跨团队的沟通和规划，你需要更多的构建环境，还有更具意义的所有制感觉。

　　结构

　　一旦QA加入，你可能需要至少3个非生产环境服务器。在某些特定条件下，代码变更从一台服务器提送到下一台服务器。

　　集成环境

　　这是功能代码签入后，构建版本到达的第一台服务器。被称为“集成环境”，是因为签入功能代码会与其他功能代码完全集成。用来现场检查一个构建版本是否适于提供给QA。这个环境中允许不稳定，但是不允许构建版本停留太长时间。

　　QA环境

　　这是QA团队完成自己大部分工作的地方，根据需要会从集成环境更新代码。

　　交付准备环境

　　交付准备环境现在完全用作演示和在构建进入生产环境前的最后检查。任何构建版本到了这个环境，都应该是牢固可靠的。交付准备环境也许可以连接到生产环境资源，比如数据库和文件系统，但不是必须这么做。

　　QA交付选项

　　从构建服务器向集成环境交付代码，可以使用基线场景中提到的多种方式之一。从集成到QA环境就需要动动脑子，因为涉及多个团队。下面是我看到的一些成功模式。

　　开发者发起

　　在“开发者发起”模式中，开发人员决定何时进行编译检查和把构建版本提送给QA。说得难听一点，当QA完全“服从”开发人员时，可以使用该模式。可能第一眼看上去，这对开发人员来说还挺好，实际上常常阴暗着某种问题。比如：如果发生某个质量上的问题，QA人员可能要等很长时间，等着阻碍他们工作的bug得到解决。

　　极端情况下，需要设置自动提送机制，定时自动提送到QA环境。

　　QA发起

　　这是更适合大部分团队的典型方式。开发人员仍然参与，他们需要在集成环境中检查他们的构建，然后确定构建版本是否可以提送。

　　在这种方式下，QA准备好测试新功能时，他们会拉过来“已知正常”的最新构建版本。通常是QA经理完成该工作，一般来说他对于QA人员的需要最了解。虽说如此，有些QA团队允许所有成员提取新构建版本。

　　Test Runner启动

　　对于想真心做好自动化测试的公司来说，这才是目标。构建版本到达集成服务器后，整个自动化测试套件就开始运行。如果全部通过，构建版本会自动提送到QA。跟其他自动化交付方式一样，可以采取签入时方式或定时方式。

　　不要低估这种方式需要投入的成本。不仅需要有完整的测试套件，所有的测试必须还都能通过。构建服务器无法区分测试失败是由于新功能出问题，还是说有些问题需要留待将来解决。

　　变通方式，是把测试拆分成必须通过(must-pass)的项目和临时项目。测试从临时项目开始，特别是在TDD风格编程中用到的测试。只要测试验证正确、有用，代码也可以通过这些测试，就转而处理必须通过的项目。构建服务器不会运行临时测试，但是会看重必须通过的测试项目的结果。

　　交付准备/生产环境交付选项

　　在持续交付思想指导下，QA对于接收到的给定构建版本，只有两个选项：构建要么失败，要么提送到交付准备服务器。QA不会一边处理一个可用的构建版本，同时等待某些功能完成

　　这的确提出一个问题：如何定义某个构建版本是“可用的”?任何可以安全放到生产环境的构建版本，都是可用的构建版本。如果其中有未完成的功能，但这些功能可以以as-is方式工作，那么构建就可以往前提送。除非某个失败的功能会影响应用在生产环境中的使用，构建版本就不能停滞在QA这里。

　　进入交付准备服务器后，构建版本在下个发布周期中就要提送到生产环境。尽管持续部署到生产环境很难完全实现，还是经常听到成功的每周、甚至每日部署。关键点在于：一旦一个某件版本证明没有问题，就需要快速移动到生产环境，这样团队就可以聚焦于下一系列要开发的功能。如果构建版本停留在交付准备阶段长达几周乃至几个月，就会造成无尽的问题。

　　把QA环境和交付准备环境分开，是为了推进工作流。只要一个构建版本提送到交付准备服务器，下一个构建版本就会从集成服务器拉过来。这样一来，交付准备服务器就总会有一个稳定的环境，供利益相关者和其他第三方查看演示版本，同时QA仍有自己可以工作的环境。如果把服务器的职责混合起来，当环境锁定时，QA的工作就必须要停下来。

　　配置相关问题

　　一旦有了多个环境之后，配置文件就会成为严重的问题。举个例子，交付准备服务器必须配置正确，避免发生诸如发送测试邮件给所有用户，或是通过正式支付网关下订单等问题。我曾与一个刚入门的开发人员一起工作，他当时试图通过一个配置错误的测试服务器购买几百万美元的债券。(幸运的是，每张债券的价格比实际价格高，因为订单没有成功购买。)

　　出现这种状况，因为生产环境的配置保存在版本控制系统中，并与应用一起部署。这么做，是要防止出现非生产环境的配置放在版本控制系统中，然后被部署到生产环境服务器上的状况。

原文转自：http://kb.cnblogs.com/page/117932/