DevOps、微服务是现代软件开发代表性的技术和方法论，他们的共同特征都是强调持续、敏捷的交付软件产品。影响DevOps、微服务实施有很多因素，包括技术的，比如框架和架构选型；管理的，比如编程规范和门禁等等。兼容性管理是影响DevOps和微服务实施非常重要，但是又极容易被忽视的环节。探讨兼容性管理对DevOps和微服务实施的影响需要大量的实证经验。本文跳过对实证经验的分析，直接描述最佳实践。评估这个实践，需要把握一个核心的原则，“始终围绕改善软件产品质量，降低软件维护成本，提升软件创新效率”，这样才能够理解这个最佳实践的意义。实施这个实践需要上下游齐心，协调一致，共同进步。

兼容管理分类

兼容管理一定不能一刀切。根据应用场景选择合适的兼容策略，是第一个需要关注的内容。最简单的方法是把它分为两类：

• 服务。服务指给用户提供某种功能的软件，一般指一个进程。服务的表现形式一般是REST API。 服务的兼容管理就是REST API的兼容管理。当然广义的服务还包括运行时，比如操作系统、容器等。
• SDK。SDK是开发服务的组件，SDK需要和业务代码、其他SDK一起编译，最终打包为服务。为了简化，我们把SDK的表现形式称为JAVA API。SDK的兼容管理就是JAVA API的兼容管理。

服务的兼容管理

服务兼容管理的核心原则

• 采用双版本机制管理服务。在研版本和维护版本。在研版本和维护版本在REST API上不兼容。在研版本和维护版本的各个小版本之间REST API兼容。
• 小版本升级采用自动化的方式进行。当发布一个新的小版本，提供自动化的方式升级。由于小版本升级REST API是兼容的，这个过程一般不会对客户的业务造成中断。自动化方式升级的目的，是尽可能减少版本的数量，这对软件功能规划（新增、兼容、下线等）都具有重要意义。
• 维护版本升级到在研版本，只需要考虑最新的维护版本升级到最新的在研版本，升级版本的跨度很小，从而极大的降低升级风险、升级代码和验证复杂度。

SDK的兼容管理

SDK兼容管理的核心原则

• 采用双版本机制管理SDK。在研版本和维护版本。在研版本和维护版本在JAVA API上保持恰当的编译时兼容。集成新的SDK版本的时候，需要重新编译、解决编译错误、增加适当测试用例。SDK不需要保持JAVA API的运行时和编译时兼容，只需要保证没有功能丢失，废弃的功能有替换方案。这种方式可以让SDK的开发维护变得简单，持续的重构也能够改善SDK的质量。
• 服务进行持续集成。根据需要，比如发现bug，按照迭代计划，比如每个月，两个方向安排SDK的升级。通过这种方式，减少版本的数量。
• 维护版本升级到在研版本和普通小版本升级只是工作量差异。

补充说明

恰当的编译时兼容的说明参考：http://servicecomb.gitee.io/servicecomb-java-chassis-doc/java-chassis/zh_CN/featured-topics/compatibility.html 。这里面描述了SDK兼容管理的一些最佳实践。 服务的兼容性管理实践在手机操作系统上已经非常普遍，但是在一些云产商的PaaS服务方面，还不是特别多，这主要受限于对于兼容管理的理解，以及自动升级的风险管理能力建设的缺失。 兼容管理实践还有很多细节的内容，比如构建自动化测试能力，开发部署流水线、代码策略（通过删除语义变化的接口，提供新的接口强制编译失败）等。