В системе контроля задач создаётся новый элемент с уникальным именем (порядковым номером). В репозитории проекта создаётся ветка с этим именем в нижнем регистре.
Раработчик вносит изменения в код и выполняет push на удалённый сервер.
CI-сервер (gitlab) подхватывает это событие и создаёт задание worker для песочниц.
Worker выполняет задание - разворачивает песочницу и добавляет в конфигурацию nginx уникальный домен,
с которым может работать заказчик/тестировщик/аналитик и другие участники процесса.
Конфигурация worker:
- много оперативной памяти (из расчёта количество задач в день, над которыми предстоит работать * количество контейнеров * количество потребляемой памяти на контейнер);
- 200 GB HDD в разделе
/var/lib/dockerдля сборки контейнеров; docker-демон;docker-compose;- хостовой nginx для проксирования сайтов - должен быть по умолчанию закрыт из внешки для коммерческих проектов; его конфигурация должна автоматически подтягивать конфигурации песочниц;
- хостовой consul для разрешения имён контейнеров в IP-адреса;
- скрипты для ночного удаления контейнеров;
- скрипты для ночного удаления песочниц.
Worker создаётся таким с целью:
- выделения ресурсов по требованию (требование гибкости);
- возврата ресурсов в общий пул, когда они становятся не нужны (ресурсы стоят денег).
В таком случае шаги сборки будут следующими:
- Вычистить образы selenium (при потребности в браузерном тестировании)
- Собрать dev-образ 1 (например, web); Собрать dev-образ 2 (например, cron);
- Развернуть dev-образы в окружении разработчика (допустимо использование других контейнеров, например, percona);
- Прогнать автоматические тесты с вычислением покрытия, загрузить артефакты (покрытие, неудачные тесты) в CI;
- Собрать продуктовые образы;
- Развернуть продуктовые в окружении разработчика;
- Прогнать автоматические тесты ещё раз;
- Вычистить образы selenium (при потребности в браузерном тестировании);
- Выгрузить образ в магазин приложений;
- (вручную) Разместить приложение в продуктовой среде.