标题先来一个近几年比较火热的 DevOps，但这个系列里只讲述笔者在实际工作中从 no-DevOps 到 semi-DevOps 的心路历程。

石器时代

记得刚进 大M 的时候，草草的扫了代码、体验了一周开发流程后，我的内心几乎崩溃的，如同一夜回到解放前，各种的纯手工作业，手工也就算了，还是各种粗制滥造。（大M的员工请勿板砖拍我呀 哇哈哈哈）
主要现象：

• Git 只用 master 分支，开发和部署都用这master
• Git 使用中，把图形化工具当成傻瓜相机用
• 部署工具是用 Git 维护的一个jar repository，在工程师本地手工地 maven 打包项目，并拷贝到deployment git 里提交，Production 服务器部署的时候采用 git pull 那些 jars 之后重启服务的方式
• Java 项目中大量的自研 SNAPSHOT 版本依赖

随之而来的主要问题：

• Production环境的bug基本不可能做到纯净的hot-fix，因为只有所有的代码都怼master，当你需要修复1期开发中产生的线上问题时，不得不把2期开发中还没完成的代码给带了上去（毕竟工程师们秉承了把git当成“备份工具”来用的优良传统，每写几段代码就commit一次，拿去测试环节调试——醉了）
• Git 里时不时会出现鲁莽的 merge，把别人有用的代码更新给覆盖了——恐怖
• Git deployment repository 的体积会越发的膨胀（大体积 jar 的diff简直就是完全覆盖）。你还别嫌弃老一辈革命家的这套“部署工具”，要更新有更新，要回滚也可以回滚，但所有操作都得 git 命令行搞定，你要是改了一些repo里的文件（比如configuration file），麻烦就更大了，还要两边同步才行，新手基本是要在 git command 上踩雷的。
• Java maven 里的 SNAPSHOT 版本概念在开发里还是有优点的，但缺点是一大箩筐：
  • 新入职的工程师，刚git clone下的源码执行 "mvn clean install" 一大堆的找不到jar，各种新手不友好，只能一个个clone下来maven安装本地。
  • 用于发布到Production，结合石器时代的“手工Maven打包”，会有很大的版本控制风险。想象一下，某个SNAPSHOT版本的 jar dependency忘记用最新代码重新 “mvn clean install” 了，那么你当前项目 maven打包的时候就只会带上老代码的依赖。同样的道理，你hot-fix的时候，当初大明湖畔的 SNAPSHOT 已经难以找到了，只能被迫使用当前的新代码。

前面还忘记说了，因为同时维护了两个类似的产品，所以很多代码都是共用一个git repo，但在不同“master”来开发。这也算是 git的反模式吧，我想大部分项目应该不会遇到这样的情况。

工业时代

要想活儿干得顺，工具得顺手才行是吧。那么针对以上石器时代的问题，将在下一篇中讲述笔者用到的解法。提前预告一下，主要做了以下几个改进：

• Git 中新建 release 分支，一个开发周期中要发布的代码，将从master “迁移”到 release 分支（用git rebase）。当有线上bug需要 hot-fix 时，在 release 分支直接修bug。
• 使用Jenkins 搭建了一个简易的 CI 系统，配合 AWS S3 和 bash 脚本实现了build-store-deploy 唯一发布包的体系
• Java 开发配合 git release 分支，在release之前将 SNAPSHOT 版本锁定成 release 版本，并且讲pom的版本升级到新的 SNAPSHOT 版本