Решили мы навести порядок с развёртыванием приложений на серверах. Точнее, решили-то давно, а вот, что называется, “руки доходить” начали только сейчас.
Основные тезисы:
- Иметь в проекте несколько вариантов конфигурационных файлов, использующихся в разных окружениях (Local, UAT, Test, Staging, Production, etc) – неправильно, сложно и некрасиво. Сюда же как вариант относятся файлы трансформации, поддерживаемые VS2010 (*.Staging.Config, *.Prod.Config, *.UAT.config, etc).
В идеале хотелось бы иметь один конфигурационный файл с максимум одной трансформацией для debug и release компиляци. Release-компиляция для всех окружений должна быть одинаковой. - Иметь где-то в проекте/почте/голове/на стене список, по которому развёртывается приложение – неправильно.
Я имею в виду списки вида: - Остановить сервисы такие-то;
- Обновить базу данных так-то;
- Скопировать в каталог веб-сайта то-то;
- Изменить/проверить конфигурацию и connection strings;
- Прочая байда…
- Выполнять этот список наполовину вручную – неправильно
- Прописывать имена и пароли к базе данных и прочие значимые вещи в конфигурационные файлы и хранить их в lдоступном каждому source control – неправильно;
- Ситуация, при которой разработчики имеют доступ/пароли к production environment – неправильная;
- Если в случае формирования нового окружения, или в случае добавления каких-то серверов/компьютеров приходится делать долгое и утомительное конфигурирование новых машин перед тем, как установить на них приложение – это неправильно;
Хочется сделать более-менее правильно и удобно, поэтому остановились на использовании MSDeploy, который позволяет делать следующее:
- Создавать самодостаточный инсталляционный пакет (в конечном итоге это zip-файл), либо набор таких пакетов;
- Изменяющиеся от окружения к окружению параметры могут быть переданы при развёртывания пакета как параметры;
- Операторам, выполняющим развёртывание, не нужно “знать лишнего”, достаточно лишь знать на какую машину послать какой пакет (в случае, если их несколько), либо с какими параметрами устанавливать пакет на какой машине (в случае, когда всё упаковано в одном пакете), для чего они легко и привычно сделают скрипт, который смогут запускать одним нажатием клавиши;
- Пароли от “настоящего” production environment никогда не попадут в source control, доступный разработчикам. IT-ребята могут, как они и любят, хранить файлики с параметрами в своих закромах, недоступных неверным;
- MSDeploy позволяет автоматическое развёртывание пакетов без необходимости заходить и копировать что-то по FTP/SSH/RDP, включая опции типа “сделай везде как вот здесь” и т.д.;
- Cоздание пакета MSDeploy может быть полностью автоматизировано, например, как часть билд-процесса;
- Грамотно созданному пакету практически всё равно, устанавливаться ли “с нуля” на “чистую” машину, либо обновлять уже существующую версию, после развёртывания получаем работоспособную машину;
- Уже созданные пакеты легко хранить, в любой момент можно найти и установить текущую, либо любую из предыдущих версий;
Вкратце, развёртывание должно быть простым и безболезненным, не должно требовать дополнительной подготовки и должно сводиться к “нажатию большой зелёной кнопки” техническим оператором, мы в любой момент готовы к развёртыванию.
На вопрос “что” мы уже ответили – MSDeploy.
Возможно я ещё напишу немного ответов на вопрос “как” (документация по MSDeploy отчего-то крайне невнятная и убогая).
Subscribe