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