AutoPatch.Net 0.0.2

Обновил autopatch до версии 0.0.2 - теперь поддерживаются скрипты, содержащие GO. Как результат - можно создать differentional script при помощи например RedGate SQL Compare или VS for Database Professionals, и накатывать такой скрипт автопатчем без изменений

Скачать новую версию можно здесь:
http://code.google.com/p/autopatchnet/

AutoPatch .Net - how it works

Выложил на RSDN небольшой рассказ о том, как работает AutoPatch .Net

http://rsdn.ru/forum/dotnet/3518828.1.aspx

Встречаем: AutoPatchNet with nice UI

.Net port of Tactiknowledge AutoPatch.

Доработал и выложил на Google Code исходники и инсталлятор пре-пре-альфа версии 0.0.1 .Net-овского порта AutoPatch. Авторы начали портирование, но забросили его в лохматом году.

Я довел порт до состояния, когда он уверенно патчит SQLServer-ные базы и добавил к нему консольный и WinForm-овские front-end-ы.

Кроме того, я попробовал использовать AutoPatch как довесок к юнит-тестам, который отвечает за то, чтобы перед стартом тестов приводить базу данных в некоторое известное изначально состояние.

В планах - ввести пакеты для обновления БД (архив, содержащий манифест+каталоги с патчами), сделать чтобы AutoPatch UI открывал такие пакеты в один клик.

Ссылка на страницу проекта: http://code.google.com/p/autopatchnet

См также

• Идеальный Package Manager
  

Идеальный package manager - 2

Удивительное дело, нормального opensource менеджера обновлений для БД в мире .Net похоже не существует.

Есть несколько библиотек, предоставляющих Ruby-style migrations, но это не совсем то, что мне нужно. Ближе всего к ожиданиям из готового сейчас RedGate SQLPackager, но он во-первых платный, во-вторых хочется поддержки именно жизненного цикла в духе AutoPatch.

По опыту, идеальный процесс должен выглядеть так

• программисты работают с локальной или dev базой напрямую
• перед началом тестирования при помощи инструмента типа SQLCompare строится дифференциальный sql скрипт между дев-базой и stage. При этом скрипт должен быть в "родном" для БД формате, чтобы не упереться случайно в недостатки фреймворка
• этот скрипт фиксируется в репозитории и затем на основе всех скриптов обновления строится пакет для обновления БД
• этот пакет разворачивается на требуемой базе, причем package manager должен предоставлять либо режим с ручным контролем (для боевой базы, чтобы не страшно было), либо автоматический режим (для всевозможного continious integration

Ссылки по теме

• Идеальный package manager - часть 1
• AutoPatch

Еще о базах данных - идеальный package manager

См. также 2 часть размышлений об идеальном package manager.

Вот эта вот дискуссия у Бескова -- напомнила мне о всех тех ужасах, которые я переживаю при думании о поддержке баз данных.

В жизненном цикле ПО, особенно серверного, базе данных отведено отдельное место

* БД почти всегда обновляется, и почти никогда не ставится с нуля. Исключение -- только установка новых инсталляций продукта
* Я не знаю никаких встроенных в известные RDBMS инсталляторов схемы - с инкрементальными патчами, версиями модулей и т д. А их очень не хватает

В минимальном виде идеальный package manager должен уметь делать следующее
* вести помодульный реестр установленных в БД компонентов
* позволять инсталлировать/деинсталлировать модули.
* вести зависимость между модулями.
* позволять установить БД "с нуля", накатывая патч за патчем до определенной версии
* инсталляционные скрипты должны быть в виде .sql-файлов (желательно)

В идеале, система должна иметь одинаковый интерфейс под всеми RDBMS.

Может быть, пришло время для какого-нибудь DB Maven? :)

PS: несколько ссылок
* http://www.agiledata.org/essays/tools.html
* http://autopatch.sourceforge.net/documentation.php
* http://migratedb.sourceforge.net/

UPD от 13 Cен: http://www.liquibase.org

UPD 19 янв 09:

* http://db.apache.org/ddlutils/index.html

UPD 9 авг 09:

Подборка относительно недавних проектов, привносящих в .Net мир ruby style migrations

• http://www.rikware.com/RikMigrations.html
• http://code.google.com/p/migratordotnet
• http://code.google.com/p/octalforty-wizardby