Развертывание приложения для тестирования?

Question

[RokeAlvo]

Есть web-приложение, которое состоит из нескольких частей:
- база
- репозиторий бека
- репозиторий фронта
- репозиторий конфигов
- и еще всякие разные репозитории

для разработки новой фичи нужно внести изменения в пару репозиториев, перед мержами нужно провести ручное тестирование, те развернуть приложение из нужных веток на каком-нибудь поддомене (например branchName.myDevServer.com)

Какие инструменты для этого есть? Мб есть ссылки на статьи по этому поводу?

Comments

[Pitonoslav]

А приложения как запускаются? В кластере кубера?

[RokeAlvo]

сейчас - из ранера по ssh разворачивается на нужном сервере
но репозиторий бека и фронта - один, остальные не критично
там есть еще репозиторий с конфигами nginx, есть репозиторий с докер-файлами (используются для развертывания локально) - но они меняются редко

хочется бек и фронт по разным репам разнести

по сути вопрос не как это сделать, а какие инструменты
например, слабо представляю, что такое "кластер кубера"... ну те слышал, читал, но не более

Answer 1

[d-stream]

Собственно вокруг любых систем контроля версий существуют и "системы сборки" - то есть как раз то что может по прописанному в репозитории что-то соберет и например отправит (на хосты/стенды или в хранилище артефактов).

Как пример - тот же gitlab и gitlab runners - то есть по коммиту/пендалю будет интерпретироваться .gitlab-ci.yml в котором могут быть прописаны нужные шаги (build, test, deploy и т.п.)

Ну или jenkins, по сути так же интерпретирующий jenkinsfile

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

p.s. по сути всё это повторяет ручные операции, если их хорошо описать aka автоматизирует
При желании это можно и навелосипедить, но задача типовая и поэтому есть 100500 решений почти от каждого крупняка... правда почти все они на начальном этапе несколько избыточны, но тем и хороши

Comments

[RokeAlvo]

понятно что есть ранеры и хуки, но вопрос в том, что разные репозитории
пока репозиторий один все просто:

при создании мержа запускаем джобу которая все разворачивает (остается только вопрос с тем как сделать приложение доступным по адресу feature-1234.dev-server.com)

а когда репозиториев больше чем 1?

можно конечно через хуки накостылить какой-то инструмент для этого:
отдельное приложение, которое принимает хуки от всех репозиториев и что-то делает
но сразу, помимо непосредственно самой логики, появляется веб-интерфейс для управления, база для хранения состояния и тд

Пример.
состав приложения:
- бек
- фронт
- база

некая фича (переименовали поле на беке) требует разработки в двух репозиториях и они не могут быть вылиты отдельно:
- фронт
- бек

бекендер делает свою часть в своем репозитории `back-repo/feature/1234`
фронтендер делает свою часть в `front-repo/feature/1234`

теперь нужно развернуть приложение для ручного тестирования

на дев-сервере нужно обеспечить развертывание приложения:
- бек из back-repo/feature/1234
- фронт из front-repo/feature/1234

и запускать деплой при любом изменении в исходниках

после того как все будет протестировано и смержено "прибраться"

[d-stream]

А разницы? Ну 100500 репозиториев, выхлопом каждого будет некая законченная сущность. Докер, архив с js и т.п. В зависимости от потребности результаты сборок либо льются по нужным местам этаким 100501 репозиторием, "исходником" которого будет список из 100500 конкретных версий которые нужно собрать в кучку и раздеплоить в указанные места; либо будет пинать сборки тех 100500 реп и забирать артефакты для той же цели.

Ну а задачу обновления/замены на стендах/проде в виде "100499 модулей не менялось" - это хлебушек какого-нибудь ансибла - он это умеет хорошо.

Вариант поменялся фронт - льём только его и наоборот - в общем-то при должном старании в обеспечении версионной совместимости - тоже не исключен.

Если ко всему этому приложить методики и рекомендации ветвления - то вообще сказка получается: деплой ветки dev например улетит на dev стенд, а release_* - на тестово-испытательный, ну а мастер [с тегом релиза] - на прод.

[RokeAlvo]

не очень хорошо сформулировал вопрос

да, "выхлоп" каждого репозитория это либо контейнер, либо архив

при изменении в каком-то репозитории, он запускает свои пайплайны и готовит этот "выхлоп"... "управляющий репозиторий" (100501) почему запустит свои пайплайны?

а что работает на сервере? ансибл? ну те что обеспечивает развертывание?

[d-stream]

при изменении в каком-то репозитории, он запускает свои пайплайны и готовит этот "выхлоп"... "управляющий репозиторий" (100501) почему запустит свои пайплайны?

Самый простой вариант - "я решил раздеплоить" aka "ручной запуск"
вариант посложнее - по коммиту в этот самый 100501 репозитарий файла со списком "что брать"

а что работает на сервере? ансибл? ну те что обеспечивает развертывание?

тут не совсем явное "что есть сервер?" То бишь если мы говорим о некоей машине на которой исполняется сборка - то да, как вариант - ансибл, который сверяет текущее состояние с декларациями в одном (или нескольких) репозитарии из этих 100500, где описана инфраструктура

Answer 2

[Alexey Dmitriev]

Это называется CI/CD и есть множество решений для этого.
Azure DevOps, Jenkins. Gitlab Runners и т.п.