Сегодня разберёмся, что происходит после завершения разработки кода, создания дизайна и тестирования приложения. На очереди деплой — процесс, который обеспечивает доставку программного обеспечения до конечного пользователя. Поговорим о его задачах, особенностях и сложностях. Эти знания пригодятся всем, кто хочет разобраться в том, как компании выпускают обновления своих продуктов.
Но прежде чем погружаться в детали, рассмотрим, как программы попадают к пользователям.
Как пользователи получают новые версии программ и сервисов
Когда разработчик создаёт программу для личного использования, она запускается напрямую с его компьютера. Можно использовать командную строку или графический интерфейс. В этом случае доступ к программе ограничен, и дополнительных разрешений от других устройств не требуется.
Но чтобы продуктом могли пользоваться другие, его нужно сделать доступным для скачивания. Это может быть официальный сайт или магазин приложений. А если пользователь уже работает с программой, важно организовать процесс её обновления.
С точки зрения пользователя всё выглядит просто: уведомление о новой версии, кнопка обновления, и всё работает. Однако за этой простотой стоит сложный процесс, обеспечивающий безопасное и корректное обновление.
С онлайн-сервисами ситуация схожа: внешне может показаться, что ничего не изменилось, но производительность улучшилась. Для этого необходимо заменить старую версию сайта или приложения новой, избегая при этом простоев в работе.
Таким образом, все процессы обновления и публикации новых версий связаны с деплоем.
Что такое деплой
Деплой (от английского deploy — «внедрять») или развёртывание — это процесс, при котором программное обеспечение становится доступным пользователям. Грубо говоря, это развёртывание запакованных на локальных устройствах возможностей для широкой аудитории. Недаром символом деплоя часто служит изображение коробки, символизирующее распаковку.
Когда говорят «задеплоить», имеют в виду сделать программу доступной для других. В отличие от разработки, где создаётся код, деплой включает в себя множество задач, таких как:
- запуск и настройка сервера для новой версии;
- проверка работы системы в условиях, близких к реальным;
- обеспечение доступа пользователей к обновлённому продукту;
- подключение систем мониторинга для отслеживания сбоев и состояния приложения.
Деплой позволяет:
- в магазине приложений выпустить обновление программы;
- опубликовать новый продукт;
- изменить логику работы сайта;
- обновить интерфейс приложения.
Для чего нужен деплой
Цель деплоя — предоставить пользователям доступ к программному обеспечению. Процесс может различаться, но основная задача остаётся неизменной: обеспечить доступность продукта. Примеры:
- Новый продукт: после разработки и тестирования его делают доступным. Для этого арендуется сервер или разворачивается собственный, загружаются файлы и подключается доменное имя.
- Обновление существующего приложения: вносятся исправления, добавляются новые функции или обновляется дизайн.
- Автоматизация: настраивается процесс, при котором изменения в репозитории автоматически доходят до пользователей.
Автоматизация значительно упрощает процесс, исключая необходимость ручного вмешательства.
Способы деплоя
Деплой должен быть плавным, чтобы пользователи могли сразу начать работу с обновлением. Если разработчик вносит изменения в рабочую версию, пользователи могут столкнуться с ошибками или потерять доступ. Поэтому изменения готовят отдельно и внедряют аккуратно.
Иногда обновление требует кратковременного отключения пользователей, что называют временем простоя. Существуют разные сценарии деплоя:
Big Bang Deployment
Все изменения внедряются разом, что требует кратковременного отключения системы. Метод прост, но рискован: если в новой версии обнаружатся ошибки, придётся срочно их исправлять или откатывать.
Чтобы минимизировать риски, новую версию можно запускать параллельно со старой. Балансировщик нагрузки перенаправляет запросы пользователей на новую версию, а в случае ошибок возвращает их к старой.
Rolling Deployment
Метод для систем с несколькими серверами. Обновления внедряются поэтапно: отключают один сервер, обновляют его, а остальные продолжают работу.
Преимущества:
- отсутствие времени простоя;
- выявление ошибок на ранних стадиях.
Минусы: процесс занимает больше времени, и разработчики не контролируют, какие пользователи первыми получат новую версию.
Blue-Green Deployment
Популярный подход. Поддерживаются две системы: одна активна, другая готовится к обновлению. После тестов пользователи переключаются на обновлённую систему.
Преимущества:
- исключение времени простоя;
- возможность быстро вернуться к предыдущей версии.
Минус: высокая стоимость из-за поддержки двух систем.
Canary Deployment
Новая версия запускается для небольшой группы пользователей. Если ошибок не возникает, её распространяют на всех.
Преимущества:
- тестирование на ограниченной группе;
- возможность быстрого отката.
Этот метод требует мониторинга и анализа, а также инструментов для управления обновлениями.
Этапы деплоя
Процесс развёртывания начинается с готового кода. Это может быть первая версия приложения или его обновление. Основные этапы:
- Подготовка сервера
Если сервера ещё нет, его арендуют или покупают. Далее настраивается доступ к файлам программы. - Загрузка кода
Код отправляется на сервер с использованием систем контроля версий, таких как Git. - Обновление базы данных
Настраивают базу данных для работы с новой версией программы. - Замена старой версии
Останавливают старую версию приложения и запускают новую.
Этапы могут варьироваться в зависимости от инструментов и требований проекта.
Кто этим занимается
В небольших компаниях деплоем занимается один из бэкенд-разработчиков. Обычно это наиболее опытный сотрудник. Однако, когда разработчик занят деплоем, другие задачи откладываются. Если во время развёртывания возникают ошибки, их приходится срочно исправлять.
В крупных компаниях эту задачу берут на себя DevOps-инженеры. Их обязанности:
- автоматизация процессов разработки;
- настройка инструментов для программистов;
- управление серверами;
- внедрение систем мониторинга.
Автоматизация
Автоматизация деплоя позволяет значительно упростить процесс. При правильно настроенной системе разработчику достаточно отправить код в репозиторий, остальное сделает алгоритм.
Процесс выглядит так:
- Разработчик вносит изменения и сохраняет их в репозитории.
- Ответственный за проект проверяет изменения и утверждает их.
- Система формирует и запускает план деплоя.
- Если на каком-то этапе обнаруживаются ошибки, процесс останавливается, а разработчики получают уведомление.
- Если всё прошло успешно, изменения становятся видны пользователям.
Инструменты: GitHub Actions, Jenkins, GitLab CI/CD.
Что нужно знать
Для деплоя необходимы базовые знания разработки. Также потребуются:
- Работа с серверами. Навыки настройки серверов или виртуальных машин.
- Знание инструментов автоматизации. Популярные сервисы — GitHub Actions и Jenkins.
- Понимание языка разработки. Инструменты могут различаться в зависимости от языка.
Как научиться
Если у вас есть базовые навыки разработки и работы с репозиториями, начните с двух вещей:
- Настройка сервера
Арендовать и настроить сервер проще, чем кажется. - Работа с инструментами автоматизации
Начать можно с GitHub Actions или GitLab CI/CD.
Если вы хотите углубиться в DevOps, обратите внимание на курс «DevOps для эксплуатации и разработки». Начинать с нуля сложно, но при наличии базового опыта освоение будет легче.