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

Развёртывание может включать действия как со стороны производителя разработчика программного обеспечения, так и со стороны потребителя пользователь, либо с обеих сторон. Развёртывание на стороне потребителя часто представляет сложную задачу из-за разнообразия и непредсказуемости целевых систем^[10][11]. Модель программное обеспечение как услуга позволяет избежать многих трудностей, поскольку развёртывание производится только на выделенных серверах, обычно находящихся под контролем производителя. Для автоматизации развёртывания и обновления программного обеспечения на стороне потребителя применяются системы унифицированного управления конечными устройствами (UEM). Они позволяют удалённо устанавливать приложения на различные операционные системы, минимизируя ручное вмешательство^[12].

Эволюция от традиционных моделей и SaaS привела к распространению бессерверных вычислений (Serverless). В этой архитектуре управление инфраструктурой полностью делегируется облачному провайдеру, а развёртывание осуществляется на уровне отдельных функций с автоматическим масштабированием^[13].

Каждая программная система уникальна, поэтому конкретные процессы или алгоритмы в рамках отдельных этапов развёртывания редко поддаются строгому определению. Следовательно, под «развёртыванием» подразумевается общий процесс, который должен адаптироваться под специфические требования и особенности задачи^[14].

Для преодоления непредсказуемости целевых систем применяются методологии Инфраструктура как код (IaC) и GitOps. Они обеспечивают строгий декларативный подход: желаемое состояние инфраструктуры описывается в виде кода, а программные агенты непрерывно синхронизируют с ним фактическое состояние среды^[15].^[16]

Важную роль в обеспечении воспроизводимости развёртывания играют облачно-ориентированные (Cloud-native) технологии. Docker обеспечивает упаковку приложений со всеми зависимостями в стандартизированные контейнеры, гарантируя их переносимость. В свою очередь, оркестратор Kubernetes автоматизирует управление контейнерами, обеспечивая высокую доступность, балансировку нагрузки и плавные обновления^[17].

В эпоху больших, дорогих и громоздких мэйнфреймов и миникомпьютеров программное обеспечение часто поставлялось в комплекте с аппаратным обеспечением и предоставлялось производителями бесплатно^[18]. Переломным моментом стало решение компании IBM в 1969 году, вынесенное под влиянием антимонопольных судебных разбирательств: с этого времени программное обеспечение и сервисы стали продаваться отдельно от техники. Такое «разукрупнение» положило начало современной индустрии программного обеспечения, превратив софт в коммерческий продукт^[18]. Ранние процессы развёртывания были очень формализованными: так, Фазовая модель лаборатории Линкольна, созданная в 1956 году для системы противовоздушной обороны SAGE, ввела последовательные этапы, оказавшие большое влияние на последующие методики^[19]. Подобная схема получила завершённое оформление в водопадной модели, после публикации описания Уинстоном Ройсом в 1970 году. Для таких моделей были характерны редкие, дорогие и продолжительные релизы, зачастую длящиеся годы^[19]. В случае необходимости установки делового программного обеспечения требовалось выездное и зачастую дорогостоящее обслуживание архитектора или консультанта^[19]. При сложной внедряемой установке корпоративного ПО подобная ситуация сохраняется и в наши дни.

Появление массового рынка программного обеспечения для микрокомпьютеров в 1980-х открыло новые формы распространения: сначала картриджи, затем аудиокассеты, дискеты, позже (с 1990-х) оптические диски, интернет и флэш-накопители^[20]. Теперь непосредственно пользователь отвечал за развёртывание ПО^[21]. В этот период появились альтернативы жёстким «водопадным» процессам: спиральная модель, предложенная Барри Боэмом в 1988 году, позволяла гибко управлять рисками и итерировать продукт, что стало почвой для гибких методологий^[19]. По мере широкого распространения пользовательского развёртывания важным стало удобство настройки: в 1990-х появились такие средства, как InstallShield, избавившие пользователей от ручного внесения изменений в реестр^[22].

В эпоху до распространения Интернета развёртывание происходило редко и было затратным^[19]. Появление сети Интернет радикально изменило способы распространения ПО и позволило использовать гибкие методы разработки с быстрой коллаборацией и цифровой доставкой. В 1990-х Кент Бек заложил основы быстрой поставки, разработав принцип непрерывная интеграция как часть экстремального программирования, где разработчики ежедневно интегрируют изменения^[23]. С 2000-х годов с распространением облачных вычислений и SaaS стало возможным развёртывать ПО сразу для многих клиентов за минуты, а график релизов обычно определяет поставщик, а не заказчик^[24]. Это привело к развитию концепции непрерывная поставка (continuous delivery), особенно для веб-приложений^[23].

Движение DevOps начало формироваться в конце 2000-х годов как ответ на разобщённость между командами разработки и эксплуатации. Ключевым моментом стал 2009 год, когда инженеры Джон Оллспоу и Пол Хэммонд выступили с докладом о сотрудничестве разработчиков и системных администраторов. Вдохновившись этим выступлением, ИТ-консультант Патрик Дебуа в том же году организовал первую конференцию DevOpsDays, где и закрепился термин «DevOps». Внедрение DevOps радикально трансформировало процессы релиза, позволив компаниям выпускать обновления многократно в день благодаря автоматизации и использованию практик CI/CD^[25].

Современные стратегии развёртывания, развивающие эти идеи, включают blue–green развёртывание и развертывание по модели canary release^[26].

Исторически методы развёртывания прошли путь от ручного копирования файлов на сервер (например, по FTP) и использования императивных скриптов к автоматизированным процессам. В 2010-е годы расширение автоматизации привело к появлению контейнеризации (в частности, Docker) и систем оркестровки, таких как Kubernetes. Это ознаменовало переход к декларативному управлению инфраструктурой. С конца 2010-х годов получила развитие концепция GitOps, при которой инфраструктура управляется как код напрямую из системы контроля версий Git, обеспечивая автоматическую синхронизацию ожидаемого и фактического состояния системы^[27][28].

Релиз

Релиз завершает процесс разработки и иногда рассматривается как его часть, а не как элемент развёртывания^[29]. Он включает операции по подготовке системы к сборке и передаче на вычислительные узлы, где она будет эксплуатироваться. Зачастую этот этап требует определения ресурсов, необходимых для нормальной работы системы, и планирования/документирования последующих операций развёртывания.

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

Для простых систем установка — это создание команды, ярлыка, скрипта или службы для запуска ПО вручную или автоматически. В сложных системах она может включать настройку параметров — запрашивая информацию у конечного пользователя о способах эксплуатации или вариантах конфигурирования, а также подготовку всех зависимых подсистем. «Активация» — запуск исполняемого компонента ПО впервые.

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

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

Современным стандартом установки на корпоративные устройства является Zero-touch deployment (ZTD) — автоматизированное предоставление ресурсов через системы UEM. Этот подход позволяет подготовить рабочее место без ручного вмешательства: при первом включении устройство автоматически регистрируется в облачной службе, после чего загружаются конфигурационные профили, политики безопасности и необходимые корпоративные приложения^[30].^[31]

Деактивация

Деактивация — противоположный процесс, подразумевающий остановку исполняющихся компонентов. Часто необходима для обновления системы. Выведение устаревших систем из эксплуатации называют отказом от приложений или списанием.

Деинсталляция

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

Обновление

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

Для минимизации рисков при непрерывном развёртывании применяются современные стратегии: Canary releases (постепенный перевод небольшой части трафика на новую версию), Feature Flags (включение или выключение функциональности в рантайме без переразвёртывания) и Shadow deployment (дублирование реального продакшн-трафика на новую версию для проверки под нагрузкой без влияния на пользователей)^[32].

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

Механизмы встроенного обновления реализованы в некоторых приложениях и операционных системах Linux, Android, iOS. В современных ОС активно применяются механизмы атомарных (бесшовных) обновлений на основе A/B-разметки (например, в Android и ChromeOS), когда обновление скачивается и устанавливается в фоновом режиме на неактивный системный раздел, минимизируя время простоя^[33]. Автоматизация тут варьируется от полностью автоматического обновления до пользовательского контроля. Пример: Norton Internet Security с полуавтоматическим обновлением антивируса и компонентов. Некоторые продукты могут также автоматически уведомлять пользователя о доступности новых версий.

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

Системы отслеживания версий помогают пользователям искать и устанавливать обновления программ. Пример — каталог программ, хранящий сведения о версиях ПО на локальной системе; обновление запускается щелчком мыши по ссылке. В Linux, Android и iOS процесс может полностью автоматизироваться благодаря интеграции отслеживания версий. Некоторые сторонние программы поддерживают автоматическое обновление и для Windows-приложений. В современных процессах развёртывания важную роль играет SBOM (Software Bill of Materials) — перечень компонентов и зависимостей, интегрируемый в конвейеры CI/CD для автоматизации контроля уязвимостей. Использование SBOM позволяет непрерывно сверять компоненты с базами уязвимостей и автоматически инициировать обновления уязвимых пакетов^[34][35].

