问题描述
继承了一个使用本地/暂存/生产环境的项目。这是一个简单的项目，允许用户创建登录并下载定制的PDF文档。我们将文档模板和每个用户的定制保存在S3中。但是，用户听说githubflow允许在合并PR到主分支后直接部署到生产环境。该项目包括一个React前端和一个Django后端。后端托管在AWS上，并通过Kubernetes进行管理。AWS上还有一个数据库和S3存储桶。由于基础设施从未完成，用户正在自动化部署到暂存/生产环境，并想知道自己是否过时了。用户认为，如果部署到生产环境时自动备份数据库和S3，这可能会提供更快/更高效的工作流程。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
当你说”行业标准”时，这很大程度上取决于所在的行业。你可以以任何你想要的方式将代码放入生产环境（法律限制的行业显然是例外），但你应该考虑的问题可能是你是否应该这样做。最近，我参与了一些产品的开发，这些产品的测试覆盖率非常高，设置了大量的基础设施来执行针对任何存在的集成点的每个可想象的回归测试。尽管在那个特定的产品中，这不是常规做法，但在通过所有必需的自动化测试后，我可能会很放心地直接发布到生产环境。另一方面，我也参与了一些项目的开发，可以说这些项目是在生产环境中开发的，因为生产实例与实际检入源代码或运行在任何测试环境中的代码非常不同，当然，没有测试用例。使生产部署尽可能安全的标准方法是尽量确保你计划部署的内容经过了严格的测试，并且大部分测试都需要自动化，否则你将花费大量时间进行测试。此外，大多数现代系统使用标准模式使生产回滚成为一项极其简单的任务，如果不是完全自动化的话。如果你正在部署软件的金丝雀版本，或者你正在运行蓝/绿部署，并且可以内置机制以在不满足某些成功条件的情况下回滚，那么它进一步降低了生产更改破坏某些东西的风险。基本上，我会质疑任何告诉你如何管理和降低生产发布风险的人，除非他们对软件和你一样熟悉。
方案2
在软件行业中，拥有暂存环境是很常见的，但要理解为什么需要这些环境，就需要了解这些环境存在的原因。生产环境是公司的软件与公司的用户相遇的地方。大多数公司希望用户满意，并获得符合他们期望的高质量软件。另一方面，开发环境是开发人员创建软件的地方。在大多数情况下，刚创建的软件质量远非良好。即使是优秀的开发人员也会偶尔犯错误，他们需要一些安全网来捕捉这些问题，以便修复它们。提高软件质量是一个迭代的过程。开发人员的任务是不断创建更多的变更，这是他们的工作。这些变更需要变得高质量，唯一的方法就是在某个地方测试这些变更，直到所有问题都被解决。这就是QA、暂存和用户验收环境的作用。这些环境是软件在面向客户之前进行检查和捕捉问题的地方。上述所有内容描述了为什么拥有多个环境可以降低生产环境中出现糟糕代码的风险，同时允许开发人员有一个可以安全犯错和修复错误的地方。许多公司还有其他规定，使得拥有多个环境变得实际可行。例如，有一个传统，在特定日期发布软件供所有人使用，就像苹果一样。在此发布之前，他们仍然有测试人员和其他测试，这可以被视为暂存或用户验收环境。在一些受到严格监管的行业中，对”生产环境”有访问权限的人员受到限制。在许多情况下，只有指定的人员被允许触碰这些环境，因为涉及到安全和法律问题。在这样的公司中，还有数百名其他开发人员没有被指定，他们需要一个集成和测试他们的代码的地方，暂存环境对于谁可以更改环境的事项要求不那么严格。