何时更新Release Notes/Changelogs？Azure DevOps自动化场景疑问

这类场景大多和团队的发布流程、合规要求或业务实际需求挂钩，常见的情况包括：

• 灰度/分批发布的团队：如果用逐步放量的方式上线，只有等所有批次部署完成、确认没有回滚或调整时，才会生成最终的变更日志。毕竟中间要是因为问题撤回了部分变更，提前写的文档就和实际生效内容对不上了。
• 有严格合规要求的行业：像金融、医疗这类领域，往往要求变更必须在生产环境验证生效后，才能正式记录到变更文档里，确保日志完全反映实际落地的内容，不能出现“记录了但没上线”的情况。
• 绑定生产发布事件的流水线配置：很多团队会把变更日志生成环节，直接绑定到Azure DevOps Release Pipeline的「生产部署成功」阶段上——等生产环境部署完成触发这个阶段后，再用conventional-changelog这类工具从Git历史里提取符合约定式提交规范的记录，生成最终的变更日志或发布说明。
• 规避回滚导致的日志不一致：PR合并、CI完成后到生产上线前，可能因为预发环境发现问题而回滚变更，这时候提前生成的日志就失效了。等生产上线后再生成，能保证日志和实际生产的内容100%匹配。

在Azure DevOps里实现这个流程也很简单：

1. 在Release Pipeline的生产部署成功阶段，添加一个脚本任务，调用conventional-changelog工具提取符合规范的提交记录。
2. 把生成的内容更新到项目的变更日志文件，或者同步到Azure DevOps的Release Notes板块。
3. 还可以结合Azure DevOps的工作项跟踪，只把关联到已完成生产部署工作项的提交纳入日志，进一步提升准确性。

内容的提问来源于stack exchange，提问作者David Coxsey