V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
myCupOfTea
V2EX  ›  程序员

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

  •  1
     
  •   myCupOfTea · 2020-05-25 10:35:56 +08:00 · 4255 次点击
    这是一个创建于 1403 天前的主题,其中的信息可能已经有所发展或是发生改变。
    现在公司项目发布都没有做版本控制,日志都不知道是啥版本的
    我的想法就是在 ci 里做版本自增长然后合并代码,就像 lerna publish 那样,但是 lerna publish 是有一个选择发布
    patch,minor,major 这个过程的.
    那么有没有一个发布管理平台让运维人员控制发布版本(同时我还可以在构建的环境获取到该版本变量取到),最好顺带了把构建时环境变量设置一并带上的系统呢
    19 条回复    2020-05-25 14:10:14 +08:00
    myCupOfTea
        1
    myCupOfTea  
    OP
       2020-05-25 10:44:40 +08:00
    我现在有个想法,直接用当前 commit 的 hash 做版本号算了
    qoo2019
        2
    qoo2019  
       2020-05-25 10:46:05 +08:00
    为啥不用 tag ?
    yjxjn
        3
    yjxjn  
       2020-05-25 10:47:46 +08:00
    Jenkins ?
    TinySec
        4
    TinySec  
       2020-05-25 10:51:49 +08:00
    小团队可以使用 gitea + drone 的持续集成方案,成本很低,
    nightwitch
        5
    nightwitch  
       2020-05-25 10:53:05 +08:00
    开源项目常见做法:
    要发布的时候 commit 打一个 tag, 'release-xxx' , 方便后面追踪 release 对应的源码版本. CI/CD 看到 tag 后进行编译-打包-部署的流程.
    xizismile
        6
    xizismile  
       2020-05-25 11:01:15 +08:00 via Android
    1.控制版本号还是开发来定比较好。找相关的技术负责人定一下发布的版本号标准(主版本,次版本,修复版本)

    2.线上环境获取构件的版本号,你可以看一些插件类的。比如 java 的话有 git-commit-id 的插件,maven 打包的时候会把 git 相关的信息打包进项目里面,然后在线上就能直接访问到了
    hantsy
        7
    hantsy  
       2020-05-25 11:19:17 +08:00
    1.Git 可以 Tag,这个一般可以根据 Feature 开发计划进行。
    2. 一般普通的项目开发,采用敏捷发布(比如完全走 Github Flow,Code Review,CI/CD 测试通过,直接 merge 后就自动发布),不需要版本号。除非你的项目是一个公开项目,有很多其他项目依赖它,你可以另外走 Git Flow,定制严格版本发布计划。
    myCupOfTea
        8
    myCupOfTea  
    OP
       2020-05-25 11:21:29 +08:00
    @qoo2019 因为老板不让干...
    myCupOfTea
        9
    myCupOfTea  
    OP
       2020-05-25 11:22:39 +08:00
    @hantsy 你说的这个流程没错,但是不带版本号 错误日志没法区分是那个版本出现的 bug,蛋疼呢
    myCupOfTea
        10
    myCupOfTea  
    OP
       2020-05-25 11:27:27 +08:00
    @nightwitch 俺也这么想的,主要现在项目负责人都是测试人员,他们基本不管这些,开发人员也不知道啥时候发布呢,我去跟老板谈谈吧,还是打 tag 比较好
    myCupOfTea
        11
    myCupOfTea  
    OP
       2020-05-25 11:30:10 +08:00
    其实还有一个很大的问题啊,因为是微服务架构,如果都是项目负责人打 tag,也太多了,但是各个服务负责人自己打 tag 又不靠谱ヽ(°◇° )ノ
    dullwit
        12
    dullwit  
       2020-05-25 11:41:30 +08:00
    git flow 结合 jenkins
    myCupOfTea
        13
    myCupOfTea  
    OP
       2020-05-25 11:54:18 +08:00
    @dullwit 微服务拆的太细,仓库太多属实蛋疼,感觉只有改成 monorepos 才方便处理
    cheng6563
        14
    cheng6563  
       2020-05-25 12:29:26 +08:00 via Android   ❤️ 1
    我司是上线前以日期为版本号打 tag 。这样同一次上线的不同服务版本号相同。只有一些基础框架项目不怎么改的是用 1.0.0 这样的版本号
    myCupOfTea
        15
    myCupOfTea  
    OP
       2020-05-25 12:36:36 +08:00
    @cheng6563 主要服务多是一方面,各个服务负责人的态度不一致,甚至经常出现代码提交了,但是依赖更新了没有 deploy(指的 spring-cloud 场景下的 common 和 client, 当然本来也应该 cicd 自动去 deploy,这种场景大多能避免,不过运维不知道为啥不乐意)
    msg7086
        16
    msg7086  
       2020-05-25 12:45:17 +08:00
    商业软件 Git-tags,开源软件可以直接 rev 编号或者 git hash 。我开源软件是 tags 打 rev 编号发的。
    hantsy
        17
    hantsy  
       2020-05-25 13:28:28 +08:00
    从你们现状,真的很佩服你们的领导,最基本的 devops 流程都没有,就上了微服。心真的大,如果一个自动化流程都没跑通过,我是坚决不会做微服的。

    我坚守一条最基本的原则: 没有基本的 devops 设施的微服务开发都是假装在做微服务,没有写测试的敏捷开发都是假敏捷。
    baymax123456
        18
    baymax123456  
       2020-05-25 14:06:04 +08:00
    maven 有打包时自动生成 git 版本号的插件
    cco
        19
    cco  
       2020-05-25 14:10:14 +08:00
    看领导脸色~
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   3270 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 14:03 · PVG 22:03 · LAX 07:03 · JFK 10:03
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.