本地/分期/生产是否仍然是行业标准？

Question

我继承了一个使用本地/分阶段/生产的项目。

这是一个简单的项目，让用户创建一个登录和下载定制的PDF文档。我们在S3中保留文档模板和每个用户的自定义。

但我听说githubflow允许直接deploy-to-production--upon--merge-PR-to-master.

该项目包括一个反应前端和一个Django后端。后端托管在AWS上，并通过Kubernetes进行管理。在AWS上还有一个数据库和S3 bin。

基础设施从来没有完成过，所以我正在自动化部署到{分阶段/生产}，并想知道我是不是一个恐龙。

我的想法是，如果部署到生产自动备份数据库和S3，这可以提供一个更快/更高效的工作流。

Answer 1

当你说“行业标准”时，那将很大程度上取决于哪个行业。

您可以随意将代码放入生产中(法律上受限制的行业显然是对此的豁免)，但您可能应该检查的问题是，您是否应该这样做。

我最近开发了一些产品，从拥有难以置信的测试覆盖范围，建立了大量的基础设施来针对任何存在的集成点执行所有可以想象的回归测试，尽管这不是针对特定产品所做的事情，但在通过了分支机构可合并所需的所有自动化测试之后，我可能会很乐意直接投入生产。另一方面，我还参与了一些项目，这些项目可以说是在生产中开发的，因为生产实例与实际签入到源代码控制或在任何测试环境中运行的内容非常不同，当然，也没有任何测试用例可以看到。

使生产部署尽可能安全的标准方法是尝试并确保您计划部署的东西是尽可能严格的测试，并且完成大部分测试将需要自动化，否则您将结束您的生命测试。

此外，大多数现代系统使用标准模式来使生产回滚一个外部无摩擦的任务，如果不是完全自动化的话。如果您正在部署软件的金丝雀，或者您正在运行蓝色/绿色部署，并且在某些成功条件不满足的情况下可以内置回滚机制，那么它将进一步降低生产更改破坏某些东西的风险。

本质上，我会质问任何告诉你如何管理和启动你的产品发行版的人，除非他们和你一样熟悉软件。

Answer 2

在软件行业中，拥有分阶段环境是很流行的，但是为了理解为什么首先要理解这些环境存在的原因是很重要的。

生产环境是公司软件满足公司用户的地方。大多数公司希望他们的用户满意，并获得高质量的软件，以满足他们的期望。

另一方面，开发环境是开发人员创建软件的地方。在大多数情况下，这个软件的质量在第一次创建是远远不好的。即使是伟大的开发人员也会时不时地犯错误，他们需要一些安全网来捕捉这些问题，这样他们才能解决这些问题。

提高软件质量是一个迭代过程。开发人员的任务是不断地创造越来越多的变化，这是他们的工作。这些变化需要成为高质量的，而唯一的方法是测试变化的某处，直到所有的皱纹被擦亮。这就是QA、暂存、用户接受环境出现的地方。在这些环境中，可以对软件进行检查，并在将软件提交给客户之前捕捉到任何问题。

上述所有内容都描述了如何使用多个环境来减少生产中出现不良代码的风险，同时允许开发人员能够安全地犯错误并修复这些错误。

许多公司都有更多的规则，使得拥有多个环境是可行的。例如，有一种在“特殊日期”发布软件的传统，每个人都可以像苹果一样使用。在这个版本发布之前，他们仍然有beta测试人员和其他测试--这可以被认为是一个分期或用户接受的环境。

在一些受严格管制的行业中，对谁能够进入“生产环境”有限制。在许多情况下，出于安全和法律考虑，只允许指定人员接触这些环境。在这样的公司中，有数以百计的其他开发人员没有被指定，他们需要在某个地方集成和测试他们的代码--对于谁可以在环境中更改内容，暂存环境没有那么严格。