技术团队代码管理和部署

主流公司使用svn和git做为代码版本管理，固然也不排除直接copy或者ftp。公司经历了的svn到git的变迁，也深入体会到不一样的版本管理服务，使得技术团队的协做方式变得更为流畅。

简单介绍下背景，有一个项目V5，从版本V1一直演变到如今V5，可见历史之久，想从svn切换到git，其中的代码管理和上线部署迁移，都会是经历很长一段时间的不稳定，尤为是一些开发同窗对新的版本管理和部署理解不透彻，很容易引起事故。

在svn的主干开发流程

---

• 开发同窗更新主干代码，提交代码

• 部署测试环境

• 检查每个要上线的文件版本，是否夹带其它同窗的提交，若是有，先回滚再提交，或者是带版本号上线，如：

common/request/Base.php
common/config/db.php -r 182993909

如今庞大的V5代码库仍然是全公司同窗往master里更新代码，开发团队愈来愈大，这种原始的原始的开发方式，让全部同窗都在一个master分支上协做的成本愈来愈大。

成本大在哪些地方？

---

团队协做首先是要让成员更方便得到彼此的更新，这样才能更一块儿完成各个模块，最后联调测试。成员就会把代码加入版本管理，而项目是有时间跨度的，若是时间短的项目和大项目的代码混合了，小项目要上线须要剥离大项目，剥离是否出错先不说，这个时候已经影响到另一个项目了。若是遇到线上bug，须要紧急修复，须要从线上版本检出，最后和其它成员合并，这工做量都是附加的。

另外，在部署的时候繁重的版本检查，会严重耽误上线时间，改代码和验收花了5分钟，上线检查和处理夹带其它提交也花了5分钟。这时间成本在线上事故面前，那就直接影响着你的KPI了。

切换到git分支开发

---

这，不是咱们想要的开发流程。迁移到git的分支开发是早晚的事情，它首先带来的好处就是团队不一样项目的开发是相互隔离的，测试回归能够灵活地选择feature分支验收，经过再合并到主干。

branch和tag

---

Branch: master 和 development。其中 master 对应目前的发布分支，在这个分支只能增长从 master cherrypick 过来的 commit。development 是当前开发的分支，全部的 pull request 都应该发到这个分支。有些团队会以master做为开发主干，另外推送一个online分支做为发布分支，名字不一样而已。

Tag: 对应每一个发布版本的 tag。 tag 遵守 tag_[milestone号]_日期 的命名，如 tag_m6_2015-08-12，若是有 bugfix，则在后面增长小写字母，如 tag_m6_2015-08-12后是 tag_m6_2015-08-12a，而后是 tag_m6_2015-08-12b。

正常开发流程

---

1. 从master切feature分支开发

2. 自测经过以后，提交 pull request 到 development（若是是大项目milestone的话，能够先pull request到milestone分支），并通知QA部署feature分支回归

3. CodeReview标Ok，QA验收经过后进行merge到development，若是CodeReview或者QA发现有问题，在feature分支修正再部署到测试环境，直到没有问题

4. merge 验收经过的 feature-fix 到 development

5. 部署development分支到测试环境

6. 测试验收经过，merge development分支到master，打tag

7. 发起仿真环境上线，仿真环境验收

8. 验收经过，发起生产环境上线

9. leader审核上线任务，发起同窗进行部署，生产环境验收

hotfix流程

---

1. 从master切hotfix分支开发

2. merge 确保全部要发布的 pull request 到 master

3. 后面与正常开发流程一致了

4. merge master分支到development

大项目与hotfix开发和上线流程图

---

若是不是开发周期有两三个星期的项目，迭代速度快的，一天要上线好几个小功能的，能够在开发完feature分支，跳过milestone分支直接merge到development分支，让QA验收打tag。另外，并非每一个 bug 都有专门发布 bugfix 版的必要，对于不紧急的 bug，能够在 master 里 fix 后随下一个版本发布。

应用

---

目前试用瓦力上线系统：https://github.com/meolu/walle-web，分别部署测试、仿真、生产环境大大节约了脚本上线的成本，开发、测试同窗自行可发起部署。部署过程支持

• 用户分身份注册、登陆

• 开发者发起上线任务申请

• 管理者审核上线任务

• 支持多项目部署

• 快速回滚

• 部署前准备任务（前置检查）

• 代码检出后处理任务（如vendor，环境配置）

• 同步到各目标机器后收尾任务（如重启）

• 执行sql构建（不要担忧忘记测试环境sql同步）

• 线上批量文件指纹检查

目前花满树的主页、博客、瓦尔登、瓦力本身已交由瓦力来部署上线，欢迎star、fork试用，有任何问题请反馈：）