Deploy

Деплой (deploy) — это развертывание и запуск веб-приложения или сайта в его рабочей среде, то есть на сервере или хостинге. Разработчик загружает приложение, написанное на локальном компьютере, в специальное пространство, из которого оно доступно в интернете.

Когда сайт загружают на сервер или хостинг, говорят, что его деплоят или «выкатывают». Также процесс называют деплоингом (deploying). Еще есть выражение «отправка в продакшн» или «на прод» — оно описывает этот же процесс.

Продакшн (production) — запущенная версия сайта, та, которую видят пользователи. Так что отправка в продакшн — тоже деплой. Точнее, одна из его разновидностей, потому что разворачивать приложение могут не только для конечных пользователей, но и, например, на тестовом сервере.

Само английское слово deploy в переводе означает «развертывать».

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

Сайты не пишут непосредственно на серверах: всю работу программисты делают на собственных или рабочих компьютерах. Соответственно, когда приложение написано и протестировано, нужно доставить его на сервер, настроить и запустить там. Так его смогут увидеть пользователи интернета.

Без деплоя код не дойдет до сервера и так и останется на рабочей машине программиста. А писать прямо на сервере — очень плохая идея даже в теории: это сложно, неудобно и может его «уронить». Тем более часто рабочая среда — не один сервер, а сотни разных устройств, и процесс развертывания и запуска в продакшн довольно сложный.

Что именно деплоят

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

Деплоят не обязательно приложение целиком. Чаще, если речь идет о процессах в коммерческой разработке, различные новые функции и доработки пишут разные программисты. По мере готовности отдельные завершенные части деплоятся. Это удобнее. А разработка распределенных приложений со множеством отдельных частей вообще выглядит как множество независимых деплоев.

Как выглядит жизненный цикл кода

Чтобы лучше понимать, как все происходит и какую роль играет деплой, простыми словами расскажем о процессе разработки в IT-компаниях.

1. Разработчик пишет код. Это может быть принципиально новый сервис или доработка к уже существующему, обновление сайта или что-то еще. Он делает это на локальном компьютере.

2. Когда код готов, разработчик коммитит его: загружает в репозиторий, специальную «общую папку» команды, например на сервисе GitHub. Там его смогут увидеть и прокомментировать другие разработчики — это называется код-ревью.

3. В определенный момент — по расписанию или после успешного коммита, который одобрили другие, — команда решает, что код нужно отправить в продакшн.

4. Создается релиз, публикуется своеобразное сообщение о будущем деплое: код в репозитории маркируется специальным тегом. Это нужно, чтобы избежать случайной отправки в продакшн каких-то изменений, которые внесли в репозиторий уже после сообщения о будущем деплое.

5. В нужное время происходит деплой. Код уходит в продакшн, появляется на серверах, его видят пользователи.

Что входит в деплой

Это зависит от того, что именно развертывают и какими инструментами при этом пользуются. Если речь о простом статическом сайте, где нет сложного бэкенда, достаточно загрузить новые файлы на сервер, обновить старые файлы, подключить зависимости и «собрать» проект. То же самое касается изменений, которые затрагивают только фронтенд — внешнюю часть, которую видит пользователь.

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

Когда все готово, новую версию запускают, а старую останавливают. Тут есть свои хитрости, которые позволяют избегать простоев сайта в этот период, но ими пользуются не все. Мы поговорим о них позже.

Деплоймент пошагово: как это выглядит

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

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

Автоматизация деплоя

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

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

  • с помощью надстроек и утилит, написанных для конкретных языков или библиотек;
  • через системы автоматизации и управления, такие как Ansible, или через облачные сервисы для веб-приложений вроде Heroku;
  • с помощью оркестраторов, платформ, которые управляют контейнерами, — самым известным примером считается Kubernetes.

Сборка и запуск тоже автоматизируются, уже с помощью других инструментов.

Уровень автоматизации может быть очень разным, вплоть до систем непрерывной доставки, при которой деплой полностью автоматический и не требует участия разработчика.

Избежание простоя: что такое подход Zero Downtime

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

При использовании подхода Zero Downtime Deployment сайт не останавливается. Это происходит, потому что в таком случае сначала запускается новая версия, а потом отключается старая.

Звучит просто, но на деле намного сложнее: во избежание ошибок и конфликтов нужно, чтобы старая и новая версия были единообразно написаны, а база данных была совместима с обеими одновременно. Кроме того, понадобятся автоматические системы, которые будут проверять запуск новой версии и переключать трафик на нее. Сам процесс усложняется.

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

Как начать деплоить

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

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

Узнайте больше о процессе разработки на курсах — мы поможем разобраться с нужными технологиями и начать работать по новой специальности.

Освойте новую профессию

(рейтинг: 5, голосов: 3)
Добавить комментарий