在非 main 分支上使用 continuous deployment,真的好吗?

JasonLaw 23天前 14

最新回复 (16)
  • sutra 19天前
    引用 2
    意思是内测版没资格部署,测试不需要线上测
  • GeruzoniAnsasu 19天前
    引用 3
    @sutra github 默认主分支就叫 main 分支,再无 master ```
  • lyusantu 19天前
    引用 4
    这个问题有歧义,main/master 分支不一定就对应的是 production environment,得先定义你用的是什么分支模型。
  • sutra 19天前
    引用 5
    那万一这个 repo 有 prod branch 呢?这个 branch 是不是 dev or prod 是自己定义的,并不是约定俗成的。

    当然,在大多数 case 里 master branch 的确是 prod 。
  • PqZS58MLPBHFpEqm 19天前
    引用 6
    我们都在 master 分支上搞~
  • janxin 19天前
    引用 7
    @GeruzoniAnsasu #2 什么意思?不太明白。
  • 楼主 JasonLaw 19天前
    引用 8
    @sutra #4 我指的 main 分支就是 production environment,公司的其他项目组有 dev 分支的概念(我这个小组不使用这种方式),也就是在测试环境运行的,那么 dev 分支有必要做 continuous deployment 吗?
  • 楼主 JasonLaw 19天前
    引用 9
    @janxin #6 也就是只有 main 才做 continuous deployment ? merge request 被合并之后自动触发生产环境的部署?
  • 楼主 JasonLaw 19天前
    引用 10
    我们用的 release-vX.Y.Z,咋就不行了,main/master 分支只是最新的代码
  • thet 19天前
    引用 11
    @thet #10 我在附言中补充了我提出这个疑问的原因。
  • 楼主 JasonLaw 19天前
    引用 12
    @JasonLaw 不是,你提问的情况看上去开发时仅两个分支在工作:发布分支和开发分支;实际上如果分支还包含预发分支等其他功能分支的话,预发分支或其他需要部署的功能分支是可以作为 CD 部署的对象的,用作预发或者内部集成测试等功能需求。当然这跟开发分支需要进行持续部署没有关系。
  • janxin 19天前
    引用 13
    1. 太频繁的 commit 污染可以用 squash 解决

    2. 每个 branch 应当建立单独的测试实例
    比如
    dev 分支有一个 dev.example[.]com 的记录
    然后 fix-issue-42 有一个 fix-issue-42.example[.]com 的记录
    内网泛域名索引,然后根据 Host 头响应

    这种做法倒没什么不对的;道听途说,过于庞大的项目根本不能在合理时间内本地编译,都是丢专门的编译服务器的,改两三行代码,然后编译一天。
  • no1xsyzy 19天前
    引用 14
    但是我看着觉得你这是不是缺乏自动化测试?
    理应当不用 CD,CI 先跑通再说啊
  • no1xsyzy 19天前
    引用 15
    @no1xsyzy #14 你说的对,完全没有自动化测试
  • 楼主 JasonLaw 19天前
    引用 16
    就看你的 dev env 是否需要用来给别人用了,如果需要给别人用,那就 CD 呀。

    test env 肯定是要给别人用的,那肯定要 CD,不然手工搞多累。
  • sutra 19天前
    引用 17
    服务频繁不可用?
    如果测试环境是共用的话,这样当然不好。如果是每个人自己的测试环境的话倒是没关系。

    至于频繁 commit,这算啥问题? Git 历史重写就好了。
  • 游客
    18
返回