与几乎所有已经编程了一段时间的人一样，我对“生产代码”这个术语很熟悉，并且对它的含义有一个模糊的理解。但是，有人可以提供一个半严格的定义吗，因为维基百科和谷歌似乎不能？似乎在生产中存在很多灰色区域，例如一小群人使用的内部工具，因此在 UI、文档等方面没有“正式化”，以及开源应用程序是功能完整、无缺陷且工作正常，但缺乏润色、UI 和广泛的测试。
【问题讨论】：
标签： definition semantics production
当您的代码在生产系统上运行时，这意味着目标受众正在实际情况中使用它。
但是，生产代码并不一定意味着健壮、可靠或稳定的代码。 The Daily WTF 在这方面提供了大量证据。
【讨论】：
生产意味着您需要可靠、一致地工作。
是构建脚本还是面向公众的 Web 服务器。
当其他人依赖您的代码时，尤其是可能不理解它的人（即即使是“聪明”的开发人员，但可能不在您的团队中，但使用您编写的库），该代码就是生产代码。
这是生产，因为生产代码失败时“工作停止”和“金钱损失”。
【讨论】：
据我了解，生产代码是在实时、非测试平台系统上安装或使用的任何代码。如果公司内部使用的服务器是公司员工使用的实时系统，那么它就是生产系统。这里的重点是，在编写代码的公司内部服务器上运行的代码可以是生产代码。
通常，在查看内部代码时，一个很好的区别是维护代码的组是否与使用代码的组分开。如果这些组是分开的，则代码很可能是生产代码。如果运营业务依赖于代码，那么它肯定是生产代码，即使它是内部开发和维护的。
【讨论】：
编辑：简短的回答：如果您“将农场赌在上面”，那就是 “生产”。
这是一个很好的问题——一个绝对关键的区别，经常因为误解而让每个人都陷入困境。什么是“生产”的问题是什么是“环境”的相关问题的一个子集。
所以部分答案是“生产”是最重要的“环境” 重要且最受信任的是“真实”的东西。
所以现在我们必须定义“环境”（然后重新访问“生产”）。 我们离满意的答案还很远。
我们程序员经常使用术语“环境”来指代由执行软件的硬件组成的计算机系统。该软件是我们编写的代码以及它所依赖的软件，这些软件是由其他人编写的。我们编写代码并将其与其他软件集成，然后我们通常通过一系列升级的测试（单元测试、集成测试、功能测试、验收测试、回归测试等）运行集成软件，直到我们最终运行以预期的完整方式集成软件。
当然，并非一切都是完全自动化的。通常有很多人参与，他们有手动流程要执行。我们程序员寻找使这些过程尽可能多的自动化的方法，但在我们工作的系统中总是存在“人/机边界”。通常，在任何特定情况下都有许多这样的界限。
另一方面，可能根本没有任何显着的自动化。例如，当我们有一个房间里满是从事体力劳动的人生产产品时，我们谈到了“生产”。因此，我们的“生产”“环境”中不必存在任何自动化。还有一个中间地带，其中涉及的自动化不包括软件，例如在一个人运行织布机织布的情况下。
此外，可能没有产品，因为我们已经调整了我们的“生产”“环境”语言以包括产品-更少的服务提供商。
同样，测试可能不涉及软件，因为我们可能正在测试非软件驱动的机器（例如织布机）甚至人员（培训和评估）。
现在我们已经触及了“环境”的所有关键要素：
intent，正在追求intent 需要有意向者，因此必须有 sponsor（个人或
组，但不是机器）指定 intent
intent 是通过各种 processes 执行的
各种actors
actors 可能是人，他们可能是在硬件上执行的软件，或者他们
可能是非软件驱动的机器，因此可能存在也可能不存在自动化现在我们可以正确、完整地定义我们原来的术语了。
environment由所有processes及其actors组成 代表其sponsor合作追求特定的intent。那 是指在硬件上执行的软件，即非软件驱动的机器，以及 指履行各种职责的人。主要是intent定义一个environment，而不是它的processes或它的actors。
还有……
如果在特定的
environment中被追求的intent是sponsor's最终目标，通常涉及生成product或 提供一个service来换取钱，那么我们指的是environment为production。
现在我们可以更进一步了。
如果
environment中的intent是验证processes和他们的actors为production做准备，我们致电testenvironment。如果该测试涉及
processes的重要个人或团体的初始联合和 他们的actors。如果该准备工作涉及人类
actors的“编程”以执行新的processes，或者后续的验证（evaluation），那么我们称之为atrainingenvironment。
有了这些区别和定义，我们现在可以理解几种常见的场景了。
environment 可能被错误标记为与其 intent 不匹配的名称，例如 training环境被用作test。
environment 可能会被严重滥用，例如当 integration 或 training 在 @ 中完成时987654367@.
environment 可能会被误传，例如当密钥 processes 或 actors 未识别时（例如，手动和解，甚至完全无视人民）。
environment 可以重新分配任务，方法是将其 processes 和 actors 重新用于新的 @987654374 @。对于一些组织来说，一个非常成功的技术是在 production、testactors（服务器托管软件） /strong>、training 和 integration 每次发布。
在大多数情况下，单个actor（人或硬件）可以执行多个processes，可以参与多个environments强>。例如，单个计算机服务器可以托管执行 production 事务的软件，同时还可以托管执行 test 或 training 的其他软件> 功能。
通常，actor 的单个实例一次只能参与一个 environment。在极少数情况下，如果 intents 相互兼容，则单个 actor 可以在 environments 之间共享。大多数时候，尝试这样的共享是非常不明智的，因为 intents 并不真正兼容。一个完美的例子是在同样支持 production processes 的服务器上运行 test process strong>，导致停机，因为 test 导致整个服务器出现故障。
因此，environment 的 intent 必须具有非常宽的范围，以包含 可用性 等概念， 可靠性、性能、灾难恢复、准确度、精度、可重复性、longevity 等。这意味着 actors 和 processes 通常必须被解释为包含类似 提供电源、冷却、备份和冗余。
最后，请注意，情况可能会变得相当复杂。例如，开发团队 (sponsor) 可能会委托台式计算机 (actor) 托管其源代码控制 (process)，团队依靠它来完成他们的主要工作 (production)。尽管如此，IT 人员仍将同一台台式计算机视为开发人员工作站（development，而不是 production），并在开发硬件问题。但是开发人员正在生成 production 代码，那么他们不也是 production 的一部分吗？观点很重要。
编辑：生产质量
可靠的验证 (testing) 方法应该从 development 获取打包代码并通过一系列 tests 运行它> （集成、TQA、功能、回归、接受等），直到它出现在另一方“标记”以供 production 使用。然而，这使得包 production 质量，但实际上不是 production。只有在 sponsor 实际将包部署到具有 @ 终极级别的 environment 中时，该包才会变为 production 987654418@.
但是，如果您的组织仅生产该软件包（其 product）供其他人使用，那么这样的发布与 production 一样接近该组织将体验到 product，因此通常将术语 production 延伸到应用而不是澄清它是 @987654423 @ 质量。实际上，该组织的 production 环境由参与其开发/发布工作的 actors 和 processes 组成，从而导致product。
我说它可能会变得相当复杂......
【讨论】：
目标用户群将使用的任何代码都符合我对“生产代码”的定义。
当然，该定义中的灰色区域将明确定义您的用户群是谁。
G-Man
【讨论】：
【讨论】：
我认为描述它的最佳方式是“引导”部署和“后续”部署的任何代码。部署本身被定义为使软件系统可供使用的所有活动。如果您的代码可供人们在内部或其他地方使用，那么它就是生产代码。
【讨论】：
简单地说“目标受众正在使用的生产代码”
【讨论】：
术语“生产代码”混合了两个不同的概念。一个是部署管理，一个是release life cycle。
从严格意义上讲，当系统被用作业务或服务操作的一部分时，它就处于生产状态。生产中没有的是开发、测试、QA、演示和登台系统。生产系统并不直接意味着质量。
从发布生命周期的角度来看，“生产”构建是发布给公众或客户的构建。它是 pre-alpha、alpha、beta（功能完整、代码完整等）和候选发布之后的阶段。对于无法轻松部署更新的收缩包装产品，进入生产阶段可能意味着需要进行一系列测试和错误修复。
【讨论】：