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