LINUX.ORG.RU
Форум — Development  

Подготовка к старту проекта

 


0

1

Всем привет) У меня скоро стартует проект. Набираем разработчиков, у меня есть где то недели 2-3 для того что бы развернуть и настроить нашу среду prod/dev, и начать писать первый код.

Есть три репозитория:

1. esh-site
2. esh-web-app
3. esh-api

Эти три репо - очевидно лендос, веб-приложение и api соответственно. Я хочу поступить следующим образом: так как у каждого проекта есть версия - то конечная работающая система, это по сути модуль из этих трех репозиториев. То есть я могу написать конфиг где говорю что включаю туда лендос версии 1.0.0, web-app версии 1.0.0, api версии 1.0.0. Плюс мне нужна возможность, что бы я мог собрать такой модуль, который включал бы определенную версию бд, с данными на какой то момент времени. Соответственно, если несколько разработчиков пишут код по своим задачам в ветках b1 и b2, то нужно что бы под эти ветки запускались отдельные docker с модулями, включающими ветку в которой они изменяют код, и разработчики имели к ним доступ на dev стенде (конечно бд тоже своя на тестовых стендах). Сумбурно объяснил конечно, но я думаю посыл понятен) Как это можно реализовать?



Последнее исправление: maksspaces (всего исправлений: 1)

monorepo используй и не усложняй себе жизнь

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

Это понятно, а как быть с разными версиями бд? По сути снапшоты на момент выхода релиза

Разделяй данные и схему бд. В гите скрипты наката и отката схем всех версий - в бранче своя схема накатывается на пустую базу.

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

stave ★★★★★
()

Эти три репо - очевидно лендос, веб-приложение и api соответственно.

Когда архитектура приложения подразумевает раздельное использование модулей, тогда использование независимых репозиториев оправдана. В этом проекте архитектура изначально строится на жесткой сцепке модулей и в таких случаях используются моно-репозитории.

Для моно-реопзитория написать инструкцию CI будет в разы легче и проще. И полученная простота позволит без геморроя реализовать поэтапное тестирование модулей.

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

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

Зачем на dev-машине поднимать раздельные БД, когда это окружение разработчика?

Для понимания, с какими ветками идёт работа, в Travis CI есть $TRAVIS_BRANCH, в GitLab Runner есть $CI_COMMIT_REF_NAME. Облегчить работу с контейнерами поможет Ansible, который будет запускать контейнеры. Отдельная БД для отдельной ветки создаётся через линкование контейнеров, здесь поможет Docker Compose.

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