具有多个环境的简单原因

在我的整个职业生涯中，我曾在各种公司中工作，这些公司为不同的目的而收集了不同的环境。我们总是拥有或多或少的桌面环境，测试环境，QA环境，登台环境和生产环境。这适用于服务器/应用程序以及我们正在使用的任何数据源。

当我在现任公司任职时，我发现90％的应用程序要么在桌面环境中针对生产数据源开发，要么直接在生产服务器上开发，具体取决于平台。这并不特别令人惊讶，因为我被录用了一部分以进行更改以改善开发团队的运作方式，这在我的面试过程中很明显。我们逐渐开始转变理念，很快，大多数应用程序可以在台式机，测试或生产环境中运行。不久之后分阶段进行。

现在，我们的大多数开发人员都看到了这种方法的好处，并保持警惕。但是，我们有许多从未迁移过的旧版应用程序。我们也有许多传统程序员，他们认为这是浪费时间。不幸的是，我们得到了口头服务，但从未得到管理层的全力支持。大约一年前，我们得到了我们认为在此基础上进行大量投资的承诺，但是尽管我们进行了相当大的计划，但仍未实现。现在，我们发现我们需要越来越多的环境。我们需要服务器/网络管理团队的帮助来进行设置，并且需要业务利益相关者的参与以支持发布周期。我们现在处于一个项目可以正常运作的地方，合理的开发人员会考虑“正常”

我很想提出一个完整的论据，但是在出现关键问题之前，管理层真的没有时间和兴趣听我讲话。我无法简单地说明收益，因为对我而言，收益似乎总是天生的。我想知道是否存在分离环境的良好，简单，无可辩驳的理由，这会使管理人员缺乏开发经验来支持这一想法？。是否有关于该主题的良好资源/文献？

答案：钱

我不在乎实际原因是什么。金钱必须是您所有推理的基础，尤其是在与管理层打交道时。

如果我们都在一个房间里2小时坐着，我们可以拿出几十的原因，最好是有多个环境。

这就是问题所在：如果原因不是基于金钱的，那么它们都不重要。

程序员不是雇用聪明的人。他们没有被雇用来发挥创造力。他们被雇用来增加收入 -通过赚钱或存钱。如果您不选择其中任何一种，则最好将简历放在一起。

从这种角度来看，答案很简单：

只有一种环境会增加我们的停机时间，并导致收入损失。多种环境使我们能够通过为用户提供与我们公司一样可靠和可靠的前端来保护我们的利润。

每天重复一次。

以下是一些很棒的评论，这些评论为该答案增加了实际价值，因此我将提及它们：

• 卡尔·比勒费尔特（Karl Bielefeldt）提到成本/收益分析是一个重要因素时，他的观点很重要。经济学家可能将其称为追求多种环境的机会成本。尽管可能令人惊讶，但在某些情况下可能无法解决多种环境！如果您公司的网站只是很小的一部分，那么意外的停机实际上可能是更经济有效的经商方式。这听起来不像您所处的位置，但值得一提。

• BlairHippo有一个很好的观点，那就是您可以随意使它看起来像一场灾难（如果丢失数据，那就是！）。责任对于说服经理人来说是一个很好的工具，但出于同样的原因，诉讼也很昂贵。避免它们可以节省金钱。

作为附录，我发现本文相当不错。它并不能直接回答您的问题，但可以使您认识到如何将程序员视为管理人员，进而可以得出答案。好读。

单点故障

如果没有开发或暂存环境，则这些旧应用程序将具有单故障点。如果您用这些术语描述旧版应用程序，则管理层将听到您的声音。

您需要能够以对他们有意义的声音字节来宣传您的消息。从讨论中删除“ 程序员说话 ”，然后将其替换为“ 经理说话 ”。还要假装您有30秒钟的电梯行程，以方便您理解。

我曾遇到过老板是步兵海军陆战队的情况。我一直告诉他我需要为海军陆战队使用软件工具和计算机培训，以提高生产力。他不明白。我终于有一天走进他的办公室，告诉他事情已经发生了。

我说了些什么……“如果我打仗，我会用棍棒，石头和树枝。我需要的是手榴弹，火箭筒和机关枪。” 他收到了消息。

真的很关键吗？

我可以理解使用单独环境的愿望。不明显的问题是：

迁移遗留系统实际上至关重要吗？

我认为大多数具有技术头脑的人都倾向于关注学术问题，即哪种方法更好，哪一种在学术界是好的。尽管在业务上最好并不总是能取胜。我并不是说这是消极的，也不是发火焰。我要说的是显而易见的，或者对于已经从事软件业务几年的我们来说应该是显而易见的。

通常，所有业务决策都是基于感知的成本/收益。因此，企业可能要问的问题是：

