Как и зачем применяют деплой в программировании

Любое ПО проходит несколько стадий, прежде чем окажется у пользователя:

● разработка;
● тестирование;
● препродакшн тестирование;
● переход в продакшн.

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

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

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

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

Деплой веб-приложений можно выполнить тремя способами:

1. Использовать виртуальный арендованный сервер (VPS), чтобы передать файлы вручную. Это может быть скомпилированная версия, когда код переведён в машинный, или просто отдельные HTML-страницы либо JavaScript. Веб-сервер считывает изменения в файлах и отправляет их пользователю. Такой подход считается устаревшим, потому что уже никто не хранит файлы в папке на сервере.

2. На виртуальных машинах (VDS) — операционных системах, способных имитировать другое устройство или программу. Они подходят для запуска любого ПО. Для деплоя устанавливают Docker — платформу для разработки, доставки и запуска контейнерных приложений, веб-сервер, например легковесный и мощный Nginx, и уже к нему добавляют разрабатываемое ПО. Это более продвинутый путь, универсальный, но сложный.

3. С помощью специальных платформ: GitHub, GitLab, Heroku, OpenShift Online, Yandex Cloud. Это самый современный способ деплоя: разработчику не нужно ничего передавать вручную или устанавливать на компьютер дополнительные программы. Достаточно указать в коде сценарий деплоя, отправить изменение в репозиторий или хранилище данных, и все действия по сборке и деплою кода произойдут внутри платформы.

1. Отправка кода на сервер.
Файлы доставляются в рабочую среду через Git — систему контроля версий, которая позволяет сразу нескольким разработчикам сохранять и отслеживать изменения в файлах проекта.

2. Установка зависимостей.
Исходные файлы обновляются, в них прописываются связи с новыми частями кода, результат интегрируется в структуру.

3. Сборка.
Все файлы «соединяются» в единый работоспособный проект.

4. Запуск.
Предыдущая версия прекращает свою работу, запускается вариант программы с новыми функциями.

На курсе «Основы работы с Git» студенты учатся работать с системой контроля версий Git, разбираются в принципах и основах её работы.

Чтобы настроить сценарий через GitHub Actions, нужно создать в репозитории директорию .github/workflows. В ней размещаются файлы с шагами, которые нужно выполнить в ответ на различные события. Например, проект написан на React, его нужно скомпилировать и поместить в GitHub Actions. После того как программист отправит коммит (от англ. commit, сохранить изменения), этот сценарий запустится автоматически. Платформа сама выполнит все действия: сборку, упаковку, передачу данных и запуск.

Посмотреть, как работать с GitHub Pages и Actions на React, можно на примере открытого проекта