这是一个创建于 2676 天前的主题，其中的信息可能已经有所发展或是发生改变。
看见有人在讨论 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 什么乱七八糟的就不说了
 | 1 mritd OP  |
 | 2 Immortal 2018-06-20 11:33:30 +08:00 一直也想有这么一个实践 想问下楼主学习和入门从何开始 还有楼主觉得有用的资料和链接能分享么 |
| 4 mritd OP @Livid imgur markdown gifv 格式为毛线 总是在链接( https://xxx) 前面加一个空格？我改成 gif 就好了 |
| 5 mritd OP 哇.....上面的回复又加了一个 |
 | 6 feiyuanqiu 2018-06-20 11:38:01 +08:00 赞赞赞 |
 | 7 ShineSmile 2018-06-20 11:49:24 +08:00 gitlab 的 runner 用过一段时间 还是很爽的 git 成也分支 败也分支 svn 没有分支只有目录 |
| 8 mritd OP @ShineSmile #7 runner daocker 启动 还是挺舒服的，然后 build 也走 docker 容器，不过 cache 稍微有点麻烦 |
 | 9 gamexg 2018-06-20 12:09:17 +08:00 请教 gitlab runner 是部署在国内还是国外？ 国内受网络影响很难用，有什么比较好的解决办法吗？ |
| 10 mritd OP |
| 12 mritd OP @gamexg 这个没麻烦啊，基础镜像做好了就行了，dockerfile 写好 有 cache 的，https://mritd.me/2017/11/12/ci-cd-dockerfile/ |
| 13 ShineSmile 2018-06-20 13:53:14 +08:00 @mritd 哈哈 我是做.NET Fx 的 gitlab 对我这边的生态唯一一个问题就是不支持直接部署在 windows 上。只能弄个虚拟机凑合一下 当然，runner 是跨平台的。 另外需要注意 runner 的脚本要防注入，控制好分支的权限 当时是通过 gitlab 接触到的 CI 和 CD 以及容器甚至 DevOps 很喜欢这个产品，非常适合开放的团队使用 后面才接触到 jenkins travis 和 appvenyor 也都用过 感觉还是直接拿工具链工具写脚本不受束缚最舒服 遗憾的是现在回到了巨硬的怀抱 auzre portal 上点点点 Visual Studio 一键发布 失去了对脚本的研究动力 可能还是团队规模太小吧 |
| 14 mritd OP @ShineSmile #13 runner 直接调用脚本应该是可以的，不过我记着 .net 后端项目好像可以在 docker 里跑，然后扔在 linux 上 |
| 15 ShineSmile 2018-06-20 14:10:41 +08:00 @mritd dotnet core 可以的。 dotnet fx 只能运行在 windows 的 docker 中。 例如 nano server 好像巨硬的 service fabric 是做 windows 容器调度的。 遗憾的是同样没细研究过…… |
 | 16 lt450196683 2018-06-20 14:20:27 +08:00 学习，嵌入式的环境。。docker 可以模拟么。。例如 wince/Android/mcu。。 |
| 17 ShineSmile 2018-06-20 14:22:13 +08:00 @lt450196683 LXC 了解一下？ |
| 18 feiyuanqiu 2018-06-20 15:10:44 +08:00 @mritd 关于 Angular git commit message，我有一个疑问想请教一下， 开发新功能用 feature 做 commit tag，处理生产问题用 hotfix tag，是吧？ 那开发时，处理新 feature 的 bug，提交时应该用什么 tag 呢？ |
| 19 mritd OP @feiyuanqiu #18 我目前的做法是，commit message 中对于修复性提交全部走 `fix(scope): subject` 这种格式；分支名称上，对于新功能应当从 develop checkout 新分支，且以 `feat/xxxx` 形式命名，只会合并到 develop 分支；对于线上问题紧急修复，从 master 创建分支，以 `hotfix/xxxx` 命名，ok 后同时合并到 master 与 develop ；最终原则是 master 要时刻保持和生产一致，develop 作为开发日常修改 |
| 20 mritd OP @feiyuanqiu 其实 gitflow 目前没有完全的统一标准，这东西存在的意义就是对 提交修改清晰化、测试部署流程化，你只要在几大模型中找寻出适合你的就可以 |
| 21 feiyuanqiu 2018-06-20 15:26:48 +08:00 @mritd 不好意思，刚才提问的时候走神了，名称打错了，上一条里面的 `hotfix` 应该是 `fix` 我的疑问主要是因为在你这套流程里面，会用 git-chglog 自动根据 commit message 生成变更说明，所以就比较纠结处理新 feature 的 bug 的 commit message 的 subject 的命名： 如果用 feat 的话，会导致变更说明里的 features 重复； 如果用 fix 的话，其实它们也并不是生产上的问题，没有必要把开发过程中的问题也写到 change log 里吧？ |
| 22 mritd OP  1 @feiyuanqiu #21 这个是个粒度问题，如果你的提交以功能为单位，那么当一个功能 ok 以后应当放入 测试环境测试，这时候有问题进行 fix 我感觉在 CHANGELOG 里是没什么问题的；如果以修改为单位提交 那么出现在 CHANGELOG 里会有点多，可以考虑用其他的； 那个 CHANGELOG 生成工具可以自己定义的  还有就是实际上这个 CHANGELOG 应该是面向开发人员的，我感觉多点少点无所谓，我只是想通过看到每个版本之间我们开发变动了什么东西；而对于类似 app 发版啥的这种 CHANGELOG 肯定是手写一个符合普通大众理解的 |
| 23 gamexg 2018-06-20 20:33:36 +08:00 via Android |
 | 24 dexterzzz 2018-06-20 21:59:18 +08:00 CI,CD 去看下 TFS,VSTS 什么才是业界最强 |
| 25 mritd OP @dexterzzz #24 这个贴子只是我对 opnsource CI 整理的一套工具链，如果硬对比商业版工具我敢保证有很多比它们还牛逼的，就算是商业版也无法做到每个方面都 ok，比如 提交规范、工作流的建立 |
 | 26 johnnie502 2018-06-21 7:35:55 +08:00 @dexterzzz 又在日常引战 |
 | 27 twistedmeadows 2018-06-22 00:48:18 +08:00 via Android 感谢楼主。最近正好遇到工作上协同缺乏规范的问题，版本控制有点混乱。学习了。 |
Select Language