如何管理您的 Perl 应用程序开发、构建和部署？

Question

我还没有想出一种令人满意的方法来管理我的 Perl 应用程序的开发、构建和部署。我想听听您是如何解决这个问题的和/或您希望在您现在没有的应用程序构建系统中拥有什么。

请描述您的应用程序类型（它是 Web 应用程序，是否在服务器上运行，或者您是否使用 PAR 或 PerlApp 将其捆绑以便可以在无 perlless 系统上运行）。

构建系统应提供的关键内容：

• 库控制。
  • 应该可以将库分发检查到我的 dev 目录中以在我的构建中使用它。
  • 应该很容易执行带有@INC 值的 perl，该值将使用适当的目录。
  • 应该可以从系统 perl 安装中获取模块列表。
• Makefile/构建集成
  • 应该很容易通过只发出一个make test 或类似命令来对整个应用程序进行全局测试。
• 版本控制友好
  • 结构不应干扰CVS、SVN等版本的正常使用 控制系统。
• 跨平台
  • 系统至少应在 Win32 和 Unix 派生系统上运行。
  • 理想情况下，工具应该在 perl 运行的所有地方都具有相同的功能。
• 单个 Perl 安装
  • 作为设置环境的一部分，不必将 perl 安装到特殊目录中。
• 轻松启动
  • 启动应用程序应该是一个大部分自动化的过程。类似于 Module::Starter 或 h2xs 的东西应该可用于布局基本结构并创建任何标准文件。

在Perlmonks交叉发布。

Answer 1

关于这个我可以写很多东西

1. 控制库 - 我只使用我想要的模块创建自己的 CPAN 版本。最新版本的App::Cpan 有几个功能，例如加载一次性配置的-j 选项，可以帮助解决这个问题。一旦你有了这个，你可以将它分发到一个包含所有模块、CPAN.pm 配置和你需要的所有其他东西的拇指驱动器或 CD 上。只需稍加编程，您就可以创建一个 run_me 脚本，让这一切都发生。

2. Makefile/Build 集成 - 我不集成 Makefile。这就是灾难之路。相反，我使用顶级应用程序模块进行集成测试，该模块也会自动测试其所有依赖项。 -t 切换到 cpan 命令对于测试当前工作目录中的模块很有用：

   cpan -t.

您也可以使用各种集成测试框架。您将 PERL5LIB 设置为空（在硬编码的 @INC 目录中只有核心模块），因此 cpan 必须从头开始安装所有内容。

1. 版本控制友好 - 你使用什么并不重要。大多数东西都有某种出口，你可以在没有源代码控制的情况下获得所有东西。 Git 非常好，因为它在正常情况下只有最低限度的污染。

2. 跨平台 - 我提到的一切都可以在 Windows 和 Unix 上正常运行。

3. 单个 Perl 安装 - 这部分比较棘手，我认为您走错了路。任何时候多个事物必须依赖于同一个 perl，就会有人为其他事物搞砸了。我绝对建议不要使用系统 Perl 进行应用程序开发，以免弄乱系统的操作。至少，每个应用程序都应将所有非核心模块安装到自己的目录中，以免与其他应用程序竞争。

4. 轻松启动 - 这只是简单的编程问题。

奖励：我不使用 Module::Starter。这是错误的方法，因为您必须依赖 Module::Starter 认为您应该做什么。我使用Distribution::Cooker，它只是获取一个模板工具包模板的目录并处理它们以提供您的分发目录。你可以做任何你喜欢的事情。如何获得初始模板取决于您。

Answer 2

我在一个非常小的网站应用程序上工作，我们只是在改进我们的部署（改进它从“花一天时间在 Windows 上设置我们需要的所有模块，然后向它扔文件直到一切正常”，所以这是一些改进）。

我们需要做三件事来建立我们的网站：

1. 使用Module::Starter 制作的Perl 模块，包含一个Config 模块，该模块包含站点范围的配置选项。安装时，此模块（使用MakeMaker 的PREREQ_PM 检查我们需要的所有模块是否已安装）。在安装此模块之前不需要安装的任何模块。
2. 需要执行一些 SQL 文件来设置数据库。
3. 构成网站的 Perl CGI 文件。只要 Apache 指向它们，该网站“就可以正常工作”。这包括所有 Perl 文件使用的通用代码模块。

部署包括从每个人的 Git 分支中提取并打包一个版本。然后，我们可以将其移交给本地或 Amazon EC2 实例进行测试。一旦我们准备好发布，我们要么在上一个版本上安装它，要么将数据库移动到测试实例并让那个成为新实例。

将此与您的标准进行比较：

1. 图书馆控制：有点。我们非常广泛地使用 CPAN 模块。为了尝试新版本，我们在生产服务器上进行升级之前升级我们自己的模块版本。我们手动维护了一个列表，但由于我们的代码库相当小，因此不难确定正在使用哪些模块（例如，通过 greping 查找以 use 开头的行）。
2. Makefile/Build 集成：是的。任何与 Makefile 相关的东西都由我们的 EU::MM 设置完成。我们没有全局测试，但由于我们的整个测试套件最近都放在一个文件夹中，希望我们很快就会有一些可以直接运行 prove 的东西。
3. 版本控制友好：是的。我们的整个源代码都包含在一个文件夹中，没有太多重复。
4. 跨平台：是的。我们在 MakeMaker 中发生了很多奇怪的事情，让我们能够做到这一点，但作为一家初创公司，拥有跨平台代码为我们提供了宝贵的灵活性。我们尝试尽可能多地使用 Perl 的核心模块和工具，以及来自 CPAN 的 Pure Perl 模块。
5. 单个 Perl 安装：是的。我们可以在任何地方处理 Perl，并在任何设置下安装，只要 Perl 自己的所有模块工具都可以工作 - 我们付出了很多努力来让 CPAN、EU::MM 和其他工具在所有系统中正常工作，并且浪费它似乎很可惜。
6. 轻松启动：并非如此。这个系统是从一个包含所有源文件的文件夹和一个包含需要安装的模块列表的文本文件演变而来的（即：不是智能设计的）。虽然对已安装模块的正式测试是一个巨大的改进，但我们仍然需要大约一天的时间来设置它，主要用于安装我们的必备模块（并非所有模块都易于在 Windows 上安装）。我希望使用the Perl Win32 community 来尝试解决有问题的 CPAN 模块的问题。

请注意，这是一个真正简单的网站，没有 XS、复杂的网络框架或任何类似的东西。我们也仅通过大约两个版本支持此设置，因此随着代码变得更加复杂并且我们的部署平台变得更加多样化，我们没有足够的经验来了解这将如何工作。非常感谢我们系统上的任何建议或 cmets。