Зберігаються процедури під контролем джерел, найкраща практика

На даний момент я використовую Tortoise SVN для управління джерелом .NET Web Application. Що було б найкращим способом залучення збережених процедур SQL Server до управління джерелами? В даний час я використовую VS 2010 як своє середовище розробки та підключаюсь до базової бази даних SQL Server 2008 R2 за допомогою інструментів даних SQL Server (SSDT).

Те, що я робив у минулому, - це збереження програм у файлі .sql та утримання цих файлів під контролем джерела. Я впевнений, що повинен бути більш ефективний спосіб, ніж цей? Чи є розширення, яке я можу встановити на VS2010, SSDT або навіть SQL Server на виробничій машині?

Там є такі інструменти, як, наприклад, Redgate , але я завжди вважав, що найкраще - це зберегти як файли SQL, можливо, навіть у проекті баз даних (SSDT?) У своєму рішенні.

Поряд із цим я пропоную наступні вказівки:

• Завжди приймайте версію SVN як "поточну" / "останню"
• Переконайтеся, що кожен запущений сценарій має на початку відповідний " if exists then drop" текст
• Не забудьте написати свої дозволи, якщо такі є

Ви можете спочатку створити ці файли SQL, використовуючи сценарії безпосередньо з SSMS, і ви можете встановити SSMS для сценаріїв усіх ваших " drop" і " create", а також ваших прав.

Збереження файлів SQL у керуванні джерелом забезпечує контроль лише над файлами SQL. Він не контролює зміни фактичних об'єктів бази даних, а також не перешкоджає одночасним змінам одного і того ж об’єкта бази даних декількома користувачами (і, мабуть, ви хотіли б, щоб і цей був під контролем). Ми використовуємо сторонній інструмент ( версія ApexSQL)), вона інтегрується як із SSMS, так і з VS, ви можете вибрати, чи працювати з версією бази даних об’єкта, або з версією Source Control. Якщо ви редагуєте версію бази даних, вона автоматично перевіряється лише для вас, тому ніхто більше не може її редагувати (вона не об'єднує зміни у різних користувачів). Тільки коли ви повторно зареєструєте його, інші можуть змінити його. І ви можете мати свою версію SC, відмінну від версії живого об’єкта (я використовую це, коли я виїжджаю на день, і планую закінчити правки та перевірити його на наступний)

Використовуйте RedGate Source Control, щоб підключити його до вашого джерела управління.

http://www.red-gate.com/products/sql-development/sql-source-control/

Він підключить ваш SSMS безпосередньо до сховища управління джерелом і навіть дозволяє перевірити статичні дані.

Працює як шарм

Спробуйте Ankhsvn , дуже рекомендується та безкоштовно.

З домашньої сторінки:

AnkhSVN - постачальник управління субверсійними джерелами для Microsoft Visual Studio 2005, 2008, 2010 та 2012 років .

AnkhSVN надає підтримку управління вихідним кодом Apache ™ Subversion® для всіх типів проектів, що підтримуються Visual Studio, і дозволяє виконувати найпоширеніші операції з управління версіями безпосередньо зсередини IDE Microsoft Visual Studio IDE.

Інформаційна панель очікуючих змін дає вам унікальну інформацію про процес розробки та забезпечує легкий доступ до вихідного коду та функцій управління випуском. Інтеграція управління глибоким вихідним кодом (SCC) дозволяє зосередитись на розробці, а AnkhSVN відстежує всі ваші зміни та надає інструменти для ефективного впорядкування ваших конкретних потреб.

Я спробував як проект бази даних RedGate, так і Visual Studio, і я вважаю за краще зберігати визначення бази даних у проекті бази даних. Як тільки база даних стане частиною рішення, ви можете скористатись уподобаним постачальником джерела управління. Більшість мають чудову інтеграцію Visual Studio.

За допомогою інструментів SSDT у вас є "остання версія" визначення бази даних, що дозволяє вам легко робити порівняння схем і генерувати сценарії оновлення схеми.

