在一家拥有大约100名开发人员和2名笔试员的公司,正在开发一种产品.每天都有大量不同的代码通过github PR请求传入。
目标是在合并之前尽可能多地检查新代码。
在极端的一端,就像是‘在笔试器验证之前检查每一个PR,并且不允许合并’。很明显,这是非常耗费资源的。另一个极端是‘让所有的东西都通过,并在版本上对每个模块进行笔试’。
在这两个极端之间是否有任何有意义的公关覆盖策略?
注意:不要求将自动代码分析集成到构建管道中,目标是以一种有意义的方式对尽可能多的代码进行手动审计。此外,不要询问代码评审方法(例如识别某些类型错误的方法)。
发布于 2018-01-23 21:35:18
我建议列出一些类型的更改,这些更改需要测试人员在拉出请求时签署,例如:
这只是一个例子。您的专家应该能够为您的特定领域制定一个更好的列表。
此外,您还可以制定一项策略,使拉请求保持足够长的时间,以便笔试人员可以选择检查其他类型的更改(如果他们愿意的话)。我遵循一份波奥多罗时间表,所以我每隔半个小时就检查一次电子邮件。对于在那个时间框架内打开和合并的公关来说,有一些重要的事情要说,这是非常令人讨厌的。
https://softwareengineering.stackexchange.com/questions/364533
复制相似问题