姑且算是一个 CI 实践(多图慎点)

[mritd]

看见有人在讨论 git、svn 哪个好，都喷起来了；当然我是选择 git 的，svn 可能人家也有成熟的解决方案，这里我只是想单纯的给出一个我们目前 git 的方案；如果有其他大佬有更好的方案欢迎提出。(本帖禁止鄙视链、无脑喷)

主要涉及: GitLab、GitFlow、Mattermost、Docker、Kubernetes

先上几张图:

GitFlow 负责保证提交格式、分支名称足够规范

refs: https://mritd.me/2017/09/05/git-flow-note/

refs: https://github.com/mritd/gitflow-toolkit

这张图片保存后总是自动加空格 https://i.imgur.com/vcNUo3h.gifv mmp

提交格式规范后生成 CHANGELOG

refs: https://github.com/git-chglog/git-chglog

不同分支名称、多分支等用于 CI 触发(GitLab CI)，CI 已经对接了 Kubernetes

refs: https://mritd.me/2017/11/28/ci-cd-gitlab-ci/

IM 对接

目前缺失的:

CI Bot: 正在开发中，以前的基于 Hubot 造过一个，不过不喜欢 node，准备对接 tg 用 go 重新造一个

其他的还有 sentry 什么乱七八糟的就不说了

[feiyuanqiu]

@mritd 不好意思，刚才提问的时候走神了，名称打错了，上一条里面的 `hotfix` 应该是 `fix`

我的疑问主要是因为在你这套流程里面，会用 git-chglog 自动根据 commit message 生成变更说明，所以就比较纠结处理新 feature 的 bug 的 commit message 的 subject 的命名：

如果用 feat 的话，会导致变更说明里的 features 重复；
如果用 fix 的话，其实它们也并不是生产上的问题，没有必要把开发过程中的问题也写到 change log 里吧？

[mritd]

@feiyuanqiu #21 这个是个粒度问题，如果你的提交以功能为单位，那么当一个功能 ok 以后应当放入 测试环境测试，这时候有问题进行 fix 我感觉在 CHANGELOG 里是没什么问题的；如果以修改为单位提交 那么出现在 CHANGELOG 里会有点多，可以考虑用其他的；

那个 CHANGELOG 生成工具可以自己定义的

还有就是实际上这个 CHANGELOG 应该是面向开发人员的，我感觉多点少点无所谓，我只是想通过看到每个版本之间我们开发变动了什么东西；而对于类似 app 发版啥的这种 CHANGELOG 肯定是手写一个符合普通大众理解的

[gamexg]

@mritd 恩，docker 单独使用有 cache。
不过 gitlab runner 时没 cache 了，我记得好像有命令能开启。
不过直接把 runner 放到国外解决了所有问题，没在细看。😁😁😁

[dexterzzz]

CI,CD 去看下 TFS,VSTS 什么才是业界最强

[mritd]

@dexterzzz #24 这个贴子只是我对 opnsource CI 整理的一套工具链，如果硬对比商业版工具我敢保证有很多比它们还牛逼的，就算是商业版也无法做到每个方面都 ok，比如 提交规范、工作流的建立

[johnnie502]

@dexterzzz 又在日常引战

[twistedmeadows]

感谢楼主。最近正好遇到工作上协同缺乏规范的问题，版本控制有点混乱。学习了。