Что такое деплой в программировании
Перейти к содержимому

Что такое деплой в программировании

  • автор:

Deploy

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

«IT-специалист с нуля» наш лучший курс для старта в IT

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

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

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

Профессия / 8 месяцев
IT-специалист с нуля

Попробуйте 9 профессий за 2 месяца и выберите подходящую вам

vsrat_7 1 (1)

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

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

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

Читайте также Востребованные 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 — выберите подходящую и сразу освойте ее.

картинка (75)

Статьи по теме:

Что такое деплой

Деплой — процесс «разворачивания» веб-сервиса, например, сайта, в рабочем окружении. Рабочее окружение — место, где сайт запускается и доступен для запросов. Это может быть как готовый хостинг, так и своя собственная серверная инфраструктура.

Деплоятся не только веб-сервисы, но любые сервисы, доступные по сети. Даже если эта сеть внутренняя и не доступна для запросов через интернет.

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

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

Каждый раз, когда разработчики решили что все, пора, они создают релиз. Под релизом обычно понимают тег в Git, который фиксирует, что уйдет в деплой. То есть изменения, добавленные в мастер после создания тега, не повлияют на сам тег, а значит, мы точно уверены в том, что деплоим.

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

Стоит сказать, что PaaS-платформы, такие как Heroku, берут деплой полностью на себя. Там достаточно выполнить коммит, и дальше все произойдет само. Цена за это — стоимость самой платформы.

  • Шаги деплоя
  • Автоматизация
  • Zero Downtime Deployment
  • Дополнительная литература

Шаги деплоя

Доставка кода на сервер

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

  • Git: git checkout tag-name
  • Docker: docker pull image-name:tag-name
  • Apt (Пакет): apt-install application-package-name

Обновление базы данных

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

CREATE TABLE car ( id INT NOT NULL PRIMARY KEY, license_plate VARCHAR NOT NULL, color VARCHAR NOT NULL ); ALTER TABLE owner ADD driver_license_id VARCHAR; 

Запуск и остановка

Где-то в этом процессе происходит остановка старой версии и запуск новой. Если сначала остановить старую версию, а потом выполнить миграции и запустить новую, то мы получим простой (downtime) в работе сервиса. Так действительно работают многие, но это может быть болезненно для бизнеса и частых деплоев. Поэтому самые продвинутые проекты не останавливаются во время деплоя. О том, как это делать — ниже.

Автоматизация

Деплой нужно максимально автоматизировать, от этого зависит Time To Market — ключевая характеристика бизнес-ориентированных приложений. Чем быстрее и чаще мы доставляем изменения пользователю, тем лучше. Быстрее проверяем гипотезы, быстрее вносим исправления, быстрее оправдываем деньги, вложенные в разработку. Без автоматизации разработчики боятся выполнять деплой, он становится обузой, что приводит к снижению числа деплоев и регулярному стрессу для всей команды, с засиживанием на работе до позднего вечера.

Основных способа автоматизации три:

  1. С помощью утилит, созданных для конкретных языков. Например, в Ruby это Capistrano, одна из первых и наиболее известных утилит подобного рода, ставшая популярной далеко за пределами Ruby. Основная проблема с такими инструментами — сильная завязка на язык.
  2. С помощью Ansible, в который уже встроен модуль для деплоя. Идеально подходит для большинства ситуаций деплоя на управляемые сервера.
  3. Системы оркестрации типа Kubernetes. Если они используются, то без автоматического деплоя никак.

Но, даже если автоматизация выполнена, все равно остается задача «запустить деплой». Запуск тоже автоматизируется. Существует целый подход, который называется Непрерывная доставка(continuous delivery). Его сложно внедрить, и он не везде подходит, но если получилось, то про деплой забывают. Он выполняется полностью сам без участия людей. Главное в таком варианте — хороший мониторинг и система оповещения (алертинг) для реакции на ошибки.

# https://docs.ansible.com/ansible/latest/collections/community/general/deploy_helper_module.html#examples - name: Initialize the deploy root and gather facts community.general.deploy_helper: path: /path/to/root - name: Clone the project to the new release folder ansible.builtin.git: repo: ansible.builtin.git ://foosball.example.org/path/to/repo.git dest: '>' version: v1.1.1 - name: Add an unfinished file , to allow cleanup on successful finalize ansible.builtin.file: path: '>/>' state: touch 

Zero Downtime Deployment

Если не предпринимать специальных шагов, то каждый деплой будет приводить к остановке (возможно частичной) сервиса. В это время пользователи либо увидят ошибку, либо сообщение о происходящем обновлении. Но такого не происходит на большинстве крупных сервисов в интернете. Почему? Из-за реализации подхода «деплой без даунтайма» (downtime — простои в работе сервиса).

Zero Downtime Deployment выглядит так, как будто сервис никогда не останавливается, но при этом обновляется. Достигается это за счет одновременного запуска старой и новой версий кода. То есть, когда деплоится приложение, то сначала поднимается новая версия рядом со старой. И только когда автоматика убеждается, что новая версия запустилась и работает, происходит остановка старой версии. Для выполнения этой процедуры понадобится следующее:

  1. Инфраструктура. Нужен балансировщик, который может переключать трафик (входящие соединения от браузеров или других систем) между старой и новой версиями кода. И желательно иметь как минимум два сервера, хотя это и не обязательно.
  2. Деплой. Процесс деплоя без простоя значительно сложнее, чем с остановкой. Проще всего такой деплой делается на системах оркестрации, например, Kubernetes.
  3. Культура кода. Обеспечить безостановочную работу невозможно без определенной культуры написания кода. Чтобы старая и новая версии могли работать одновременно, нужно следить за всеми интерфейсами. Важно соблюдение обратной совместимости (работа с api, базой, очередями и, в целом, любыми хранилищами).
  4. База данных. Она должна быть обратно-совместима между старой и новой версией. Все миграции только вперед (их нельзя откатывать!) и только на добавление. Нельзя удалять и обновлять (переименовывать, менять тип) колонки и таблицы.
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: tomcat -deployment -$ TARGET_ROLE > spec: replicas: 2 template: metadata: labels: app: tomcat role: $ TARGET_ROLE > spec: containers: - name: tomcat -container image: tomcat :$ TOMCAT_VERSION > ports: - containerPort: 8080 readinessProbe: httpGet: path: / port: 8080 

Дополнительная литература

  • Подробнее про Zero Downtime Deployment
  • Инжиниринг в Booking
  • Стратегии деплоя
  • Stateless vs Statefull
  • Ansible Deploy
  • Среды разработки

Что такое деплой

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

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

1. Деплой нужен для обновления приложения.

2. Он позволяет заменить устаревшую версию приложения новой.

3. Деплой необходим для тестирования изменений в реальной среде перед тем, как они станут доступными пользователям.

4. Деплой может выполняться для применения настроек и конфигурационных файлов, обновления библиотеки или замены данных.

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

Когда речь идет о деплое, обычно имеется в виду процесс распространения разработанных программных продуктов на серверы, где они будут работать.

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

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

Жизненный цикл кода — это процесс от создания и написания кода до его удаления или модификации. На этом пути код может пройти через различные этапы, каждый из которых выполняет свою функцию. Рассмотрим основные этапы жизненного цикла кода.

  1. Создание кода
  2. Тестирование и отладка
  3. Публикация
  4. Использование
  5. Обновление
  6. Удаление.

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

Что такое Data Science

Что такое Data Science

Кто такой веб-разработчик

5 февр. 2024 г.

Кто такой веб-разработчик

Какой язык программирования выбрать в 2024 году

31 янв. 2024 г.

Деплой — что это в программировании (deploy)

vedro-compota's picture

Деплой (deploy) — задача развертывания приложения на новой машине/или на той же самой, но новой его версии.

То есть, деплой это процесс (так или иначе организованный) перевода кода вашего проекта в рабочее состояние на конкретной машине, как следствие деплой может включать (в этом или ином порядке):

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

Как хорошо и как плохо делать деплой

Сегодня деплой принятно производить максимально автоматизированным способом — т.е. писать скрипты (или использовать готовые инструменты), которые автоматизируют:

  • перенос кода проекта,
  • его адоптацию (скажем, разворот данных бд)
  • и запуск на новой машине.

Перенос системы с одной машины на другую должен быть «приятным процессом», а не собиранием её (системы) руками по кускам (файлам), сопровождающимся танцами с бубном.

Примеры систем для развертывания («деплоиинга»)

  • Для PHP есть Deployer — умеет перенести на сервер конкретную ветку СКВ, ему можно написать задачи типа «выполни миграции после выкачивания ветки» на боевой сервер.
  • Универсальным знаменитым средством деплоя и сборки (а также для автоматизации других задач) является Jenkins

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *