Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Continious Integration (MS SQL + SSDT)  [new]
PavluxaF
Member

Откуда: СПб
Сообщений: 126
Доброго времени суток!

Хотелось бы поднять обсуждение организации процесса непрерывной интеграции при разработке на SQL Server + SSIS + SSRS + SSAS.

Из информации в открытом доступе:
Самое интересное - [url=]http://habrahabr.ru/post/258005/[/url]
есть еще пару StackOverflow с "вялыми" комментариями и все.

Из того, чем пробовал заниматься сам:
На прошлой работе пробовал организовать разработку из среды VS 2013, однако даже самому не понравилось, не говоря о мотивации коллектива.
Из недостатков данного подхода могу выделить слабенькое окружение для разработчика БД в VS 2013 (как например отсутствие execution plan и т.д.)
Таскать код туда-сюда - вероятнее всего будет проходить его рассинхронизация (при таком подходе стажеры будут производить фурор!)

Посмотрел продукты RedGate.
Вроде все красиво, в моем случае даже очень выгодно (возможно интегрировать в JIRA), однако --- цена вопроса!

Хотелось бы узнать у Вас, коллеги:
1) используются ли в Ваших компаниях подобные практики? (Если можно список используемых продуктов и организация процесса)
2) вопрос по продуктам Red Gate - качество исполнения, удобство, надежность и т.д.
3) результативность внедрения? Если я потрачу 10 000$, а результата не будет, меня просто уволят))

Буду рад ссылкам на любую полезную литературу.
За ранее благодарю
6 авг 15, 10:08    [17982198]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
Maxx_UA
Guest
PavluxaF
Доброго времени суток!

3) результативность внедрения? Если я потрачу 10 000$, а результата не будет, меня просто уволят))


как говорил,помоему,Форд - если вы не можете описать процесс вы его не сможете оптимизировать
Внедрять можно что угодно и за какире угодно деньги... но если нет хорошо документированного процесса то и 1 лям баксов можно спустить на ветер.
Посему любой такое начи нание начинаеться с описания процесса и применения к нему выбранных методик - все остальное просто инструмент реализации, не более. Посему начните для себя с поставноки задачи - что я хочу в итоге получить со всего етого...а потом выберайте подходящий интрумент.
6 авг 15, 10:18    [17982268]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
AlanDenton
Member [скрыт]

Откуда:
Сообщений: 985
С предыдущим комментарием согласен.

Лишь добавлю от себя. Redgate это конечно круто, но немного дорого. Например, у меня лицензия на SQL Prompt, но это не говорит о том, что другие продукты от этой фирмы стоят своих денег. Хотите сэкономить - смотрите в сторону альтернатив от DevArt и APEX SQL.
6 авг 15, 10:53    [17982526]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
PavluxaF
Member

Откуда: СПб
Сообщений: 126
Ок, согласен.

Процесс разработки следующий:
Стенды:
Local
Dev
Test
Production

Разработка на Local с данными за маленький период.
Процесс:
Делаем checkout -> работаем -> checkin на Dev (Dev и Test могут быть одним и тем же (пока не определились))
Далее тестирование
Раз в некоторое время Dev заливается в Production

В чем оптимизация: Рутина по ручной подготовке скриптов, передачи их админам prod-а, тестирование сейчас ручное


Нагуглил еще возможность коннекта из SSMS к TFS, тоже хочу узнать отзывы об использовании?
6 авг 15, 11:26    [17982783]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
PavluxaF
Member

Откуда: СПб
Сообщений: 126
Из методик - SCRUM
6 авг 15, 11:27    [17982792]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
Maxx_UA
Guest
Сам процесс длинный и итерационный не буду описывать - просто формализирую пункты ,что юзаем :
Описание задачи етц -JIRA
Система хранеия версий - SVN
Средства разработки - SSMS,MVS + SQL Century +Beyond Compare
6 авг 15, 11:55    [17982984]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 5987
А какие проблемы со скриптами-то? Или вы программируете исключительно на GUI?
6 авг 15, 12:02    [17983031]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
PavluxaF
Member

