如何看待 CI 持续集成产生的大量 tag？

[dandankele]

最近在研究 CI 由于公司业务性质，网站每天可能会有数十次的更新上线，而每次上线都会通过 CI 自动化的 release 打上语义化的 tag，长期下来产生的 tag 非常的多，担心后续对 git 仓库的管理和性能产生的影响。

不禁思考，每次 git 提交都有 commit id，为何还要 tag ？打这么多 tag 是不是太浪费了

[zealic]

对性能影响不大，语意化及可追溯更重要。

[tuxz]

也可以使用 commit id 的前几位作为标签

[miaoxia]

每天数十次的上线肯定是有问题的
每次上线打 tag 这样的行为是对的
commid id 和 tag 完全不是一个纬度的东西
建议去了解下 git flow 工作流，分别了解下开发、提测、上线及修复不同 bug 的处理流程
打 tag 不会对性能造成影响，无意义的 co 二进制文件才会

[zhuweiyou]

每天上线 10 次。。。

[chinesestudio]

我就好奇啥业务

[misaka19000]

每天上线数十次？这种上线频率肯定是有问题的

[clino]

可以将 sha1 信息存在一个专门的 git 里来记录历史

[mercury233]

- bash -c "git tag -d latest ; exit 0"
- git tag latest HEAD
- git push -f origin latest

[mikicomo]

每天上线十次？是开发自己有权限发版么？如果是运维，不怕被打死？

[bkmi]

多业务线并行的情况下每天上线数十次真的挺正常的，不过可以考虑拆分一下

[petelin]

我们大概有 200 多万 tag 吧

[Torpedo]

你这上线太多了，不要怪 ci

[mywaiting]

依稀记得先前看 coolshell 的 blog，里面有说 amazon 的基础设施每几秒钟就有一次部署？

每天线上能滚动部署数十次，侧面说明你们的线上环境 /流量转移 /AB 测试都做得挺好的，应该感谢有这么好的开发部署流程啊

git tag 多少无所谓的，我个人的项目都有好几百个 tag，回滚比 comment id 要方便好多

好像记得有一种利用 git tag 来进行灰度发布，引入部分流量开启部分 feature 测试的方法，大体是这个思路，我没有实践过，贴主可以去自己搜索看看

[ericgui]

@mikicomo 全都自动化了，没什么了不起的

[xiaket]

为什么上面这么多同学认为每天上线十几次是坏事的?

[wenzhoou]

@xiaket 因为上线是个很严肃的事情需要审查。而且因为上线频繁，有可能导致大量 bug 不知道到底在什么版本会重现，相当于定时炸弹。

[ericgui]

@wenzhoou 全自动的嘛，从 push 到 run test，到 build 到 deploy，一条龙自动化

能够做到这个，理论上你要写很多测试用例的，尤其是新加 feature 的时候，要写很多测试用例。所以其实一般这么做，显然都是 master branch 做这一套，有权限管理，只能有权限的人把自己的分支合并到 master。

[Fule]

我也考虑过这个问题。不过一个 tag 对 git 来说也就是多几个字节的问题吧，所以至少中短期内应该不是问题。最后大不了写个程序从最早的 tag 开始删一波~~

[airfling]

你把每天上线十次压缩为两周上线一次，你看看还会不会有问题

[apex]

楼上身体不好的男人们，纷纷对一天十次表示惊讶😂