M>Планируется внутреннее приложение (.net core/react + mssql), доступ будет по АД. OS: не точно, но планируется винда
M>Какие нынче тренды?
Вместо React есть смысл посмотреть Blazor Web Assembly.
M>1. максимально простое разворачивание. Сейчас в другом проекте из гитхаба из нужной ветки вручную создается через дженкинс билд и деплоится на нужный стенд и накатываются миграции.
M> Хочется чтобы билды сами создавались
Это требует поддержки со стороны движка CI/CD. В GitHub для этих целей есть github actions, который, собственно, заменяет весь функционал Jenkins.
Но, т.к. github у вас, по всей видимости, облачный, то не факт, что этот вариант вам подойдет.
За Jenkins не скажу, но, например, TeamCity/Bamboo умеют отслеживать изменения в ветках remote-репозитория и запускать билды по определенным событиям (e.g. push в ветку). Там этот функционал называется тригерами.
В GitLab (который, кстати, можно развернуть standalone, в отличие от GitHub) есть аналог github actions — gitlab CI/CD, который тесно проинтегрирован с git. Там билд (pipiline в терминах GitLab) можно запустить
практически по любому событию в репозитории (push в ветку, создание MR, принятие MR и т.п.)
M>и миграции накатывались. ?
Это делается либо отдельным шагом билда, который готовит и накатывает на БД скрипты обновления.
Либо, прямо в коде при запуске приложения.
У нас, например, используется EF Core+Migrations и подход смешанный.
На LOCAL/TEST/STAGE скрипты накатываются автоматически при старте приложения.
Для PROD готовятся в виде SQL-архива и накатываются вручную ради большего контроля (плюс есть нюансы с созданием/ребилдом индексов на большой PROD БД — там бывает нужен некоторый ручной тюнинг).
M>2. первичный деплой максимально простой. а то часто бывает локально всё работает, а на прод деплоишь первый раз и пляшешь там с бубном. Я так понимаю докер решает эти проблемы? локально настроить и потом можно просто его скопировать на нужный сервер, просто поменяв нужный конфиг?
Нет. Докер эти проблемы полностью не уберет.
Но он дает уверенность, что артифакт (образ), собранный и проверенный на TEST-контуре — это тот же самый бинарный код, что покатится дальше, на STAGE/PROD.
Но проблемы корректной конфигурации, настройки сетевых доступов, логины/пароли/сертификаты для подключения к внешним сервисам — здесь Docker никак не поможет.
Из практики добрая половина ошибок развертывания — это где-то не прокрутили сетевую дырку наружу, где-то забыли создать пользователя для БД или прописали неверный пароль.
M> сразу вопрос по докеру. там просто зайти на hub.docker зайти можно или есть варианты лучше?
Обычно для внутренних разработок разворачивают in-house копию докер-хаба.
Что, логично, т.к. вряд ли вы захотите, чтобы образы ваших корпоративных приложений были доступны всему интернету.
Здесь, опять же, вариантов много. Гуглить "local docker registry".
Например, в том же GitLab есть встроенные docker и package registry.
M>3. как настроить базы, чтобы если один разработчик поменял разработческую базу (удалил столбец к примеру) и не запушал еще изменения другие могли работать, а не ждать пока изменения попадут в гит?
M> думал, в идеале, иметь локальные базы каждому разработчику, но тогда вопрос как настроить репликацию мастер данных (в системе много мастер данных, а их заливают в прод)
Имхо, локальная БД — самый нормальный вариант.
Я по возможности стараюсь сделать так, чтобы все инфраструктурные сервисы (БД, очереди, кэши, S3 и т.п.) разработчик мог развернуть у себя локально в автоматическом режиме.
Docker-compose с этим отлично справляется.
Как вариант — выделенная БД под каждого разработчика на общем MSSQL-сервере + jobs, которые периодически или по требованию актуализируют master-данные в этих БД.
Впрочем, без понимания особенностей ваших данных здесь сложно подсказать что-то дельное.
M>4. дженкинс лучше иметь один на компанию или под разные проекты свой?
Это от размера компании/проектов зависит.
Имхо, лучше начать с одного общего и разделять по мере необходимости.
M>5. очень много слышал про trunk development. как он? сейчас просто каждый в своей ветке делает (часто фронт с бэком в одной) и потом сливают и потом ручками делают деплой и ручками меняют версию
А что вы лично хотите получить от trunk development?
Придется менять весь текущий процесс разработки — от способа постановки/декомпозиции задач, до деплоя и эксплуатации.
Стоит ли оно того в ваших реалиях?
