Comments 5
Допустим есть asp.net приложение, где логика приложения описана в visual studio проекте, и загружена в репозиторий MyApp. Также есть база данных MyAppDb в котором много таблиц, хранимых процедур за разработку которого отвечают другие люди в лице sql разработчиков и хранится в своем репозитории.
Приложение MyApp использует базу данных MyAppDb для своей работы.
Кроме того есть много других приложений MyApp2(3...), баз данных типа MyAppDb2 (3...).
Иногда хранимые процедуры в одной базе данных могут тянуть данные таблиц из других баз данных.
Каким образом можно шаблонами организовать деплоймент приложений и баз данных? Возможны случаи:
1) Если есть небольшие изменения, то собирается и развертывается только проект приложения. С этим все просто
2) если есть значительные изменения которые затрагивают и приложение и базу данных с которым она работает. 2 разных репозитория должны одновременно пройти процесс build и deploy так как они зависимы. Будет плохо если приложение обновилось, а новую хранимую процедуру которая она должна использовать нет в базе данных
3) если нет изменений в приложении, а есть только доработки в самой бд
4) как организовать revert изменений если таски могут быть разными. Пример: разработчик А добавил фичу в приложение и соответственно чтобы она работала добавил новый column в таблицу бд. Вроде протестировали, все хорошо , это попало в прод. SQL Разработчик Б ,в ту же БД добавил новую хранимую процедуру для другого таска. Все также протестировали и это попало в прод. Потом обнаружилось в коде разработчика А что-то не то и изменения откатили назад. При откате назад вернулась и БД. А значит работа разработчика Б тоже пропала.
Задача нетривиальная и решать ее можно разными способами, не совсем понял как вопрос относится к шаблонам gitlab-ci?
В статье описано построение модульности, если правильно понял, то логику которую вы хотите реализовать можно встроить в эти шаблоны, но не сами шаблоны будут решать логику деплоя.
Вам больше подойдут миграции с таким подходом. В общем случае нельзя, чтобы изменения в бд вносились вручную, тогда тест и прод будут не синхронизированы.
А миграции это код, так что им вполне место в репозитории, да и версионировать уже можно.
Gitlab-ci модульные pipelines для вашего enterprise