与将相同的投资投入另一个项目/产品相比，对遗留应用程序的附加系统和开发投资的成本是否值得呢？

我已经并且仍在进行定期的成本效益分析，不仅要确定是否要迁移/重写软件，而且要在日常决策中做出决定，通常要由潜在客户来做。因此有价值。

分离环境

该业务的原因分开的环境。

• 降低发行和修复错误的风险。 用数字证明。由于不良的发布/错误，产品失败了多少次，并导致客户收益减少。
• 降低开发风险。 意外删除开发数据库与意外删除生产数据库不同
• 明确区分角色和访问权限的能力，即 更好的安全性。限制生产馅饼中的手指数量是一件好事
• 分离环境的能力以及这种开发风格所伴随的实践和过程允许将来将其构建到Cloud Systems中。
• 环境的分离应在复制环境中提高效率，这可能对计划以及动态缩放很有用。

听起来您已经有了所有“正确”的论点。相反，如果您愿意的话，您正在经历“红色鲱鱼”。或者，“追赶胡萝卜”

在出现严重问题之前，管理层真的没有时间和兴趣来听我讲话

我认为这就是真正的问题。以我的经验，如果一家公司的开发实践不如您描述的那么糟糕。这不仅仅是“我们没有更好的了解”的问题。相反，它是由不知道（在乎）问题的高级管理团队造成的技术债务汇总。

在这种情况下，良好的鼓舞士气不会突然改变您的方向。也许是严重的创伤（客户可以看到产品故障，并直接与不良做法联系在一起），但是我敢肯定，精明的技术人员会在尝试这种交谈之前。

我的建议是要么将其吸纳起来，然后按自己的意愿去做，要么寻找新的职位。

有多少人计划一次使用该应用程序？通常，我已经为每一个人看到了一个环境。这是开发人员（他们有一个DEV环境和一个DEV集成环境-有些人说不是100％必要，我会说它因项目而异），两个测试环境（一组测试人员进行非常详细的测试，另一个用于高级质量检查测试人员-通常是实际的业务用户，而不是经过培训的测试人员）。通常还存在一个隔离的性能测试环境（因此您可以测试大量数据，模拟大量用户，等等... g）。

为什么是所有这些环境？因此，不同的小组可以测试不同的功能，而无需踩踏彼此的脚趾。如果开发人员和测试人员在同一环境中工作，那将是一场噩梦：测试人员可以打开开发人员每分钟都会对其进行主动更改的功能的缺陷。如果有两个测试级别，则他们可以专注于不同的活动，而不必担心会弄乱彼此的数据。具有隔离的性能环境使您可以运行可能会使计算机挂起的测试，但是如果隔离，则不会影响其他测试人员。

当太多的人试图在同一环境中做太多不同的事情时，您将浪费大量时间，因为一个团队等待另一组的测试完成，以便他们可以运行他们的测试。这就浪费了时间，浪费的时间会导致金钱的浪费，Stargazer712指出，这种方法最有力。

另一个原因（不是很常见）是数据：如果您的应用程序具有敏感的个人数据或信用卡数据，则通常无法将其放入测试环境中，并且对质量检查和生产环境以外的所有内容通常都具有屏蔽要求。

您似乎付出了巨大的努力来实现工作场所的文化变革。这是一项伟大的成就，因为变革在最佳时机很难，但是文化变革不仅涉及改变人们的思想，还涉及改变习惯，打破偏见，并最终使可能封闭的思想开放给更大的可能性。因此，此时要问自己的问题是“我想念什么？”。一个简单的答案是您可能没有完全参与管理。

从管理层那里买进是容易的，但更难获得接受。无论关于金钱等的争论如何，现实都是您需要能够影响管理层对优先权的看法。您的经理将有一个预算，并希望证明预算已被合理地应用，并且与公司的价值观和优先事项保持一致。这些优先事项中的一些将是财政上的优先事项，而其他一些将是为满足其他需求。在某些情况下，这可能意味着增加其他经理的手掌，以得到老板一直想要的晋升。但是，在大多数情况下，这可能与寻找方法来获得更多业务或改善与合作伙伴和客户的关系有关。如果您不能以这些方式陈述您的观点，那么您只能走得那么远，直到陷入僵局。

我的建议是，像其他人所建议的那样，尝试对生产率及其对预算的影响进行论证，同时就公司的优先事项以及生产率如何直接影响公司与其他公司的关系来论证。

这是一个：可测试性。

拥有测试环境使您可以自由地对数据库进行测试，而这在生产环境中是不可取的。

您要更改组织开发软件的方式吗？不用担心“以不同的方式做事”的“原因”。人类不会因为理性的争论而改变行为。他们由于心理习惯的改变而改变。

那么，我要去哪里呢？

