版本管理

Project

所有项目在开始时必须添加版本号，版本号格式参考major.minor[.maintenance[.build]]，同时将主版本号加入server.path 作为api版本号。在同一主版本号上不会对原有API进行破坏性重构，所有的破坏性重构都要考虑升级一个大的版本号。小版本号可以新增API，API扩展。
版本号需要体现在log，jar，docker image 和docker container上.
如使用gradle可以用下面命令将gradle的变量导入到application.properties中

processResources {
    filesMatching('application.properties') {
        expand(project.properties)
    }
}

在spring的配置文件里可以

info.build.version=${version}

在同一版本上开发时，需要加上snapshot。
API版本分为两种情况：

• 开放给外部调用的API
• 内部系统调用的API

开放给外部调用的API

指会通过gateway直接暴露微服务外部的API。这种API需要自己去检查每次请求的权限信息。通常对暴露给外部调用的API很难进行大版本的升级，所以在这种API设计的时候需要经过再三的review。

内部系统调用的API

内部系统调用的API指在微服务中为其他的微服务调用而设计的API。要求每个API的提供方需要维护调用API的client，client来控制权限校验和数据传输过程中的加密、压缩等处理。而其他消费方只与client进行集成，而消费方并不需要知道client的实现细节。

严禁出现同一API同时提供给内部和外部使用

GIT

每当版本发布时，git上需要打上版本号的tag。在后续针对该版本维护时，checkout出一条对应的branch对其进行维护，从而避免影响到develop分枝的开发。

CI

每一个project的CI都需要集成contract test保证API的稳定性。API的提供方只需编写provider side的contract test，consumer side的contract test由各个调用方编写并集成在提供方的contract test里。
在deploy的时候，需要固化当前版本号下所依赖的第三方API的版本号以及对应的测试代码的版本号。

版本切换

非主版本号的升级，在通过了contract test时，可以直接停止所有老版本服务而发布新的版本。
主版本号升级时，需要在同时部署新版本服务的同时保留老版本服务，后续通过日志监控API的流量情况逐步减少老版本服务的instance数量直到最后完全停掉老版本。