Continuous Integration: Рефакторинг Config-файлов

Скачать исходный код

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

До того, как наш релиз попадет на боевой сервер, он обычно разворачивается сначала на окружении для разработки, потом на staging или preproduction, а уже потом идет на сервер с конечными пользователями. Для каждого из этих окружений нужно выставить свои настройки подключения к БД, SMTP-сервера, пути в файловой системе и т.п.

В примерах я буду писать про App.config, но всё описанное будет применимо и для Web.config, и для любого config-файла, основаного на XML.

Continuous Integration: Трансформация App.config

Скачать исходный код

При работе с корпоративными проектами нужно создавать приложения разного рода. Например, проект может содержать несколько веб-сайтов, WCF-сервисы, Silverlight-приложения, Windows-сервисы или консольные утилиты. Все эти приложения нужно будет включить в Continuous Integration, чтобы выпуск версий для тестового сервера и боевого производился в автоматическом режиме. У всех этих приложений есть файлы настроек, которые обычно хранятся в App.config или других XML-подобных файлах. Для разных версий приложений мы должны хранить свои строки подключения к БД, ссылки к сторонним сервисам, SMTP-хостам, задавать разные уровни логирования и т.п.

Мы уже рассмотрели, как работать с Web.config, как писать для него трансформацию, что такое трансформация и как она встраивается в процесс сборки проекта. Продолжим эту тему рассмотрением работы с App.config.

Проекты моей компании: Проект buzzego

Недавно я писал о том, что компании ByndyuSoft исполнился 1 год. Хочется больше описывать то, что мы делаем, но проекты довольно долго разрабатываются и не все лежат в публичном доступе.

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

Проект: http://buzzego.com

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

Сервис обрабатывает сотни тысяч статей ежедневно. Всё это сделано с хорошей балансировкой нагрузки и оптимизацией алгоритмов сбора и анализа информации. Из основных технологий back-end'а можно выделить: ASP.NET MVC, RabbitMq, MSSQL + MongoDB.

Делать проект такого уровня очень интересно. Сюда входят и новые технологии, и новые платформы разработки. К тому же это одностраничное приложение с богатой логикой на JavaScript, самое трендовое направление в веб-разработке. Всё реализовано под различные браузеры, мобильные устройства и ОС.

При разработке команда и Product Owner переходили от Scrum к Kanban, адаптируя методы гибкой разработки под требования проекта.

В данный момент проект запущен на американском рынке и продолжает развиваться.

Continuous Integration: Создание собственной конфигурации

Скачать исходный код

Конфигурации сборки (build configurations) обеспечивают хранение нескольких версий настроек для солюшена и проектов. Создание новой конфигурации будет необходимым шагом для работы с несколькими окружениями и версиями релиза.

Для начала рассмотрим, что такое конфигурация сборки на уровне проекта и на уровне солюшена. Потом создадим свою конфигурацию и config-файлы для нее.

Continuous Integration: Процесс сборки проекта и трансформации Config-файлов

Скачать исходный код

Мы рассмотрели основы трансформации Web.config. Теперь стоит углубится в тему сборки проекта и рассмотреть детально, когда и как делается трансформация файлов конфигурации.

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

Continuous Integration: Трансформация Web.config

Скачать исходный код

Начнем рассмотрение работы с config-файлами с самой простой темы. Создадим приложение ASP.NET MVC 4. По-умолчанию в созданном проекте уже есть 2 конфигурации (Debug, Release) и 3 config-файла (Web.config, Web.Debug.config, Web.Release.config):

Continuous Integration: Работа с Config-файлами

Скачать исходный код

Сборку проекта и выпуск артефактов для релиза уже давно никто не осуществляет вручную. Весь процесс интеграции и Deploy довольно просто автоматизируется с помощью TeamCity, Cruise Control.NET или Team Foundation Server.

Dotnetconf #6: мастер-классы

Открыта регистрация на 6-ю конференцию .NET разработчиков.
Дата проведения — 28 апреля 2013
Место проведения — г. Челябинск, Отель ParkCity
Вход бесплатный после регистрации, количество мест ограничено.
Бесплатные обеды и подарки от спонсоров.
Регистрация на сайте http://www.dotnetconf.ru/Registration

Моей компании 1 год

Ровно год назад 6 апреля я сделал первый коммит в первый репозиторий первого проекта своей компании. Тогда за час с небольшим я смог объяснить представителю заказчика прелесть работы по Agile. Его начальник нам не поверил и сел писать техническое задание. Мы же каждый день делали релиз и получали обратную связь. К концу первой итерации, когда заказчик дописал ТЗ, мы дали ему готовый продукт. Так началась компания ByndyuSoft.

Dapper + QueryObject, как замена ORM

Не так давно я утверждал, что нужно использовать высокоуровневую ORM и даже делал опрос на эту тему. Как показал опрос, не многие пишут SQL-запросы руками.

Проблематика

Для работы с типовыми проектами действительно не надо углубляться в вопросы специфики SQL. Но сейчас я веду проект, где без этого просто не обойтись. Речь про базы данных по 700ГБ и требования к отклику на UI менее 1 секунды. При этом происходит много разных расчетов, строятся графики и т.п.

Для начала я по привычке использовал NHibernate. Уже через пару итераций оказалось, что эта ORM мне не подойдет (не говоря уже про EntityFramework) по следующим причинам:

• Скорость: создание сессии, маппинг и другие сопутствующие вещи отнимали до 200 мс. В моем случае это 20% времени, которое тратилось впустую;
• Гибкость запросов: сначала я писал запросы на Linq, потом понял, что трудно сделать хитрые запросы и добавлять хинты через высокоуровневые интерфейсы типа Linq, QueryOver или Criteria. Из всех возможностей NHibernate я начал использовать только функцию ExecuteSql, но скорость маппинга была слишком низкой;
• Утечки памяти: увы, но в NHibernate есть утечки памяти. Когда в вашей системе делается много запросов, это становится критичным. Сервисы через 20-30 часов работы падали с OutOfMemoryException и MemProfiler указал на NHibernate;
• Много чтения, мало записи: в проекте мне надо считывать очень много данных, получается такой cRRRRud, поэтому UoW от NHibernate оказался тоже не нужен.