首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  DevOps

技术团队代码管理和部署

  •  1
     
  •   wushuiyong · 2015-10-28 14:46:02 +08:00 · 3059 次点击
    这是一个创建于 1304 天前的主题,其中的信息可能已经有所发展或是发生改变。

    主流公司使用 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 同步)
    - 线上批量文件指纹检查

    其宿主机、目标机群、操作用户关系如下图:

    部署发布每次都会有版本记录保留,事故一旦发生,回滚可瞬间完成。其上线流程安全可靠,同时支持 git 、 svn ,支持多任务辅助,即可对一些前置、后置操作自定义。如 vendor 更新, java mvn 编译。我们看下其部署的原理。

    目前花满树的主页博客瓦尔登、瓦力自己已交由瓦力来部署上线,欢迎 star 、 fork 试用,有任何问题请反馈:)

        1
    pochonlee   2015-10-30 09:01:01 +08:00
    写的不错。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   967 人在线   最高记录 5043   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 21ms · UTC 19:10 · PVG 03:10 · LAX 12:10 · JFK 15:10
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1