我们为啥非得搞个Sigma版本大全？
你可能觉得，一个破软件，屁大点事，版本号管好就行了，干嘛非得整出个“大全”？
说起来都是眼泪。我们这个项目，代号就叫“Sigma”，最早是老板拍脑袋要搞的。他老人家说要“敏捷开发”，结果敏捷开发没学会，倒是把锅都扔给了下面的人。
刚开始的时候，大家都图方便。前端工程师自己拉了一个2.1版本用得欢，后端说2.1有bug，偷偷升级到了2.5。测试那边，因为自动化脚本是老同事写的，用的还是1.8的配置。运维，更绝，直接在1.5的基础上打了个补丁，说这样性能最
结果？一团糟！
-
小编温馨提醒：本站只提供游戏介绍，下载游戏请前往89游戏主站，89游戏提供真人恋爱/绅士游戏/3A单机游戏大全，点我立即前往》》》绅士游戏下载专区
新来的同事压根不知道从哪儿下手，光是搭环境能搭两天。
-
线上出问题，一查日志，三套版本号对不上，大家推三阻四，光是确认“你用的是哪个Sigma？”就能吵半个小时。
-
最要命的是，每次回归测试，总有那么几个版本兼容性出问题，白白浪费时间，活脱脱成了内部最大的效率杀手。
我当时就拍桌子了，不能再这么下去了。可光靠嘴喊没用，我深知，想把这事儿彻底解决了，就得自己动手，把所有的版本、配置和历史，从头到尾扒一遍，整合成一个谁也赖不掉的“大全”。
我是怎么动手的？
我先是拉出了一张超级大的表格，把所有涉及到“Sigma”的服务节点全列出来。然后从最老的SVN仓库开始挖起，翻了将近五年的提交记录，就是为了找出每一个版本号最初是为什么存在的、解决了什么问题。又跑去跟几个老伙计磨嘴皮子，让他们交出自己电脑里那些“祖传”的本地配置文件。那段时间，我基本就是个文物修复专家，每天都在研究老版本遗留下来的代码“化石”。
我把它们按环境、功能、稳定度分了类：稳定版（只推荐线上用）、实验版（随时可能废弃）、废弃版（禁止使用）。然后用最简单的Markdown文档写清楚，每一种版本号，对应了哪个配置，哪个团队应该用，哪个团队绝对不能用。
我为啥这么较真？
我知道，很多人觉得这是个吃力不讨好的活儿，但我就像着了魔一样，非要把这个“大全”建起来。为
这事儿，得从我上一个公司说起。
那时，我们也是版本混乱，我负责一个重要的小模块。结果有一次上线，大版本是没问题，但是运维偷偷换了一个小版本的依赖库，觉得没啥影响。结果生产环境直接崩了，出了个大事故。
我当时还没睡醒就被电话叫去公司，上头问责的时候，那个运维和他的领导一口咬定是我模块兼容性差，没做好适配。我一个人百口莫辩，被硬生生扣了个“流程疏忽”的帽子，年终奖泡汤了不说，还被晾了好几个月，差点被开了。那感觉，真是冤得慌，窝囊透了。
从那时起我就明白了，技术上的混乱，到头来背锅的，往往是那些认真干活的人。只要版本控制这根线没拉直，所有人头上就悬着一把达摩克利斯之剑。
我这回做“Sigma版本大全”，不是为了炫耀技术，就是为了给自己和团队买个保险，让所有人都能在清晰透明的版本下干活，不再做那种无辜的“大冤种”。
现在这个“大全”建好了，团队效率提高了一大截。上次隔壁部门跟我抱怨说他们版本又乱了，我直接把我的文档甩给他们，告诉他们：看，这才是解决问题的办法。