Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 ms sql server continuous integration and shared static data  [new]
mazzy
Member

Откуда: Москва
Сообщений: 2343
почитал про инструменты continuous integration для баз данных вообще и для MS SQL в частности.

принцип понятен:
1. создаем дев-тест-merge-build-.... окружения различными способами
2. заливаем тестовые данные в эти окружения
3. тестируем-билдим...
4. заливаем на прод

получается, что нужно много баз с тестовыми данными.

если у нас корпоративное приложение с рабочей базой на MS SQL в несколько терабайт, то возникает вопрос как сделать корректные тестовые данные? генерить собственную маленькую AdventureWorks - тот еще проект с непонятной трудоемкостью и непонятной корректностью.

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

возникает технический вопрос к MS SQL - а можно ли как-то сказать MS SQL что у данных в разных базах есть общий (shared) кусок первоначальных данных, а в каждом окружении храни только изменения от этого куска?

что-то вроде снапшотов для виртуальных машин (внимание! снапшоты MS SQL не подходят, поскольку они дают только read-only доступ к данным).
или вроде докера для данных.

есть ли такое? как называется?
ткните носом куда рыть, пожалуйста.
29 авг 19, 11:26    [21959656]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
Minamoto
Member

Откуда: Москва
Сообщений: 1041
mazzy
есть ли такое? как называется?
ткните носом куда рыть, пожалуйста.


Есть такая штука как SQL Clone: https://www.red-gate.com/products/dba/sql-clone/
Мы как то игрались (тоже для CI, да), не могу сказать, что особо успешно. Может у вас лучше получится...
29 авг 19, 11:36    [21959665]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6697
mazzy,

Смотря что Вы намерены проверять. Если функции кода, то все справочные данные, необходимые для тестирования формируются руками в теле теста в проекте "модульные тесты" VS. Это тоже не сложно, т.к. тесты могут содержать похожие наборы. Просто копируете при написании теста.

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

Тестирование в духе "лучших практик" проходит три этапа - локальное тестирование автотестами, т.е. у каждого разработчика развернута конфигурируемая версионируемая среда (студия, сервер, эмуляторы), после разработки перед чек-аут разработчик проверяет локально модульными тестами разработку (желательно регрессионно). А ещё лучше, когда тесты разработчик пишет в первую очередь. Затем наступает очередь публикации центрального репозитория на единую систему тестирования непрерывной интеграции, которая раз в сутки высылает протокол ошибок. После окончания этапа разработки версия продукта проходит дополнительное ручное тестирование на приёмочном сервере, после этого накатывается на прод.
29 авг 19, 11:57    [21959684]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
mazzy
Member

Откуда: Москва
Сообщений: 2343
Minamoto
mazzy
есть ли такое? как называется?
ткните носом куда рыть, пожалуйста.


Есть такая штука как SQL Clone: https://www.red-gate.com/products/dba/sql-clone/
Мы как то игрались (тоже для CI, да), не могу сказать, что особо успешно. Может у вас лучше получится...

о, спасибо. похоже на то, что хочется. покопаю.

значит, нет стандартных средств... жаль.

Владислав Колосов
А ещё лучше, когда тесты...

это понятно, что лучше быть богатым и здоровым, чем бедным и больным.
спасибо.
29 авг 19, 12:40    [21959724]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
mazzy
Member

Откуда: Москва
Сообщений: 2343
Minamoto
Есть такая штука как SQL Clone: https://www.red-gate.com/products/dba/sql-clone/

работает на уровне vhd-файлов. прикольная мысль.
29 авг 19, 13:20    [21959798]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6697
mazzy,

так стремитесь к здоровью. За пять минут проблему вы не решите. Лучше с самого начала использовать проверенные методки, чем потом зайти в тупик из-за нехватки ресурсов, квалификации персонала и так далее.
29 авг 19, 13:24    [21959804]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
mazzy
Member

Откуда: Москва
Сообщений: 2343
Владислав Колосов
Лучше с самого начала использовать проверенные методки, чем потом зайти в тупик из-за нехватки ресурсов, квалификации персонала и так далее.

:)
абсолютно согласен.

по поводу SQL Clone. Оставлю для истории: https://habr.com/ru/post/440804/
29 авг 19, 13:28    [21959814]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 28996
mazzy
если у нас корпоративное приложение с рабочей базой на MS SQL в несколько терабайт, то возникает вопрос как сделать корректные тестовые данные? генерить собственную маленькую AdventureWorks - тот еще проект с непонятной трудоемкостью и непонятной корректностью.

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

А для теста лучше восстанавливать рабочую БД, потому что, несмотря на размер БД, её бакап всё равно нужно где то проверять путём восстановления.
Притом нужно отметить, что для "корпоративных баз в несколько терабайт" будет достаточно одного копеечного HDD. Тут же не нужна производительность, нужна только ёмкость.
29 авг 19, 22:22    [21960170]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 32129
Блог
alexeyvg
Притом нужно отметить, что для "корпоративных баз в несколько терабайт" будет достаточно одного копеечного HDD. Тут же не нужна производительность, нужна только ёмкость.


