入职必备技能--版本流程（二）

昨天介绍了一种常用的版本开发上线的流程，今天我们来介绍另一种玩法。

对于整体的流程，不论怎么划分都还是离不开三个基本环境：开发环境，测试环境，线上环境；

在上一篇文章中，develop对应的就是开发环境，release对应的就是测试环境，master对应的就是线上环境。针对这种开发模式，如果在发布的过程出现问题需要回退版本怎么办呢? master上面的代码都是最新版的，也不太可能根据history来一个个的回滚代码呀；或者如果现在需要回退到指定版本怎么办，在这个开发流程中是没有版本号的概念，线上的跑的都是master上面的代码呀。

常见的做法，就是我在发布新代码之前，将线上运行的jar/war包备份一样，再发布新的代码，这样新代码在发布的过程中出现问题，可以立即使用原来的包来回滚，简直不要太方便。但是这仅仅针对的上一个版本的回退，如果要回退到指定版本呢？

我们先了解下tag，在github的项目左上角，可以看到一个切换框，一个是branch，另一个就是tag；branch就是我们上面所说的分支的意思，而tag呢就是一个快照，从分支而来为不可变类型，通俗的来说，当我从master中打了一个tag命名1.0.0，那么这个tag中的代码生成之后便不会再有变动。

所以我们每次发布的时候就不是从master分支来直接发布项目，而是先基于master分支打个tag版本号，然后在使用该tag发布线上版本。这样在每次发布的时候都能留下完美的足迹来跟踪。

总结一下：

1. 发布新功能前，可以先备份上一个版本的包以备在发布失败时立即回滚；
2. 如果需要对项目进行版本控制就需要引入tag的概念，也为了可以指定版本回滚；
3. 评估是否需要引入tag，因为可能会造成版本混乱管理；

个人觉得适合引入tag的项目必定是对版本号有严格要求的项目，比如提供基础的架包（spring-framework，mybatis等等）针对不同的版本有不同的功能说明，还比如手机APP更新也会告知具体的版本。

但是如果是中后台功能，其实是没有必要引入版本的概念，只用保证现网运行的是最新的代码即可。