我提出这个疑问的原因是:我发现有人将CD当做一个测试自己代码是否OK的工具,自己还没有验证修改是否符合期望之前就提交 commit,push到远程仓库,通过CD,在测试环境验证。这样不仅仅会造成频繁 commit,造成n个“fix issue 1”,污染git的历史,并且会造成服务的频繁不可用。
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 历史重写就好了。 |