软件工程之美
宝玉
Groupon 资深工程师,微软最有价值专家
44272 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 55 讲
软件工程之美
15
15
1.0x
00:00/00:00
登录|注册

35 | 版本发布:软件上线只是新的开始

课后思考
总结
软件上线只是新的开始
规范好发布流程,保障发布质量
版本发布前,做好版本发布的规划
关于软件版本
版本发布

该思维导图由 AI 生成,仅供参考

你好,我是宝玉。上一章我们学习了软件测试篇,今天,我们将从版本发布这个话题开始,进入到运行维护篇的学习。
说到版本发布,对于很多开发人员来说,觉得是一件很简单的事情,就是将程序编译打包部署,但实际发布的时候,却经常出现发布错版本的问题,或者是发布前修改了一点代码导致上线出现 Bug 的情况发生。
而版本发布对于很多项目管理者来说,又是一个很纠结的事情,觉得还有很多功能没完成,很多 Bug 还没改完,害怕用户负面评价,结果时间一拖再拖,迟迟无法上线。
所以今天我将带你一起学习一下如何做好版本发布,保障好发布产品的质量。

关于软件版本

在讨论这个话题之前,我们需要了解“版本”的含义。也许你已经知道版本的含义,但是这里还是有必要明确一下,因为在不同的语境下,版本的含义也有所不同。比如产品经理会对开发人员说:“这个功能我们会放到下个版本中实现”,开发人员会对测试人员说:“这个 Bug 在昨天的版本中已经修复了”。
这里产品经理说的“版本”是指特定功能集合,开发人员说的“版本”是指某一次程序的构建结果。也就是说对软件版本来说,包含两部分含义,一部分代表特定功能集合,一部分代表某一次特定的代码构建结果。
为了明确标识软件版本,需要对版本进行编号。目前业界在软件版本的命名上,通常会采用以下方式:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文详细介绍了软件版本发布前的规划工作,强调了版本发布并不要求完美,而是需要在用户预期和软件实际情况之间取得平衡。作者提到了版本发布前需要规划要发布的功能、定义质量标准、设计发布策略,并制定综合性的发布计划。通过实例和案例,生动地阐述了版本发布规划的重要性和实际操作方法。文章还介绍了大厂常见的发布流程,并指出软件上线只是新的开始,需要收集用户反馈、进行监控和预警,并对整个版本的开发过程进行总结回顾。总的来说,本文强调了版本发布规划的重要性,以及如何通过合理的发布流程确保发布版本的正确性和稳定性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件工程之美》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(11)

  • 最新
  • 精选
  • beiler
    老师,我想问个问题啊,比如我冻结了代码,但是测试测试出来了二十个bug,那回归测试是二十个bug修完了一起测试还是修一个测一个?最后再整体测试?

    作者回复: 好问题! 冻结了代码后测试出来的Bug,首先要分级,不会20个都需要在当前版本修复的,有一部分影响不大的可以放到下一个版本修复。 然后剩下的这些Bug,什么时候测试取决于两个条件:1. 你什么时候部署测试环境,只有部署了才能测试;2. 测试自己的测试节奏,比如他们每天测试上一天的bug。 回归测试一般不会测试完一个就做一遍,但也不需要全部修复了才做,都是这一批测试完了再做一次,比如说今天测试完昨天所有修复的Bug后,会再做一遍回归测试,看有没有造成新的Bug。

    2019-06-02
    8
  • 熊猫
    多个项目发版时,要注意依赖,莫慌,匆匆忙忙很容易出现问题

    作者回复: 👍依赖关系这个也很重要 如果自动化更新,应该能很好的改善这个问题,可以按照设定好的顺序去部署更新。

    2019-05-21
    7
  • yellowcloud
    宝玉老师,您好,我们目前有一个项目是做实时数据采集的,对方将实时数据推送给我们,基本上每天每个时刻都可能有数据推送过来。这样就导致一个问题,我们部署新的版本时,他们的数据还在推送,这样就不可避免地丢失了部署过程中的数据,对方也没有重新推送的机制。请问下宝玉老师,这种问题有没有比较好的解决方案,以解决更新版本时数据丢失的问题。

    作者回复: 这个问题其实不复杂,你可以将服务分拆,独立出来一个专门接受数据的服务,这个服务极其简单,只做一件事:接收数据,并存储到数据库或消息队列。 你原有的服务,改从数据库或者消息队列读取即可。 更新部署的时候,接受数据的服务就不要轻易更新了,这样就不担心会丢数据了。真要更新,只要和对方协商一下,暂停推送就好了。 -- @熊欲轻飞: 这种建议还是做个返回确认的机制,推送方对得到确认的数据做标记,没有得到确认的加入队列后续再推。

    2019-05-21
    6
  • Charles
    我们目前人工管理版本很容易乱,看了文章才知道最后一位是构建版本并且是自动生成的,之前也没深究,豁然开朗,看来很多表面上看起来很简单的东西深究都是学问,谢谢! 另外问宝玉老师一个团队管理问题,如果是瀑布流带点敏捷部分实践的开发方式,总觉得UI这个岗位工作量不怎么饱和,一个版本过来特别是小版本迭代,周期可能是两周,UI可能1天就搞定了,其它岗位都差不多都要全程跟下来,这个问题出现在哪里?

    作者回复: 这个问题有点不好回答,毕竟对你项目情况不够了解。 我觉得呢,如果UI这个岗位对你的团队来说是必须的,并且UI设计师很好的完成了他/她的工作,那么就很好,没有任何问题。毕竟有的人效率就是比较高,好过故意磨洋工看起来很忙。 如果UI这个岗位是可有可无,那么就可以考虑不设置这岗位,将工作外包出去,或者尽可能用一些标准的UI,或者让前端工程师兼职UI设计工作。

    2019-05-22
    4
  • 纯洁的憎恶
    版本规划: 1.规划好要发布功能。必要的先发,锦上添花的后发。根据用户的质量容忍度,划分质量标准,明确哪些功能质量必须一步到位,哪些可以慢慢来。 2.设计好发布策略。对内发布还是对外发布,beta版还是正式版,是否用灰度测试,管理好用户预期。 3.制定综合性发布计划。协调项目团队、客户、运营等多方利益确定发布时间进度。 科学规范的发布流程: 1.代码冻结。禁止修改即将发布到主干的程序,以避免出现不可控的新bug。 2.bug分级。冻结程序中的bug做到心中有数,但对于极其严重的bug仍要在发布前修正,修复后要生成新的候选版本号以示区分。 3.回归测试。最终候选版本发布生产环境前,对主流程和已知bug测试,确保无误。 4.上线申请、审批与部署。 5.上线测试。第一时间发现问题,如有必要立刻回滚,切忌急于打补丁。

    作者回复: 👍感谢分享补充!

    2019-05-25
    3
  • 小老鼠
    一个产品的客户有许多,客户的环境各不相同,如何保证产品质量?(比如A电信企业生产的DNS服务器,在X产商集成的是B电信企业的DHCP服务器,在Y产商集成的是C电信企业的DHCP服务器⋯。)

    作者回复: 我觉得对于你说的这种情况要保证产品质量,需要抓两头: 一头是在做需求分析和设计的时候,充分考虑到各种环境的差异; 另一头是在测试和验收的时候,要充分对哥哥环境进行测试。

    2019-10-07
    2
  • calvins
    2 b和2 c在版本上线差距真大,从文章来看,我们大部分的发版还是不够严谨。没有beta版,没有灰度,经常紧急修复,版本管理工具缺失,好多问题。不知道这么方面老师有没有好的方法或建议?

    作者回复: 版本发布要做到稳定可靠,需要注意做到几点: 1. 自动化测试不可少,只依赖人工测试是不够和不可靠的,要想系统稳定,一定要写足够的自动化测试代码,覆盖主要的用户使用场景。借助持续集成CI/CD工具每次代码合并分支,每次部署之前都跑一次自动化测试,跑不过就要分析原因,修复为止。 2. 测试要充分,在正式部署到生产环境之前,在测试环境要运行一段时间,发现问题提交到Bug跟踪系统跟踪起来,根据优先级修复,通过测试后再部署生产环境。 3. 版本管理工具要用好,把测试版本和开发版本要分开,开发中的版本是不稳定的,如果一边开发新功能还一边修复bug,很难稳定下来。所以最好是要有两个分支,一个是开发新功能的,一个是已经开发好测试中的,部署后再合并一起,新版本完成了再创建新的测试分支。 4. 发布和回滚都实现自动化,一方面提升部署和回滚效率,另一方面可以减少人工导致的错误。 5. 一些新功能可能会导致系统不稳定,最好让模块尽可能独立,加上开关,让一小部分用户先使用,逐步放开,如果出现故障,通过开关控制关闭,这样不必回滚。 6. 用好ELK、Splunk这样的日志收集分析系统,把关键信息记录起来,当发现问题的时候,可以借助日志快速定位到问题,即使问题还没发生,定期对日志信息进行分析,也可以对潜在问题提前发现。

    2020-04-08
    1
  • E
    老师,我看您讲的大多数是针对2C,针对2B的有什么好的提议吗?

    作者回复: 我个人对于2B确实没啥经验,所以讲得少。 2B的项目相对来说,迭代周期要长一些,对界面和用户体验要求低一些,更多是来源于客户需求,更难控制需求。 针对这些特点,要多花功夫在需求的管理和控制上,在开发上可以选择迭代模型或敏捷开发,优先实现已经确定的和核心的需求,勤和客户沟通。

    2019-08-28
    1
  • javaadu
    这篇文章来得正好,很有收获,今天要组织项目的发布评审,昨天我在文档里主要梳理了几个点:本次发布的变更点;与前端的合作;自己内部应用的依赖关系;db变更;配置变更等等。 读了这篇文章,感觉自己需要改进几个点 第一,跟产品确认本次的功能点和标准 第二,不同应用的发布记录和灰度计划 第三,发布上线后健康状态的监控(这块我已经做了个降级开关,不过需要提出来,把信息同步出去) 另外,今年跟着老师的专栏学习下来,感觉自己的项目管理能力有不小的提升,表现在工作中就是试用期就开始做技术pm了,感谢老师🙏

    作者回复: 👍赞,能学以致用最好! 也谢谢你的支持

    2019-05-24
    1
  • Geek_Zeal
    大型项目程序配置管理演化之路,这篇链接失效了呢老师
    2023-11-01归属地:重庆
收起评论
显示
设置
留言
11
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部