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.

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.