Управление исходным кодом SQL Server

Ответ 1

Недавно мы использовали Visual Studio Team System Database Edition, и я должен сказать, что он работал очень хорошо. Все хранимые процедуры хранятся в виде файлов, а также проверяются и удаляются из исходного элемента управления, а также имеют инструменты для генерации скриптов и т.д.

Кроме того, в прошлом мы использовали скрипты, хранящиеся в виде текстовых файлов, которые проверяются и контролируются источником. Правило состояло в том, что вам нужно было проверить файл, а затем отредактировать его, например, в Management Studio, и сохранить его, и проверить его обратно. В верхней части каждой хранимой процедуры script файл будет удалено существующее хранилище proc, а затем использовать оператор CREATE для создания нового (обходит проблему CREATE/ALTER). Затем у нас был инструмент, который запускал бы все скрипты в правильном порядке для создания пустой базы данных с нуля, а затем мы использовали RedGate SQL Compare product для создания script для обновления наших существующих баз данных. Я признаю, что это утомительно.

Примерно в то же время я работал над системой с примерно 10 другими разработчиками, и они внедрили строгую процедуру управления изменениями базы данных. Было много приложений, которые зависели от набора из 2 или 3 баз данных. Каждый раз, когда необходимо было изменить схему базы данных (мы говорим только о таблицах, столбцах и представлениях), тогда был создан документ, в котором объяснялось изменение, а затем появилась матрица, в которой перечислены изменения в сравнении с теми приложениями, которые, по нашему мнению, будут влиять, Затем документ был распространен и должен был быть рассмотрен кем-то ответственным за каждое выражение, и им пришлось искать в своем приложении все, что могло бы быть затронуто, и т.д. Это была долгая трудная процедура, но она сработала. Тем не менее, сохраненные procs были просто сохранены в виде текстовых файлов в исходном элементе управления.

В более отдаленном прошлом с меньшими проектами, которые были больше похожими на настольные приложения с базой данных в качестве хранилища данных, каждый раз, когда приложение запускалось, я бы:

• Проверьте, существует ли база данных, а если нет, создайте ее
• Убедитесь, что все таблицы существуют, а если нет, создайте их
• Убедитесь, что все столбцы существуют, а если нет, добавьте их

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

Вы можете уменьшить некоторые из этих проблем, приняв ADO.Net Entities или другую аналогичную инфраструктуру Entity Framework, например Entity Spaces. Это объектно-реляционные слои отображения. Они автоматически генерируют классы для каждого объекта (таблицы) в вашей базе данных, включая свойства для каждого столбца и т.д. Затем они позволяют расширить эти классы с помощью настраиваемой логики. Если вы можете уйти от своей бизнес-логики в хранимых процедурах и поместить их в классы Entity, то преимущество в том, что они строго типизированы. Поэтому, если вы измените имя столбца или удалите столбец, и вы обновите классы сущностей, тогда ваша среда IDE или компилятор автоматически отметят все места, где был нарушен код. Очевидно, что весь код сущности, естественно, находится в контроле источника с остальной частью исходного кода.

Ответ 2

Red Source SQL Source Control полностью интегрирует исходный контроль в SQL Server Management Studio. Это эффективно связывает ваши базы данных разработки с существующей системой управления версиями (TFS и SVN), позволяя совершать изменения и извлекать изменения других разработчиков одним нажатием кнопки.

http://www.red-gate.com/products/SQL_Source_Control/

Теперь мы добавили поддержку VSS и SourceGear Vault в версию EA. Подробнее здесь: http://www.red-gate.com/MessageBoard/viewtopic.php?t=12265

Ответ 3

То, как я видел, что управление исходным кодом лучше всего подходит для SQL Server в командной среде, было тогда, когда администратор баз данных делал регулярные сборки базы данных с помощью кода с проверкой. Обычно требуется только один экземпляр, чтобы потерять что-то, потому что он не был проверен, прежде чем разработчики получат изображение, что проверка их кода означает что-то.

Надеюсь, что это поможет,

Билл

Ответ 4

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

Администраторам баз данных были даны заметки о выпуске, которые требовали от администратора базы данных получить исходный контроль, а затем отпустить изменения хранимой процедуры или SQL-скрипты. Если вы можете получить DBAs на стороне, то это хороший способ избежать прерванных выпусков, так как вы должны иметь возможность предварительно протестировать SQL в системе UAT.

Если данные не выпущены в исходное управление, он не освобождается.

Для освобождения кода были использованы ветки интеграции.

Ответ 5

Мы всегда использовали утилиту scptxfr, которая поставляется с SQL Server 2000 до script базы данных, в файл, который хранится под контролем источника.

Мы запускаем его перед выполнением проверки, и он будет выделять любые шансы, которые произошли (независимо от того, ожидаются они или нет). Он не приходит с 2005 года или позже, но если у вас есть старая версия 2000, она по-прежнему работает против более новых версий. У этого могут быть проблемы со сложными схемами, но это хорошее начало. Это также можно было бы сделать автоматическим процессом в сочетании с триггерами управления источником или непрерывной интеграцией.

Ответ 6

Ключ состоит в том, чтобы ограничить право производить только несколько человек и настаивать на том, что они никогда не вносят изменений, кроме как путем вызова script из исходного элемента управления. В новых версиях SQl Server вы также можете настроить ведение журнала DDL, чтобы точно выяснить, кто изменил эту таблицу на версию, отличную от Source Control!

Когда мы впервые перешли к использованию источника управления в нашей базе данных, у всех были права prod (с тех пор, как мы исправили), поэтому у нас была dba, периодически сравнивающая проверки исходного кода с фактической базой данных prod и избавляясь от любые несанкционированные изменения. Это потребовалось только один раз, чтобы убедить разработчиков, что они должны использовать контроль источника.

Ответ 7

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

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

http://trycatchfinally.net/2011/06/roll-your-own-lightweight-sql-server-source-control/

Ответ 8

Предоставление разработчикам возможности запоминать код сложно.

Другой конец этого немного проще, потому что, как только обновления находятся в исходном управлении, они могут быть автоматизированы с помощью скриптов для создания новой базы данных/или удаления и воссоздания базы данных из исходного элемента управления.

Просмотрите этот бесплатный продукт, который поможет настроить базовую базу данных SQL Server.

Инструмент также будет создавать БД из исходного управления, поэтому теоретически вы можете иметь разработчиков X, работающих над проектом, и все они могут запускать друг друга из источника в свою собственную базу данных - и наоборот, развертывая их обновляется обратно в исходное управление.

К сожалению, - я не могу придумать, как заставить разработчиков помнить о внесении изменений в БД. Возможно, они могут запустить инструмент (или пакетный файл), который будет выполнять привязку локальной базы данных к исходному элементу управления, а затем получить привычку запускать эту повторяющуюся задачу через пакетный файл - каждый раз, когда они приходят к выполнению pull/commit в источнике контроль?