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

4 мая 2013 г.

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

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

Одной из важных частей выпуска артефактов проекта является настройка файлов конфигурации для различных конфигураций сборки. Из стандартных конфигураций можно выделить:

  • Debug, Local: локальная сборка или сборка на каждое изменение в репозитории кода;
  • Staging, Pre-production, UAT: сборка для окружения, на котором вся функциональность будет протестирована перед заливкой на боевой сервер;
  • Release, Production: сборка, с которой работают конечные пользователи.

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

Я разделил тему работы с файлами конфигурации на 5 статей. Это даст возможность погрузится в решения от простого к сложному:

  1. Continuous Integration: Трансформация Web.config
  2. Continuous Integration: Процесс сборки проекта и трансформации Config-файлов
  3. Continuous Integration: Создание собственной конфигурации
  4. Continuous Integration: Трансформация App.config
  5. Continuous Integration: Рефакторинг файлов конфигурации

Статьи будут полезны как начинающим разработчикам, так и практикующим.


Ссылки

9 комментариев:

  1. "Сборку проекта и выпуск артефактов для релиза уже давно никто не осуществляет вручную."

    Ага щас-же. Некоторые до сих пор на боевом сервере в VS дебажат код.

    ОтветитьУдалить
  2. Разные извращения встречаются, я имел ввиду здравомыслящее население :)

    ОтветитьУдалить
  3. К сожалению, 95% населения - идиоты. Так что большниство не использует системы контроля версий, CI, CD, и т.д.

    ОтветитьУдалить
  4. Это не идиоты, а мамонты. Скоро вымрут.

    ОтветитьУдалить
  5. Хорошая статья, спасибо.

    ОтветитьУдалить
  6. Я бы не был так уверен, если б не проверил на своем опыте.

    ОтветитьУдалить
  7. Согласен с Сашей. По опыту, автоматическую сборку юзают в 5-10% проектов, в которых я участвовал. И деплой почти всегда происходит ручками.

    ОтветитьУдалить
  8. Дак давайте же менять эту ситуацию :)

    ОтветитьУдалить
  9. Это невозможно. Куча контор работает на CMS, CRM и прочих **M (далее "система"). Иногда кастомные модули к этим системам можно прогонять через CI но не всегда. Есть куча задач, которые даже невозможно сложить в репозиторий исходного кода, потому что никакого исходного кода в данном случае нет. Есть некая конфигурация, которую невозможно экспортировать\импортировать из\в систему. К примеру, workflow в SharePoint, созданные в SharePoint Designer (вот тут есть как это делать ручками http://blogs.technet.com/b/wkng/archive/2012/08/21/exporting-and-importing-sharepoint-designer-2010-list-workflow.aspx через экспорт в Visio и так далее). Тут возникает ситуация, когда из QA на Production нужно перепечатывать эти workflow вручную. Делать это после окончания рабочего дня и в итоге молиться, что ты все перенес правильно. Конечно ты можешь возразить: "не используйте SharePoint", но реальность такова, что SP - это единственное средство, доступное на рынке. Малый и средний бизнес не может себе позволить 2 года разрабатывать систему документооборота.

    Другой пример - 1С. Тут без комментариев.

    ОтветитьУдалить

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...