Как управлять разработкой, сборкой и развертыванием приложений Perl?

45

Мне еще предстоит найти удовлетворительный способ управления разработкой, сборкой и развертыванием моих приложений Perl. Я хотел бы услышать, как вы решили эту проблему и/или что хотели бы иметь в системе сборки приложений, которой у вас нет.

Просьба описать тип вашего приложения (это веб-приложение, оно выполняется на сервере или связывает его с помощью PAR или PerlApp, чтобы вы могли работать в системах без потерь).

Ключевые вещи, которые должна обеспечить система сборки:

  • Контроль библиотек.
    • Должно быть возможно проверить дистрибутив библиотеки в моем каталоге dev, чтобы использовать его в моей сборке.
    • Должно быть легко выполнить perl с @INC значением, которое будет использовать соответствующие каталоги.
    • Должно быть возможно получить список модулей, которые получены из системы perl install.
  • Интеграция Makefile/Build
    • Легко сделать глобальный тест по всему приложению, выпустив только одну make test или аналогичную команду.
  • Управление версиями
    • Структура
    • не должна мешать нормальному использованию CVS, SVN и другой версии системы управления.
  • Кросс-платформа
    • Система должна работать как минимум на Win32 и Unix.
    • В идеале инструменты должны функционировать одинаково во всех местах, где работает perl.
  • Одиночная установка Perl
    • Не нужно устанавливать perl в специальный каталог как часть настройки среды.
  • Легкий запуск
    • Запуск приложения должен быть главным образом автоматизированным процессом. Что-то по строкам модуля:: Starter или h2xs должно быть доступно для компоновки базовой структуры и создания любых стандартных файлов.

Перекрестная ссылка на Perlmonks.

Теги:

2 ответа

18
Лучший ответ

Там много, что я мог бы написать об этом

  • Управление библиотеками - я создаю свои собственные версии CPAN только с теми модулями, которые я хочу. В последних версиях App:: Cpan есть несколько функций, таких как опция -j для загрузки одноразовых конфигураций, чтобы помочь в этом. После этого вы можете распространять его на накопителе большого пальца или компакт-диске, в котором есть все модули, конфигурация CPAN.pm и все остальное, что вам нужно. С небольшим программированием вы создаете run_me script, чтобы все произошло.

  • Интеграция Makefile/Build - я не интегрирую Make файлы. Это путь к катастрофе. Вместо этого я тестирую интеграцию с модулем приложения верхнего уровня, который автоматически проверяет все его зависимости. Переключатель -t для команды cpan полезен для тестирования модуля в текущем рабочем каталоге:

    cpan -t.

Существуют различные схемы тестирования взаимодействия, которые вы также можете использовать. Вы устанавливаете PERL5LIB на что-то пустое (только с основными модулями в жестко закодированных каталогах @INC), поэтому cpan должен установить все с нуля.

  1. Управление версиями - это не имеет большого значения, что вы используете. У большинства вещей есть какой-то экспорт, где вы можете получить все без материалов для управления версиями. Git очень хорошо, потому что в нормальных случаях он имеет минимум загрязнения.

  2. Кросс-платформа - все, о чем я упомянул, прекрасно работает в Windows и Unix.

  3. Single Perl install - эта часть более сложная, и я думаю, что вы ошибетесь. В любое время, когда несколько вещей должны зависеть от одного и того же perl, кто-то собирается испортить это для других. Я определенно рекомендую не использовать систему Perl для разработки приложений, чтобы вы не испортили работу системы. Как минимум, каждое приложение должно установить все неядерные модули в свои собственные каталоги, чтобы они не конкурировали с другими приложениями.

  4. Простота запуска - это просто вопрос программирования.

БОНУС: я не использую Module:: Starter. Это неправильный путь, поскольку вы должны зависеть от того, что Module:: Starter думает, что вам следует делать. Я использую Distribution:: Cooker, который просто берет каталог шаблонов Template Toolkit и обрабатывает их, чтобы предоставить им свой каталог распространения. Вы можете делать все, что вам нравится. Как вы получаете исходные шаблоны, зависит от вас.

  • 0
    Отличный ответ, спасибо. Система, которая будет работать для меня, не должна устанавливать вещи на сайт и должна быть в состоянии сосуществовать с одним системным perl. Моя работа со старыми версиями ActivePerl делает это абсолютным требованием. Где это возможно, я согласен, что лучше использовать отдельный Perl.
