各位大佬们所在部门或者公司的上线发布流程、checklist 是怎样的？有哪些规范？
zhuzhibin BinZhiZhu 2024-02-09 11:28:41 +08:00 2852 次点击这是一个创建于 618 天前的主题，其中的信息可能已经有所发展或是发生改变。
大佬们新年好~，如题，我们 team 目前的方式是走上线清单，例如 DB 工单、MQ 、配置中心（如有新增配置）、权限节点等等。
现状：发版的时候，发布人根据上线的需求执行上线清单（理论上需求发布到每个环境，都要严格执行上线清单），目前是仅生产环境，交给发布人去执行以及检查线清单，但是有时候需求太多了，或者有些小需求变更不大，总的来说没有严格执行上线清单的 checklist ，所以还是存在一些上线发布的风险。
年后想在内部重新制定一个上线发布规范，团队内严格执行，降低上线发布的风险，同时也制定一些惩罚追责制度，让开发者重视起来"上线需谨慎", 例如有些临时配置本次需求上线后，理论上要按期下线的，如果没按期影响到一些服务，那么同样追责。最终是希望这个规范是可以往其他部门推广（前提是内部执行完善且制度规范是成熟的），所以想调研一下老哥们所在部门、公司或者团队一般是怎样的呢？听听大家的分享，取取经，或者有一些好的文章推荐也可以哈
最后祝大家新年快乐~，新的一年嘎嘎猛，嘎嘎晋升，年终奖嘎嘎多
 | 1 zhuzhibin OP 滴滴 |
 | 2 Hurriance 2024-02-09 14:40:39 +08:00  1 要定期下线的配置可能设置一个提醒会好一些 人都是会犯错的，但是可以通过尽可能完善的流程来降低风险 我们之前的发布都是领导层层审批的，但依旧有一些是人难以察觉的错误，例如某些特殊字符被上线了，这些肉眼是很难看出的 不过我们好在，出了问题领导都是主动担责，不会责怪下面，反而鼓励大家，都是些小问题啦 否则，想用严格的追责制度来让开发重视上线，我能想到的是，开发反而不敢接一些需求，各种甩锅 |
 | 3 ccde8259 2024-02-09 19:25:25 +08:00 上线发布真正有用的不是说怎么样一个流程怎么一个 Checklist ，而是整个研发团队对于生产环境要有敬畏之心…… 与其推动团队严格执行 Checklist ，不如把配套的工具能力搭建起来，不依赖于人去执行这些繁琐的事情，而是通过自动化的流水线工具，保障发布流程过程中错误能被准确及时暴露出来…… |
| 4 zhuzhibin OP @ccde8259 感谢老哥回复，老哥你这个思路是没问题的，但是造轮子或者推自动化是有成本的，先搞个过渡方案…就如你说的，得先让大家重视起来 |
 | 6 lnnttoo 2024-02-09 21:17:48 +08:00 3 见过两种风格的 1.某一线大厂的。单元测试、代码评审、自动化测试全部没有，有各种核心依赖的 Checklist ，但 Checklist 本身很难强制或者全部自动化。起作用的主要是极其严厉的故障评级制度，跟个人和团队绩效强挂钩。因此形成了核心功能的变更发布极其小心的风格，同时也造成了几乎无人去重构已有代码的现象。大量凌晨发布，偶尔有大故障，故障之后搞各种流程，循环往复。 2.某小有名气的创业小团队。一个 PR 的发布从设计、单元测试、代码评审都需要 peer review ，发布的 checklist 需要开发的人自己来写，并在 PR 里说明。核心功能必须有较为完备的集成测试，代码合并之后的事情就只归发起 PR 的人来跟进。在发布前单元测试必须要跑过，发布之后会对生产环境自动跑集成测试。形成一个代码和质量是个人形象代表的氛围，大家都为自己的形象而对生产环境谨慎但不会过分小心。 经常有人主动重构或者删除无用代码。基本只选白天开始灰度发布，偶尔有小故障。 总结：使用一个严格、奖惩的流程或制度来限制研发人员，但是长期负面代价也会很明显；构建一种良好的氛围，善用团队和他人的力量（每个人都会犯错），让研发人员自觉为质量的好坏而努力，但是需要长期的沉淀。 |
 | 8 zgscwjm 2024-02-19 14:17:28 +08:00 make 有着同样的困惑.感觉靠制度来约束,很难.人都会犯错. |
Select Language