Развёртывание программного обеспечения

Развёртывание програ́ммного обеспе́чения — совокупность всех действий, которые делают программную систему готовой к использованию.

Процесс развёртывания может включать действия как на стороне производителя (разработчика), так и на стороне потребителя (пользователя), либо на обеих сторонах. Развёртывание для потребителей является сложной задачей, поскольку целевые системы разнообразны и непредсказуемы. Модель SaaS (программное обеспечение как услуга) позволяет избежать этих трудностей, поскольку развёртывание происходит только на выделенных серверах, которые, как правило, находятся под контролем производителя.

Поскольку каждая программная система уникальна, точные процессы или процедуры в рамках каждого этапа развёртывания трудно определить однозначно. Поэтому «развёртывание» следует интерпретировать как общий процесс, который необходимо адаптировать в соответствии с конкретными требованиями или характеристиками.

История

Во времена, когда компьютеры были чрезвычайно большими, дорогими и громоздкими (мейнфреймы и мини-компьютеры), программное обеспечение (ПО) часто поставлялось производителями в комплекте с аппаратным и предоставлялось бесплатно. Поворотный момент наступил в 1969 году, когда компания IBM под влиянием антимонопольных исков начала взимать плату за программное обеспечение и услуги отдельно от аппаратных средств. Это «разделение» (англ. unbundling) фактически создало современную индустрию ПО, превратив его в коммерческий продукт. Ранние процессы развёртывания были строго структурированы; например, поэтапная модель Лаборатории Линкольна (Lincoln Labs Phased Model), разработанная в 1956 году для системы ПВО SAGE, ввела последовательные этапы, повлиявшие на более поздние методологии. Этот подход был формализован в виде каскадной модели, ставшей доминирующей после её описания Уинстоном Ройсом в 1970 году. Он приводил к редким, дорогостоящим и длительным циклам выпуска релизов, часто занимавшим годы. Если требовалось установить бизнес-приложение, это часто влекло за собой дорогостоящий и длительный визит системного архитектора или консультанта. В наши дни при сложной локальной установке корпоративного ПО такая практика иногда сохраняется.

Развитие массового программного обеспечения для новой эры микрокомпьютеров в 1980-х годах привело к появлению новых форм распространения ПО — сначала картриджи, затем кассеты, дискеты, а позднее (в 1990-х и далее) оптические носители, Интернет и флеш-накопители. Этот сдвиг означал, что развёртывание программного обеспечения можно было переложить на клиента. В этот период появились альтернативы жёсткой каскадной модели. Спиральная модель, предложенная Барри Бомом в 1988 году, представила итеративный подход, основанный на анализе рисков, бросив вызов линейной структуре каскадной модели и проложив путь к более гибким, гибким методологиям. Когда развёртывание силами клиента стало стандартом, пришло понимание, что процесс настройки должен быть удобным для пользователя. В 1990-х годах популярность обрели такие инструменты, как InstallShield, чьи мастера установки избавляли пользователей от необходимости выполнять сложные задачи, например, редактировать записи в реестре.

До появления интернета выпуски ПО по своей природе были дорогостоящими и редкими. Распространение интернета коренным образом изменило дистрибуцию программ и сделало возможной сквозную гибкую разработку, обеспечив быструю совместную работу и цифровую доставку. Основы для современного быстрого развёртывания были заложены в 1990-х годах, когда Кент Бек разработал непрерывную интеграцию как одну из ключевых практик экстремального программирования, призывая разработчиков интегрировать свою работу ежедневно. Появление облачных вычислений и модели SaaS в 2000-х годах ещё больше ускорило эту тенденцию, позволив развёртывать ПО для огромного числа клиентов за считаные минуты. Этот переход также означал, что график развёртывания теперь, как правило, определял поставщик ПО, а не клиенты. Такая гибкость привела к становлению непрерывной доставки как жизнеспособного подхода, особенно для веб-приложений.

Современные стратегии развёртывания, основанные на этих принципах, включают сине-зелёное развёртывание и канареечный выпуск.

Этапы развёртывания

Выпуск (релиз)

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

Установка и активация

Для простых систем установка включает создание команды, ярлыка, скрипта или службы для запуска ПО (вручную или автоматически). Для сложных систем может потребоваться настройка — возможно, путём опроса конечного пользователя о предполагаемом использовании или прямых вопросов о конфигурации — и подготовка всех необходимых подсистем к работе. Активация — первый запуск исполняемого компонента ПО (не путать с активацией лицензии, которая является функцией систем DRM).

