在 上一篇文章 中，我强调了使所有测试环境尽可能与生产环境相似的重要性。我提到安装应该是完全自动化的——但可能会出现这样的问题，自动化程度如何才足够？现在让我们考虑这个问题：
正如 Martin Fowler 所说 ：“ 您在进行持续交付时……您可以按需将任何版本的软件一键式部署到任何环境。 ” 只需按一下按钮即可快速轻松地部署软件的能力是实现持续交付的关键，但通常人们会不愿将安装过程的所有方面自动化。他们问，真正可以实现多少自动化？他们经常说，有些事情我们需要亲手做。
我不同意。如果您没有实际将硬件安装到盒子中，那么您的任务应该并且可以自动化。
环境搭建
安装应用程序时，环境对于确保所有测试都在具有相同框架的所有系统上运行的过程至关重要。能够准确识别环境中的内容是拥有从开发一直到生产的一致测试环境的关键。如果需要，确定环境的组成部分、所有安装的工具、环境变量集等，在创建 物料清单 (BOM) 时也很重要。
环境的创建和所有更改都应尽可能自动化——这可能包括更改环境变量、安装新软件包或补丁等。显然，硬件更改不能通过脚本自动进行，但所有其他更改都可以编写脚本或编程。
应该进行自动化，使其足够灵活，可以运行所有可能在应用程序测试中使用的环境。通过在整个过程中使用相同的自动化流程，可以在安装脚本到达生产系统之前对其进行全面测试。
配置数据
随着 Release 流程在各个测试阶段的推进，每组测试环境都会有不同的配置信息。此信息可能包括特定于单个环境的 IP 地址、主机名和其他数据。此信息可以存储在一个文件中，该文件可以存储在软件配置管理 (SCM) 系统中。将其存储在 SCM 系统中可以跟踪和监控更改。
使用在安装时解析的配置文件，允许为多个环境配置安装，因为每个环境都可以有自己的配置文件，或者配置文件中可以有适用于所有适用环境的适当条目。
可以配置多个环境：不仅是各种类型的环境（开发、QA、暂存等），而且在许多情况下，每个环境中的多台机器，以及这些不同环境的多个实例（可能有几十个开发测试环境，几套 QA 测试环境等）。由于需要配置和管理的环境和机器数量众多，因此拥有一种管理这些配置的方法至关重要。
将配置文件存储在 SCM 工具中有助于跟踪对各种文件的更改。此外，拥有管理这些环境配置的工具也很重要，因为安装环境通常由多台机器（Web 服务器、应用程序服务器、数据库服务器等）组成。 ElectricFlow 中的部署功能 能够管理多种类型的部署，以及发布管道所需的各种环境的多个实例。它还可用于创建和拆除各种虚拟环境的实例，使您的测试系统具有灵活性和适应性。
软件安装
为要发布的应用程序和其他组件实施自动化安装解决方案对于创建平稳可靠的发布流程变得越来越重要。安装的所有方面都应该是自动化的，包括上传应用程序、运行安装和重新启动任何必要的服务。通过自动化所有这些，您可以提高可靠性、可重复性，并且它可以让其他人准确地识别每个版本需要什么（对于 BOM 也很有用）。
另一个常见的反模式是“仅在开发完成后才部署到类生产环境”。这意味着如果特定软件版本从未在生产副本中进行过测试，则几乎没有信心可以为最终用户成功运行该软件版本。
重要的是，在所有测试环境的 整个开发过程中都 使用自动化。这确保它在到达生产环境之前经过测试。该过程的自动化程度越高，整个开发生命周期中的每个人就越容易执行必要的安装任务。
使用 ElectricFlow Deploy ，可以在多台服务器上设置复杂的安装。只需按一下按钮，即可根据需要配置服务器和部署软件。
虚拟环境
虚拟环境允许您根据需要启动环境。 ElectricFlow 的动态环境功能允许您创建、配置和保存虚拟环境以满足未来的测试需要。这对于启动新的测试环境以及记录特定版本的确切环境包含的内容特别有效。如果需要环境来重现在生产中发现的问题，这在以后可能很重要。
环境快照可用于在发布过程的各个阶段创建必要的测试环境。通过使用虚拟环境，QA 工程师可以确保他们正在测试的环境没有被修改，因为他们可以简单地启动新环境。
但是，在测试阶段使用虚拟环境，如果不在生产中使用，则会产生需要评估的风险。可能会在物理硬件上发现虚拟环境中找不到的潜在问题。
所以这仍然留给我们一个问题：多少自动化就足够了？您希望在安装过程中很少或没有人为交互，一切都应该以某种方式自动化。安装期间发生的人为交互越少，发生错误的可能性就越小，执行 Martin Fowler 所指的按钮式安装的能力就越强。使用的脚本、配置文件和其他文件越多，这些文件就可以在 SCM 系统中进行跟踪。通过使用自动化工具，工程师可以腾出时间专注于应用程序安装以外的事情，减少安装过程中出现的问题所花费的时间。
