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

Есть несколько баз данных: дивелоперская, тестовая (та, на которой выполняются юнит и функциональны тесты), UAT (user acceptance test), на которой работают тестеры и немножко – маркетеры, pre-production (используется для проведения презентаций и т.д). В свете очень скорого релиза предполагается появление одной и более production базы данных.

Дивелоперская версия “эволюционирует” в режиме реального времени, в то время, как обновление UAT происходит автоматически по расписанию (это делает Team Build) и, понятное дело, нужно производить обновление базы данных в момент обновления продукта, то есть, в составе этого самого билда. Остальные базы – та же история, в момент обновления инсталяции.

Кроме того, понятное дело, каждая база данных хранит свои собственные данные. То есть, содержимое всех баз абсолютно разное и должно оставаться абсолютно разным. А вот структура данных должна быть одинаковая. Структура – это и схема БД, и состояние данных. То есть, если по каким-то причинам вдруг понадобилось увеличить цену продуктов на 20% (дурацкий пример), то сделать это нужно во всех базах, а продукты везде разные.

В общем, мы пробовали пользоваться различным софтом для сравнения и синхронизации схем БД, автоматизировать его, как-то проверять периодически на предмет, не напутал ли он чего (ведь может быть в девелоперской базе есть что-то, что и не нужно, чтобы было больше нигде), а уж DML эти (это я про “увеличить цену” как отслеживать…

В общем, мы пришли к очень простому, но действенному методу. Я, кстати, не верил, что будет так эффективно, когда начинали. Оказалось – очень неплохо.

Смысл метода заключается в том, что все изменения, которые делаются в БД, делаются посредством SQL-скриптов (а я предупреждал, что метод простой).
Скрипты, согласно конвенции, именуются в порядке очередности: 00129.sql, 00130.sql и т.д. Они хранятся в папке scripts одного из проектов в solution.
База данных содержит табличку SchemaVersion с одним числовым полем (TFS поступает так же, если я не ошибаюсь).
Проект, в котором это все лежит, называется DatabaseMigrator. Все, что он делает – читает из config-файла connection strings, подключается к базам, смотрит в SchemaVersion и исполняет скрипты, версия (имя) которых выше, чем то, что находится в БД. Выполнил – обновил версию.
Вот и все.
А дальше – для каждой конфигурации – просто свой app.config-файл. Team Build запускает DatabaseMigrator каждый раз, когда делает обновление UAT. Другие билды, которые обновляют другие инсталяции, делают то же самое.

Работать с этим всем совсем просто: каждый раз, когда мне нужно изменить схему, поменять структуру данных или что-то еще, я создаю sql-файлик и запускаю migrator. Прошло – отлично, дивелоперская и тестовая базы обновлены, можно работать. UAT и прочее – обновятся своевременно. При этом если я что-то напортачил в скрипте, то просто “упадет” билд – и ничего не сломается на существующей инсталяции.

В .NET Framework 4.0 планируется (и в Beta 1 уже есть) некоторая поддержка параллельных вычислений. Что, конечно, не может не радовать в свете того, что я уже писал здесь по поводу многопроцессорности, многоядерности и человеческих способностей всё это эффективно использовать.

В частности, в .NET 4.0 появляются такие вещи, как статический класс Parallel:

Parallel.For()
Parallel.For<>()
Parallel.ForEach<>()
Parallel.Invoke()

и статический класс ParallelEnumerable со всеми его благами в виде .Cast<>, .All, .Where, .GroupBy и прочее, прочее.

Кроме того, IEnumetable теперь тоже имеет метод-расширение (или как это по-русски? придумали термин? extension method, в общем) .AsParallel, позволяющий распараллелить операции над элементами последовательности.

Очень здорово: если у меня есть цикл, обрабатывающий немереное количество данных и я знаю, что обработка каждого элемента независима (например, я увеличиваю стоимость каждого продукта на 20% и выбираю все, ценою до 50 долларов), то все, что мне нужно сделать, чтобы эта часть приложения работала эффективнее – это просто воспользоваться соответствующей конструкцией.

Насколько оно эффективно?
Ну, если верить словам разработчикам pLINQ (parallel LINQ), выступление которых я смотрел еще на TechEd 2008 Australia, то достаточно эффективно: “параллелит” оно учитывая количество процессоров/ядер, данные, что-то еще… Плюс там предусмотрено несколько стратегий работы (как именно парраллелить данные), используются lock-free алгоритмы… Словом, это гораздо, гораздо эффективнее того, что делает большинство из нас даже в лучшем случае (создать 1-2 потока на ядро). В обычном же (даже не в худжем) случае мы даже не думаем о параллельности, просто пуская привычный for/foreach, правда?

Ну, и эксперимент. Простой цикл на 1000 итераций, я не придумал, что делать в каждой из итераций, поэтому просто сделал там задержку в 100 милисекунд.
Результат:
 
Первая цифра - “обычный” for, вторая - Parallel.For().

Вчера (или позавчера) в публичный доступ выложили Visual Studio 2010 Beta 1 и .NET Framework 4.0 Beta 1.
Поскольку я из своего личного опыта знаю, что начиная с бета-версии со студией уже можно вполне нормально работать, да и сам статус “Бета” означает, в отличие от CTP, что архитектура фреймворка устоялась и даже если и будет меняться, то будет меняться незначительно… В общем, нет повода не начать присматриваться к будущему инструменту. И нет повода не начать изучать инфраструктуру, с которой придется работать, опять таки в будущем.
Ну а чтобы было не так скучно, буду писать по ходу дела. Сегодня – только про “студию”, дальше – глубже.

Про установку рассказывать не буду. Установка – как установка, времени сколько заняла – не считал, не принципиально. Самое интересное – после.

Нужно сразу сказать, что UI у Visual Studio теперь сделан на WPF. Даже редактор кода. Отсюда много всяких интересностей (а то, на самом деле, для всех людей программы развиваются, принципиально эволюционируют, а программисты до сих пор в примитивных, в общем-то, текстовых редакторах сидят). Но пойдем по порядку.

При первом запуске на обновленной стартовой странице я увидел возможность загрузить расширения.
Про расширения – отдельная история. Расширения к новой “студии” делаются и подключаются до безобразия элементарно (фактически атрибут навесить да в папку скопировать), не то, что раньше. Над extensibility поработали тоже неслабо. В общем, наверное, стоит ожидать большого количества плагинов на любой вкус, начиная от визуализаторов (те же комментарии показывать не в виде xml comments, а более красиво и функционально, как это показывали на MIX) и каких-то очень функциональных вещей.

Итак, расширения. Конечно, стало интересно. И, конечно, их пока не много – всё же бета, да и комьюнити не подключилась… Но полезного я себе уже нашел:

Полезным показался Regex Editor (возможно будет альтернатива глючному “The Regulator” и волшебному “ConsoleApplication1”), Italic Comments (интересно попробовать) и Image Insertion для вставки картинок в комментарии (я уже говорил, что UI написан на WPF и редактор стал более продвинутым?). Комментарии я люблю (в том числе и писать). Советую.

Что приятно, очень приятно - “студия” “научилась” строить sequence-диаграммы! То есть, можно кликнуть мышкой на любой метод, ограничить уровень вложенности и получить такую вот диаграмму:

Или вот так:

Это как раз то, чего не хватает в повседневной работе! Не слишком-то это удобно – отслеживать Call Flow с помощью Find All References / Go To Definition. Или в дебаге по call stack’у, тоже не всегда удобно.

О дебаге, кстати. Появился новый (во всяком случае я такого раньше не видел) инструмент: Debug History:

Очень удобно! На каждом шаге можно посмотреть и autos и call stack. Ну и обратите внимание на значки на второй картинке: тоже, на мой взгляд удобно.

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

Всё это, конечно, очень полезно. Очень всего этого не хватет, когда садишься, как у меня это в последнее время бывает, рефакторить подсистему, с которой дела раньше не имел…

Над профайлером тоже поработали в плане внешнего вида и отчетности. Функциональные отличия, впрочем, пока не сравнивал.

Плюс в составе студии (team suit я ставил конечно) появились очень полезные инструменты для работы с базами данных, из картинки хорошо видно, что там.

Впрочем, если говорить о поддержке нескольких ДБ (релиз или несколько, тест, девелоперская база) мы в команде нашли отличную методику поддержки всего этого дела в едином состоянии, синхронизировании схем и т.д.
Как-нибудь расскажу, а то давно ничего не писал :)

Инструментов рефакторинга, кстати, в Visual Studio 2010 не добавили. Жаль. Ибо ReSharper, например, глючен неимоверно, так и пришлось его снести чуть ли не всей командой. Самые стойкие еще держатся (таких у нас один). Из категории “мыши плакали, кололись, но продолжали есть кактус” :)

Это был мой первый запуск Visual Studio 2010, так сказать, знакомство с интерфейсом. На более функциональные вещи как студии, так и 4-го фреймворка посмотрим чуть позже.

http://www.russia.ru/video/clinux/

Ну и кто там самый зомбированый, как вам кажется? :)