见过两种风格的

1.某一线大厂的。单元测试、代码评审、自动化测试全部没有，有各种核心依赖的 Checklist ，但 Checklist 本身很难强制或者全部自动化。起作用的主要是极其严厉的故障评级制度，跟个人和团队绩效强挂钩。因此形成了核心功能的变更发布极其小心的风格，同时也造成了几乎无人去重构已有代码的现象。大量凌晨发布，偶尔有大故障，故障之后搞各种流程，循环往复。

2.某小有名气的创业小团队。一个 PR 的发布从设计、单元测试、代码评审都需要 peer review ，发布的 checklist 需要开发的人自己来写，并在 PR 里说明。核心功能必须有较为完备的集成测试，代码合并之后的事情就只归发起 PR 的人来跟进。在发布前单元测试必须要跑过，发布之后会对生产环境自动跑集成测试。形成一个代码和质量是个人形象代表的氛围，大家都为自己的形象而对生产环境谨慎但不会过分小心。 经常有人主动重构或者删除无用代码。基本只选白天开始灰度发布，偶尔有小故障。

总结：使用一个严格、奖惩的流程或制度来限制研发人员，但是长期负面代价也会很明显；构建一种良好的氛围，善用团队和他人的力量（每个人都会犯错），让研发人员自觉为质量的好坏而努力，但是需要长期的沉淀。