首页 文章

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

提问于
浏览 次
45

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

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

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

  • 控制图书馆 .

  • 应该可以将库分发检查到我的开发目录中，以便在我的构建中使用它 .

  • 使用适当的目录 @INC 值执行perl应该很容易 .

  • 应该可以获得从系统perl安装中获取的模块列表 .

  • Makefile / Build集成

  • 通过只发出一个 make test 或类似命令，可以很容易地在整个应用程序中进行全局测试 .

  • 版本控制友好

  • 结构不应干扰CVS，SVN和其他版本控制系统的正常使用 .

  • 跨平台

  • 系统应该至少在Win32和Unix派生系统上运行 .

  • 理想情况下，工具在perl运行的所有地方应该具有相同的功能 .

  • 单Perl安装

  • 在设置环境时，不必将perl安装到特殊目录中 .

  • 轻松启动

  • 启动应用程序应该是一个主要是自动化的过程 . 应该可以使用Module :: Starter或h2xs的某些内容来布局基本结构并创建任何标准文件 .

Cross-posted at Perlmonks.

perl

2 回答

  • 7

    关于这一点，我可以写很多东西

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

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

    cpan -t .

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

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

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

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

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

    奖励：因为你不得不依赖Module :: Starter认为你应该做的事情，所以我不会错误地去做 . 我使用Distribution::Cooker，它只需要一个Template Toolkit模板目录并处理它们以给它们你的分发目录 . 你可以做任何你喜欢的事情 . 如何获得初始模板取决于您 .

    回复于
  • 17

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

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

    • 使用 Module::Starter 制作的Perl模块，包含 Config 模块拥有站点范围的配置选项 . 在安装时，这个模块（使用 MakeMaker 的 PREREQ_PM 来检查我们需要的所有模块是否已经安装） . 可以安装在此模块之前不需要安装的任何模块 .

    • 需要执行一些SQL文件来设置数据库 .

    • 构成网站的Perl CGI文件 . 只要Apache指向他们，网站"just works" . 这包括所有Perl文件使用的公共代码模块 .

    部署在于我从每个人那里撤回，我们要么将其安装在最后一个版本上，要么将数据库移动到测试实例并将其作为新实例 .

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

    • 图书馆控制：有点 . 我们非常广泛地使用CPAN模块 . 要尝试新版本，我们在 生产环境 服务器上进行升级之前升级我们自己的模块版本 . 我们手动维护一个列表，但由于我们的代码库相当小，因此不难确定正在使用哪些模块（例如，通过 grep 对于以 use 开头的行） .

    • Makefile / Build集成：是的 . 任何Makefile相关的东西都是由我们的EU :: MM设置完成的 . 我们很快就会直接运行 prove .

    • 版本控制友好：是的 . 我们的整个源代码包含在一个文件夹中，没有太多重复 .

    • 跨平台：是的 . 我们've got lots of weird stuff happening in MakeMaker to allow us to do this, but as a startup, having cross-platform code gives us valuable flexibility. We try to use Perl'的核心模块和工具，以及CPAN的Pure Perl模块，尽可能多 .

    • Single Perl安装：是的 . 我们可以处理的Perl是在任何地方，并且在任何设置安装的，只要所有的Perl 's own module tools can work - there'已经过了很多努力投入越来越 CPAN ， EU::MM 和其他所有系统运作良好，这似乎是一个耻辱浪费它 .

    • 轻松启动：不是真的 . 该系统从所有源文件的单个文件夹和具有需要安装的模块列表的文本文件演变（即：未智能设计） . 正式化对已安装模块的测试是一项巨大的改进，但是我们仍然需要花费一天的时间来设置它，主要用于安装我们的必备模块（并非所有模块都易于在Windows上安装） . 我希望使用the Perl Win32 community尝试解决有问题的CPAN模块的问题 .

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

    回复于

相关问题