> For the complete documentation index, see [llms.txt](https://docs.system-analyst-base.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.system-analyst-base.ru/hard-skills/devops-for-sa/razvertyvanie-prilozhenii.md).

# Развертывание приложений

{% hint style="info" %}
**Деплой (deploy)** — это развертывание и запуск веб-приложения или сайта в его рабочей среде, то есть на сервере или хостинге. Разработчик загружает приложение, написанное на локальном компьютере, в специальное пространство, из которого оно доступно в интернете.
{% endhint %}

## Откуда тут DevOps?

<figure><img src="/files/zJNQ0T33DvqoMAQ8fbuw" alt=""><figcaption></figcaption></figure>

Возвращаясь к главе:

{% content-ref url="/pages/DjL7MXBh7rL1Gfu5aoB9" %}
[Роли в IT продукте](/soft-skills/produkt/roli-v-it-produkte.md)
{% endcontent-ref %}

На самом деле после разработки продукта внутри команды, этот продукт нужно донести до конечного пользователя (заказчика), иными словами развернуть приложение, чтобы оно стало доступно всем. Как раз тут и появляется DevOps.

## Жизненный цикл кода <a href="#kak-vyglyadit-zhiznennyi-cikl-koda" id="kak-vyglyadit-zhiznennyi-cikl-koda"></a>

1. Разработчик пишет код. Это может быть принципиально новый сервис или доработка к уже существующему, обновление сайта или что-то еще. Он делает это на локальном компьютере.
2. Когда код готов, разработчик коммитит его: загружает в репозиторий, специальную «общую папку» команды, например на сервисе GitHub. Там его смогут увидеть и прокомментировать другие разработчики — это называется код-ревью.
3. В определенный момент — по расписанию или после успешного коммита, который одобрили другие, — команда решает, что код нужно отправить в продакшн.
4. Создается релиз, публикуется своеобразное сообщение о будущем деплое: код в репозитории маркируется специальным тегом. Это нужно, чтобы избежать случайной отправки в продакшн каких-то изменений, которые внесли в репозиторий уже после сообщения о будущем деплое.
5. В нужное время происходит деплой. Код уходит в продакшн, появляется на серверах, его видят пользователи.

## Deploy

Вот как примерно выглядит процесс пошагово:

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

## Для чего нужен деплой

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

Поэтому программисты придерживаются подходов непрерывной интеграции (от англ. continuous integration) и непрерывной доставки (от англ. continuous delivery).&#x20;

{% content-ref url="/pages/3SFZjrMt06vkqoT88JEU" %}
[CI/CD](/hard-skills/devops-for-sa/razvertyvanie-prilozhenii/ci-cd.md)
{% endcontent-ref %}

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

## Подходы к развертыванию приложений

**Традиционный способ.** На первых этапах развития компьютерной техники несколько приложений, установленных на одном сервере, отбирали ресурсы друг у друга, снижая эффективность работы. Решением стал запуск одной программы на одном физическом сервере. Но иметь несколько серверов было невыгодно.

**Виртуальная машина.** Это программная или аппаратная эмуляция работы одной или нескольких гостевых платформ (quest) на платформе-хозяине (host). Виртуальная машина имитирует компоненты аппаратного обеспечения или целый ПК с отдельной ОС. Это позволило эффективнее разграничить ресурсы физического сервера между ВМ и масштабировать их работу.

**Контейнер.** По сути, это усовершенствованный вариант виртуальной машины с максимальной изоляцией в рамках одной операционной системы. В отличие от обычной ВМ, он не связан с базовой аппаратной инфраструктурой и может легко переноситься между облаками и несколькими ОС.

Источники:

* <https://blog.skillfactory.ru/glossary/deploy/>
* <https://practicum.yandex.ru/blog/chto-takoe-deploy/#dlya-chego-nuzhen>