Откуда: СПб
Сообщений: 126
GUI вообще не пользуюсь.
Пример неприятной ситуации:
DEV = PROD
данных много
на DEV накатил скрипт строк на 100-200 (для примера), меняющий данные, структуры и т.д.
случайно срубил скрипт CloseAllTabs

Имеем рассинхронизированные базы (продуктов типа SQL DATA CHECK и SCHEMA CHECK --- нет)
6 авг 15, 12:42    [17983319]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
Maxx_UA
Guest
PavluxaF
GUI вообще не пользуюсь.
Пример неприятной ситуации:
DEV = PROD
данных много
на DEV накатил скрипт строк на 100-200 (для примера), меняющий данные, структуры и т.д.
случайно срубил скрипт CloseAllTabs

Имеем рассинхронизированные базы (продуктов типа SQL DATA CHECK и SCHEMA CHECK --- нет)


а вот ето вы ничем не исправите....ето называеться культура разработки однако
как минимум
Перед такими скриптами - прогоняеться скрипт "бекапа" для изменемых сущностей..на то он и ДЕВ сервер,чтоб на нем можно было до опупнения анкатывать такие скрипты, тестировать,возращать к исходному состоянию если надо. Хуже все скрипты такого толка - должны быть ПЕРЕНАКАТЫВАЕМЫЕ и не включать в себя изменение более 1 бизнесс сущности.
6 авг 15, 12:47    [17983365]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 5987
PavluxaF, дык перед накатом скрипта создавайте снапшот базы для отката. И рубите все, что пожелаете.
6 авг 15, 13:18    [17983599]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
PavluxaF
Member

Откуда: СПб
Сообщений: 126
Очень большое спасибо Maxx_UA за APEX SQL. Сбил цену в 3 раза. Ищу дальнейшие пути оптимизации))

Что касается :
автор
а вот ето вы ничем не исправите....ето называеться культура разработки однако


SQL Data Compare | SQL Schema Compare для этого и ищу такие продукты тоже. Все дорого!
6 авг 15, 14:59    [17984423]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 5987
Зачем что-то сравнивать, не пойму? Вы пишите ALTER код и его применяете. Не нужны никакие сравнения, т.к. источник изменений для продуктива единственный.
6 авг 15, 15:19    [17984521]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
PavluxaF
Member

Откуда: СПб
Сообщений: 126
Если PROD рассинхронизировался с DEV, причем я знаю что на DEV накатил правильные изменения, но скрипта не осталось --->
SCHEMA COMPARE сгенерит код ALTER something, а DATA COMPARE - выровняет данные
6 авг 15, 15:31    [17984600]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2371
PavluxaF
Если PROD рассинхронизировался с DEV, причем я знаю что на DEV накатил правильные изменения, но скрипта не осталось --->
SCHEMA COMPARE сгенерит код ALTER something, а DATA COMPARE - выровняет данные


все зависит от ситуации и от продуктива, я на своем продуктиве никогда не дам никакой программе запускать скрипты в автоматическом режиме, потому как 10 лиардов строк, шагвлево-шагвправо и каюк продакшену, а никакая машина этого не понимает, голову надо включать на продуктиве, а не автопрогон скриптов.
6 авг 15, 16:07    [17984830]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 5987
Чтобы скрипты объектов не терялись, правильные разработчики используют системы версионирования.
6 авг 15, 17:37    [17985299]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 27433
PavluxaF
Из информации в открытом доступе:
Самое интересное - http://habrahabr.ru/post/258005/
По ссылке - веб-программиста взяли начальником, вот, выпали базы данных, ну он и руководит. :-)
Не видно вменяемой организации. Про процесс написано, но при чём тут руководитель отдела БД?
Процесс он может придумать, или его могут ему спустить сверху, но тут это обсуждать не имеет смысла, это всё таки форум по MSSQL, а не про управление проектами и процессами.
А про организацию разработки именно MSSQL он не пишет, только типа "нажали кнопку - оно и хорошо".
PavluxaF
Хотелось бы узнать у Вас, коллеги:
1) используются ли в Ваших компаниях подобные практики? (Если можно список используемых продуктов и организация процесса)
2) вопрос по продуктам Red Gate - качество исполнения, удобство, надежность и т.д.
3) результативность внедрения? Если я потрачу 10 000$, а результата не будет, меня просто уволят))
1. Какие "подобные"? Именно такие не используются.
В последние 17 лет использовал для работы с MS стеком технологий её же продукты разработки и организации - VSS, TFS, Visual Studio. По моему, это вполне логично, хотя, конечно, многое у них несоверешнно, можно прилепить и ещё что то.
Ещё использовали в некоторых фирмах ErWin и PowerDesigner. Но продукты дорогие, по вашим меркам, там на одного человека лицензия будет 10 000$

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

