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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кто такие свитчеры

27 янв. 2024 г.

Как быстро и правильно гуглить

26 янв. 2024 г.

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

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

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

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

Как это происходит. Разработчики добавляют код в репозиторий. В какой-то момент они решают, что пора доставить его до продакшена. Это может происходить как по регулярному расписанию, например, раз в две недели, так и просто по необходимости, вплоть до выкатки после каждого изменения. Во многом количество деплоев зависит от уровня его автоматизации — того, насколько процесс легкий в проведении и откате в случае проблем. На Хекслете деплои выполняются практически после каждого изменения, около 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
• Среды разработки

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

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

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

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

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

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

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

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

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

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

Деплой — Веб-разработка на PHP

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

1. Покупка домена
2. Покупка хостинга и его настройка
3. Деплой

Первый пропустим, так как скоро мы его опишем в https://guides.hexlet.io. Про два других поговорим в этом уроке.

Процесс деплоя

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

Во время деплоя выполняются следующие задачи:

1. Код проекта скачивается на сервер (обычно через клонирование Git)
2. Ставятся необходимые зависимости
3. Выполняется процесс сборки, например, собирается фронтенд-часть
4. Выполняются миграции. Миграции — SQL-скрипты, которые изменяют структуру базы данных
5. Запускается новая версия кода

Это один из возможных вариантов, причем довольно примитивный.

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

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

Если после или во время деплоя что-то пошло не так, то нужно деплоить снова, причем именно предыдущую версию.

Также деплои можно классифицировать по способу обновления и отката:

• Последовательное обновление — сервера обновляются по очереди
• Сине-зеленый деплой — полное дублирование инфраструктуры с подменой

Отдельно стоит сказать про канареечный релиз — canary release. При таком подходе переключение на использование новой версии происходит постепенно: сначала для небольшого процента пользователей, а затем и для всех.

Типы хостингов

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

• Виртуальный хостинг (Shared Hosting) — самый дешевый способ размещать сайт в интернете. Такая услуга включает в себя доступ на сервер с уже настроенным программным обеспечением под конкретный стек, например, Linux + PHP + MySQL. Этот способ подходит для самых простых сайтов и требует минимальной настройки
• VPS/VDS — наиболее сбалансированная услуга, в рамках которой предоставляется виртуальная машина. Плюс в том, что такой вид хостинга позволяет задействовать больше серверных мощностей: ЦПУ, память и диск. Предустановленного ПО нет, всё нужно делать самостоятельно. По сравнению с виртуальным хостингом мы не ограничены в правах и можем настраивать сервер, как угодно
• Выделенный сервер (Dedicated Server) — либо свой, либо арендованный сервер. Такой хостинг требует больше всего участия, но зато мы получаем лучшее соотношение производительность/цена
• IaaS (Infrastructure as a Service) — инфраструктура как сервис. Вид хостинга, при котором большая часть возможностей представляется как сервис. Как пример: Amazon Web Service (AWS)
• PaaS (Platform as a Service) — платформа как сервис. Наиболее дорогой и самый автоматизированный способ из коробки по размещению сайтов. Выкладка сайта происходит буквально по команде git push . Кроме цены важно учитывать используемые технологии и подходы. PaaS обладает наибольшим числом ограничений по тому, что и как можно делать. Но в обмен мы получаем не просто автоматизированный хостинг, но и платформу, которая автоматически «скейлится» (масштабируется) под нагрузку.

Все способы деплоя можно разбить на две большие категории: деплой на PaaS и деплой на все остальное.

PaaS

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

Популярное PaaS-решение на текущий день — Render.com . У этого сервиса есть документация . Если следовать ей, можно быстро выложить свой первый сайт.

Render используется в Хекслете студентами для выполнения проектов и в опенсорсе.

Все остальное

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

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

Установка необходимого ПО — такой же автоматизируемый процесс как процесс деплоя. У него есть собственное название — Управление конфигурациями (Configuration Management).

Рекомендуем использовать Ansible — популярное решение для настройки (На Хекслете есть соответствующий курс).

- hosts: all tasks: - lineinfile: create: yes regexp: ~/.local path: ~/.bash_profile line: "export PATH=$PATH:~/.local/bin" - name: install packages apt: pkg=python3-pip state=latest update_cache=yes tags: pip become: yes - pip: name: pip state: latest become: yes 

Ключевое понятие Ansible — Playbook (плейбук). Это файл в формате YAML, в котором описывается, что нужно сделать на указанной машине.

В каждом плейбуке используются готовые модули, поставляемые вместе с Ansible. Этих модулей сотни. С их помощью можно делать практически всё: от установки программ до настройкой сети и управления правами файловой системы.

Открыть доступ

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

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Наши выпускники работают в компаниях: