应用程序正在部署到服务器上.它不是CPAN或脚本.它实际上是一个PSGI Web应用程序.那就是一大堆Perl包.
我目前有一个部署脚本,使用Net :: SSH :: Expect SSH到新服务器,安装一些工具并配置服务器,然后从源代码控制下拉所需的应用程序分支.这感觉是正确的,但这是最好的做法吗？
下一步是构建应用程序.跟踪和管理依赖关系的最佳做法是什么,从CPAN安装这些依赖关系,并确保应用程序准备好运行？
谢谢
解决方法
@H_403_13@ 我目前正在为每个CPAN和每个CPAN构建RPM的公司一个应用程序的内部依赖(相当多的包！)安装到系统的site_perl目录中.这有一些问题：>随着版本在CPAN上碰撞,继续构建RPMs是耗时的.
>将系统perl绑在一起意味着你正在分配你的分配,以使其破坏你的perl(在Centos 5中,我们有一个最大perl版本的5.8.8！).
>如果您将多个应用程序部署到同一台主机,为所有应用程序配置一个perl库,则意味着升级依赖关系可能是危险的,无需重新测试主机的每个应用程序.我们部署了很多不同程度的维护注意事项,所以这对我们来说很重要.
我们正在为每个依赖关系构建RPM,而是计划使用纸箱[1]为我们部署的每个应用程序构建一个完全自包含的perl库.我们正在将这些库构建到系统包中,但是如果您不想处理包管理器,您也可以轻松地将其压缩并手动复制它们.
纸箱的问题是您需要设置一个内部CPAN镜像,您可以安装内部依赖关系,如果您的应用程序依赖于不在CPAN上的模块.如果您不想处理这些,您可以随时手动将需要的libs安装到local :: lib [2]或perlbrew [3]中,并将生成的库打包到部署到生产箱中.
使用所有规定的解决方案,要非常小心XS perl libs.您将需要在与您部署的主机相同的架构上构建您的纸箱/本地：libs / perlbrews,并确保您的制作框具有与您以前构建的相同的二进制依赖关系.
要回答关于您的问题的更新是否是最佳做法来源结帐并安装到您的生产主机上？我个人认为这不是一个好主意.我认为这是有风险的原因,因为很难完全确定您安装的一组库与您测试的库完全一致,因此部署有可能是不可预测的.这个问题可能会被webapps吓倒,因为您很可能将相同的代码部署到可以脱离同步的多个生产箱中.虽然perl社区做了一个很好的工作,试图发布质量好的向后兼容的代码,当出现问题时,通常会很努力地弄清楚.这就是为什么正在开发纸箱,因为这会创建一个缓存,您需要在特定版本中安装冻结的所有分发tarball,以便可以预见部署代码.所有这一切说如果您乐意接受这种风险并在遇到困难时解决问题,那么本地安装应该对您而言是正确的.但是,至少我强烈建议安装到本地的lib,以便您可以在安装更新之前备份旧的本地lib,以便在遇到问题的时候有一个回滚点.
> [1] https://metacpan.org/module/Carton(小心,还在发展中)
> [2] https://metacpan.org/module/local::lib
> [3] https://metacpan.org/module/perlbrew