3. Какая результативность внедрения управления кодом?
Например, не нужно будет нанимать новую компанию-разработчика, который всё перепишет.
Например, задачи по новым требованиям, фиксам, оптимизации будут выполняться в разы, или в десятки раз быстрее, если вы видите историю изменений кода с привязкой к задачам, результатам тестирования и т.п.
6 авг 15, 21:15    [17986044]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 27433
PavluxaF
Пример неприятной ситуации:
DEV = PROD
данных много
на DEV накатил скрипт строк на 100-200 (для примера), меняющий данные, структуры и т.д.
случайно срубил скрипт CloseAllTabs

Имеем рассинхронизированные базы (продуктов типа SQL DATA CHECK и SCHEMA CHECK --- нет)
Не понимаю я таких нгеприятных ситуаций.

1. У вас есть DEV, там девы девелопят.
Результатом работы девелоперов является инсталлятор новой версии (скрипты изменений базы, SSIS пакеты и прочее)

2. Вы восстанавливаете бакап продакшена на тест, запускаете инсталлятор, тестеры неделю тестят, потом инсталлятор накатывается на продакшен. Под контролем билд мастера, тим-лида девелоперов, DBA. С бакапом наготове. Но при такой схеме вероятность факапов необычайно низка.

3. Если тестеры не принимают версию на тесте, на продакшен она не заливается, девелоперы работают дальше, исправляют свои косяки.

При такой схеме у вас проект соответствует продакшену, деплои версий проходят гладко, без проблем, все изменения запротоколированы и привязаны к задачам, бизнес-требованиям.
PavluxaF
На прошлой работе пробовал организовать разработку из среды VS 2013, однако даже самому не понравилось, не говоря о мотивации коллектива.
Из недостатков данного подхода могу выделить слабенькое окружение для разработчика БД в VS 2013 (как например отсутствие execution plan и т.д.)
Да, VS 2013 - не самое сильное средство для разработки БД, хуже даже не отсутствие планов (тяжёлые запросы можно отладить и в SSMS), а отсутствие хорошего графического представления модели данных, причём доступного для групповой разработки, и отсутствие простых средств подготовки инсталлятора (хотя можно использовать MSBuild, но это для тех, кто не боится трудностей).

Тем не менее - лучше пока всё равно нет.
6 авг 15, 21:50    [17986197]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 27433
PavluxaF
на DEV накатил скрипт строк на 100-200 (для примера), меняющий данные, структуры и т.д.
случайно срубил скрипт CloseAllTabs

Имеем рассинхронизированные базы
И ещё не понимаю, как прерывание скрипта может рассинхронизировать базу. Ещё раз запустить скрипт никак?
6 авг 15, 22:03    [17986247]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30746
Блог
alexeyvg
и отсутствие простых средств подготовки инсталлятора (хотя можно использовать MSBuild, но это для тех, кто не боится трудностей)


не совсем понял,
что мешает нажать Build и получить скрипт изменений (с неявным использованием MSBuild)?
6 авг 15, 22:41    [17986337]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 27433
Критик
alexeyvg
и отсутствие простых средств подготовки инсталлятора (хотя можно использовать MSBuild, но это для тех, кто не боится трудностей)


