你们都怎么发布 release 版本的呀

• 主 資深大佬 : myCupOfTea

  我现在有个想法,直接用当前 commit 的 hash 做版本号算了

• 資深大佬 : qoo2019

  为啥不用 tag ？

• 資深大佬 : yjxjn

  Jenkins ？

• 資深大佬 : TinySec

  小团队可以使用 gitea + drone 的持续集成方案，成本很低，

• 資深大佬 : nightwitch

  开源项目常见做法:
  要发布的时候 commit 打一个 tag, ‘release-xxx’ , 方便后面追踪 release 对应的源码版本. CI/CD 看到 tag 后进行编译-打包-部署的流程.

• 資深大佬 : xizismile

  1.控制版本号还是开发来定比较好。找相关的技术负责人定一下发布的版本号标准（主版本，次版本，修复版本）

  2.线上环境获取构件的版本号，你可以看一些插件类的。比如 java 的话有 git-commit-id 的插件，maven 打包的时候会把 git 相关的信息打包进项目里面，然后在线上就能直接访问到了

• 資深大佬 : hantsy

  1.Git 可以 Tag，这个一般可以根据 Feature 开发计划进行。
  2. 一般普通的项目开发，采用敏捷发布（比如完全走 Github Flow，Code Review，CI/CD 测试通过，直接 merge 后就自动发布），不需要版本号。除非你的项目是一个公开项目，有很多其他项目依赖它，你可以另外走 Git Flow，定制严格版本发布计划。

• 主 資深大佬 : myCupOfTea

  @qoo2019 因为老板不让干…

• 主 資深大佬 : myCupOfTea

  @hantsy 你说的这个流程没错,但是不带版本号 错误日志没法区分是那个版本出现的 bug,蛋疼呢

• 主 資深大佬 : myCupOfTea

  @nightwitch 俺也这么想的,主要现在项目负责人都是测试人员,他们基本不管这些,开发人员也不知道啥时候发布呢,我去跟老板谈谈吧,还是打 tag 比较好

• 主 資深大佬 : myCupOfTea

  其实还有一个很大的问题啊,因为是微服务架构,如果都是项目负责人打 tag,也太多了,但是各个服务负责人自己打 tag 又不靠谱ヽ(°◇° )ノ

• 資深大佬 : dullwit

  git flow 结合 jenkins

• 主 資深大佬 : myCupOfTea

  @dullwit 微服务拆的太细,仓库太多属实蛋疼,感觉只有改成 monorepos 才方便处理

• 資深大佬 : cheng6563

  我司是上线前以日期为版本号打 tag 。这样同一次上线的不同服务版本号相同。只有一些基础框架项目不怎么改的是用 1.0.0 这样的版本号

• 主 資深大佬 : myCupOfTea

  @cheng6563 主要服务多是一方面,各个服务负责人的态度不一致,甚至经常出现代码提交了,但是依赖更新了没有 deploy(指的 spring-cloud 场景下的 common 和 client, 当然本来也应该 cicd 自动去 deploy,这种场景大多能避免,不过运维不知道为啥不乐意)

• 資深大佬 : msg7086

  商业软件 Git-tags，开源软件可以直接 rev 编号或者 git hash 。我开源软件是 tags 打 rev 编号发的。

• 資深大佬 : hantsy

  从你们现状，真的很佩服你们的领导，最基本的 devops 流程都没有，就上了微服。心真的大，如果一个自动化流程都没跑通过，我是坚决不会做微服的。

  我坚守一条最基本的原则: 没有基本的 devops 设施的微服务开发都是假装在做微服务，没有写测试的敏捷开发都是假敏捷。

• 資深大佬 : baymax123456

  maven 有打包时自动生成 git 版本号的插件

• 資深大佬 : cco

  看领导脸色~