При крупных развёртываниях на серверах основная копия ПО, используемая пользователями («production»), может быть установлена на рабочем сервере в рабочей среде. Другие версии развёрнутого ПО могут быть установлены в тестовой среде, среде разработки и среде аварийного восстановления.

В сложных средах непрерывной доставки и/или системах SaaS в рабочей среде могут одновременно существовать по-разному сконфигурированные версии системы для разных внутренних или внешних клиентов (это называется мультитенантной архитектурой) или даже постепенно выкатываться параллельно для разных групп клиентов с возможностью отмены одного или нескольких параллельных развёртываний. Например, известно, что Twitter использует такой подход для A/B-тестирования новых функций и изменений интерфейса. В рабочей среде также может быть создана «скрытая живая» группа серверов, ещё не подключённых к балансировщику нагрузки, для целей сине-зелёного развёртывания.

Деактивация

Деактивация — обратный процесс активации, означающий остановку всех работающих компонентов системы. Деактивация часто требуется для выполнения других действий по развёртыванию, например, систему может потребоваться деактивировать перед обновлением. Практика вывода из эксплуатации редко используемых или устаревших систем часто называется списанием приложений (application retirement).

Удаление (деинсталляция)

Удаление — обратный процесс установки. Это удаление системы, которая больше не требуется. Может также включать перенастройку других программных систем для удаления зависимостей от удалённой системы.

Обновление

Процесс обновления заменяет более раннюю версию всей системы или её части новым релизом. Обычно он состоит из деактивации и последующей установки. В некоторых системах, например, в Linux при использовании системного менеджера пакетов, старая версия приложения обычно удаляется автоматически в рамках этого процесса. (Это связано с тем, что менеджеры пакетов Linux, как правило, не поддерживают одновременную установку нескольких версий приложения, если пакет не был специально разработан для обхода этого ограничения.)

Встроенное обновление

Механизмы для установки обновлений встроены в некоторые программные системы (или, в случае некоторых операционных систем, таких как Linux, Android и iOS, в саму ОС). Автоматизация этих процессов варьируется от полностью автоматической до инициируемой и контролируемой пользователем. Norton Internet Security — пример системы с полуавтоматическим методом получения и установки обновлений как для антивирусных баз, так и для других компонентов.

Отслеживание версий

Системы отслеживания версий помогают пользователю находить и устанавливать обновления. Например, каталог программного обеспечения хранит информацию о версии каждого пакета, установленного в локальной системе. Нажатие кнопки открывает веб-страницу обновления приложения. В Linux, Android и iOS этот процесс ещё проще, поскольку стандартизированный механизм отслеживания версий встроен в ОС, поэтому отдельные шаги входа, загрузки и выполнения не требуются, и процесс можно настроить на полную автоматизацию.

Роли в процессе развёртывания

Сложность и разнообразие программных продуктов способствовали появлению специализированных ролей для координации и инжиниринга процесса развёртывания. Для настольных систем конечные пользователи часто сами становятся «специалистами по развёртыванию», устанавливая ПО на свои машины. Развёртывание корпоративного ПО включает гораздо больше ролей, и они обычно меняются по мере продвижения приложения от тестовой (предпроизводственной) до рабочей среды. Типичные роли, участвующие в развёртывании корпоративных приложений, могут включать:

• в предпроизводственных средах:
  • разработчики приложений: см. Разработка программного обеспечения
  • инженеры по сборке и релизам: см. Инженерия релизов
  • менеджеры по релизам: см. Управление релизами
  • координаторы развёртывания: см. DevOps
• в рабочих средах:
  • Системный администратор
  • Администратор баз данных
  • координаторы релизов: см. DevOps
  • менеджеры проектов по эксплуатации: см. ITIL

См. также

• Управление жизненным циклом приложения
• Управление жизненным циклом продукта
• Системное администрирование
• Среда развёртывания
• Стадии разработки программного обеспечения
• Readme

Ссылки

• Стандартизация
  • Solution Installation Schema Submission request to W3C
  • OASIS Solution Deployment Descriptor TC
  • OMG Specification for Deployment and Configuration of Component-based Distributed Applications (OMG D&C)
  • JSR 88: Java EE Application Deployment
• Статьи
  • Hall, Richard S.; Fuggetta, Alfonso; Wolf, Alexander L.; Carzaniga, Antonio; Van Der Hoek, André; Heimbigner, Dennis. A Characterization Framework for Software Deployment Technologies – Technical Report CU-CS-857-98  (неопр.). Boulder, CO: Department of Computer Science, University of Colorado Boulder (апрель 1998).