首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
Coding
V2EX  ›  git

请求互联网企业中,频繁的上线项目,代码是如何管理的,最好能看下 git workflow 长啥样

  •  
  •   MrXiong · 2017-10-17 13:23:24 +08:00 · 4324 次点击
    这是一个创建于 786 天前的主题,其中的信息可能已经有所发展或是发生改变。

    目前公司的测试环境只有一个,但是有的代码测试周期比较长且上线比较频繁,传统的 workflow 好像并不适合如 workflow,那么使用 git,如何管理代码,以及如何实现自动化部署呢,求教??

    15 回复  |  直到 2019-03-22 11:38:13 +08:00
        1
    nullcoder   2017-10-17 13:42:41 +08:00
    你想问的是 CI/CD 的方案吧,跟 git workflow 没啥关系
    可以了解一下 gitlab 的方案
    https://about.gitlab.com/features/#release
        2
    jinhan13789991   2017-10-17 13:46:27 +08:00
    git 有比较标准的分支管理。
    持续集成系统,比如 jenkins,可以配合 git 一起使用。
    自动化部署可以考虑使用 docker。
    比如 git 有:开发分支,测试分支,发布分支。
    就可以使用 jenkins 来检测分支提交变化,自动打包部署 docker。
    以上只是我个人的见解,希望能够帮助到你
        3
    MrXiong   2017-10-17 13:59:17 +08:00
    @nullcoder,不是 ci/cd,是代码的管理,不是 ci,cd 的实现。问题是单个测试环境,有的代码测试周期比较长但是别的需求需要测试上线,在这种情况下能通过 git 方便的管理代码吗
        4
    nullcoder   2017-10-17 14:08:24 +08:00
    你说的单个测试环境是什么意思?
    是两个需求的测试环境相同?那就没问题
    两个需求不能同时测试?这个就。。。
    git 本来就去中心化了,做好版本管理,不建议搞太多分支。
        5
    frankynwa   2017-10-17 14:12:29 +08:00
    团队一直用 gitflow 的 http://www.cnblogs.com/cnblogsfans/p/5075073.html
    但是一直也没有解决周期长的分支的合并问题
    我们一直认为最好不要产生跨迭代的特性
    也不要在一个迭代里让两个开发同时做一个功能 = =
        6
    zhangsen1992   2017-10-17 14:39:03 +08:00
    gitlab 做好各个分支 测试上线 联调 打好 docker
        7
    cnJason2012   2017-10-17 15:15:44 +08:00
    我原来在某互联网独角兽公司工作做过一小段时间的 DevOps。当时我们团队对于频繁上线的系统采用的是这样的管理方式:git 上面分 3 个分支。master、stable、develop。功能描述是:develop 是开发主分支,以供开发人员合并代码和联调使用。stable 是稳定版本。以供多部门协调用的调试版本 [也称稳定版本] 。只有 stable 上经过确认的版本才能上 master 分支。这些都有专门的 CICD 的项目来进行管理。每天对于 master 分支的上线次数是有规定的。会避免一大部分失误造成的上线。
        8
    bash99   2017-10-17 15:28:06 +08:00
    说个在小 team 里面实现得还过得去的模式(当时 docker 还不够流行)

    前提:
    1. 强大的测试能力或者说自动化测试
    我们的测试哥们工资很高,能指导开发数据库设计不合理,能写自动化测试
    2. 较好的线上环境重建能力;包含标准测试数据库依赖的环境 5 分钟(也就是不管因为测试把数据库弄得怎么样了,5 分钟全套回复到标准环境);线上数据库脱敏重建 30 分钟;
    3. 变更管理较完备,数据库变动版本化进入代码。

    做法:
    敏捷模式,每周 release,但是每 2 ~ 4 周为一个 sprint,每个 sprint 里面程序员手头 3 ~ 6 个功能 /Fix,每个功能一个分支。少数情况 2 ~ 3 人工作在一个分支上
    hotfix/紧急变动在测试通过后会迅速合并到 master
    分支提测前,会保证合并了当前 master (普通 merge 模式;不 rebase -- 当时大家 rebase 用得实在不熟,否则 rebase 应该也行)。会要求程序员做基本自测。
    自动化测试通过后,该分支会被合并到一个测试环境(代码包括所有提测的分支),合并有冲突会打回让程序员自己去兼容其它分支(这个情况比较少,可能也是比较麻烦的,基本上让他们本地拿测试分支 merge 找问题);这个测试环境会再来一轮自动化,有问题也打回,然后 revert (这两步后期是土法脚本化了);
    然后在这个环境上做对应的新功能测试,有问题也是 revert 掉这个分支带来的改动。
    周五下午会决定哪些功能在上述环境上已经稳定并且准备上线,所有待上线分支都冻结,然后单个分支 squash merge 到 master。对这个 master 做一些最后测试并确认。
    周一上线。(只有脚本自动化,有回退,但是没有灰度发布,有数据库变动且不兼容回退也碰到过,这个没完美解决好)
    之后删除已上线两周的老分支(少数重要分支打 tag 后删除)。

    优势是 master 上都是干净的一个个功能 commit 和部分 hotfix。

    另外,如果分支跨了 sprint,基本上也是很烦的,和其他分支冲突几率大大增加;通常我们在回顾会上检讨是产品经理粒度不合适还是开发没做好。

    现在有 docker 了按说可以把上面的自动化测试和环境重建做得更好方便。我仍然觉得 CI 流程做好了是基础,git 只是更灵活更能适应各种的 CI 流程而已。
        9
    zhaoace   2017-10-17 15:32:49 +08:00
    感觉不是代码的问题,是测试环境不够的问题。 你们可能把 staging 的测试环境当成 dev 测试环境来测 feature 用了。


    feature 没 complete 之前,不确定能上的时候是不能进 staging 环境的。feature 全测通过了决定合并进去上线了再进 staging 环境。 也就是说 测 feature ( dev 测试环境) 和 测 release ( staging 测试环境或者叫 migration 测试环境)是要分开的。

    基本等同#7 楼说的做法。

    一个测试环境是不够的。。。想想单车道怎么超车,对吧。。。
        10
    BBCCBB   2017-10-17 15:53:34 +08:00
    @frankynwa 我们目前也是 git flow, 合并的时候很是恼火,

    github flow 这种基于 pull request 的可能更合理.
        11
    crazybinggan   2017-10-17 16:18:39 +08:00
    目前也是尝试 git flow,分支管理真的好头疼。取下经。
        12
    mingyun   2017-10-17 23:21:18 +08:00
    赞同 7 楼,经测试通过的代码分支才合并到 master
        13
    zonghua   2017-10-18 00:57:15 +08:00
    @bash99 新项目怎么分配任务,很多功能会依赖基础的框架类库
        14
    testcount   2017-10-18 10:06:14 +08:00
    用 GitHub Flow。
        15
    sevenwhat   266 天前
    在公司用 gitlab 吧 结合 gitlab-runner 在、.gitlab-ci.yml 写 CICD 的流程,在结合 ansible 搞个 远程部署
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3352 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 28ms · UTC 05:00 · PVG 13:00 · LAX 21:00 · JFK 00:00
    ♥ Do have faith in what you're doing.