软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

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

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

关于软件版本

在讨论这个话题之前,我们需要了解“版本”的含义。也许你已经知道版本的含义,但是这里还是有必要明确一下,因为在不同的语境下,版本的含义也有所不同。比如产品经理会对开发人员说:“这个功能我们会放到下个版本中实现”,开发人员会对测试人员说:“这个 Bug 在昨天的版本中已经修复了”。
这里产品经理说的“版本”是指特定功能集合,开发人员说的“版本”是指某一次程序的构建结果。也就是说对软件版本来说,包含两部分含义,一部分代表特定功能集合,一部分代表某一次特定的代码构建结果。
为了明确标识软件版本,需要对版本进行编号。目前业界在软件版本的命名上,通常会采用以下方式:
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

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

    作者回复: 好问题!

    冻结了代码后测试出来的Bug,首先要分级,不会20个都需要在当前版本修复的,有一部分影响不大的可以放到下一个版本修复。

    然后剩下的这些Bug,什么时候测试取决于两个条件:1. 你什么时候部署测试环境,只有部署了才能测试;2. 测试自己的测试节奏,比如他们每天测试上一天的bug。

    回归测试一般不会测试完一个就做一遍,但也不需要全部修复了才做,都是这一批测试完了再做一次,比如说今天测试完昨天所有修复的Bug后,会再做一遍回归测试,看有没有造成新的Bug。

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

    作者回复: 这个问题其实不复杂,你可以将服务分拆,独立出来一个专门接受数据的服务,这个服务极其简单,只做一件事:接收数据,并存储到数据库或消息队列。

    你原有的服务,改从数据库或者消息队列读取即可。

    更新部署的时候,接受数据的服务就不要轻易更新了,这样就不担心会丢数据了。真要更新,只要和对方协商一下,暂停推送就好了。

    --
    @熊欲轻飞: 这种建议还是做个返回确认的机制,推送方对得到确认的数据做标记,没有得到确认的加入队列后续再推。

    2019-05-21
    4
  • 小小
    多个项目发版时,要注意依赖,莫慌,匆匆忙忙很容易出现问题

    作者回复: 👍依赖关系这个也很重要

    如果自动化更新,应该能很好的改善这个问题,可以按照设定好的顺序去部署更新。

    2019-05-21
    4
  • Charles
    我们目前人工管理版本很容易乱,看了文章才知道最后一位是构建版本并且是自动生成的,之前也没深究,豁然开朗,看来很多表面上看起来很简单的东西深究都是学问,谢谢!

    另外问宝玉老师一个团队管理问题,如果是瀑布流带点敏捷部分实践的开发方式,总觉得UI这个岗位工作量不怎么饱和,一个版本过来特别是小版本迭代,周期可能是两周,UI可能1天就搞定了,其它岗位都差不多都要全程跟下来,这个问题出现在哪里?

    作者回复: 这个问题有点不好回答,毕竟对你项目情况不够了解。

    我觉得呢,如果UI这个岗位对你的团队来说是必须的,并且UI设计师很好的完成了他/她的工作,那么就很好,没有任何问题。毕竟有的人效率就是比较高,好过故意磨洋工看起来很忙。

    如果UI这个岗位是可有可无,那么就可以考虑不设置这岗位,将工作外包出去,或者尽可能用一些标准的UI,或者让前端工程师兼职UI设计工作。

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

    作者回复: 我觉得对于你说的这种情况要保证产品质量,需要抓两头:

    一头是在做需求分析和设计的时候,充分考虑到各种环境的差异;

    另一头是在测试和验收的时候,要充分对哥哥环境进行测试。

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

    作者回复: 我个人对于2B确实没啥经验,所以讲得少。

    2B的项目相对来说,迭代周期要长一些,对界面和用户体验要求低一些,更多是来源于客户需求,更难控制需求。

    针对这些特点,要多花功夫在需求的管理和控制上,在开发上可以选择迭代模型或敏捷开发,优先实现已经确定的和核心的需求,勤和客户沟通。

    2019-08-28
    1
  • 纯洁的憎恶
    版本规划:
    1.规划好要发布功能。必要的先发,锦上添花的后发。根据用户的质量容忍度,划分质量标准,明确哪些功能质量必须一步到位,哪些可以慢慢来。
    2.设计好发布策略。对内发布还是对外发布,beta版还是正式版,是否用灰度测试,管理好用户预期。
    3.制定综合性发布计划。协调项目团队、客户、运营等多方利益确定发布时间进度。

    科学规范的发布流程:
    1.代码冻结。禁止修改即将发布到主干的程序,以避免出现不可控的新bug。
    2.bug分级。冻结程序中的bug做到心中有数,但对于极其严重的bug仍要在发布前修正,修复后要生成新的候选版本号以示区分。
    3.回归测试。最终候选版本发布生产环境前,对主流程和已知bug测试,确保无误。
    4.上线申请、审批与部署。
    5.上线测试。第一时间发现问题,如有必要立刻回滚,切忌急于打补丁。

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

    2019-05-25
    1
  • javaadu
    这篇文章来得正好,很有收获,今天要组织项目的发布评审,昨天我在文档里主要梳理了几个点:本次发布的变更点;与前端的合作;自己内部应用的依赖关系;db变更;配置变更等等。

    读了这篇文章,感觉自己需要改进几个点
    第一,跟产品确认本次的功能点和标准
    第二,不同应用的发布记录和灰度计划
    第三,发布上线后健康状态的监控(这块我已经做了个降级开关,不过需要提出来,把信息同步出去)

    另外,今年跟着老师的专栏学习下来,感觉自己的项目管理能力有不小的提升,表现在工作中就是试用期就开始做技术pm了,感谢老师🙏

    作者回复: 👍赞,能学以致用最好!

    也谢谢你的支持

    2019-05-24
    1
收起评论
8
返回
顶部