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

Question

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

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

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

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

Кросс-пост в Perlmonks .

Answer 1

Я мог бы много написать об этом

1. Контроль библиотек - я создаю свои собственные версии CPAN только с теми модулями, которые мне нужны. Последние версии App :: Cpan имеют несколько функций, таких как опция -j для загрузки одноразовых конфигураций, чтобы помочь с этим. Получив его, вы можете распространять его на флэш-накопителе или компакт-диске, который содержит все модули, конфигурацию 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 PREREQ_PM, чтобы проверить, что все необходимые нам модули уже установлены). Любые модули, которые не нужно устанавливать перед установкой этого модуля.
2. Несколько файлов SQL, которые необходимо выполнить для настройки базы данных.
3. Файлы Perl CGI, которые составляют веб-сайт. Пока Apache указывает на них, сайт «просто работает». Это включает в себя модули общего кода, используемые всеми файлами Perl.

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

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

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

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