Pull to refresh

Comments 3

Добрый день, у меня с коллегами спор. Рассудите пожалуйста.
Вы диаграммы в Microsoft Word рисовали или нет?
А у нас немного попроще все организовано. У нас также есть несколько сайтов, которые нужно разрабатывать и тестировать и несколько людей, которые этим занимаются. Все боевые сайты у нас располагаются на 1-м сервере. Для разработки и тестирования — отдельный сервер с веб-окружением, очень похожим на боевой сервер.

Как мы разруливаем конфликты между разработчиками/тестировщиками? Просто у нас для каждого человека создается и закрепляется за ним копия всех сайтов при помощи специального скрипта — так называемая песочница. Скрипт просто копирует эталонный набор сайтов, который также находится на дев-сервере и настраивает nginx, чтобы эти сайты открывались. Тогда доменное имя сайта песочницы выглядит примерно так: mysite1.dev1.mycompany.com. Здесь dev1 — это номер песочницы, закрепленной за отдельным разработчиком/тестировщиком.
Таким образом, у нас просто нет проблемы, чтобы Вася пришел и сказал Пете, что он занял его песочницу — каждый работает в своей.

Так как вся разработка у нас проходит через git, то мы также разработали интерфейс, где можно выбрать номер своей песочницы, сайт и ветку, которую нужно развернуть. Дальше автоматически все разворачивается. На тестируемом сайте также отображается бирка с названием ветки, кто и когда ее развернул. Вот так:

Текущая задача
Ветка: petrov-f-error-log-add-157087
Ветку установил: [294870] (ivanovforever) Иванов Иван
Дата установки: 06.03.2018 22:17:36
Сменить/обновить ветку

Я использовал GitLab Review Apps для решения подобной задачи. На каждую ветку создается динамическое окружение, которое отображается в общем списке окружений GitLab. Плюс ссылка указывается в данных пул-реквеста, что позволяет быстро посмотреть реализованный в ветке функционал. На текущий момент развертывание происходит автоматически при пуше в origin ветки в рамках общего CI конвейера. Собираются образы, гоняются тесты, образы складываются в GitLab Registry, потом оттуда разворачиваются в контейнеры. Развертывание происходит посредством Helm в Kubernetes кластер. То есть, если окружениям станет тесно, можно решить добавлением ноды. Адресация происходит по субдомену — имени ветки. Маршрутизируется через ingress. При удаления ветки (после мержа или руками) окружение полностью удаляется. Либо можно по кнопке удалить.
Sign up to leave a comment.