如何管理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.那是通向灾难的道路.相反,我使用顶级应用程序模块进行集成测试,该模块也会自动测试其所有依赖项.的-t切换到CPAN命令是有用的测试模块中的当前工作目录:

   cpan -t.

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

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

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

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

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

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

Answer 2

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

我们设置网站需要做三件事:

1. 使用的Perl模块Module::Starter,包含一个Config保存站点范围配置选项的模块.在安装时,这个模块(使用MakeMaker's PREREQ_PM来检查我们需要的所有模块是否已经安装).可以安装在此模块之前不需要安装的任何模块.
2. 需要执行一些SQL文件来设置数据库.
3. 构成网站的Perl CGI文件.只要Apache指向他们,网站"正常".这包括所有Perl文件使用的公共代码模块.

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

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

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

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