尽管有时您可以通过辩论成功地改变组织的行为，但还有其他一些效果更好的策略。这些包括：

• 基层支持：寻找另一个愿意为您提供帮助的“传统”开发人员。与他成为伙伴，改变事物的运作方式。不要宣布更改。只需进行更改即可。如果有人问过您，请说“哦，是的，我们现在就是这样做的。”

• 承担责任。自愿处理遗留人员的部署。表现得像你喜欢它。他们可能很乐意放弃这一责任。然后以您想要的方式运行它。

• 责怪正确的人为自己的错误。下次由于您的石器时代部署机制而将遗留应用程序错误引入生产时，请指出。巧妙地做...不在电子邮件中。下次您与经理开会时，只需随便提一下部署存在问题的原因示例。“是的，还记得我们上周五是因为Bob投入生产的Foo bug导致的吗？是的，这是很多浪费的工作！”

• 轻松实现更好的方法。例如，看看iphone。上面有一个按钮。（嗯，两个）。很容易打开。使部署到多个环境的疯狂愚蠢变得容易。让所有管理人员都能轻松做到！

当您开始处理互连系统或旧系统时，这更成问题，这是业务赖以运作且准确的系统。这很重要，因为各个阶段之间需要隔离，这是您不对PROD进行开发的原因，因为它有可能在丢失的时间中造成数百万美元的损失。

我们总是执行DEV-> QA-> PROD（有时将这些步骤分解为较小的部分），并在其后添加相同的硬件。当前生产数据总是从PROD推送到QA到DEV。

DEV：旨在用作开发沙箱，在此环境中，任何数据都必须经过尝试，迭代和殴打，因此永远不应该被其信任，并且开发人员通常会在寻找解决问题的方法时经常将其丢弃。

QA：一旦您的开发人员对单元测试感到满意，测试小组就该开始关注它了。他们运行测试用例，性能测试并查找错误。这些错误/约定会反馈给DEV，并且该循环一直持续到大家满意为止。

PROD：一旦进入这一阶段，您应该确保代码可以与当前数据结合使用，并且您的QA小组/业务用户对该实施感到满意。如果您正确地完成了所有操作，则只需更新代码即可完成。

以同样的方式，您永远不会向客户发布未经测试的产品，也永远不要向生产环境发布未经测试的代码。

如果公司不愿意花时间进行正确的处理，他们将偿还紧急维护和错误的成本的10倍。

举一个小例子：我们有一家公司决定自己更改生产报告。直到我们一两年前解决各种各样的问题，没人知道它会改变。

当我们指出报告中的违规行为时，CFO的脸变得白了，结果是由于有人快速做出改变，他们每季度损失约25万美元。

发生的次数比您想的要多，如果您负担不起正确做的事，那就不要做。

在产生这些环境所需的软件公司和软件产品的成功背后，管理层起着很大的作用。让我们以您的项目为例。如果您的软件是大规模开发的，那么如果您无法管理项目要求，过程控制，测试构建等，那么这很可能会失败。以便存在项目管理。

我在某种程度上同意@ Stargazer712的观点，即您的声明指向金钱问题，但是请检查以下声明，该声明是我从马克·汉密尔顿（Marc Hamilton）关于软件开发的书中获得的：构建可靠的系统（Prentice Hall PTR，1999，ISBN 0-13-081246- 3）。看完所有这些因素后；我对您的问题的看法是，“单一环境”并不能节省您的费用，它将使您长期完成项目/软件。正如我从经验中学到的那样，分布式环境将节省时间和收入，我从中开始运营的新兴软件公司所发生的事情。

有很多文章表明成功与成功息息相关，请查看此文章组织成功的软件开发

组织中的每个人都有一定的技能，通常根据正式或非正式的绩效指标来衡量这些技能，从而获得奖励（补偿）作为对未来绩效的激励。组织中的人员建立了自己的文化-这些行为模式和价值观通常被公认是被采用的。

如果一大批软件开发人员不得不花所有的时间与不适当的组织结构进行斗争，他们将奋斗并最终无法实现他们的目标。

许多软件初创公司的诞生之初，只有几个开发人员在车库里工作。在公司的历史记录中，此时不需要太多的组织结构，但是组织结构仍然存在。例如，在1977年，比尔·盖茨（Bill Gates）和保罗·艾伦（Paul Allen）建立合作伙伴关系并正式将其命名为Microsoft时，该公司的组织结构很小。在新墨西哥州阿尔伯克基市微软第一家办公室工作的员工不到12名，每个人都知道谁负责。无需复杂的组织结构图即可确定每个人的报告结构。同时，所有员工都知道他们在公司中的角色以及他们想要实现的目标。这是因为可以在每个员工之间非正式地交流所需的任何组织结构。