Однак, схема зазвичай є лише частиною рівняння. У реальному житті виявляється, що в базах даних вже існує велика кількість даних. І мої користувачі, як правило, дуже розчаровані, коли втрачають його.

Отож, як тільки я розгорнув v1.0, мені потрібно переходити, щоб підтримувати сценарії оновлення. Іноді вони просто містять зміни схеми, але мені багато разів потрібно створювати типові параметри на основі вмісту якоїсь іншої таблиці, потрібно звільняти певне обмеження, поки я не засію дані тощо. Зазвичай просто оновлення схеми не дуже скорочує її. Я вважаю за краще, щоб цей сценарій оновлення містився в окремій папці в проекті баз даних. Зазвичай вони виглядають як "оновлення з v1.0 до v1.1".

У моїх базах даних завжди є довідкова таблиця, яка вказує мені номер поточної версії, тому я можу заблокувати несумісні оновлення. Перше твердження в моїх сценаріях оновлення перевіряє поточну версію та видаляє, чи не відрізняється від очікуваного.

Ще одна перевага проектів баз даних - можливість розгортати різні набори даних на основі однієї схеми. У мене є різні набори даних для розробки, команди з контролю якості, тесту на прийняття користувачів та для тестів автоматизованої інтеграції. Оскільки проект бази даних може мати лише 1 сценарій після розгортання, фокус полягає в тому, щоб створити новий проект бази даних, який посилається на "головний" проект, і зробити власну базу даних частиною процесу розгортання після цього проекту.

Це були мої 2 копійки, який би процес ви не підійшли, перш за все, він повинен відповідати вам та вашій команді та сподіваємось підтримати вас у більшості загальних завдань.

Я закінчив писати інструмент самостійно.

Він доступний для безкоштовного завантаження - http://www.gitsql.net

Я сподіваюся, що це допомагає іншим людям, які хочуть досягти тієї самої кінцевої мети.

Ось стаття, в якій описано, як джерело управління SQL Server. http://gitsql.net/documentation-04_SQL_Server_and_GIT

Я намагався зробити це якомога простіше. (3 екрани)

• Підключення до SQL Server
• Виберіть об'єкти
• Оберіть папку для експорту з / імпорту з

Я також - випадково - додав особливість можливості вибіркового вибору окремих об'єктів для імпорту - чи експорту. Що робить його набагато легшим під час розвитку.

Зазвичай я вносив би зміни до збереженої процедури та таблиці, а потім експортував ці два об'єкти в каталог GIT.

Тоді я використовую Дерево-джерело, щоб візуально побачити зміни, а потім здійснити їх у бітбукет, якщо я щасливий.

Моя компанія щойно розробила цей новий інструмент ( безкоштовний ), який допоможе вам легко витягувати скрипти для баз даних SQL, може робити порівняння , запускати WinMerge для швидкого порівняння сценаріїв з живою базою даних, а також може синхронізувати відмінності як оновлення сценаріїв, так і застосування змін до бази даних (за винятком таблиць, що передбачало б більшу складність та більше ризиків).

Servantt - це WinMerge для порівняння баз даних SQL Server із скриптами, керованими версіями.

Він підтримує та заохочує передовий досвід розробки програмного забезпечення:

• Утримання об'єктів Бази даних під контролем версій (*)
• Видалення прав доступу від розробників у виробничих середовищах
• Огляд DBA змін у процедурах / поглядах на вузькі місця та стандарти найменування
• Іменування об'єктів за допомогою повністю кваліфікованих ідентифікаторів та обмежених кольорів (це виправляє сценарії CREATE PROCEDURE / VIEW / FUNCTION / тощо)

(*) Сценарії зберігаються у локальній папці, яка може бути робочою копією Git, Subversion, TFS, Source Safe або будь-якої іншої VCS.

Безкоштовне завантаження: http://servantt.com

Професійна версія (яка ще розробляється) буде зовсім іншим звіром - вона орієнтована на автоматизацію розгортання (управління випуском), на автоматизацію таких завдань, як оновлення IIS, оновлення служб Windows тощо.