SOA治理中版本控制的最佳实践是什么？版本控制工具应该具备哪些功能？

在服务的生命周期当中，版本控制是人人都要面临的一项挑战。首先，也是最重要的最佳实践是，永远都要假定事情是会变的。然后设法在一开始就定义流程和标准，在变化发生时予以应对。Gartner的Roy Schulte谈到了早在2000年代中期时的SOA，指出系统做出来是为了能持续。但是，在当下，我们需要为变化而做系统。

比方说，你是否允许多个版本的服务进入生产环境运行？如果你的答案是肯定（本来也应该如此）的，消费者如何才能被引导到正确的版本？消费者会不会明确指出自己期望的版本是什么，或者是靠隐式确定的？只要是牵涉到SOA的地方，我们总是以这样或那样的方式在要求中明确主要版本（如1.0还是2.0），但是次要版本（1.1还是1.2）就不那样要求。

主要版本和次要版本之间的区别在于，次要版本总是向后兼容的，而主要版本则不一定。我们通常都会努力争取向后兼容，因为这是影响最小的变化。如果我们决定打破向后兼容性时，这么做往往会有比较好的理由。试图通过转换来规避这一点有可能会在中间引入显著的复杂性，让消费者有借口不做改变，而这正是我们不希望看到的行为。系统会针对消费者和提供商而做出改变。

版本控制工具的第二个最佳实践是，就产品运行中应该有多少个版本设定限制。我的建议是不要超过三个主要版本，然后每一个都只保留一个次要版本。因此，1.0、2.0、3.0可以有，但是永远不要同时出现1.1、1.2，除非是在1.2刚刚发布的短时间内保留一阵子，以便执行A/B测试时回退的需要。　　

为什么要三个版本？

答案部分依赖变化率的情况。如果你服务的变化率不同于正在消费系统的变化率，事情可能就无法同步。对于每一个待修改的消费系统，你必须确定现实的预期。如果每一个消费应用每年都会有一项重大发布，你就应该能够把服务升级作为这些发布的考虑因素，生产环境下同时运行的版本不超过三个应该就行了。如果你每年发布的主要版本超过3个，那就是表明界面设计糟糕的一个迹象，说明东西没有一直保持向后兼容性。

你也不能在未对服务消费者提出需求的情况下对服务提供商做出限制。一旦新版本到位，确保有政策指明服务消费者在必须升级前还有多少时间。每一次发布，除了业务所需的功能增强以外，组织往往很容易就会陷入做某些基础性工作的习惯当中。如果消费者不把它当作标准惯例，服务提供商就要维护非常非常多的服务版本，导致相关维护成本的增加。

而对于内部和外部消费者，你也许有需要不同的策略。内部消费者处在组织的控制下，而外部消费者则很难告诉他们该如何花钱。这意味着升级所需的时间有可能更长一点，令向后兼容变得更加重要。　　

建立信任

说到向后兼容，回归测试必须成为任何版本控制策略的核心。消费者一旦被变更搞得焦头烂额，显然应该会导致重大的信任问题。为了建立起信任，服务提供商应当竭尽所能去向服务消费者说明变更是否会对他们产生影响。

这要在消费者开始使用服务时从他们中当中收集回归测试开始。然后，内一次发布，服务提供商都可以执行每一个消费者提供的测试来说明变更是否影响到他们。在每一个消费者身上进行测试非常重要。

如果测试主要由服务提供商创建，而服务消费者却一点都没有参与的话，他们就会说“你没有执行我的测试，因此我无法信任你不会搞砸我的应用。”对于一个拥有大量消费者的服务来说，这些测试包会变得很大，所以有牢靠的自动化测试手段来保持回归测试的低成本是很重要的。

最后，如果你没有跟踪服务消费者，那你就相当于给自己挖了一个大坑。无论你是用Excel表格，还是Access数据库，或者是正规的SOA容器来做这件事都行，你得跟踪这些消费者，并且对你的信息一直都要有一个身份的表示。在你试图让旧版退出运行时，如果你不能观察运行时流量，不能方便地确定这些流量来自于哪些消费者的话，你就有大麻烦了。

还有技术可以扮演的角色，尤其是当你使用像ESB、XML装置或资产网关这样的东西时。你可以用这些来进行转换，针对特定场景执行基于消息的路由，不过我已经发现，在保持事态控制方面，明确的版本控制策略以及预期要比试图让所有人根据最有利自己的特定系统去做自己想做的事情，然后再试着在其中用技术来管理混乱的效果更好。

这并不是说这些技术没有用，技术是有用的。但是要用版本控制工具来支持这些策略，而不是取代策略。