7

Я работаю над довольно маленьким веб-приложением, и мы просто работаем над улучшением нашего развертывания (улучшая его от "тратить день, настраивая все модули, которые нам нужны в Windows, а затем бросаем файлы на него, пока все не работает", так что некоторые улучшения).

У нас есть три вещи, которые нам нужно сделать, чтобы настроить наш сайт:

  • Модуль Perl, созданный с использованием Module::Starter, содержащий модуль Config, который содержит параметры конфигурации всего сайта. При установке этот модуль (используя MakeMaker PREREQ_PM, чтобы проверить, что все необходимые нам модули уже установлены). Любые модули, которые не должны быть установлены до того, как этот модуль может быть установлен.
  • Несколько SQL файлов, которые необходимо выполнить для настройки базы данных.
  • Файлы CGI Perl, составляющие веб-сайт. Пока Apache указывает на них, веб-сайт "просто работает". Это включает в себя общие модули кода, используемые всеми файлами Perl.

Развертывание состоит в том, что я вытягиваю из всех ветвей Git и упаковываю версию. Затем мы можем передать это для тестирования либо локально, либо на экземпляр Amazon EC2. Как только мы будем рады опубликовать, мы либо устанавливаем его поверх последней версии, либо переносим базу данных на экземпляр тестирования, и делаем это новым экземпляром.

Сравнивая это с вашими критериями:

  • Контроль библиотек: несколько. Мы используем модули CPAN довольно широко. Чтобы попробовать новую версию, мы обновляем нашу собственную версию модуля перед выполнением этого обновления на рабочем сервере. Мы вручную поддерживаем список, но поскольку наша кодовая база довольно мала, нетрудно определить, какие модули используются (например, через grep для строк, начинающихся с use).
  • Интеграция Makefile/Build: Да. Любые файлы, связанные с Makefile, выполняются нашей установкой EU:: MM. У нас нет глобальных тестов, но так как весь наш тестовый пакет недавно оказался в одной папке, мы надеемся, что скоро у вас будет возможность запускать prove напрямую.
  • Совместимость версии: Да. Весь наш исходный код содержится в одной папке без излишнего дублирования.
  • Кросс-платформа: Да. У нас есть много странных вещей, происходящих в MakeMaker, чтобы позволить нам сделать это, но в качестве стартапа наличие кросс-платформенного кода дает нам ценную гибкость. Мы стараемся максимально использовать основные модули и инструменты Perl, а также модули Pure Perl из CPAN.
  • Установка Single Perl: Да. Мы можем обрабатывать Perl, находясь где угодно, и устанавливаться в любых настройках, если все инструменты собственного модуля Perl могут работать, - было затрачено много усилий на получение CPAN, EU::MM, а другие хорошо работают во всех системах. кажется, стыдно тратить его.
  • Легкий запуск: не совсем. Эта система эволюционировала (т.е. Не была разработана разумно) из одной папки всех исходных файлов и текстового файла со списком модулей, которые необходимо установить. В то время как формализация тестирования для установленных модулей является огромным улучшением, нам по-прежнему требуется что-то вроде дня, чтобы установить это, в основном, проводили установку наших предварительных модулей (не все из них просты в установке в Windows). Я надеюсь использовать сообщество Perl Win32, чтобы попытаться устранить проблемы с проблемными модулями CPAN.

Имейте в виду, это действительно простой веб-сайт, нет XS, сложная веб-фреймворк или любой такой. Мы также поддерживали эту настройку только в двух версиях, поэтому нам не хватает опыта в том, как это будет работать, поскольку код становится более сложным, а наши платформы развертывания становятся все более разнообразными. Я бы очень признателен за любые предложения или комментарии в нашей системе.

  • 0
    Я делаю подобные вещи, и все это кажется мне слишком ручным и подверженным ошибкам. Со временем я немного изменился, но мне нужно поддерживать несколько приложений, поэтому я не хочу вносить слишком много изменений.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню