Deploy
Деплой (deploy) — это развертывание и запуск веб-приложения или сайта в его рабочей среде, то есть на сервере или хостинге. Разработчик загружает приложение, написанное на локальном компьютере, в специальное пространство, из которого оно доступно в интернете.
«IT-специалист с нуля» наш лучший курс для старта в IT
Когда сайт загружают на сервер или хостинг, говорят, что его деплоят или «выкатывают». Также процесс называют деплоингом (deploying). Еще есть выражение «отправка в продакшн» или «на прод» — оно описывает этот же процесс.
Продакшн (production) — запущенная версия сайта, та, которую видят пользователи. Так что отправка в продакшн — тоже деплой. Точнее, одна из его разновидностей, потому что разворачивать приложение могут не только для конечных пользователей, но и, например, на тестовом сервере.
Само английское слово deploy в переводе означает «развертывать».
Профессия / 8 месяцев
IT-специалист с нуля
Попробуйте 9 профессий за 2 месяца и выберите подходящую вам
Для чего нужен деплой
Сайты не пишут непосредственно на серверах: всю работу программисты делают на собственных или рабочих компьютерах. Соответственно, когда приложение написано и протестировано, нужно доставить его на сервер, настроить и запустить там. Так его смогут увидеть пользователи интернета.
Без деплоя код не дойдет до сервера и так и останется на рабочей машине программиста. А писать прямо на сервере — очень плохая идея даже в теории: это сложно, неудобно и может его «уронить». Тем более часто рабочая среда — не один сервер, а сотни разных устройств, и процесс развертывания и запуска в продакшн довольно сложный.
Читайте также Востребованные IT-профессии 2023 года: на кого учиться онлайн
Что именно деплоят
Все, что работает в сети: веб-приложения, сайты, разные сервисы, в том числе те, которые не предназначены для внешнего использования. Даже если речь идет о каком-то локальном сервисе, работающем только во внутренней сети компании, его тоже нужно задеплоить, чтобы он стал доступен в этой сети.
Деплоят не обязательно приложение целиком. Чаще, если речь идет о процессах в коммерческой разработке, различные новые функции и доработки пишут разные программисты. По мере готовности отдельные завершенные части деплоятся. Это удобнее. А разработка распределенных приложений со множеством отдельных частей вообще выглядит как множество независимых деплоев.
Курс для новичков «IT-специалист
с нуля» – разберемся, какая профессия вам подходит, и поможем вам ее освоить
Как выглядит жизненный цикл кода
Чтобы лучше понимать, как все происходит и какую роль играет деплой, простыми словами расскажем о процессе разработки в IT-компаниях.
1. Разработчик пишет код. Это может быть принципиально новый сервис или доработка к уже существующему, обновление сайта или что-то еще. Он делает это на локальном компьютере.
2. Когда код готов, разработчик коммитит его: загружает в репозиторий, специальную «общую папку» команды, например на сервисе GitHub. Там его смогут увидеть и прокомментировать другие разработчики — это называется код-ревью.
3. В определенный момент — по расписанию или после успешного коммита, который одобрили другие, — команда решает, что код нужно отправить в продакшн.
4. Создается релиз, публикуется своеобразное сообщение о будущем деплое: код в репозитории маркируется специальным тегом. Это нужно, чтобы избежать случайной отправки в продакшн каких-то изменений, которые внесли в репозиторий уже после сообщения о будущем деплое.
5. В нужное время происходит деплой. Код уходит в продакшн, появляется на серверах, его видят пользователи.
Что входит в деплой
Это зависит от того, что именно развертывают и какими инструментами при этом пользуются. Если речь о простом статическом сайте, где нет сложного бэкенда, достаточно загрузить новые файлы на сервер, обновить старые файлы, подключить зависимости и «собрать» проект. То же самое касается изменений, которые затрагивают только фронтенд — внешнюю часть, которую видит пользователь.
Если же обновляется бэкенд, или серверная часть сайта, все куда сложнее. Нужно как минимум подключить к коду базу данных и соединить составные части приложения друг с другом. Иногда этот процесс бывает довольно долгим.
Когда все готово, новую версию запускают, а старую останавливают. Тут есть свои хитрости, которые позволяют избегать простоев сайта в этот период, но ими пользуются не все. Мы поговорим о них позже.
Деплоймент пошагово: как это выглядит
Вот как примерно выглядит процесс:
- отправка кода на сервер — файлы «приходят» в рабочую среду, чаще всего через Git;
- настройка зависимостей — старые файлы обновляются, в них прописываются связи с новыми частями кода, нововведения интегрируются в структуру;
- сборка — все файлы «собираются» в единый проект, в систему, которая может функционировать;
- миграции — выполнение специальных скриптов для базы данных, которые «готовят» ее к нововведениям, обновляют и настраивают структуру;
- запуск — старая версия останавливается, задеплоенная запускается. После этого приложение начинает работать с новыми функциями.
Автоматизация деплоя
Делать все перечисленное вручную — долгий процесс, который отнимает у программиста время и силы, увеличивает риск ошибки и уровень стресса в команде. В перспективе ручной деплой еще и ухудшает продуктивность: увеличивается срок до выхода в продакшн, сервис развивается медленнее, нововведения выкатывают реже.
Поэтому деплоймент обычно автоматизируют. Сделать это можно несколькими способами, какой выбрать — зависит от стека технологий, бюджета и масштаба проекта:
- с помощью надстроек и утилит, написанных для конкретных языков или библиотек;
- через системы автоматизации и управления, такие как Ansible, или через облачные сервисы для веб-приложений вроде Heroku;
- с помощью оркестраторов, платформ, которые управляют контейнерами, — самым известным примером считается Kubernetes.
Сборка и запуск тоже автоматизируются, уже с помощью других инструментов.
Уровень автоматизации может быть очень разным, вплоть до систем непрерывной доставки, при которой деплой полностью автоматический и не требует участия разработчика.
Избежание простоя: что такое подход Zero Downtime
Выше мы говорили, что в классическом варианте старая версия отключается, а новая запускается и, пока это происходит, сайт простаивает. Посетители не могут им пользоваться. Для крупных проектов деплой занимает много времени, и такой простой критичен, особенно если сайт коммерческий. Поэтому есть способы, позволяющие его не допустить.
При использовании подхода Zero Downtime Deployment сайт не останавливается. Это происходит, потому что в таком случае сначала запускается новая версия, а потом отключается старая.
Звучит просто, но на деле намного сложнее: во избежание ошибок и конфликтов нужно, чтобы старая и новая версия были единообразно написаны, а база данных была совместима с обеими одновременно. Кроме того, понадобятся автоматические системы, которые будут проверять запуск новой версии и переключать трафик на нее. Сам процесс усложняется.
Из-за высоких требований к инфраструктуре таким подходом обычно пользуются большие проекты, у которых есть ресурсы для его реализации.
Как начать деплоить
Проще всего пользоваться сервисами вроде Heroku: бесплатный план ограничен, но поможет разобраться. Если вы хотите потренироваться, можете воспользоваться хостингами: они обычно предлагают решения для настройки окружения, но за них придется платить.
В коммерческих проектах новички обычно не занимаются деплоем — это довольно ответственная задача. В больших компаниях за развертывание отвечает DevOps-инженер, но если проект маленький, эта задача может лечь на бэкендера, тимлида или другого специалиста.
Узнайте больше о процессе разработки на курсах — мы поможем разобраться с нужными технологиями и начать работать по новой специальности.
IT-специалист с нуля
Наш лучший курс для старта в IT. За 2 месяца вы пробуете себя в девяти разных профессиях: мобильной и веб-разработке, тестировании, аналитике и даже Data Science — выберите подходящую и сразу освойте ее.
Статьи по теме:
Боевой сервер (продакшн, production) — что это в программировании и разработке
Боевой сервер (он же продакшн, production или просто «прод»/prod) — сервер (обычно подразумевают железку, ну или как минимум виртулизированную операционную систему), на котором приложение выполняется для нужд конечных клиентов.
Может существовать и тестовый сервер, на котором, в отличие от «боевого», приложение просто тестируют.
Что такое на проде?
Вижу как разработчики общаются, и один спросил: А на проде на кунгуре у всех какой фпс?
Что такое «на проде»?
Голосование за лучший ответ
Боевой сервер (он же продакшн, production или просто «прод»/prod) — сервер (обычно подразумевают железку, ну или как минимум виртуализированную операционную систему), на котором приложение выполняется для нужд конечных клиентов.
Может существовать и тестовый сервер, на котором, в отличие от «боевого», приложение просто тестируют.
IT-термины: как разговаривать с программистами
Сколько раз с вами случалось, что в ответ на предложение «скипануть» встречу или «заэстимейтить» план задач собеседник удивленно приподнимал бровь? Такое происходит довольно часто, когда IT-специалисты или выпускники курсов программирования используют свой сленг при общении с теми, кто работает в других сферах.
Давайте пройдемся по основным терминам, которые, на самом деле, очень легко запомнить, если провести аналогию с оригиналом их происхождения — английским.
Scrum—способ ведения разработки, при котором сохраняется итеративность (четкие списки задач на короткие отрезки времени) и равномерное распределение ответственности между всеми участниками команды.
Спринт — это не только бег спортсменов на короткую дистанцию, известный в широких кругах как sprint. В разработке это — небольшой промежуток времени (1-4 недели), укомплектованный задачами на команду.
Релиз — своеобразный «выход в свет», release. Выпуск целого приложения или его части (например, багфикс) в продакшн-версии для конечного пользователя или в промежуточной для внутреннего тестирования. В идеале каждый спринт должен заканчиваться релизом.
Продакшн —конечная версия приложения или сайта, доступная рядовым пользователям (production). Проще говоря, то, что мы можем найти в Google, скачать с Google Play или Apple Store.
Стейджинг —промежуточная, отладочная версия сайта, выкладка для тестировщиков (staging). Обычным юзерам недоступна.
Баг —нет, это не жук в стандартном понимании слова bug. С багами чаще всего сталкиваются тестировщики. Баг — это ошибка в коде, которая ломает приложение в тех или иных местах. Приносит так же мало счастья, как и реальный жук.
Багфикс — работа над ошибками и их исправление (bug fix).
Деплой — перенос разработчиками свежего кода на нужный сервер (промежуточный или продакшен), deploy. Очень часто в конце спринта можно услышать тревожное «Задеплоил ли ты свои изменения?».
Билд —сборка мобильного приложения, несущая в себе последние обновления (build). Самые свежие результаты «строительства».
Таска —задача (task). Например, добавить поле на странице регистрации.
Эстимейт — оценка времени или усилий, необходимых для выполнения задачи (estimate). Если используем время, то проставляем количество часов, необходимых для закрытия задачи. Если усилия — стори поинты.
Стори поинты —баллы, неотъемлемая часть скрама. Индивидуальная оценка задачи разработчиком. Чем больше баллов, тем сложнее. При использовании story points основная задача менеджера – понять, сколько всего баллов команда может выполнить в течение спринта.
Линк — проще, чем кажется. Ссылка, link.
Бекенд —представьте себе машину и загляните под капот. Backend — это и есть «то, что под капотом» сайта или приложения, то, что скрывается за красивой картинкой, серверная часть. Сюда относится поиск информации, отправка форм и сообщений, загрузка информации и т. д.
Фронтенд — та самая красивая картинка, «лицо» вашего автомобиля. Цвета, отступы, стрелочки, всякие кнопки и другая визуальная часть, доступная глазу пользователя.
Ну, и скипануть означает пропустить, skip something.
А если хотите узнать все термины с первых рук, вам нужны курсы IT онлайн 😉
Примечание: а если вы хотите, чтобы и ваш ребенок был в IT, детские курсы программирования будут полезны!