Сложность и многообразие программных продуктов привели к появлению специализированных ролей, связанных с организацией и инженерным сопровождением процесса развёртывания. На настольных системах функции развёртывания часто выполняет сам пользователь. Внедрение корпоративного ПО включает большее количество ролей, причём их набор меняется по мере перехода от тестовой среды к эксплуатации. Типичные роли при развёртывании корпоративных приложений:^[36]

• В тестовых средах:
  • разработчики приложений (см. Процесс разработки программного обеспечения)
  • инженеры по сборке и релизу
  • менеджеры релиза (см. Управление релизами)
  • координаторы развёртывания (см. DevOps)
  • DevSecOps Engineer (интеграция инструментов безопасности в CI/CD-конвейер и настройка security gates)^[37][38]
• В рабочих средах:
  • системный администратор
  • администратор баз данных
  • координаторы релиза (см. DevOps)
  • менеджеры ИТ-проектов (см. ITIL)^[39]
• Общие для сред:
  • платформенный инженер (Platform Engineer) — создание внутренних платформ разработки и предоставление разработчикам доступа к современным инструментам^[40][41]
  • SRE-инженер (Site Reliability Engineer) — обеспечение надёжности, мониторинг систем и использование производственных данных для принятия продуктовых решений^[40][41]

Современным трендом в развёртывании программного обеспечения является развитие платформенной инженерии, направленной на создание внутренних платформ разработчиков (Internal Developer Platform, IDP). IDP представляет собой портал самообслуживания, который абстрагирует сложность облачной инфраструктуры и предоставляет автоматизированные инструменты для доставки приложений^[42][43]. Внедрение таких платформ снижает когнитивную нагрузку на команды, стандартизует процессы и позволяет разработчикам самостоятельно управлять ресурсами в рамках корпоративных стандартов^[42][44]. Благодаря автоматизации рутинных задач время подготовки окружений и доставки кода сокращается до нескольких минут, что позволяет осуществлять несколько развёртываний в день^[42][44].

Для управления конфигурациями и мониторинга инфраструктуры применяются автономные ИИ-агенты. Они обеспечивают непрерывное отслеживание показателей производительности, обнаружение аномалий и автоматическое масштабирование ресурсов в зависимости от текущей нагрузки^[45]. Использование машинного обучения позволяет проактивно прогнозировать сбои на основе исторических данных, а методы обработки естественного языка помогают выявлять проблемы из текстовых описаний инцидентов^[45][46]. ИИ-агенты также способны анализировать трассировки микросервисов и обучаться на предыдущих инцидентах для совершенствования стратегий устранения проблем^[45][47].

Искусственный интеллект активно интегрируется в автоматизированное тестирование на этапах CI/CD. Применение ИИ позволяет ускорить релизные циклы за счёт автоматической генерации и восстановления тестов, а также интеллектуального выбора необходимых проверок при развёртывании^[48]. Для этих целей используются специализированные ИИ-платформы, большие языковые модели (LLM) и ИИ-ассистенты, которые интегрируются с классическими фреймворками тестирования и системами автоматизации.

На российском рынке инструментов развёртывания программного обеспечения и управления ИТ-инфраструктурой представлены отечественные DevOps-платформы и системы класса UEM (Unified Endpoint Management).

Среди ключевых DevOps-платформ, обеспечивающих автоматизацию жизненного цикла разработки, непрерывную интеграцию и развёртывание ПО, выделяются:^[49]

• GitFlic («Группа Астра»);
• Digital Q.DevOps («Диасофт»);
• AppSec.Code (AppSec Solutions);
• Gitlife Enterprise (3Logic Group);
• GitVerse («СберТех»).

В категории систем UEM, предназначенных для централизованного управления парком устройств, автоматизации развёртывания операционных систем и приложений, представлены:^[50]

• RuDesktop UEM^[51];
• «Аврора Центр»;
• Kaspersky Secure Mobility Management;
• UEM SafeMobile;
• Cloud Mobile Device Management;
• U-Connect;
• «Доступ от Контур.Эгиды».