не совсем понял,
что мешает нажать Build и получить скрипт изменений (с неявным использованием MSBuild)?
В SSDT, или вы про другие типы проектов?

Вообще может быть, в новых версиях это и стало возможным, но я про это не слышал...
Нужно вообще поизучать.

В SSDT никогда раньше такого не было, в проектах типа Dataabse Project нажатие Build ведь не создаёт инсталлятор для апдэйта базы до определённой версии?
7 авг 15, 00:22    [17986661]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30746
Блог
alexeyvg
В SSDT никогда раньше такого не было, в проектах типа Dataabse Project нажатие Build ведь не создаёт инсталлятор для апдэйта базы до определённой версии?


при любом Build создает dacpac-файл, а при Publish - файл с изменениями,
так делают VS2013 и VS2015, про более ранние версии не скажу
7 авг 15, 07:31    [17986888]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 27433
Критик
alexeyvg
В SSDT никогда раньше такого не было, в проектах типа Dataabse Project нажатие Build ведь не создаёт инсталлятор для апдэйта базы до определённой версии?


при любом Build создает dacpac-файл, а при Publish - файл с изменениями,
так делают VS2013 и VS2015, про более ранние версии не скажу
А, если dacpac-файл, то вы про SSDT?

Да, в SSDT проектах можно делать и апдэйты версий, и инсталляцию с нуля.

Но тут возникает несколько другой вопрос, о применимости концепции SSDT к разным типам проектов.

И, как я понимаю, ТС его не применяет?
Хотя в названии темы SSDT, но потом всякие рассуждения о скриптах, CloseAllTabs, сравнении схем - к чему это, если тип проекта SSDT?


Ну, и ещё раз хочу подчеркнуть, что для начала нужно разработать и озвучить концепцию ведения проекта, схему - без использования названий продуктов.
Потому что озвучиваемые PavluxaF проблемы вроде рассинхронизаций, потерь данных, неуверенности в работоспособности продакшена после апдэйта, прочих факапов, есть результат непродуманной схемы, непродуманных требований к процессу, непродуманного процесса, а не недостаток инструментов.
7 авг 15, 10:31    [17987526]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
PavluxaF
Member

Откуда: СПб
Сообщений: 126
alexeyvg , комментарии грамотные.

Единственное, про прерывание скрипта вопрос не стоял, речь шла о том, что срипт накатили на DEV и не сохранили.

Хотелось бы спросить про организацию SVN.
Что и чем версируете?
Тут более детализирую вопрос:
- интересует атомарность версий
- интересует порядок организации целостности данных

Например все работают на централизованном DEV. Допустим накат DEVа на TEST - еженедельный
Для себя представляю примерно следующий порядок работы:
Есть backup (или параллельная копия DEV) в начале недели. Есть централизованный репозиторий. Все изменения в виде скриптов закидываются в репозиторий -> ежесуточно каким-либо SVN создается subversion. Еженедельно DEV перегоняется на TEST и если он проходит успешно, мы считаем это версией.

Остается открытым вопрос - в случае если TEST надо вернуть в DEV как разруливать изменения, созданные за время тестирования.
В моем понимании только руками при тщательном контроле. Благо историю суточных изменений мы будем иметь.

Можно ли оптимизировать данный процесс?

Еще один вопрос - ежесуточное создание subversion. Некоторые работы могут оставаться не законченными. Стоит ли создать корпоративное правило закрывать subversion в целостном состоянии системы?
7 авг 15, 10:47    [17987636]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
PavluxaF
Member

Откуда: СПб
Сообщений: 126
Еще один вопрос касается миграции версий.
Как Вы перегоняете источники с данными с DEVа на TEST, с TESTа на PROD.
С какими проблемами сталкивались?
7 авг 15, 10:49    [17987651]     Ответить | Цитировать Сообщить модератору
 Re: Continious Integration (MS SQL + SSDT)  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 27433
