Инфраструктура тестирования обсуждается реже чем проблемы программирования или шестизначные зарплаты. Дьявол кроется в деталях, а если точнее, то дьявол сидит в процессах внутри команды. В небольших командах процессы устраиваются сами собой без обсуждения. Продуктивность команды снижается по мере роста команды и в условиях игнорирования процессов. Статью будет полезно прочитать, если команда испытывает следующие трудности:
тестирование становится бутылочным горлышком и замедляет работу;
в продукт баги проникают чаще чем хотелось.
Процесс
Классический процесс в микрокоманде на ранних этапах выглядит следующим образом:
Шаги с первого по четвертый не стоят обсуждения, сразу перейдем к шагу номер пять. Чаще в микрокомандах тестировщик не разворачивает проект локально и не переключается на нужную ветку. Тестирование проходит на тестовом сервере, который соответствует ветке develop.
Процесс выстроен логично, но давайте пофантазируем насчет ожидаемых проблем. Если задача сложная и цикл тестирования и внесения изменений продолжительный, то такая задача тормозит остальные задачи и разработчики либо сделает релиз гораздо позже, либо будут мерджить небольшие задачи напрямую в ветку master.
Получается нечто вроде конвейера, если на ленте (dev-server) застряла Feature 6, это блокирует конвейер и предприятие останавливается. Согласно теории ограничений, это классическое бутылочное горлышко. Выпуск релиза будет отложен ровно на столько, сколько требуется на исправление проблем в Feature 6. Если однажды Feature 6 попала в ветку develop, остальные задачи (Feature 4, Feature 5) будут ожидать исправления ошибок в Feature 6. При таком подходе, трудно делать релизы вовремя, будут задачи, которые блокируют релиз.
Если внимательно посмотреть на схему, очевидное решение – сливать в ветку develop только готовые задачи, для этого код должен быть протестирован. Для тестировщика или менеджера затруднительно разворачивать локально проект и переключаться с одной ветки на другую. Следовательно, для каждой разрабатываемой задачи необходим собственный сервер с публичным доступом. Попробуем!
Теперь, разработчик для каждой задачи или состояния проекта имеет свой собственный домен и может отправить его тестировщику. При этом, если в коде есть какие-то проблемы, это не заблокирует релиз, так как проблемный код еще не попал в develop ветку. Значит, мы в любой момент времени можем готовить релиз, на тестовом сервере только готовые задачи. Вроде бы на этом можно и закончить, но каждый раз для каждой задачи даже разработчику или девопсу трудно разворачивать новое состояние приложения.
Реализация
Для того чтобы погрузиться в техническую реализацию, предлагаю добавить некоторые детали к проекту. Предположим, у нас обычное веб-приложение, например на next.js.
Пришла задача от дизайнера поменять цвет кнопки "Купить" на красный. Разработчик добросовестно выполнил задачу и теперь хочет показать красную кнопку тестировщику.
Прежде чем разбираться, как это сделать, стоит сформулировать критерии выполнения задачи:
QA имеет ссылку на сборку приложения в конкретном состоянии ветки.
Ссылка уникальная и никак не переопределяет дев-сервер
Весь процесс полностью автоматизирован и не требует дополнительных усилий со стороны разработчиков.
Попробуем схематично изобразить решение.
Выглядит просто, как рецепт приготовления макарон. Теперь по шагам помеченным на схеме цифрами в желтом круге.
Разработчик отправляет код в новой ветке в репозиторий. На нашей схеме это "Репозиторий".
Gitlab CI собираем проект в контейнере и отправляет конкретное состояние приложения в реестр без дополнительных усилий разработчика.
Теперь размещаем это в интернете и получаем ссылку на это состояние. Для этого, используем скрипт на python или другом языке. Скрипт запускается по расписанию каждые 7 минут и проверяет не появилось ли новых контейнеров в реестре контейнеров.
Скрипт понимает что появился новый контейнер и размещает на виртуальном сервере. Теперь на сервере запущено приложение в требуемом состояние, но невозможно получить к нему доступ из интернета.
Скрипт меняет конфигурацию nginx. С этого момента, если на локальном компьютере добавить в файл hosts запись ip_address feature6.myproject.com, то получим заветную красную кнопку.
Последняя задача это создать публичную ссылку. Здесь сразу дам допущение, домен делегирован в Cloudfare, который умеет через API менять A-записи. Скрипт на этом шаге — создает A-запись, тем самым получаем заветную ссылку https://feature6.myproject.com и отправляем тестировщику.
Приведу псевдокод, показывающий алгоритм.
var new_containers = list[]; // список контейнеров в реестре
var old_containers = list[]; // список запущенных контейнеров на сервере
// поиск новых контейнеров
var diff = diff(new_containers, old_containers)
for i in diff:
startLocalContainers() // запускаем новый контейнер
patchNginxConfig() // добавляем новую запись в конфигурацию nginx
createNewARecord() // отправляем запрос на API cloudfare для создания A-записи
notify() // Отправляем уведомления в slack или в другой мессенджер Результат
Мы избавились от бутылочного горлышка в процессе разработки и сделали жизнь разработчиков чуточку лучше. Бонусом, можно подключить уведомления в телеграмме, слеке или бейскемпе или даже прикреплять ссылку автоматически в jira. Эта логика также будет размещена в python-скрипте.
Сегодня мы рассмотрели простой пример, в следующей статье рассмотрим ситуацию, в которой у нас более сложная архитектура приложения с бекендом, фронтом и админкой.
gogatender
Упрощает