持续交付模式(3)

　　要避免上述问题，有个出人意料的解决方法：不要让构建代理的网络账号对配置文件有写权限。这样，如果有人不相信签入了配置文件，部署将会失败，错误就可以得到纠正。

　　不过这么做也有自己的问题。用这种方法，只要文件中的配置需要修改，就必须手工操作。如果失败了，将会使得环境出现问题，从而带来风险，因为数据更新随时可能发生。

　　关注点分离和配置文件

　　“关注点分离”这个词常常用来说明正确的设计决策应该怎么做，如果认真思考谁应该负责做什么，这种方法也是很有帮助的。比如，负责生产环境技术支持的人不关心开发人员选择注入哪种日志记录框架。然而，他们关心数据库连接串和警告发送的邮件地址。

　　我推荐下面这些类型的配置文件。

　　环境设置：与特定环境相关的值，必须按照服务器分开设置。只有某些重要事件发生时，才会需要改动它们，比如新数据库或新文件服务器上线。

　　代码作为配置：类似于驱动依赖注入框架的XML文件。虽然看起来像配置文件，但除开发人员外任何人都不应该碰它们。这些文件必须要放在版本控制系统中，而且应该把服务器上的文件标记为只读。

　　微调配置：这些配置与环境无关，但也许生产环境支持人员需要访问。可能包括比如批量上传批次限制、或是web页面请求超时设置等。

　　这三种配置中，微调配置需要付出最多精力以保证正确。理想状态下，应该有缺省配置放在文件中，并保存于版本控制系统，并可以根据特定服务器修改出多个文件，并且不必控制这些文件的版本。

　　配置和培训

　　避免增加不必要的配置设置，有一个技巧：要求为每个配置项提供文档和培训。如果不花时间教给生产环境支持人员何时、为何调整某些值，他们就无法完成这些工作，这些值就成为无法配置的摆设。

　　场景3：使用SOA的多个团队

　　使用SOA时，通常采取多团队方式。比如，一个团队构建数据库和服务，另一个团队处理UI，这种情况很常见。有时，两个团队的工作会非常紧密，相关团队成员会常常互相交换。有时，团队可能来自地球两边的不同公司。不管他们怎么切分，基本的模式相同。

　　结构

　　如场景2，服务团队需要一个地方来测试构建版本，这样他们不会对团队之外造成负面影响。同时，UI开发人员需要一台可信的服务器，能够一直保持稳定，否则他们就无法完成自己的工作。因此，除了我们前面提到的单一团队场景，有必要加入“开发环境”。

　　不考虑UI集成阶段，我们看到的顺序与场景2相同。交付选项相同，附加条件是只有UI团队参与在这个流程中。UI团队对于构建版本质量的意见比服务团队的意见重要。

　　开发交付选项

　　何时以及如何将代码交付给开发环境，是很多紧张情势的来源。有问题的构建版本到了QA环境，QA团队只要让其失败，然后就可以转向其他任务，比如为新功能准备测试，或是改进回归测试。要是有问题的构建版本到了开发环境，整个UI团队就会发现自己无法工作了。因此，虽然QA交付中的多种交付模式都可以运作，基于自动化测试的方式目前是最成功的模式。

　　说明：谁编写集成测试?

　　处理分离的服务层时，提供服务和消费服务的团队都要编写自动化测试，这很重要。提供服务层的团队最了解服务层内部机制，因此能编写出别人不知道、或是了解其重要性的测试。

　　不过，这不能成为消费服务的团队不写测试的接口。他们的测试覆盖的场景不仅服务开发者想不到，而且能测试他们对于服务层的理解。比如：UI开发人员会假定某个给定调用永远不会返回null或负值。测试过UI使用的所有参数组合后，他们就可以确保自己的假设没有问题。

　　如果你的公司有QA工程师保佑，而不仅仅是只有QA分析人员，他们会发现自己也要针对服务层开发自动化测试。这常常与自动化UI测试连在一起，特别是动作结果不需要通过用户界面验证的时候。

　　场景4：采用并行功能开发的多个团队

　　这种情况很棘手。目前，前面提到的各个场景都假定只有一个单独的开发主干。一旦开始处理多个开发团队针对同一代码库并行开发，就必须决定何时、如何将功能代码从团队分支转移到基本开发主干中。下面两种模型是我见过的成功范例。

　　功能推送模型

　　在该模型中，不管何时，只要确定没有问题，每个团队都会把自己的变更推送到主干中。该模型的优点在于：团队可以自给自足。

　　合并-推送

　　该模型中最常用的策略是：在本地合并及测试。只要测试通过，修改的部分就可以推送到主分支。

　　该模型最大的风险是缺乏原子合并。很可能某个团队修改了某个函数的名字或签名，而另一个团队正在加入新的文件使用了同一个函数。如果两个更改同时签入，构建版本就会失败，而且版本控制系统不会报告任何冲突。

　　锁定-合并-推送

　　该方式需要版本控制系统支持锁定。推送新的构建版本时，主干应该是锁定的。新的功能要在本地与主干合并，完成冒烟测试，然后推送到主干。虽然合并的问题可以在锁定时解决，任何测试的失败必须马上把锁释放掉。

　　功能拉模型

　　该模型中，团队永远不能发布他们的变更。相反，变更控制团队的人负责将功能拉入到主干中。这样一来，QA团队就只会接收到他们准备好测试的变更。

　　功能拉模型需要高级的版本控制系统，支持集成工作项跟踪。仅仅给变更打上任务号是不够的，成员必须要说明“将功能X合并入分支Y”，并让版本控制系统识别所有需要的变更。这可以手工完成，但是会耗费很长时间，而且很容易出错。

　　对于简单的合并，变更控制工程师可以自己一个人搞定。复杂的合并，特别是团队们没有定期更新自己分支的情况下，需要开发相关功能的团队协助合并工作。

　　结构

　　不管功能特性如何进入主干，结构都是一样的。每个团队都有自己的集成环境，他们会不断发布，就像基线场景一样。这些团队特定的集成环境向通用集成环境导入代码，然后就走正常流程了。

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