user-acceptance-testing - 代码提升 : Enforcing the rules

Question

所以这是我们的问题:

我们有一个由他们自己的做事方式的开发人员组成的小团队——我正在尝试制定一个流程，在该流程中我们需要按以下顺序推广我们的代码:

本地沙箱 > Dev > UAT > Staging > Live

开发人员在他们自己的沙箱上进行开发/测试，Dev 是自己的沙箱，我们将用于持续集成，UAT 是开发箱上 IIS 中的另一个站点，它使用我们的开发数据库。然后我们升级到登台，这是一个位于 Live 框上的 IIS 中的站点并使用实时数据(就像实时一样，因此是登台)。然后，最后，我们促进生活。

以下是我的一些问题:

1.) 这似乎是最佳实践吗？如果没有，需要采取哪些不同的措施？

2.) 我如何向开发人员执行规则？开发人员通常会跳过步骤以节省时间……这不应该被容忍，如果可以实际执行，那就太好了。

3.) 我如何对业务组执行这些规则？业务组只想快速推出功能。我们是否只在特定日期进行促销？

Answer 1

听起来对我来说是一个很好的设置......我们没有我工作的区域。我们有 DEV > QA > Production。

1)我不确定什么是“最佳实践”，但您的设置对我来说似乎是一个很好的实践。我唯一关心的是在沙盒环境中。是否保证每天备份开发人员的代码？以防万一他们的机器严重崩溃？我不想丢失好的开发代码。

2) 我们在这里有一个“发布协调员”，他强制访问 Sourcesafe 和 TFS，并控制对 QA 环境的访问，因此只有特定时间可用。

3) 业务测试人员也是如此，只是他们的权限来自项目经理。 PM 有一份文档，每个项目都会填写并指定测试团队。

我们只在某些日子(每隔一个星期四)进行促销。但是，我们确实理解可能会出现紧急情况，并且我们会在需要时在休息日进行生产发布，但是这些紧急情况会在事后记录下来并进行分析，以查看哪里出了问题以及我们可以在哪里进行改进。

我想说只要您的环境受到控制和记录，您就应该没问题。最好确保沙盒区域中的所有内容都得到备份，并且由一小群人控制对其他环境的访问。我还建议您保留有关“安全”环境来来往往的良好文档，以防万一出现问题，您可以回溯日志并查看可能发生的情况或可能是谁做的，不一定要指责但要回过头来说“你到底上传/更改了什么？”所以我们可以看到可能导致问题的原因。

祝你好运，