我pipe理一个多年来一直艰苦的应用程序，但仍有望继续工作。 服务器操作系统已经被维护了，但是Perl实例并没有被分配到知道Perl的那个盒子里。 我需要为请求安装一个新的模块，但是我的pipe理层担心如果出现问题，我们可以如何退出这些更改。 我已经使用CPAN在本地安装在我的机器上，但是还有大量的依赖关系需要安装。
不幸的是，我没有testing服务器开始，我不得不直接投入生产。 （我没有说这是一个理想的情况）
服务器是一个窗口框。 如果新模块更新/安装不好，是否可以制作一个Perl目录的备份副本？
我知道这有点含糊。 我不是一个服务器pipe理员，没有一个，我不知道安装什么东西到没有备份计划的生产箱。
第一种方法：
如果新模块和更新的模块应该在许多脚本中使用，请使用它。
毕竟，Perl模块只是目录中的一堆文件。 只需备份该目录（将其压缩并将其存储在盒子外面），然后按照您喜欢的任何方法安装模块。
如果出现问题，请恢复整个Perl目录。
第二个：
如果这个新模块只被一个或两个新模块使用，请使用它。
如果这是一个新的模块，它被一个新的应用程序使用，你可以将它和所有的依赖项安装到一个新的目录中，我们称之为c：\ new_perl_module，新的模块名称是fancy :: newthing;
Perlbrew是将新版本的perl和modules安装到一个单独的目录中的一种现代方式，但是cpan也可以做到这一点。
然后在需要该模块的脚本中，将这些行添加到脚本的最顶端：
use lib 'c:\new_perl_module'; use fancy::newthing;
这样只有这个脚本将使用这个新的和更新的模块。 如果失败，注释掉这些行，并且回滚完成。 安装的模块版本保持不变。
使用任何你喜欢的东西来备份你的Perl目录树，即使是一个简单的recursion文件副本。 接下来，安装你所需要的。 如果发生极不可能发生的事情，只需从备份中恢复Perl树。 严重的是，它只是没有比这更容易。
在这种情况下，我将使用Perlbrew从头开始在CPAN的所有新模块的主目录中安装一个新的Perl。 像这样，旧的安装一点也不感动。 使用所有可用模块的最新版本基本上是不错的主意。 如果事情搞砸了，也没有问题。 这一切都保存在家里，Perlbrew也负责清理。
之后，我会认真的跟pipe理层谈话。 如果他们想要你做魔术，你为什么不要求他们为你做同样的事？ 如果失败是一个大问题，他们应该做一个魔术，这样你就有一个testing环境。