Может кто знает, хорошие ресурсы, курсы по этому делу. Буду очень благодарен за ссылки.

Здравствуйте, Qulac, Вы писали:

Q>Может кто знает, хорошие ресурсы, курсы по этому делу. Буду очень благодарен за ссылки.

Зависит от того, что понимаешь под "ci/cd баз данных"

Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, Qulac, Вы писали:

Q>>Может кто знает, хорошие ресурсы, курсы по этому делу. Буду очень благодарен за ссылки.

Б>Зависит от того, что понимаешь под "ci/cd баз данных"

Ну в крадце например: я открыл в vs проект базы данных slq server, что то там сделал, сделал пуш, а на выходе если все прошло удачно получаются два mof-файла один для нового инстанса, другой для обновления. Естественно это все с какими ни будь там тестами. Примерно так. Проблема в том, что я сам точно не знаю, как это должно быть.

Здравствуйте, Qulac, Вы писали:

Q>>>Может кто знает, хорошие ресурсы, курсы по этому делу. Буду очень благодарен за ссылки.

Б>>Зависит от того, что понимаешь под "ci/cd баз данных"

Q>Ну в крадце например: я открыл в vs проект базы данных slq server, что то там сделал, сделал пуш, а на выходе если все прошло удачно получаются два mof-файла один для нового инстанса, другой для обновления. Естественно это все с какими ни будь там тестами. Примерно так. Проблема в том, что я сам точно не знаю, как это должно быть.

Понятнее не стало. Ты про миграцию базы данных что ли (обновление схемы, данных)?

Обычно для этого есть отдельные инструменты, в зависимости от приложения. Т.е. то как обновлять, определяется приложением.
Разработчик пишет скрипты обновления базы вместе с новой версией приложения. Он же пишет тесты.
Практические в любом ORM такое есть, или можно добавть как библиотеку. См. EntityFramework Migrations, FluentMigrator, DbUp, да куча их.

Такой подход гораздо лучше чем слепое вычисление разницы в структуре и потом ее применение (без понимая сути изменений),
т.к. обеспечивает миграцию существующих данных в новую структуру.

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

Здравствуйте, bnk, Вы писали:

bnk>Здравствуйте, Qulac, Вы писали:

Q>>>>Может кто знает, хорошие ресурсы, курсы по этому делу. Буду очень благодарен за ссылки.

Б>>>Зависит от того, что понимаешь под "ci/cd баз данных"

Q>>Ну в крадце например: я открыл в vs проект базы данных slq server, что то там сделал, сделал пуш, а на выходе если все прошло удачно получаются два mof-файла один для нового инстанса, другой для обновления. Естественно это все с какими ни будь там тестами. Примерно так. Проблема в том, что я сам точно не знаю, как это должно быть.

bnk>Понятнее не стало. Ты про миграцию базы данных что ли (обновление схемы, данных)?

В том числе и про нее.

bnk>Обычно для этого есть отдельные инструменты, в зависимости от приложения. Т.е. то как обновлять, определяется приложением.
bnk>Разработчик пишет скрипты обновления базы вместе с новой версией приложения. Он же пишет тесты.
bnk>Практические в любом ORM такое есть, или можно добавть как библиотеку. См. EntityFramework Migrations, FluentMigrator, DbUp, да куча их.

bnk>Такой подход гораздо лучше чем слепое вычисление разницы в структуре и потом ее применение (без понимая сути изменений),
bnk>т.к. обеспечивает миграцию существующих данных в новую структуру.

bnk>Например, добавляешь ты новое поле. Понятно что добавить его можно автоматическим вычислением разницы.
bnk>А во значение в это поле далеко не факт какое нужно прописать, тут все зависит от прилжоения.
bnk>И это простейшая миграция.

Можно и с ORM, хотелось бы сквозной пример увидеть вместе с примером как пользоваться.

Здравствуйте, Qulac, Вы писали:

Q>Можно и с ORM, хотелось бы сквозной пример увидеть вместе с примером как пользоваться.

У DataGrip есть DDL Mapping, работает как в базу, так и из базы. Выглядит многообещающе, только мне его на 10000 объектов не удалось заставить правильно работать, где-то у него крышу сносит.

Здравствуйте, Qulac, Вы писали:

Q>Ну в крадце например: я открыл в vs проект базы данных slq server, что то там сделал, сделал пуш, а на выходе если все прошло удачно получаются два mof-файла один для нового инстанса, другой для обновления. Естественно это все с какими ни будь там тестами. Примерно так. Проблема в том, что я сам точно не знаю, как это должно быть.

Конкретно про MS-stack не знаю. Но в общем случае так:

Обычно изменения в БД (миграции) явно пишет разработчик в отдельные файлики, которые живут в репозитории кода. При выкладке (в ci/cd) инструмент миграции (liquibase, alembic и т.п.) выполняет эти миграции на БД, отслеживая, какие нужно выполнить, а какие уже выполнены ранее (поддерживает для этого историю выполненных миграций в БД). Для пустой БД вообще все просто — после создания БД все миграции выполняются по порядку от первой до последней.

В ci/cd обычно сначала накатываются миграции на БД, затем выкладывается код. Отдельные тесты на миграции обычно не пишут, но миграции тестируются косвенно, через тесты кода. Соответственно код и тесты пишут, считая, что БД уже приведена в нужно состояние (миграции уже выполнились).