Это в теории. А на практике с таким подходом потеряете кучу времени разработчиков, цена простоя за год выйдет подороже, чем хороший массив.
30 авг 19, 07:52    [21960233]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 28996
Критик
alexeyvg
Притом нужно отметить, что для "корпоративных баз в несколько терабайт" будет достаточно одного копеечного HDD. Тут же не нужна производительность, нужна только ёмкость.

Это в теории. А на практике с таким подходом потеряете кучу времени разработчиков, цена простоя за год выйдет подороже, чем хороший массив.
Я же не против хорошего массива, но даже в хорошем массиве стоимость терабайта небольшая, если хранилище проектировалось для объёма, а не для скорости.
30 авг 19, 09:12    [21960271]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
Гулин Федор
Member

Откуда: МИНСК
Сообщений: 1046
alexeyvg
mazzy
если у нас корпоративное приложение с рабочей базой на MS SQL в несколько терабайт, то возникает вопрос как сделать корректные тестовые данные? генерить собственную маленькую AdventureWorks - тот еще проект с непонятной трудоемкостью и непонятной корректностью.

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

А для теста лучше восстанавливать рабочую БД, потому что, несмотря на размер БД, её бакап всё равно нужно где то проверять путём восстановления.
Притом нужно отметить, что для "корпоративных баз в несколько терабайт" будет достаточно одного копеечного HDD. Тут же не нужна производительность, нужна только ёмкость.


я правильно понимаю что для DEv -
это РУЧНОЙ скрипт ?
ну ведь там FK-s - какие то таблицы целиком тянуть
какие то можно за месяц и т.д и т.п
фактически такой полноценный ETL
к-й будет устаревать к тому же с появлением новых таблиц ?
3 сен 19, 17:00    [21962704]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 32129
Блог
Гулин Федор,

В dev-среде можно многим пренебречь, в том числе и FK
3 сен 19, 17:06    [21962710]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 28996
Гулин Федор
alexeyvg
пропущено...
Для dev можно генерить синтетические данные, либо брать небольшую вырезку из рабочих данных.

А для теста лучше восстанавливать рабочую БД, потому что, несмотря на размер БД, её бакап всё равно нужно где то проверять путём восстановления.
Притом нужно отметить, что для "корпоративных баз в несколько терабайт" будет достаточно одного копеечного HDD. Тут же не нужна производительность, нужна только ёмкость.
я правильно понимаю что для DEv -
это РУЧНОЙ скрипт ?
ну ведь там FK-s - какие то таблицы целиком тянуть
какие то можно за месяц и т.д и т.п
фактически такой полноценный ETL
к-й будет устаревать к тому же с появлением новых таблиц ?
Да, правильно.
Понятно же, что никакая разработанная изготовителем БД логика не может учесть бизнес-логику ваших данных, а получить обрезанную версию БД без учёта бизнес-логики данных невозможно.

Соответственно, остаётся либо создавать ETL-решение для частичного переноса данных (возможно, с деперсонализацией и искажениями цифр), или генерить тестовые данные (для чего в принипе существуют всякие решения, но они тоже не делают всё "одной кнопкой")

Или, как вариант, использовать в качестве дева копию продакшен базы (как и для теста), что, разумеется несравнимо дешевле, потому что десяток терабайт даже на SSD-массиве не сравнить по стоимости с полноценным проектом.

Критик
В dev-среде можно многим пренебречь, в том числе и FK
Это да, но лучше делать дев полноценной копией продакшена (по модели и логике данных), что бы понизить стоимость разработки.
3 сен 19, 22:13    [21962897]     Ответить | Цитировать Сообщить модератору
 Re: ms sql server continuous integration and shared static data  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 6697
Гулин Федор
alexeyvg
пропущено...
Для dev можно генерить синтетические данные, либо брать небольшую вырезку из рабочих данных.

А для теста лучше восстанавливать рабочую БД, потому что, несмотря на размер БД, её бакап всё равно нужно где то проверять путём восстановления.
Притом нужно отметить, что для "корпоративных баз в несколько терабайт" будет достаточно одного копеечного HDD. Тут же не нужна производительность, нужна только ёмкость.


я правильно понимаю что для DEv -
это РУЧНОЙ скрипт ?
ну ведь там FK-s - какие то таблицы целиком тянуть
какие то можно за месяц и т.д и т.п
фактически такой полноценный ETL
к-й будет устаревать к тому же с появлением новых таблиц ?


Как раз для таких случаев создаются синтетические репрезентативные наборы данных, один раз и на все время. Поскольку код теста может разрушать данные, то он должен выполняться либо в транзакции, либо, если это невозможно, "убирать мусор" и "ремонтировать" данные.

Полнообъемные наборы могут потребоваться для нагрузочного тестирования, а это уже другая история.
4 сен 19, 13:32    [21963382]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить