背景

随着前端项目工程化实践, 前端项目在逐渐面对不同程度的复杂度. DevOps 技术的推进, 也将更多的控制权左移至开发侧. 目前笔者采用的 Git 工作流程参考【DevOps 技术：主干开发】，开发分支和发布分支没有必然的联系，同一个开发分支可能会对应不同的发布分支。 为了便于跨部门协同，约定在一定时间周期内，开发分支和发布分支有固定的对应关系。比如 V1 的开发对应 alpha 发布分支，V1.1 的开发分支对应 beta 发布分支。

开发分支和发布分支的同步

那么，V1 的开发分支如何自动同步到 alpha 的发布分支？

首先我们分析方案：

什么时候触发同步？

V1 分支 push 的时候。
如何触发同步？

最简单的做法是在 CI Runner 里面 clone 项目，然后 push 到发布分支。

触发时机

要想监听触发事件，很容易的就能想到 webhooks。但是如果要依据 webhook 实现，必然要启动一个服务，用来监听 webhook 的事件。这个成本稍微有点重。

但是其实我们需要的 trigger 是在开发分支 push 的时候，这和 CI 的时机是一致的。从这个角度考虑我们可以在 CI 时同步分支。即利用 gitlab-ci 作为触发器

如何实现 git push

首先能想到的做法，在 runner 中 clone 远端项目。但是不论是使用 SSH Keys 还是 https密码 的方式，感觉都有些不美。一个需要在 runner 中固定一个 ssh 私钥，另一个需要输入密码。

最终在 Stack Overflow 上找到了解决方案，通过 AccessToken 克隆项目。

首先在 gitlab 生成 AccessToken：

# 生成的 AccessToken
gitlab_ci_push: xxxxxx

# 关联到远端仓库
git remote add origin https://gitlab_ci_push:xxxxxx@gitlab.com/myuser/myrepo.git

# .gitlab-ci.yml
stage:
	- gitlab-pub

gitlab-pub:
	stage: gitlab-pub
only:
	variables:
		# CI_COMMIT_REF_NAME 是构建项目的标记和分支
		# ALPHA_TRUNK_BRANCH 是在 gitlab 的 CI/CD 中定义的变量，值是 alpha 对应的开发分支
		- $CI_COMMIT_REF_NAME == $ALPHA_TRUNK_BRANCH
tags:
	default
# 定义仅这个 Job 使用的变量
variables:
	# git.example.com/test/test.git
	GITLAB_URL: ${CI_SERVER_HOST}/${CI_PROJECT_PATH}.git
scripts:
	- git remote rm origin;
	- git remote add origin https://<token-name>:<token>@${GITLAB_URL};
	- git branch -b alpha;
	- git push -f -u origin alpha

总结

实现目的的方案可以有很多种，我们只需要找到问题的关键，然后逐步解决问题。就能得到一个适合当前项目的方案。同理，我们也可以实现在不同的项目间的 git 协同。比如【Shopee IconBot】Figma + Gitlab CI 一键交付 SVG 多色图标库的方案，我们也可以用以上方案实现简版的图标交付方案。

参考

docs.gitlab.com/ee/api/READ… cloud.google.com/architectur… nvie.com/posts/a-suc… juuun.io/thoughts/ha…

记 Gitlab 实践中的一个小插曲

背景

开发分支和发布分支的同步

触发时机

如何实现 git push

总结

参考