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. Какая результативность внедрения управления кодом?
Например, не нужно будет нанимать новую компанию-разработчика, который всё перепишет.
Например, задачи по новым требованиям, фиксам, оптимизации будут выполняться в разы, или в десятки раз быстрее, если вы видите историю изменений кода с привязкой к задачам, результатам тестирования и т.п.

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, но это для тех, кто не боится трудностей).

Тем не менее - лучше пока всё равно нет.

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

Имеем рассинхронизированные базыИ ещё не понимаю, как прерывание скрипта может рассинхронизировать базу. Ещё раз запустить скрипт никак?

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

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

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

В SSDT никогда раньше такого не было, в проектах типа Dataabse Project нажатие Build ведь не создаёт инсталлятор для апдэйта базы до определённой версии?

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

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

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

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

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


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

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.Вопрос не понял, какие источники данных, и для чего их перегоняют?

PavluxaFЕсли да, то пожалуйста опишите кратенько как рядовой базист сочетает management studio и visual studioКопирует код из окна visual studio в окно query management studio для отладки :-)

Такие переключения же нечасто нужны, либо долго отлаживаешь в SSMS, либо простые процедуры просто пишешь в студии.

HammeralexeyvgКопирует код из окна visual studio в окно query management studio для отладки :-)

Такие переключения же нечасто нужны, либо долго отлаживаешь в SSMS, либо простые процедуры просто пишешь в студии.

Не очень понял назачем Вам нужна VS, когда как для MS есть plug-in, интегрирующий ее с TFSВозможно, я не пробовал пользоваться.

Там будут все возможности TFS, и управление задачами, привязка чекинов к ним, всякие поиски, в общем, получится полноценный TFS-клиент? И солющен будет, проекты, и файлы, не относящиеся к сиквелу?

То есть тогда SSMS станет просто улучшенной студией, с просмотром планов?

Нужно будет посмотреть...

Критикalexeyvg,

да что вы к этим плана привязались, есть они )О, круто. Всё в студии есть!