在非 main 分支上使用 continuous deployment，真的好吗？

• 資深大佬 : sutra

  意思是内测版没资格部署，测试不需要线上测

• 資深大佬 : GeruzoniAnsasu

  @sutra github 默认主分支就叫 main 分支，再无 master “`

• 資深大佬 : lyusantu

  这个问题有歧义，main/master 分支不一定就对应的是 production environment，得先定义你用的是什么分支模型。

• 資深大佬 : sutra

  那万一这个 repo 有 prod branch 呢？这个 branch 是不是 dev or prod 是自己定义的，并不是约定俗成的。

  当然，在大多数 case 里 master branch 的确是 prod 。

• 資深大佬 : PqZS58MLPBHFpEqm

  我们都在 master 分支上搞～

• 資深大佬 : janxin

  @GeruzoniAnsasu #2 什么意思？不太明白。

• 主 資深大佬 : JasonLaw

  @sutra #4 我指的 main 分支就是 production environment，公司的其他项目组有 dev 分支的概念（我这个小组不使用这种方式），也就是在测试环境运行的，那么 dev 分支有必要做 continuous deployment 吗？

• 主 資深大佬 : JasonLaw

  @janxin #6 也就是只有 main 才做 continuous deployment ？ merge request 被合并之后自动触发生产环境的部署？

• 主 資深大佬 : JasonLaw

  我们用的 release-vX.Y.Z，咋就不行了，main/master 分支只是最新的代码

• 資深大佬 : thet

  @thet #10 我在附言中补充了我提出这个疑问的原因。

• 主 資深大佬 : JasonLaw

  @JasonLaw 不是，你提问的情况看上去开发时仅两个分支在工作：发布分支和开发分支；实际上如果分支还包含预发分支等其他功能分支的话，预发分支或其他需要部署的功能分支是可以作为 CD 部署的对象的，用作预发或者内部集成测试等功能需求。当然这跟开发分支需要进行持续部署没有关系。

• 資深大佬 : janxin

  1. 太频繁的 commit 污染可以用 squash 解决

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

  这种做法倒没什么不对的；道听途说，过于庞大的项目根本不能在合理时间内本地编译，都是丢专门的编译服务器的，改两三行代码，然后编译一天。

• 資深大佬 : no1xsyzy

  但是我看着觉得你这是不是缺乏自动化测试？
  理应当不用 CD，CI 先跑通再说啊

• 資深大佬 : no1xsyzy

  @no1xsyzy #14 你说的对，完全没有自动化测试

• 主 資深大佬 : JasonLaw

  就看你的 dev env 是否需要用来给别人用了，如果需要给别人用，那就 CD 呀。

  test env 肯定是要给别人用的，那肯定要 CD，不然手工搞多累。

• 資深大佬 : sutra

  服务频繁不可用？
  如果测试环境是共用的话，这样当然不好。如果是每个人自己的测试环境的话倒是没关系。

  至于频繁 commit，这算啥问题？ Git 历史重写就好了。