В Сидней приезжает Тори Амос (Tori Amos). Будет выступать в главном зале знаменитой сиднейской оперы.
Ещё давно, несколько месяцев, наверное, назад были успешно куплены билеты и оставалось только ждать этой даты – 17-го ноября.

Однако, совершенно неожиданно с этой датой совпало проведение PDC (Professional Developers Conference). Точнее, неожиданностью оказалась не дата проведения конференции, а тот факт, что я на неё попадаю. Тем не менее, завтра с утра у меня интервью в американском консульстве на предмет получения визы, и если всё сложится удачно, то на концерт Тори Амос я, к сожалению не попадаю.

На работе смеются – для австрала персональное интервью в консульстве перед поездкой куда-то выглядит крайне забавно и необычно. Интересуются “а зачем”, “а страшно ли”, “а что там спрашивают”, удивляются.

Ничего всё это я уже проходил при получении первой британской визы (вот как раз факт того, что я был в Британии я и забыл указать в анкете, надеюсь простят), на вопрос “let me see the conference program” ответить смогу.

А австралы, кстати, тоже регистрируются где-то по какой-то визовой программе, не просто так едут. Ходить им, конечно, никуда не надо, но, видимо, какая-то электронная регистрация у них всё же есть. Ну а отпечатки пальцев снимать и фотографировать лица будут у всех одинаково :) Ну, за исключением босса – он хотя и не гражданин Австралии оказался, но канадец, а посему въезд в США для него свободный.

Вот. В Лос Анджелесе я ещё не был. Надеюсь, у них там в далёкой Америке есть интернет, напишу, оттуда, что там и как :) Уже договорился, что на время поездки мне выдадут другой, более лёгкий ноутбук…

Но 13.5 часов в самолёте! Это, я вам скажу, похлеще, чем в Австралию из России лететь. Тут придётся честно все 13.5 часов отвисеть в воздухе, тогда как перелёт в Австралию хоть и занимает 17-19 часов, но с отдыхом посередине этого временного отрезка! В прошлый раз было так неплохо поспать ночь в Японии в хорошем таком отеле, который, кстати, предоставлялся бесплатно. А тут 13.5 часов в воздухе. Мрак. Хорошо хоть ночью летим, надо будет не выспаться наконуне.

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

В общем, каждый раз после проведения PDC я смотрел видео доклады в интернете (очень советую) и каждый раз думал, что обязательно надо собраться как-нибудь и съездить. Ибо ролики – это одно, а личное присутствие – совсем другое, что бы там ни говорили те, кто всегда смотрит и никогда не присутствовал, это я по TechEd и ReMix знаю :)

Вот, представился шанс…

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

Проблемы эти таковы:

1. При изменении объекта базы данных (процедуры, функции, триггера и т.д.) разработчик создаёт скрипт и помещает его в репозиторий. Всё бы хорошо, но несколько разработчиков могут написать свои скрипты (пофиксить что-то в процедуре, скажем), положить в репозиторий независимо.. И “победит” последний. Причём узнаётся об этом обычно в самый ответственный момент: на этапе тестирования (если не позже). Проявляется баг, разработчик недоумевает “я же пофиксил его, вот и скрипт есть!”. А то, что одни-двумя изменениями дальше идёт совершенно иная копия – как же это проверишь.
   
2. Вышеописанная проблема многократно усугубляется в случае использования веток (бранчей).
   Так, как в разных бранчах делаются разные куски функциональности, то, во-первых, достаточно сложно поддерживать “сквозную” систему нумерации. Либо при каждом слиянии бранчей нужно как-то “перенумеровывать” скрипты, но тоже никогда не скажешь, какой именно должен быть порядок в итоге.
   Кроме того – та же проблема: в одном из бранчей поменяли процедуру, в другом – тоже. Скрипты перенумеровали, залили в репозиторий – а не работает.
   При этом очень сложно сказать, какая же версия была “в оригинале” (базовая), какая являет собой изменение в одном бранче, какая – в другом. Это же всё разные файлы, да и их ещё поискать.

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

На замену пришёл новый Database Project для Visual Studio 2008: http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en

Его нужно скачать, установить – и вроде как все проблемы решены :)

Краткое описание того, что мы имеем, используя эту штуку.

Все объекты БД представлены в виде скриптов.

На этапе инициализации проекта ему нужно указать БД, из которой он “заскриптует” все элементы схемы: таблицы, представления, процедуры, очереди, индексы, ключи, роли.. всё-всё-всё, даже CLR-сборки, если таковые имеются.
В результате разработчик получает дерево, по своей структуре очень похожее на то, что мы привыкли видеть в Management Studio, но все элементы – в виде create-скриптов.

Проект “умеет” отслеживать ошибки на этапе “компиляции”.

