LINUX.ORG.RU

Как организовать тестирование и сборку ПО

 


1

2

Всем привет. Прошу совета по организации процесса тестирования и сборки пакетов для небольшого клиент-серверного приложения на Python.

У нас небольшая группа (3 человека), параллельно разрабатываются 3-4 ветки. Разработка и тестирование организована на виртуалках в системе oVirt, дистрибутив - производный от RHEL 6. Репозиторий кода организован на Git в Redmine, репозиторий пакетов - ftp-сервер на одной из машин.

Процесс разработки организован следующим образом:

  • Разработчик вносит изменения в код;
  • Собирает локально на своей машине пакет со своей веткой и обновляет репозиторий пакетов;
  • Откатывает тестовые ВМ до «чистых» снепшотов и перезагружает их;
  • Устанавливает на соответствующие ВМ клиентский и серверный пакеты;
    yum clean all
    yum install <package>-<ver>-<release>.<branch>.noarch.rpm
    
  • Запускает программы;
  • На ВМ заранее клонирован репозиторий с кодом, поэтому, если возникают ошибки, разработчик-тестер делает:
    cd ~/<проект>
    git fetch origin
    git checkout <нужная ветка>
    cd /usr/lib/python2.6/site-packages/<проект>
    rm -rf <проблемный модуль>.py*
    ln -s ~/<проект>/<проблемный модуль>
    vim ~/<проект>/<проблемный модуль>
    
  • Начинает редактировать исходники на тестовой машине и снова всё перепроверять, если ошибка найдена - коммитить;

Так повторяется до 4-5 раз в день, в зависимости от фазы цикла (написание кода или отладка кода). На каждую итерацию тратится до 15 минут - накладные расходы.

Никто из участников разработки не имеет представления о том, каким образом этот процесс может быть оптимально организован. Поэтому просим поделиться опытом.

Зачем такие сложности? Нужно отдельно тестировать код и отдельно сборку пакетов.

Кстати, зачем перезагружать ВМ при наличии снапшотов?

anonymous ()

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

Но, понятно, это поможет, если есть автоматические тесты, иначе облегчится только задача сборки.

Могу предложить такое усовершенствование: code review. Мы используем Phabricator и я сделал интеграцию его с Jenkins так, что когда разработчик отправляет изменение на ревью, Jenkins делает сборку из основной разрабатываемой ветки с наложенными на нее изменениями и запускает тесты. Во-первых, ревью несколькими коллегами существенно повышает качество кода. Во-вторых, не нужно самому возиться с подготовкой чистой сборки, но при этом прогоняются на ней тесты. А когда изменение будет обсуждено, одобрено и на нем будут проходить тесты, тогда только оно пройдет в репозиторий в виде коммита.

Еще Jenkins можно попросить делать сборку и прогонять тесты по изменению репозитория, причем можно различать изменения разных веток. Правда, сделать это универсально для произвольных веток у меня пока не получилось.

moroz ()
Ответ на: комментарий от anonymous

Кстати, зачем перезагружать ВМ при наличии снапшотов?

Увы, oVirt 3.1 не позволяет откатить работающую ВМ на снапшот. Поэтому выключаем - откатываемся - загружаем.

Зачем такие сложности? Нужно отдельно тестировать код и отдельно сборку пакетов.

Из-за специфики ПО... Выдаёт большие объёмы логов, перенастраивает SELinux, меняет много конфигурационных файлов в системе. На машине разработчика неудобно.

vitalyisaev2 ()
Ответ на: комментарий от moroz

Спасибо за ответ... Мне, к сожалению, непонятно, как принято распространять свое ПО по тестовым машинам?

  • в виде пакетов;
  • через локальные клоны репозитория;

И как это реализовано в Jenkins?

Наша проблема в том, что этап отладки кода (об автоматизированном тестировании речь пока вообще не идёт) приходится выносить на виртуальные машины.

Поэтому удобно, найдя ошибку, поправить её прямо на тестовой машине и снова запустить программы. Если всё правильно, сделать коммит с тестовой машины.

vitalyisaev2 ()
Ответ на: комментарий от vitalyisaev2

Как-то все странно организовано - разработчик вообще что ли не запускает программу у себя? Обычно есть этап разработки и отладки и есть этап тестирования сборки (к которому разработчик уже не имеет отношения). И зачем отлаживать продукт в инсталляции, если еще не отлажена функциональность?

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

Jenkins можно попросить делать, что угодно. Я не смотрел, какая там функциональность для Java-проектов, но для всех остальных случаев нужные действия для сборки и тестирования просто описываются в виде sh-скрипта (или иных видов скриптов). И есть разнообразные возможности по копированию полученных при сборке файлов куда-либо и т.п. Вся подобная функциональность у него вынесена в плагины и плагинов очень много. У нас, например, Jenkins управляет сборкой под несколько операционных систем, а результаты всех сборок с нескольких сборочных машин копируются на одну CIFS-share.

moroz ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.