PavluxaF
Единственное, про прерывание скрипта вопрос не стоял, речь шла о том, что срипт накатили на DEV и не сохранили.
А, ну тогда это не проблема. На DEVе может быть бардак, хлам, DEV может не соответствовать проекту и продакшену по тыще причин - понятно, там же его курочат и портят.
Но важно, что деплой-скрипты должны формироваться как инкремент изменения проекта, и не как инкремент изменения DEVа. И потом по цепочке.
А DEV - просто восстанавливаем его время от времени из продакшена/теста, и всё хорошо.

PavluxaF
Хотелось бы спросить про организацию SVN.
Что и чем версируете?
Тут более детализирую вопрос:
- интересует атомарность версий
- интересует порядок организации целостности данных

Например все работают на централизованном DEV. Допустим накат DEVа на TEST - еженедельный
Для себя представляю примерно следующий порядок работы:
Есть backup (или параллельная копия DEV) в начале недели. Есть централизованный репозиторий. Все изменения в виде скриптов закидываются в репозиторий -> ежесуточно каким-либо SVN создается subversion. Еженедельно DEV перегоняется на TEST и если он проходит успешно, мы считаем это версией.
TFS
Про атомарность и целостность вопроса не понял.

Идёт разработка, разработчики чекинят изменения, привязывая их к задачам, и закрывают задачи.
Тестеры делают первичное тестирование на DEV, что типа задача сделана, работает, или пофиксенный баг действительно исчез.

И они отмечают те задачи, которые они заапрувили далее на деплой.

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

Можно делать и ветки, но тогда придётся делать мердж при апруве веток, мы обычно так не делали, кроме редких случаев.
К тому же ИМХО при разработке именно БД, при таких изменениях, которые глобально меняют существующую модель данных, лучше применять другой метод: делать независимый модуль, с новыми таблицами и т.д., и со скриптами переливки/модификации данных.
И ещё - если принимать подход с "ветками", то не всегда можно работать на одном DEVе.


Далее, независимо от наличия веток, в итоге, мы получаем инкремент основной ветки. Вот это есть то, из чего получается деплой-скрипты.
PavluxaF
Остается открытым вопрос - в случае если TEST надо вернуть в DEV как разруливать изменения, созданные за время тестирования.
В моем понимании только руками при тщательном контроле. Благо историю суточных изменений мы будем иметь.
Не надо TEST возвращать в DEV, это принципиально неверно, зачем вам TEST - копия DEVа? Каким целям служит такой тест?

Нужно TEST при неуспехе деплоя (тестирования) вернуть в продакшен, восстановлением из бакапа (продакшена на тест).
И при необходимости - DEV вернуть в продакшен, восстановлением из бакапа (продакшена на DEV) - это если DEV совсем разрушили, и непонятно, как дальше разрабатывать. Но это не нужно часто делать, только если приспичит, поскольку тогда каждому разработчику нужно восстановить на деве то, что он там делал.

PavluxaF
Еще один вопрос - ежесуточное создание subversion. Некоторые работы могут оставаться не законченными. Стоит ли создать корпоративное правило закрывать subversion в целостном состоянии системы?
Это несколько другой вопрос, это не относится к самому процессу деплоя изменений проекта на продакшен, с тестированием, откатами и т.д., который мы тут обсуждаем. Но зависит от используемой системы сорс-контроля и испольуемой парадигме. Не везде же используют разделение на ветки и последующий мердж.

Я уже выше сказал - при типичном изменении проекта БД (фиксы, небольшие изменения/расширения функциональности) я не вижу необходимости делать subversion и потом мержить. При крупных подпроектах можно делать, но в виде отдельных модулей, и не включать их в деплой, т.к. соответствующий таск не закрыт, а эти модули на остальное не влияют.
Впрочем, можно subversion и не делать, т.к. в таком случае отдельные новые модули проекту и не мешают.
PavluxaF
Как Вы перегоняете источники с данными с DEVа на TEST, с TESTа на PROD.
Вопрос не понял, какие источники данных, и для чего их перегоняют?
7 авг 15, 11:20    [17987833]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить