在软件开发和交付的过程中，生产环节通常是最显眼的一环。毕竟，这是产品与用户直接接触的地方，任何功能或性能问题都会在这里显现出来，并可能需要立即解决。然而，生产环节只是交付周期的最后阶段。如果没有开发和测试，几乎无法交付任何东西。
设想一下，拥有一个优秀的交付链（至少在生产端是这样），并且有一个现有的应用程序。它可能是一个打算部署到云环境中的遗留应用程序，或者是一个由外部开发（例如，通过外包）的应用程序。生产团队可以交付应用程序，并在基础设施层面上进行维护。但是，没有开发团队，没有测试团队，因此也没有代码层面上的持续支持。
没有应用程序是孤立存在的。基础设施由离散的元素组成（操作系统、支持应用程序和服务、API、运行时库和云本身），所有这些元素都可能，而且几乎肯定会随着时间的推移而变化。这意味着随着时间的推移，应用程序的代码将越来越不兼容它必须运行的基础设施。
理论上，生产团队可以通过不断调整基础设施来维护应用程序，以维持其必须运行的遗留条件。然而，最终，这将增加越来越多的功能开销，这可能会以以下形式显现：应用程序响应变慢、内存、存储和其他资源的使用增加、应用程序故障更频繁且更明显、修复时间更长。
在某个时刻，如果没有在代码层面上进行重大修订，应用程序可能会变得无法工作，或者看起来明显过时，从而失去很大一部分市场份额。
在现实世界中，应用程序和网站需要做的不仅仅是保持功能性。应用程序需要看起来新鲜，它需要能够至少做一些最新的技巧（即使它们不增强核心功能），并且需要不断提供新服务，以及现有服务的明显改进。否则，即使在功能层面没有重大问题，它的市场份额也会不断被侵蚀。
但是，如果参与软件生产和管理，已经知道这一点。知道必须让代码工作，知道必须让产品、网站和服务看起来新鲜且保持最新。知道开发和测试团队对运营绝对不可或缺。
然而，很容易将开发和测试环境本身视为理所当然，假设开发人员和测试人员是自给自足的，他们默认可用的资源是足够的。但是环境和资源确实有影响，有时影响非常大。
开发和测试工具并不引人注目。它们通常不引人注目，不直接参与使用的人可能对它们不太感兴趣。但是，如果是软件开发人员或质量保证技术人员，几乎肯定会非常了解使用的工具的优点和不足。这适用于软件和硬件，以及基础设施和特定应用程序。
库和其他资源是否完全灵活地集成到开发环境中，并且所有这些资源都是最新的吗？
可用的开发工具是否适合特定工作方式，还是发现它们经常阻碍并减慢速度？
开发环境是否要求在多个窗口之间切换或使用菜单选择和对话框来执行常见、重复的任务，或者可以轻松自动化这些过程，并完全避免图形用户界面？
开发环境是否已经成为随着时间的推移逐渐添加的补丁和变通方法的迷宫，作为让越来越过时的工具“再工作一段时间”的方式？
开发人员非常有资源，他们通常非常擅长让可用的工具工作。如果他们知道或怀疑如果他们请求最新的开发工具，他们不会在管理层得到同情的回应，他们可能会找到让旧工具工作的方法，即使这些工具应该被替换的时间已经过去很久了。
将这种资源视为高度积极的特质是诱人的，而且在很多方面确实是这样。但是，通过变通方法延长过时或不充分工具的使用寿命，最终可能导致质量下降和开发时间增加。
最终，如果现有的开发工具变得过于过时，补丁和变通方法将不再足够，开发人员可能无法使用最新的功能，或者更糟糕的是，面对基础设施、操作系统和运行时库的变化，无法保持软件运行。
另一方面，如果通过提供他们需要的新和更新的工具，并确保他们的工作环境支持他们的工作方式，让开发人员快乐，更有可能看到持续的高生产力和快速的周转。
测试团队和测试环境也是如此。如果开发人员经常被忽视，那么将测试视为事后的想法，甚至完全忽视它就更容易了。为了提供足够的结果，软件测试环境和相关工具应该准确地反映实际部署环境。
这意味着它们必须保持最新。如果在云中部署虚拟化环境的软件，测试系统应该是自动化的、虚拟化的和基于云的。不幸的是，如果不给予测试过程应有的关注，可能会发现自己依赖于过时的测试系统（例如，手动和基于硬件的）仅仅是默认的。
是的，基于平台的工具也很重要。例如，阿里云的新弹性GPU服务提供了极快的、基于GPU的计算，具有强大的并发和浮点能力，非常适合计算密集型应用程序，包括深度学习、科学、工程和金融计算，以及媒体渲染和编码。
这些能力为开发团队（从设计到实施）提供的优势是显而易见的；它们可能是能够实现应用程序所需的所有功能，或者不得不使用低性能的变通方法之间的区别。