CI/CD 如何把 feature/xxx 分支发布到测试环境

[thomaswang]

各位大佬，谢谢你们指导， 是我描述的问题不太清楚，我这里补充一下

一个项目有很多开发者， 很多功能同时开发，eg: feature/login, feature/user, feature/order, 在上线之前，每个功能需要单独的测试，测试完成没有 bug，才能合并到 master，准备上线，可能有的团队在 master 前面还会有个 dev/staging 分支， 我想开发 feature/login 的这个人，push 完代码之后，CI/CD 自动的完成生成 docker 对应的 image, 然后启动容器，测试人员只需要打开对应的域名就可以访问到 feature/login 的代码

[CivAx]

为什么不把相关 feature 的代码合并到一个 branch 里…

jenkins 的 git 插件在 pull 代码的时候指定 pull 不同分支就行了

[thomaswang]

@CivAx 多谢你解答我的疑惑， 合到类似 master 这样随时要上线的分支是不行的，如果都合到一个 A 分支，把 A 分支发到测试环境测试，测试没问题了，再把 feature/xxx 和到 master 进行发布，这样好像是可以的，会不会出现大家都把没有测试过的代码合到 A 了，互相影响(我也没有想出来什么特殊情况下会相互影响)，这样你怎么看
feature/xxx 是变动的，每天都可以开出来很多个， 而且要做到 git push 之后，gitlab 通过 webhook 去调用 jenkins 构建， 这样咋指定分支呢， 大佬有何高见

[ikes]

git 插件的 Branch Specifier (blank for 'any') 一般默认写的是*/master 是部署的 master 分支，可以改成对应的分支就能部署分支了

[horder]

分支选择里填 */feature/*,然后 CI/CD 会拉取最近的一次提交
这是相关描述
<Wildcards>
The syntax is of the form: REPOSITORYNAME/BRANCH. In addition, BRANCH is recognized as a shorthand of */BRANCH, '*' is recognized as a wildcard, and '**' is recognized as wildcard that includes the separator '/'. Therefore, origin/branches* would match origin/branches-foo but not origin/branches/foo, while origin/branches** would match both origin/branches-foo and origin/branches/foo.

[thonatos]

## step one

```bash
git tag v{x}.{x}.{x} -m '{x}.{x}.{x}'
git push --tags
```

## step two

```bash
gco master
git merge feature/{x}.{x}.{x}
gb -D feature/{x}.{x}.{x}
```

[CivAx]

@thomaswang

我觉得你们可能需要重新讨论一下 CI/CD 流程……

我理解的方案：在接到项目 A 的 new feature 开发需求后本地新建分支 A/nf，在开发完毕代码、测试完成确认功能正常后，把自己开发的部分（ A/nf ） merge 到 A 项目的 develop 分支，jenkins 固定存在一个 job，只 pull dev 分支，检测到代码更新就自动构建（这个 gitlab 中 webhook 可以实现），可以加以配合 docker 来实现应用的整体交付给测试工程师，测试通过则合并到 staging 分支，等待预发布测试，然后再合到 master 分支。

指定分支这个是 jenkins 的事情，在 job 配置里的 “ Source Code Management ” 部分的 “ Branches to build ” 里指定一个分支就行了，比如你们的分支叫 dev 那就写 dev，如果这里留空是默认 master 的…

然后关于你关心的 “一但 push/merge 代码就触发 Jenkins 构建” ，首先这个需要到 Gitlab 对应项目的 Setting - Intergretion 里设置，URL 里填入 Jenkins 对应 Job 的 “ Build Triggers ” 中提供的 URL （请勾选 Build when a change is pushed to GitLab ），然后在 “ Trigger ” 里勾选自己需要的选项，比如我们勾选了 “ push ” 与 “ merge ” ；然后在 Jenkins 的 Job 里，在 “ Build Triggers ” 插件中的 “ Enabled GitLab triggers ” 里勾选 “ Push Events ”、“ Accepted Merge Request Events ”，代表达成以下条件则触发构建，同时记得点开 [Advance] ，在 “ Allowed branches ” 里选择 “ Filter branches by name ”，填入你要的分支名，这个选项代表 “当这个项目的 xx 分支达成触发条件后，开始触发流程”，如果选择 “ Allow all branches to trigger this job ”，会造成哪怕是其他任何一个不相关的分支被 push/merge 了，也会导致触发 Job 构建（哪怕这个 Job 只 pull dev 的代码）

我觉得你们缺个运维。

[thomaswang]

@CivAx 多谢你的宝贵建议， 我们运维不太厉害，我是一枚 developer， 你理解的方案，是不是 dev 是个大杂烩， 所有的开发分支都可以合并到 dev，然后 jenkins 自动把 dev 发布测试环境，测试没问题， 就可以把 A/nf 合并到 staging， 然后把 staging 预发布，预发布里面可能会有很多 feature/xxx 分支的代码(毕竟一个项目可能有很多开发者，很多功能同时开发嘛)， 预发布测试没问题了， 就可以把 staging 合并到 master，然后上线，是这个意思吗

[warcraft1236]

@thomaswang 然后你们就会遇到分批提测，分批上线的问题，光指定一个分支上线，会发生业务上的时间冲突的

[thomaswang]

@warcraft1236 放在一个分支提交测试是会有这个问题的， 理想中是任何分支(feature/xxx, fix/xxx, master, dev...), 都可以独立的打包成 docker images，然后启动容器， 测试人员可以访问任意一个分支的代码（且只有这个分支的代码）来看效果，

[thomaswang]

@warcraft1236 上线的话，只能上 master， 必须保证合到 master 的都是经过测试的， 时刻保证 master 可以上线，N 多个 分支，只要测试没问题了， 尽管和到 master 上线， 不需要顾忌 master 有其他分支的东西， 更不需要分批

[feiyuanqiu]

我们就是这样的，一个 feature 一个服务，每个服务都可以通过单独的 uri 访问。这个只靠开发是搞不定的，需要运维也参与进来

[warcraft1236]

@thomaswang 实际场景不会这样，怎么可能不顾及没有别的代码

[CivAx]

@thomaswang

7 楼的回复没错，这是一个比较 “正常” 的 CI/CD 工作流程。Dev 分支在保证代码质量前提下是应该允许随意合并的，开发认为这个任务开发完成后应该对测试工程师进行提测，测试工程师则测试你的功能点是否工作正常；请注意，如果多人同时合并与提测应考虑代码冲突或测试工程师的工作排期，在测试通过后，你的代码会由项目负责的主管合并到 Sta 分支，Sta 分支作为预上线的测试分支应该是在阶段性工作完成后进行整体测试，通过则由相关负责人合并到 Master 分支。

按照 9 楼的回复内容来看思路似乎是 “ pull 下 Origin 版 Dev，merge 某某负责的 feature 代码，进行构建，全程保持 Dev 纯净性不做任何修改，测试通过直接 Merge 到 Sta ” ？

这样确实可以实现…但是相对会麻烦一些

而且这么做有点匪夷所思，你终归是要推到 Master 的，每次版本迭代或功能新增都在用完全脱离线上几个世代的代码进行 CRUD，怎么看都觉得奇怪。

[AnyISalIn]

可以了解一下 Jenkins X 的流程

[avenger]

可以参考下 git-flow 的流程