Автоматизация привязки базы данных управления исходным кодом Red gate и фиксации в SVN

У нас есть требование, для которого мы хотим иметь Red Gate Source Control как часть автоматизированного интерфейса.

Мы хотели бы программно связать требуемую базу данных и выполнить фиксацию изменений в базе данных.

Это возможно? Если да, то какой API мы должны использовать?


person Bandita    schedule 29.07.2013    source источник


Ответы (4)


Я знаю, что этот вопрос старый, но я делаю именно то, что вы описываете.

У меня есть задание, которое запускается каждые X минут и помещает текущее состояние базы данных в систему управления версиями (для нас это mercurial, но вы можете добиться того же самого с помощью git или чего-то еще).

cd c:\data\SourceCodeDirectory
hg pull
hg update
if not exist "c:\data\SourceCodeDirectory\databaseName" mkdir "c:\data\SourceCodeDirectory\databaseName"
cd "c:\Program Files (x86)\Red Gate\SQL Compare 11"
sqlcompare /s1:DBServer /db1:databaseName /scr2:"c:\data\SourceCodeDirectory\databaseName" /synchronize

cd c:\data\SourceCodeDirectory\databaseName
hg add
hg commit -m "Database Changes" -u DatabaseSchemaUser
hg push

Любые изменения, внесенные в базу данных, будут находиться в системе управления версиями, как только это задание будет запущено.

person chrismay    schedule 20.07.2016

Это тяжело. В зависимости от того, как вы автоматизируете, вы можете использовать комбинацию других программ. Например, если у вас есть какая-то система CI, вы можете автоматически сравнить файлы в системе управления версиями с действующей базой данных с помощью SQL Compare и указать ей синхронизироваться. Вам понадобится интерфейс командной строки системы управления версиями, чтобы вернуть изменения.

SQL Source Control, как часть программного обеспечения, был разработан только для интерактивной работы.

Если вы хотите сделать это в коде (С#, VB), вы можете использовать API системы управления версиями для проверки файлов, если они есть. Например, в SVN есть «SharpSVN», а также есть API для TFS.

person Wonko    schedule 29.07.2013
comment
Спасибо. Мы рассмотрим это, и если у меня останутся вопросы, я их подниму. - person Bandita; 30.07.2013

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

Подобные «автоматические коммиты» обычно сопряжены с риском, поскольку они могут нарушить атомарность и привести к потере информации. Рассмотрим эти сценарии:

  1. Два разработчика работают над независимыми изменениями в базе данных. Они оба изменяют свои соответствующие таблицы одновременно, и эта автоматизация улавливает это и фиксирует изменения таблицы как единое целое. Как разделить эти два вида деятельности?
  2. Когда это произойдет, чье имя будет в журнале изменений репозитория?
  3. Разработчик работает над обширным изменением, которое включает в себя изменения нескольких таблиц и хранимых процедур. Эта автоматизация фиксирует каждый из них независимо. Как вы «связываете» их для регистрации и аудита, просмотра внесенных изменений и т. д.?
  4. В моей среде каждое изменение, зафиксированное в репозитории кода, должно иметь идентификатор изменения, записанный в сообщении фиксации. Как это будет работать здесь?

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

person alroc    schedule 29.07.2013
comment
Я согласен с вами, но дело в том, что мы автоматизируем это в тестовой и производственной среде. Вероятность возникновения этих ошибок значительно меньше в тестовой и производственной среде. Кроме того, чтобы ответить для сценария № 4, если мы автоматизируем процесс, тогда идентификатор изменения будет относиться к приложению, и если кто-то еще попытается внести изменение, он покажет свое имя, и мы сможем узнать, было ли какое-либо вмешательство. . - person Bandita; 30.07.2013
comment
Это даже не требуется в этих средах, потому что в них не должно вноситься никаких изменений без предварительной остановки в системе управления версиями и на ваших серверах разработки. Есть ли у вас ограниченный доступ к тестированию и производству (разделение обязанностей) и четко определенный процесс продвижения изменений от разработки к тестированию и к производству? Если нет, это ничего не исправит и, возможно, сделает ситуацию еще более запутанной. Если это так, это не должно быть необходимо. - person alroc; 30.07.2013

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

Это должно предоставить некоторые полезные ресурсы:

http://www.red-gate.com/products/sql-development/sql-automation-pack/

Существуют сценарии NAnt и MSBuild, которые могут выполнять полезные задачи сборки/тестирования для вашей базы данных SQL Server. Если вы хотите сделать что-то более индивидуальное, вы можете использовать комбинацию командной строки вашей системы контроля версий и командной строки SQL Compare.

person David Atkinson    schedule 05.08.2013