忘记时间，金钱，可测试性，质量... 声誉如何。

分离环境的好，简单，无可辩驳的理由会使管理人员缺乏支持这一想法的开发经验。

Uber最近将代码发送到github，其中包含其实时环境的密码，从而允许“黑客”下载其所有客户详细信息。Uber说这是一个违规行为，其他所有人则说：“不要将锁的密钥公开显示。如果他们的开发人员完全在开发环境中工作，他们可能已经在github上发布了其开发环境的密钥，但这完全是生产版本的发布表明了在生产环境上执行开发的想法多么糟糕。

只是提醒您的经理，错误是会发生的，因此要避免将他拖到将要在记者面前大肆抨击的CEO并被科技界人士嘲笑的方式，是采取简单，明显的步骤来防止这些错误带来灾难性后果那些。

听起来好像您必须在许多不同的环境中工作，并且花费大量时间来设置“环境”。

您应该拥有最少的“环境”数量，但是您可以出于您和公司期望的多种原因克隆许多副本（使用“环境表示系统配置”）！

最佳地，唯一的区别应该是：

1. 大小（最小，推荐，最大支持/测试）；
2. 暂存和生产没有开发工具
3. 生产受到保护，防止意外覆盖数据
4. 您可以非常轻松地将演示，测试或[阳极化的]客户端数据加载到开发或登台服务器上

然后，应进行多少测试和哪种测试的问题是风险/成本业务评估，并在公司级别上决定，因为如果将严重的错误传给一系列客户，则整个企业都会遭受损失。

以后的编辑：这促使我将 Web产品的命名约定合理化（感谢您提出问题）。我已经决定了四个“环境”，将测试分为qa（仅用于测试功能的最小单层）和暂存（用于负载/性能/容量测试的与生产相同的体系结构）之间的测试。

调配中唯一真正的区别是生产/分阶段将数据库安装到单独的系统中，由我控制不同服务器所在的组。qa / dev同时具有Web服务器和数据库角色。负载平衡由cloudflare完成。

我还有一个ENV_NO变量，该变量被传递到系统上，因此我可以选择选择尽可能多的“ qa”或“ staging”示例。

因此，要设置第二个qa环境（包括我最新的实时备份），命令将是：

git checkout desired-branch/commit for provisioning
ENV_NO=2 bin/provision create qa
# come back after a short lunch

git checkout desired-branch/commit
ENV_NO=2 bin/cap qa deploy
# a minute or two

ENV_NO=2 bin/cap qa db:upload db:restore
# longer than I want once there is a decade of data ("longer" coffee break to traverse a 5.3km ADSL link)

最后，在落地之前，我还有一个名为“只读”的额外（可选）服务器，作为最后的安全网。它的配置类似于qa系统，但禁用了昨晚的备份和更新（该软件也已更新为昨晚）。

它使用“所有鸡蛋都放在不同的篮子中”的方法：它配备有不同的位置/ DNS注册商，DNS主机，系统主机服务提供商。这是终极/最后的安全网，因此，如果一切如火如荼，您至少可以获取到昨晚的数据。设置脚本隔离了不同提供程序之间的差异，因此99％相同，只是readonly标志。如果所有活动服务器都发生故障，Cloudflare负载平衡器会将流量重定向到只读站点。

进行更改时，您会很幸运的拥有一个只会听取您的专业意见并实施建议的更改的人。

根据我的经验，每次必须进行重大更改时，我都必须根据业务节省下来的理由对其进行论证。例如，将ReSharper引入开发管道非常容易，因为我可以在离线时说些什么：

ReSharper每位开发人员的费用约为50英镑。每年平均开发人员成本为4万英镑。充分利用ReSharper的全部潜力，ReSharper应该将开发人员的生产率提高至少20％。假设开发人员花了75％的时间在IDE中实际编写代码。4万的75％为3万英镑。现在，开发人员的生产力成本为3万英镑。每年额外的百分之一的生产力（1％）花费£300。为了获得额外的20％的生产力，企业必须花费6000英镑。

如果您要从企业角度考虑这一点，可以说您可以雇用其他人并以6000英镑的价格获得20％的额外生产率，或者您可以花50英镑购买ReSharper许可证来获得相同的结果。一旦数字出现在企业面前，就可以轻松地做出决定。

现在，关于具有多个环境的问题，您要做的就是找到一种方法来计算现在拥有这些环境每年需要花费多少业务成本。

您可以要求开发人员同行记录每周在配置应用程序以进行开发，部署等上花费的时间。例如，高级开发人员工作10个小时可能会花费500英镑。那可以花10个小时在开发上，或者更重要。您收集一段时间的数据，并为企业提供年度费用。

我个人讨厌这种政治，但这很普遍，我们必须忍受。