35 | 版本发布：软件上线只是新的开始
该思维导图由 AI 生成，仅供参考
关于软件版本
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文详细介绍了软件版本发布前的规划工作，强调了版本发布并不要求完美，而是需要在用户预期和软件实际情况之间取得平衡。作者提到了版本发布前需要规划要发布的功能、定义质量标准、设计发布策略，并制定综合性的发布计划。通过实例和案例，生动地阐述了版本发布规划的重要性和实际操作方法。文章还介绍了大厂常见的发布流程，并指出软件上线只是新的开始，需要收集用户反馈、进行监控和预警，并对整个版本的开发过程进行总结回顾。总的来说，本文强调了版本发布规划的重要性，以及如何通过合理的发布流程确保发布版本的正确性和稳定性。
《软件工程之美》，新⼈⾸单¥59
全部留言(11)
- 最新
- 精选
beiler老师，我想问个问题啊，比如我冻结了代码，但是测试测试出来了二十个bug，那回归测试是二十个bug修完了一起测试还是修一个测一个？最后再整体测试？作者回复: 好问题！ 冻结了代码后测试出来的Bug，首先要分级，不会20个都需要在当前版本修复的，有一部分影响不大的可以放到下一个版本修复。 然后剩下的这些Bug，什么时候测试取决于两个条件：1. 你什么时候部署测试环境，只有部署了才能测试；2. 测试自己的测试节奏，比如他们每天测试上一天的bug。 回归测试一般不会测试完一个就做一遍，但也不需要全部修复了才做，都是这一批测试完了再做一次，比如说今天测试完昨天所有修复的Bug后，会再做一遍回归测试，看有没有造成新的Bug。
2019-06-028
熊猫多个项目发版时，要注意依赖，莫慌，匆匆忙忙很容易出现问题作者回复: 👍依赖关系这个也很重要 如果自动化更新，应该能很好的改善这个问题，可以按照设定好的顺序去部署更新。
2019-05-217
yellowcloud宝玉老师，您好，我们目前有一个项目是做实时数据采集的，对方将实时数据推送给我们，基本上每天每个时刻都可能有数据推送过来。这样就导致一个问题，我们部署新的版本时，他们的数据还在推送，这样就不可避免地丢失了部署过程中的数据，对方也没有重新推送的机制。请问下宝玉老师，这种问题有没有比较好的解决方案，以解决更新版本时数据丢失的问题。作者回复: 这个问题其实不复杂，你可以将服务分拆，独立出来一个专门接受数据的服务，这个服务极其简单，只做一件事：接收数据，并存储到数据库或消息队列。 你原有的服务，改从数据库或者消息队列读取即可。 更新部署的时候，接受数据的服务就不要轻易更新了，这样就不担心会丢数据了。真要更新，只要和对方协商一下，暂停推送就好了。 -- @熊欲轻飞: 这种建议还是做个返回确认的机制，推送方对得到确认的数据做标记，没有得到确认的加入队列后续再推。
2019-05-216
Charles我们目前人工管理版本很容易乱，看了文章才知道最后一位是构建版本并且是自动生成的，之前也没深究，豁然开朗，看来很多表面上看起来很简单的东西深究都是学问，谢谢！ 另外问宝玉老师一个团队管理问题，如果是瀑布流带点敏捷部分实践的开发方式，总觉得UI这个岗位工作量不怎么饱和，一个版本过来特别是小版本迭代，周期可能是两周，UI可能1天就搞定了，其它岗位都差不多都要全程跟下来，这个问题出现在哪里？作者回复: 这个问题有点不好回答，毕竟对你项目情况不够了解。 我觉得呢，如果UI这个岗位对你的团队来说是必须的，并且UI设计师很好的完成了他/她的工作，那么就很好，没有任何问题。毕竟有的人效率就是比较高，好过故意磨洋工看起来很忙。 如果UI这个岗位是可有可无，那么就可以考虑不设置这岗位，将工作外包出去，或者尽可能用一些标准的UI，或者让前端工程师兼职UI设计工作。
2019-05-224
纯洁的憎恶版本规划： 1.规划好要发布功能。必要的先发，锦上添花的后发。根据用户的质量容忍度，划分质量标准，明确哪些功能质量必须一步到位，哪些可以慢慢来。 2.设计好发布策略。对内发布还是对外发布，beta版还是正式版，是否用灰度测试，管理好用户预期。 3.制定综合性发布计划。协调项目团队、客户、运营等多方利益确定发布时间进度。 科学规范的发布流程： 1.代码冻结。禁止修改即将发布到主干的程序，以避免出现不可控的新bug。 2.bug分级。冻结程序中的bug做到心中有数，但对于极其严重的bug仍要在发布前修正，修复后要生成新的候选版本号以示区分。 3.回归测试。最终候选版本发布生产环境前，对主流程和已知bug测试，确保无误。 4.上线申请、审批与部署。 5.上线测试。第一时间发现问题，如有必要立刻回滚，切忌急于打补丁。作者回复: 👍感谢分享补充！
2019-05-253
小老鼠一个产品的客户有许多，客户的环境各不相同，如何保证产品质量？(比如A电信企业生产的DNS服务器，在X产商集成的是B电信企业的DHCP服务器，在Y产商集成的是C电信企业的DHCP服务器⋯。)作者回复: 我觉得对于你说的这种情况要保证产品质量，需要抓两头： 一头是在做需求分析和设计的时候，充分考虑到各种环境的差异； 另一头是在测试和验收的时候，要充分对哥哥环境进行测试。
2019-10-072- calvins2 b和2 c在版本上线差距真大，从文章来看，我们大部分的发版还是不够严谨。没有beta版，没有灰度，经常紧急修复，版本管理工具缺失，好多问题。不知道这么方面老师有没有好的方法或建议？
作者回复: 版本发布要做到稳定可靠，需要注意做到几点： 1. 自动化测试不可少，只依赖人工测试是不够和不可靠的，要想系统稳定，一定要写足够的自动化测试代码，覆盖主要的用户使用场景。借助持续集成CI/CD工具每次代码合并分支，每次部署之前都跑一次自动化测试，跑不过就要分析原因，修复为止。 2. 测试要充分，在正式部署到生产环境之前，在测试环境要运行一段时间，发现问题提交到Bug跟踪系统跟踪起来，根据优先级修复，通过测试后再部署生产环境。 3. 版本管理工具要用好，把测试版本和开发版本要分开，开发中的版本是不稳定的，如果一边开发新功能还一边修复bug，很难稳定下来。所以最好是要有两个分支，一个是开发新功能的，一个是已经开发好测试中的，部署后再合并一起，新版本完成了再创建新的测试分支。 4. 发布和回滚都实现自动化，一方面提升部署和回滚效率，另一方面可以减少人工导致的错误。 5. 一些新功能可能会导致系统不稳定，最好让模块尽可能独立，加上开关，让一小部分用户先使用，逐步放开，如果出现故障，通过开关控制关闭，这样不必回滚。 6. 用好ELK、Splunk这样的日志收集分析系统，把关键信息记录起来，当发现问题的时候，可以借助日志快速定位到问题，即使问题还没发生，定期对日志信息进行分析，也可以对潜在问题提前发现。
2020-04-081 
E老师，我看您讲的大多数是针对2C，针对2B的有什么好的提议吗？作者回复: 我个人对于2B确实没啥经验，所以讲得少。 2B的项目相对来说，迭代周期要长一些，对界面和用户体验要求低一些，更多是来源于客户需求，更难控制需求。 针对这些特点，要多花功夫在需求的管理和控制上，在开发上可以选择迭代模型或敏捷开发，优先实现已经确定的和核心的需求，勤和客户沟通。
2019-08-281
javaadu这篇文章来得正好，很有收获，今天要组织项目的发布评审，昨天我在文档里主要梳理了几个点：本次发布的变更点；与前端的合作；自己内部应用的依赖关系；db变更；配置变更等等。 读了这篇文章，感觉自己需要改进几个点 第一，跟产品确认本次的功能点和标准 第二，不同应用的发布记录和灰度计划 第三，发布上线后健康状态的监控（这块我已经做了个降级开关，不过需要提出来，把信息同步出去） 另外，今年跟着老师的专栏学习下来，感觉自己的项目管理能力有不小的提升，表现在工作中就是试用期就开始做技术pm了，感谢老师🙏作者回复: 👍赞，能学以致用最好！ 也谢谢你的支持
2019-05-241- Geek_Zeal大型项目程序配置管理演化之路，这篇链接失效了呢老师2023-11-01归属地：重庆