Это очень удобно! Например, если мы попытаемся создать скрипт для индекса по несуществующей колонке, создать view для несуществущей таблицы или что-то ещё “этакое” (да просто допустим синтаксическую ошибку или опечатку), то мы увидим ошибку “компилятора” (так же, как мы видим в случае ошибок в коде). Понятное дело, что пока в проекте есть ошибки, изменения в БД применяться не будут.
Что характерно, проект разбирает скрипты и зависимости между ними самостоятельно, а не просто пытается выполнить SQL-код и перехватывает ошибки.
Так с предупрежденями.

Возможности рефакторинга.

Если честно – много не пробовал. Но оно там есть. Например, переименование таблицы или столбца. Просто кликаем правой кнопкой мыши на элементе в дереве, выбираем Refactor –> Rename – и готово. Будет переименовано везде.

Использование макро-переменных.

Скрипты – они, конечно, обычные SQL-скрипты, но в них можно (если захочется) использовать макро-переменные в виде $(DatabaseName). Значения этим переменным можно задать в конфигурации проекта, далее эти макросы будут автоматически подменены там, где они встречаются.
Зачем? Ну, я не знаю :) То же имя базы данных (или linked-сервера). Тот же логин пользователя. Словом, то, что может отличаться от среды к среде (у разработчиков – одно, в продакшн – другое).

Ещё много всякого…

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

Как это работает.

Процесс примерно такой:

1. Мы говорим проекту “Deploy”.
2. Происходит Rebuild проекта. На этом этапе делаются все проверки на ошибки, предупреждения и т.д. В том случае, если ошибок нет, идём дальше.
3. Происходит сравнение схемы базы данных, в которую мы делаем deploy cо схемой, которая присутствует в нашем проекте в виде кучи create-скриптов. По результатам этого сравнения генерируется дельта-скрипт, который содержит уже всевозможные alter, delete, create и т.д.
   Надо сказать, что дельта эта генерируется очень качественно. Мы тестировали на достаточно сложных комбинациях – всё проходило “на ура”. Проблем не было ни разу.
4. Дельта-скрипт применяется в базу данных.

Кстати, применять дельта-скрипт вовсе не обязательно, можно “сказать” проекту, что этот скрипт нужно просто сгенерировать.
Вообще настроек у проекта достаточно много: ANSI-ключи, нужно ли удалять объект, если он пропал из схемы проекта, нужно ли делать бекап перед применением дельта-скрипта и т.д, проще посмотреть.

Да, это всё DDL.
Что касается DML: тут всё совсем примитивно просто: есть два раздела: PreDeployment Scripts и PostDeployment Scripts. Туда (обычно в Post-, разумеется) и предполагается складывать скрипты для DML. Единственное, за чем надо следить – так это за тем, чтобы скрипты проверяли, нужно ли делать то, что они хотят делать. Ибо все они будут исполняться каждый раз при обновлении БД из проекта. Но это, как и понятно, сделать очень и очень нетрудно и вообще best practices :)

Автоматическое развёртывание.

Поскольку всё делается через msbuild, все targets уже на месте, то нет проблем ни с каким билд-сервером, ни даже без него (msbuild можно и из командной строки запустить). Словом, всё точно так же, как и с любым “кодовым” проектом - “на ура” автоматизируется ночной билд-деплой, например.

Плюсы.

Для нас – очень существенные. Судите сами: каждый объект -  это просто текстовый sql-файл. Как и любой другой файл с кодом, он отлично “уживается” в системе контроля версий, если два или более разработчика правят один файл – они будут иметь нормальный “человеческий” конфликт при чекине (или при слиянии веток) на этом файле и будут иметь все возможности грамотно этот конфликт разрешить.

Кроме того, правка таблиц, например, становится гораздо более лёгким делом, так как не приходится задумываться об ALTER TABLE, проверке на наличие (дабы не свалиться с исключением при попытке добавить то, что почему-то уже существует) и т.д. Нужен новый столбец: просто дописал его в CREATE-скрипт для таблицы – и всё. Остальное проект сделает за тебя.

Минусы.

У нас база данных – большая. Поэтому сравнение идёт достаточно долго. Долго – это где-то от 5 до 10 минут.
Хотя тут тоже не всё понятно. Сравение идёт долго на UAT-сервере, а вот локально, на той же БД (backup/restore) – одна минута пятнадцать секунд на весь деплоймент. Так что тут нужно ещё смотреть, нет ли у нас каких-то инфраструктурных затыков.

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

Словом, будем теперь так жить.

Свершилось, Microsoft наконец сделали релиз своего антивируса, о котором говорили уже достаточно давно.

Скачать можно отсюда: http://www.microsoft.com/security_essentials/

Правда, я ждал этой штуки для установки на мой Windows Home Server, а его в списке поддерживаемых ОС, к сожалению, нет (как и серверных ОС вообще)... Но если у Вас Windows XP SP2, Vista или даже Windows 7 - можно ставить!