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

咨询一下各位大公司待过的老哥,关于 bug 处理流程和项目版本管理的问题

  •  
  •   jiayong2793 · 206 天前 · 1709 次点击
    这是一个创建于 206 天前的主题,其中的信息可能已经有所发展或是发生改变。

    1 、项目上线后发现了 bug,影响很小,但是领导要求要改,这种情况一般是马上修复还是下个版本修复?

    2 、项目上线后发现缺少了某个功能,影响很小,但是领导要求马上解决,这种情况一般马上增加,还是下个版本增加?

    3 、以上两种情况,如何控制版本号?

    4 、前后端和 app 版本号是否要分开?

    我目前的小公司是集团子公司只有几个人,但是现在要开始做集团的业务系统,初期版本都是单人负责,验证业务可行后会不断迭代功能,后面还要将多个系统互联互通。

    初期版本已经上线,但是问题很多,这些问题都由系统的使用人员在群里反馈,然后复制系统的人直接修改,现在系统一多就乱成一锅粥了。

    18 条回复    2021-07-02 14:35:07 +08:00
    AoEiuV020
        1
    AoEiuV020  
       206 天前   ❤️ 1
    1 和 2 自己觉得做不了主就让领导决定,没特别要求一般是下个版本修复,如果领导说的马上解决是要马上看到结果,那当然是立马更新版本了,
    3,只要发包就改版本号,
    4,各端版本无关,
    AoEiuV020
        2
    AoEiuV020  
       206 天前
    @AoEiuV020 ==为什么限定大公司,我也是小公司的,当我没说,
    RLinux
        3
    RLinux  
       206 天前
    kop1989
        4
    kop1989  
       206 天前
    1 、2 并不是技术问题。
    3 、更新就是新版本。
    4 、每个项目的版本号独立。但要做好兼容性问题。
    raycool
        5
    raycool  
       206 天前
    你这个不是应该是做好版本管理就行了么?
    BUG 是否立即上线就看你和领导之间的权衡了。
    paradoxs
        6
    paradoxs  
       206 天前
    谁有权命令你就听谁的。 不然等着换工作。
    jiayong2793
        7
    jiayong2793  
    OP
       206 天前
    @kop1989 这些都不是技术问题,并且我也不是程序员,但现在公司的项目很乱,领导要让我管管,我就想着目前集团的发展,后面肯定是大公司的各种流程,但我没在大公司待过不知道流程怎样的,所以发到这个节点问问
    yexiaoxing
        8
    yexiaoxing  
       206 天前
    3. 版本号不都是自动生成的,控制啥。
    4. 不同的 project 就有不同的版本号。
    kop1989
        9
    kop1989  
       206 天前
    @jiayong2793 #7 你可能没理解。我所谓的“不是技术问题”,是指这并不是技术部门通过管理来决策的。换句话说,1 和 2 根本就由不得你来规划。

    比如集团领导说希望你们马上添加一个功能。你告诉领导等下个月的 release,你基本上就可以收拾东西了。
    chenluo0429
        10
    chenluo0429  
       206 天前
    1 和 2 其实是一个问题,生产环境的问题是否需要 hotfix,需要结合问题严重性,复现难度,修改难度,正常发版频率等来综合考虑。
    3. 只要发布了,版本号就要便变更。
    4. 版本独立,回溯问题的时候能够找到特定时刻每个端的版本号就可以了
    mxT52CRuqR6o5
        11
    mxT52CRuqR6o5  
       206 天前 via Android
    曾经的工作经验,看要求改的是多大的领导,像我带过的那家大公司,很高级别的领导提出的意见,不过是不是 bug,直接最高优先级处理
    hyb1996
        12
    hyb1996  
       206 天前 via Android
    客户端发版本需要权衡成本(开发修改的人力和时间,联调的时间,重新做上线测试的测试人力和时间,对其他需求的时间挤压)、风险(改动的大小、影响面、可能引入的新问题)、收益(问题的影响面、严重情况、是否为核心路径、核心体验)、是否为历史问题。如果是小概率、影响程度小的问题,一般可以跟下个版本;改动很大、修改风险高的问题,也可以跟下个版本以经过充分的测试暴露问题;本个版本引入的新问题尽量跟这个版本修复,原则是收殓问题;老板遇到的或者特别重视的可以紧急修复,但也要反馈相应的成本和风险给到老板。
    cking
        13
    cking  
       206 天前
    如果影响不是很大 一般都是下个版本 如果影响很大 那就直接 hotfix
    jiayong2793
        14
    jiayong2793  
    OP
       206 天前
    @kop1989 这不就是领导自己定规矩,然后自己先打破吗?
    kop1989
        15
    kop1989  
       206 天前
    @jiayong2793 #14

    1 、程序、流程是死的,人、业务是活的。
    2 、公司的唯一目的就是股东利益最大化。
    3 、规矩,是用来固定下属的操作范围,从而保障利益的,如果规矩与利益冲突时,必然保障利益。

    所以你的问题 1 与问题 2,其实压根就和正常的运营规范不沾边。停留在书本上谁都知道应该定期发版,灰度测试。但现实业务中又有几个“理想情况”呢?

    所以你现在应该做的是:

    1 、一个理论上的稳妥流程。非特殊情况用此流程。此流程最保守。
    2 、一个紧急处理流程。用于处理部门内的紧急情况,比如影响业务的 bug 等。进行紧急修复。此流程最激进。
    3 、一个最优先处理流程,在需要敏捷处理的需求到来时,使用此流程,此流程的安全程度介于 1 、2 之间。

    但无论哪个流程,都要保证服务器端和客户端程序版本可以无痛回滚。
    bianxiuyan1993
        16
    bianxiuyan1993  
       206 天前
    如果是定成 bug 的话,基本都是紧急处理上线
    TypeError
        17
    TypeError  
       206 天前
    小版本号就是解决问题 1 的,问题 2 看话语权,话语权强的团队就可以推到下个大版本一起开发,这样开发测试上线时间都充足,少出幺蛾子
    jiayong2793
        18
    jiayong2793  
    OP
       206 天前   ❤️ 1
    @kop1989 领导的意思是要确定一个流程来规范现在版本混乱的问题,但是领导自己又非常随意,另外他自己也开发维护了一个重要的业务系统,我根本不知道那个系统发生过什么

    另外,系统根本没有测试就直接发版了,上线了,用户发现问题了我才知道,并且这种工作方式是这个领导带领这个团队养成的作风
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1141 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 20:25 · PVG 04:25 · LAX 12:25 · JFK 15:25
    ♥ Do have faith in what you're doing.