Контроль версий базы данных

 
 
 
Сообщения:50
Привет, у меня на проекте встал вопрос версионирования базы данных, поскольку уже понемногу начинаем путаться. Хотелось бы узнать по поводу best practice. На данный момент существует два сервера, один собирается с ветки dev, другой с ветки master, приложение одно, но структура таблиц может отличаться, пока на ветке master нет новой фичи, но на dev она уже есть, то соответственно и структура таблиц разная. Решили использовать фреймворк flyway, создать ветки test-dev и test-master, на которых будет flyway.enabled=true, а на dev и master flyway.enabled=false. Нормальное решение?
 
 
Сообщения:9717
igor_:
На данный момент существует два сервера, один собирается с ветки dev, другой с ветки master,
Если есть возможность (а она обычно есть) стоит подумать о том, чтоб избавиться от сборок и деплойментов не-master'ных веток. Разработчики должны регулярно пушать в мастер качественный код. Это значит и автоматизированное, и ручное тестирование разработчиком перед каждым пушем. А также может значить feature toggling и branching by abstraction.

Современные практики идут к тому, чтоб существовала только ветка master. Это сразу решит многие проблемы и упростит настройку Build Server'ов и окружений.
igor_:
но структура таблиц может отличаться, пока на ветке master нет новой фичи, но на dev она уже есть, то соответственно и структура таблиц разная
Ну если DEV окружение уходит вперед - это не страшно. Проблема - если миграции тестировались в одном порядке, а запушались в master - в другом. Чтоб такого не происходило можно чистить DEV перед каждым деплоем или вообще использовать in-memory DB на DEV'e (но все должны будут понимать что это не гарантирует что приложение заработает на TST).

Пример полностью автоматизированного Deployment Pipeline'a который смог:
1. Build - BE unit and component testing, UI unit testing, create a binary and upload it to Nexus
2. Deploy to DEV - works with in-memory DB, is cleaned on every deployment
3. UI Selenium Tests - UI component and system testing
4. Deploy to PERF - Oracle XE, is re-created on every deployment
5. Run Performance Tests
6. Deploy to TST - Oracle
 
 
Сообщения:50
Quote:
Если есть возможность (а она обычно есть) стоит подумать о том, чтоб избавиться от сборок и деплойментов не-master'ных веток. Разработчики должны регулярно пушать в мастер качественный код. Это значит и автоматизированное, и ручное тестирование разработчиком перед каждым пушем. А также может значить feature toggling и branching by abstraction.

Dev очень нужен, так как проект на микросервисах (сервисы на Scala), у нас нет доступа к фронт енду локально (фронтендщик у заказчика удаленно работает), нет ни автоматизированных тестов, ни юнит тестов (у заказчика нет на это денег), тоесть локально можно только сервис на Java запустить и все). На dev выкатываем - проверяем, запустилось - Ок, фрондендщик поклацал, проверил - выкатываем на мастер на предпродакшен, не запустилось - смотрим логи.
Quote:
1. Build - BE unit and component testing, UI unit testing, create a binary and upload it to Nexus
2. Deploy to DEV - works with in-memory DB, is cleaned on every deployment
3. UI Selenium Tests - UI component and system testing
4. Deploy to PERF - Oracle XE, is re-created on every deployment
5. Run Performance Tests
6. Deploy to TST - Oracle

Ок, спасибо, загуглим)
 
 
Сообщения:9717
Пока вы не построите грамотный процесс где вы можете разворачивать и тестировать локально, пока не будете писать тесты (это входит в вашу работу, заказчик не должен доплачивать), тут вряд ли какие-то улучшения окружений поможет.
 
 
Сообщения:50
Ну заказчик заглядывает в джиру, требует фичи, а не "ненужные тесты". Ок, учту, спасибо, тут очень дикий темп разработки) буду топить конечно за тесты, локально как-то разворачивать эту машину в докере, правда не знаю, что с ручными тестами делать и автоматизации тестирования вообще, тестировщиков нет)
 
Модераторы:Нет
Сейчас эту тему просматривают:Нет