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

Question

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

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

构建系统应提供的关键事项：

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

在Perlmonks交叉发布。

Answer 1

我可以写很多关于这个

的文章

1. 控制库 - 我只使用我想要的模块创建自己的CPAN版本。最新版本的App::Cpan具有多项功能，例如加载一次性配置的-j选项，以帮助解决此问题。完成此操作后，您可以将其分发到具有所有模块的拇指驱动器或CD上，CPAN.pm配置以及您需要的其他所有内容。通过一些编程，您可以创建一个run_me脚本来实现这一切。

2. Makefile / Build集成 - 我没有集成Makefile。那是通向灾难的道路。相反，我使用顶级应用程序模块进行集成测试，该模块也会自动测试其所有依赖项。 {c}命令的-t切换用于测试当前工作目录中的模块：

   cpan -t。

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

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

2. 跨平台 - 我提到的一切在Windows和Unix上运行得很好。

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

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

BONUS：我不使用Module :: Starter。这是错误的方式，因为你必须依赖Module :: Starter认为你应该做的事情。我使用Distribution::Cooker只需要一个Template Toolkit模板目录并对其进行处理，以便为它们提供分发目录。你可以做任何你喜欢的事情。如何获得初始模板取决于您。

Answer 2

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

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

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

部署在于我从每个人的Git分支机构中取出并打包一个版本。然后，我们可以将其交给本地或Amazon EC2实例进行测试。一旦我们好好发布，我们要么在最后一个版本上安装它，要么将数据库移到测试实例上并使 新实例。

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

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

请注意，这是一个真正的简单网站，没有XS，复杂的Web框架或任何此类。我们也只通过两个版本支持这种设置，因此我们没有足够的经验来了解这将如何工作，因为代码变得更复杂，我们的部署平台变得更加多样化。我非常感谢您对我们系统的任何建议或意见。