在非 main 分支上使用 continuous deployment，真的好吗？
JasonLaw · 2021-04-15 07:06:25 +08:00 via iPhone · 1818 次点击这是一个创建于 1337 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2021-04-15 10:39:46 +08:00
我提出这个疑问的原因是：我发现有人将CD当做一个测试自己代码是否OK的工具，自己还没有验证修改是否符合期望之前就提交 commit，push到远程仓库，通过CD，在测试环境验证。这样不仅仅会造成频繁 commit，造成n个“fix issue 1”，污染git的历史，并且会造成服务的频繁不可用。
17 条回复 • 2021-04-15 20:59:38 +08:00
 |
1
sutra 2021-04-15 08:41:44 +08:00
main 分支是啥？
|
 |
2
GeruzoniAnsasu 2021-04-15 08:45:08 +08:00
意思是内测版没资格部署，测试不需要线上测
|
|
4
sutra 2021-04-15 08:58:59 +08:00
这个问题有歧义，main/master 分支不一定就对应的是 production environment，得先定义你用的是什么分支模型。
|
 |
5
PqZS58MLPBHFpEqm 2021-04-15 09:13:18 +08:00
那万一这个 repo 有 prod branch 呢？这个 branch 是不是 dev or prod 是自己定义的，并不是约定俗成的。
当然，在大多数 case 里 master branch 的确是 prod 。 |
 |
6
janxin 2021-04-15 09:25:36 +08:00 via iPhone
我们都在 master 分支上搞～
|
 |
7
JasonLaw OP @GeruzoniAnsasu #2 什么意思？不太明白。
|
|
8
JasonLaw OP @sutra #4 我指的 main 分支就是 production environment，公司的其他项目组有 dev 分支的概念（我这个小组不使用这种方式），也就是在测试环境运行的，那么 dev 分支有必要做 continuous deployment 吗？
|
|
9
JasonLaw OP @janxin #6 也就是只有 main 才做 continuous deployment ？ merge request 被合并之后自动触发生产环境的部署？
|
 |
10
thet 2021-04-15 10:30:23 +08:00
我们用的 release-vX.Y.Z，咋就不行了，main/master 分支只是最新的代码
|
|
12
janxin 2021-04-15 10:51:02 +08:00
@JasonLaw 不是，你提问的情况看上去开发时仅两个分支在工作：发布分支和开发分支；实际上如果分支还包含预发分支等其他功能分支的话，预发分支或其他需要部署的功能分支是可以作为 CD 部署的对象的，用作预发或者内部集成测试等功能需求。当然这跟开发分支需要进行持续部署没有关系。
|
 |
13
no1xsyzy 2021-04-15 11:12:34 +08:00
1. 太频繁的 commit 污染可以用 squash 解决
2. 每个 branch 应当建立单独的测试实例 比如 dev 分支有一个 dev.example[.]com 的记录 然后 fix-issue-42 有一个 fix-issue-42.example[.]com 的记录 内网泛域名索引，然后根据 Host 头响应 这种做法倒没什么不对的；道听途说，过于庞大的项目根本不能在合理时间内本地编译，都是丢专门的编译服务器的，改两三行代码，然后编译一天。 |
|
14
no1xsyzy 2021-04-15 11:16:00 +08:00
但是我看着觉得你这是不是缺乏自动化测试？
理应当不用 CD，CI 先跑通再说啊 |
|
16
sutra 2021-04-15 12:07:12 +08:00
就看你的 dev env 是否需要用来给别人用了，如果需要给别人用，那就 CD 呀。
test env 肯定是要给别人用的，那肯定要 CD，不然手工搞多累。 |
 |
17
msg7086 2021-04-15 20:59:38 +08:00
服务频繁不可用？
如果测试环境是共用的话，这样当然不好。如果是每个人自己的测试环境的话倒是没关系。 至于频繁 commit，这算啥问题？ Git 历史重写就好了。 |
Select Language