Как сделать деплой приложения
Часто разработчики-одиночки не пользуются привычными инструментами и практиками вроде VCS, CI/CD, которые используют в командах. Спросили у экспертов, правильно ли они делают и как можно самому построить процесс разработки, сопровождения и деплоя.
ведущий программист компании Polarr Inc.
Разработчик-одиночка в общем случае мало чем отличается от команды разработчиков с точки зрения построения собственных процессов. В случае с одним человеком, который работает над каким-то продуктом, такой разработчик одновременно берёт на себя все обязанности по работе над продуктом в виде полного цикла «заботы» о нём:
- планирование и дизайн продукта, разметка целевой аудитории;
- написание первичной версии приложения;
- тестирование первичной версии самостоятельно или с помощью приятелей и друзей;
- вторичная — «релизная» — версия приложения, исправленная с учётом тестирования первичной версии;
- финальное тестирование;
- релиз ПО ограниченному кругу пользователей для сбора дальнейшего фидбека;
- дальнейшее изменение продукта в соответствии с нуждами пользователей и вечный цикл поддержки продукта после его финального релиза.
По большому счёту, разработка ПО — это цикличный процесс с определёнными фазами. Работа непосредственно над продуктом сменяется сбором фидбека. После этого происходит выпуск новой версии, снова сбор фидбека, снова работа над продуктом.
Именно с точки зрения цикличной работы над продуктом, имеет смысл использовать следующие процессы при работе над ним одному человеку:
- Обязательно использовать VCS (например, приватный репозиторий на GitHub) – поможет следить за версиями продукта, понимать разницу между предыдущим и следующим релизом, а также даёт возможность разделять стабильные релизы от нестабильного кода, над которым в данный момент ведётся работа.
- Присваивать версии по системе Semantical Versioning — позволит выработать дисциплину относительно размера изменений в продукте. Значительные изменения выпускаются гораздо реже (особенно, если проект поддерживается одним человеком), чем небольшие правки маленьких ошибок.
- Важно самому тестировать собственный продукт после добавления определённого количества возможностей в продукт. Либо попросить знакомых сделать это вместе с вами, чтобы получить больше сторонних мнений (не принципиально, что такие тестеры не являются целевой аудиторией — главное не UI/UX фидбек, а механическое тестирование функций).
- Придётся самостоятельно общаться с пользователями проекта. Это может быть почтовое общение через почту поддержки, а может быть и через специальную площадку для фидбека о продукте. Главное — определиться с максимальным временем ответа, чтобы пользователи не ждали долгого ответа и знали, что им ответят в течение, например, 72 часов.
- Если разработчик, работающий над проектом один, не пользуется средствами трекинга задач для своего продукта, то ему могут помочь простые маркеры TODO и FIXME в собственном коде. Современные редакторы (например, VSCode) позволяют анализировать код и создавать деревья TODO и FIXME, с помощью которых можно отслеживать всё, что хотелось бы рано или поздно реализовать или изменить в продукте. Такие маркеры — это часть натуральной документации кода, которая позволит одиночке не забыть о том, в какую сторону движется код.
- В CI/CD нет необходимости, если работаешь один (по крайней мере до первого релиза точно). Некоторые процессы можно автоматизировать, но это далеко не обязательно делать с помощью тяжеловесных облачных сервисов CI/CD — автоматизацию можно выполнить в виде ряда скриптов, которые будут брать на себя основную тяжёлую рутинную работу. К тому же, локальные скрипты автоматизации — это бесплатно.
главный специалист отдела разработки программного обеспечения, Okko
В наши дни я не могу представить себе процесс написания кода без Git. Даже если работаю один над пет-проектом.
Во-вторых, если в процессе работы весь проект оказался сломан или по каким-то причинам не получилось реализовать функционал или я понял, что это всё была плохая затея, я могу одной командой вернуть предыдущую версию проекта. Или даже проводить эксперименты на тестовой ветке, а делать фичи в стабильной ветке.
Также, без системы контроля версий невозможно реализовать деплой сайта или приложения. Только если написать скрипт, который будет полностью перезаливать все файлы на сервер по FTP или SSH. Но такой процесс будет долгим и сложным – в любой момент соединение может оборваться и придётся делать всё заново. А с наличием Git, можно как минимум подключиться к серверу и сделать git pull . Когда-то мы даже использовали такой подход в продакшене.
Однако, это было до того, как веб-приложения стали нуждаться в установке зависимостей и сборке. Но и сейчас можно достаточно легко написать скрипт, например на bash, который будет клонировать новую версию проекта в отдельную папку, делать npm install , npm run build и менять символическую ссылку. А в случае проблем, запускать скрипт переключения символической ссылки на папку с предыдущей версией. Деплой на коленке готов.
Во избежание проблем с самописными решениями, я могу посоветовать воспользоваться утилитой Ansistrano. Она делает всё, что описано выше и при этом заходить на сервер не обязательно. Можно запустить скрипт прямо со своей машине. А сценарии деплоя и отката описываются в декларативных yml-файлах. Плюс, все действия идемпотенты и есть гибкие настройки: ветка, тег, коммит с которых производить деплой, количество сохраняемы резервных копий и так далее.
Для меня это минимально комфортный уровень работы над проектами. Автоматический деплой спасает от рутинных действий и уберегает от ошибок, вызванных человеческим фактором.
Если пойти чуть дальше, то можно освоить базовые функции Bitbucket Pipelines или GitHub Actions. Скрипты у них тоже пишутся в yml-файлах, только синтаксис везде разный. Но плюсом получаешь заготовленные сценарии, которые, например умеет использовать кеши npm, что значительно ускоряют процесс, и много других фич. Так же можно организовать автоматический деплой по мерджу в master или добавлению тэга. И это уже будут настоящие CI/CD.
Самое главное, что потратив один раз небольшое количество времени и сил на освоение этих технологий, получаешь крутые и удобные инструменты, которые облегчают жизнь каждый день и экономят время.
заместитель директора по разработке «ВИСТ» (группа «Цифра»)
Каждый случай индивидуален. Все зависит от объема работ, процесса согласования результатов, сроков поддержки, модернизации и многих других факторов. Зачастую кажется, что все эти системы контроля версий только увеличивают время на разработку.
Например, когда проект небольшой и есть четкое ТЗ, подробно покрывающее потребность заказчика и выполнимое в конкретный отведенный срок без возможности дальнейшей модернизации – все эти дополнительные сложности могут быть и не нужны. Написал на локале, показал заказчику, сдал проект и доволен. Но даже в таком случае системы контроля версий не будут лишними. Они могут застраховать разработчика от нечаянного удаления проекта или возврата к коду, который ранее казался неправильным (откат к прошлой версии). Но опять же если мы пишем калькулятор, то это не нужно.
Но такие проекты существуют только в идеальном сферическом мире, в вакууме. Чаще всего заказчик сам не знает, что конкретно ему нужно. После выполнения проекта по ТЗ фантазия заказчика только начинает разыгрываться, и он просит добавить в свой продукт все больше и больше фич.
В этих ситуациях без системы контроля версий не обойтись. Она позволит сократить время на согласование, так как можно накидать прототипов разных интерфейсов в разных ветках, не внося больших правок в продакшн код. Показать их заказчику, скорректировать (повторять до полного удовлетворения заказчика) и только после этого мерджить в прод. Причем работать можно параллельно над несколькими фичами, так как устраивать демонстрацию каждой отдельной фичи очень накладно по времени, а время заказчика надо уважать.
Для более крупных проектов контроль версий просто необходим, даже если разработчик всего один. Так как заказчик, с которым программист очень приятно и продуктивно поработал год назад, может вернуться и предложить новое сотрудничество. А с тех пор ноутбук мог умереть, у заказчика мог умереть сервер и вообще «метеорит упал на Челябинск». Нынешние бесплатные системы контроля версий облачные и вероятность потерять с них данные достаточно мала – следовательно даже через год можно вернуться к внесению новых фич к старому софту.
Что касается CI\CD – его необходимость также индивидуальна для каждого проекта. Этот инструмент очень сократит время при непрерывной разработке (когда с первого прототипа и до конечного варианта софт уже используется заказчиком). Все опять же зависит от объема. Если это калькулятор и его используют 1 раз в день – можно остановить работу своего приложения и на флешке поставить новую версию. Но когда софт большой, состоит из множества модулей и нагрузка на него непрерывна, то процесс обновления может занять значительное время. В этом случае даже соло программисту стоит задуматься об автоматизации этого процесса (включая тестирование, дабы не выкатить случайно код, который все положит).
Резюмируя, хочу сказать, что эти общепринятые инструменты нужны не только для организации командной разработки, а в первую очередь для увеличения качества кода, его сохранности и ускорения развертывания его у заказчика. И целесообразность их использования зависит исключительно от самого проекта. Если проект на неделю – не стоит и заморачиваться, а в случае, если проект будет обеспечивать стабильным доходом разработчика многие годы – не поленитесь обезопасить свой доход.
Деплой — процесс «разворачивания» веб-сервиса, например, сайта, в рабочем окружении. Рабочее окружение — место, где сайт запускается и доступен для запросов. Это может быть как готовый хостинг, так и своя собственная серверная инфраструктура.
Деплоятся не только веб-сервисы, но любые сервисы, доступные по сети. Даже если эта сеть внутренняя и не доступна для запросов через интернет.
Для понимания деплоя необходимо разобраться с жизненным циклом кода. Код приложения разрабатывается на рабочей машине разработчика, а запускается в другом месте, называемом продакшеном. Продакшен — это среда запуска (иногда говорят боевая среда). В случае простого приложения она может состоять из одного сервера, а может — из тысяч и десятков тысяч в случае по-настоящему сложных приложений.
Как это происходит. Разработчики добавляют код в репозиторий. В какой-то момент они решают, что пора доставить его до продакшена. Это может происходить как по регулярному расписанию, например раз в две недели, так и просто по необходимости, вплоть до выкатки после каждого изменения. Во многом количество деплоев зависит от уровня его автоматизации — того, насколько процесс легкий в проведении и откате в случае проблем. На Хекслете деплои выполняются практически после каждого изменения, около 3 деплоев в день.
Каждый раз, когда разработчики решили что все, пора, они создают релиз. Под релизом обычно понимают тег в Git, который фиксирует, что уйдет в деплой. То есть изменения, добавленные в мастер после создания тега, не повлияют на сам тег, а значит мы точно уверены в том, что деплоим.
Для статических сайтов или отдельного фронтенда (только HTML, CSS и статические файлы) деплой сводится к обновлению кода на сервере. В ситуации деплоя бэкенда, как минимум, подключается база данных. В общем случае деплой может быть сложной процедурой, занимающей приличное время. В распределенных системах, состоящих из множества независимых веб-сервисов, вообще не бывает общего деплоя — каждая часть приложения деплоится (выкатывается) независимо.
Стоит сказать, что PaaS-платформы, такие как Heroku, берут деплой полностью на себя. Там достаточно выполнить коммит, и дальше все произойдет само. Цена за это — стоимость самой платформы
Шаги деплоя
Доставка кода на сервер
Возможны разные варианты доставки кода на сервер в зависимости от способа его упаковки. Иногда код просто копируют на сервер как набор файлов, но такое встречается редко, чаще он обновляется через Git. Раньше был популярен способ деплоя через стандартные пакетные менеджеры Linux-дистрибутивов. Сейчас он тоже встречается, и для определенных ситуаций подходит лучше всего.
- Git: git checkout tag-name
- Docker: docker pull image-name:tag-name
- Apt (Пакет): apt-install application-package-name
Обновление базы данных
Новая версия приложения, как правило, требует изменений в базе данных. Для этого во время (или до) деплоя запускают миграции — специальные скрипты, содержащие правила обновления базы данных. Например sql-скрипты:
Запуск и остановка
Где-то в этом процессе происходит остановка старой версии и запуск новой. Если сначала остановить старую версию, а потом выполнить миграции и запустить новую, то мы получим простой (downtime) в работе сервиса. Так действительно работают многие, но это может быть болезненно для бизнеса и частых деплоев. Поэтому самые продвинутые проекты не останавливаются во время деплоя. О том, как это делать — ниже.
Автоматизация
Деплой нужно максимально автоматизировать, от этого зависит Time To Market, ключевая характеристика бизнес-ориентированных приложений. Чем быстрее и чаще мы доставляем изменения пользователю, тем лучше. Быстрее проверяем гипотезы, быстрее вносим исправления, быстрее оправдываем деньги, вложенные в разработку. Без автоматизации разработчики боятся выполнять деплой, он становится обузой, что приводит к снижению числа деплоев и регулярному стрессу для всей команды, с засиживанием на работе до позднего вечера.
Основных способа автоматизации три:
- С помощью утилит, созданных для конкретных языков. Например в Ruby это Capistrano, одна из первых и наиболее известных утилит подобного рода, ставшая популярной далеко за пределами Ruby. Основная проблема с такими инструментами — сильная завязка на язык.
- С помощью Ansible, в который уже встроен модуль для деплоя. Идеально подходит для большинства ситуаций деплоя на управляемые сервера.
- Системы оркестрации типа Kubernetes. Если они используются, то без автоматического деплоя никак.
Но даже если автоматизация выполнена, все равно остается задача «запустить деплой». Запуск тоже автоматизируется. Существует целый подход, который называется Непрерывная доставка(continuous delivery). Его сложно внедрить и он не везде подходит, но если получилось, то про деплой забывают. Он выполняется полностью сам без участия людей. Главное в таком варианте — хороший мониторинг и система оповещения (алертинг) для реакции на ошибки.
Zero Downtime Deployment
Zero Downtime Deployment выглядит так, как будто сервис никогда не останавливается, но при этом обновляется. Достигается это за счет одновременного запуска старой версии и новой кода. То есть когда деплоится приложение, то сначала поднимается новая версия рядом со старой. И только когда автоматика убеждается, что новая версия запустилась и работает, происходит остановка старой версии. Для выполнения этой процедуры понадобится следующее:
Вчера я понял, что веду свои _дела_ каким-то абсолютно варварским способом. Использование git и bitbucket уже никого не удивляет.
Из-за продолжительной работы конвейера, который выпускает велосипеды по моей разметке появилась необходимость облегчить некоторые этапы работы.
Прямо сейчас имеется мой пк на котором разрабатывается _очередной_ сайт и два компьютера, которые можно назвать серверами. Да черт с ним, два невероятно полноценных сервера — development и production сервера. ( а какой размах? )
Я честно воспользовался гуглом, в стране в которой отсутствует реестр незаконных сайтов, и понял, что мою маленькую проблему решает:
- Service POST на стороне bitbucket;
- Какой-то скрипт для git pull на стороне development сервера.
Но вот моя компетентность оставляет желать лучшего — я решил освоить тестирование. Каюсь, до селе пусть и знал, но не воспринимал тестирование любого вида, как должное. Пора становиться намного лучше!
С самими тестами я как-то разберусь, но где их _правильно_ было бы запускать? У меня? Уже на стороне девелопмент сервера?
И предположим, что велосипед моего производства вышел на свет в виде готового сайта на дев-сервере. По-старинке, по фтп на продакшн?
Есть ли возможность у гита вытягивать с удаленного репозитория только обновления файлов, которые сейчас существуют?
Т.е. есть желание сделать такие операции в результате которых с дев-сервера можно сливать на все файлики сайта, а только их часть.
Прошу обратить внимание, что мои вопросы могут быть заданы совсем неверно или не очень верно. Не сердитесь. :-(
- Вопрос задан более трёх лет назад
- 39343 просмотра
Я увидел в Вашем вопросе две части.
Как правильно организовать деплой (выкладку работоспособного кода на сервер)?
В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.
- Подключиться к целевому серверу.
- Залить обновление кода из репозитория.
- Выполнить предписанные Вами инструкции (перезапуск демонов, сброс индексов, обновление структуры БД и прочее).
- .
- PROFIT!
Инструменты просты, переход на них — дело одного выходного дня, и может быть сопряжен со сложностями только в связи с новизной.
Как организовать процесс тестирования?
Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.
Скорее всего, тесты будут выполняться на Вашей локальной машине, пока Вы пишете код. Используя RSpec, я держу открытым Guard. Guard отслеживает изменения в коде и запускает набор юнит-тестов, которые покрывают измененный код. Весь процесс занимает не больше минуты-двух, и особо не напрягает. Как только я вижу провалившийся тест, я меняю код до тех пор, пока он не станет зеленым. Пока тестов мало (это не самый лучший знак, к слову), Вы работаете один, локального запуска перед деплоем может оказаться достаточно — например, чтобы проверить релиз на доступность критического функционала: регистрации, покупки, создание постов и т.п.
В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.
Таким образом
Вы не указали, какие конкретно инструменты для разработки Вы используете. Если же с деплоем все гораздо проще, то при выборе инструментов для тестирования я рекомендую Вам ориентироваться на те, которые нативны для Вашего основного фреймворка и языка (PHP, если правильно понимаю) и привычны их пользователям. Это позволит быстро применить устоявшиеся практики к Вашему проекту и понять всё на деле.
Приведите в порядок Ваш репозиторий с кодом, используйте mina для деплоя и запускайте тесты на Вашей локальной рабочей машине. Как только Вы почувствуете, что этого не достаточно — Вы наверняка уже будете знать, куда шагать дальше.
Не лучше ли использовать технологии вроде bash scripting для деплоя вместо всех этих капистранов? Преимущества:
1) bash-скрипт простой и короткий. Его легко и быстро написать. Во всяких капистранах надо сначала полдня изучать инструмент, потом думать, каким костылем можно заставить его делать то, что нужно.
2) bash-скрипт легко проверить на отсутсвие ошибок и не надо полдня отлаживать
3) bash-скрипт делает ровно то, что в нем написано. Что сделает сложная система, написанная другим человеком неизвестной квалификации — никому неизвестно
4) Простое решение лучше сложного
У автора вопроса, как я понимаю, речь идет о несложном приложении, а не мегасистеме с десятками серверов и сервисов и использовать сложные системы вроде CI, юниттестов это излишнее усложнение жизни.
Плюс, как видно из описания Mina, это чрезвычайно тяжелый и сложный инструмент: вы добавили пару строчек в файл, логично закачать измененный сервер на файл за полсекунды и успокоиться, но она будет делать репозитории, выкачивать что-то, собирать, загружать… боюсь, это не способствует быстрой разработке.
Опять же, вы советуете использовать юнит-тесты. А я советую использовать функицональные тесты. Почему? потому, что функциональные тесты проверяют, правильно ли работает приложение. Если все правильно — его можно выливать на продакшен. А прохождение юнит тестов не гарантирует правильной работы приложения. А время на них расходуется. Вопрос, зачем они тогда нужны.
В общем, советую автору вопроса сделать самую-самую простую систему деплоя на основе bash скрипта/нескольких скриптов и FTP/SFTP и не мучаться.
Инструменты для разработки? PHP, MySQL, свои велосипеды (никакого yii).
Методика тестирование? TDD. :)
Очень здорово! С этими вопросами покончено! Спасибо.
Значит на продакшн проще по-старинке, да?
И всё-таки может ли гит выкачать определенные папки из конкретной ветки с указанного удаленного репозитория?
Egorinsk — Mina, если Вы этого не заметили, сама по себе генерирует баш скрипт и транслируется из Ruby напрямую в bash. Это очень легкий инструмент и отдельного внимания заслуживает DSL с помощью которого и генерируется конечный баш-скрипт. По поводу «сложной системы», «другого человека» и «неизвестной квалификации» — предлагаю периодически думать.
По поводу тестов — я привел пример того, как запускать тесты. Автор просил именно этого совета. И конечно юнит-тесты не панацея.
Автор, уточните пожалуйста, с какой целью Вы хотите выдергивать отдельные папки из гита? Сразу скажу, что это невозможно :)
shebanoff, на самом деле мои велосипеды разных моделей выходят с достаточно постоянной частотой.
Иногда в эти разработки прокрадываются баги и нужно на разных сайтах вносить одни и те же изменения в файлы _ядра_ велосипеда.
К сожалению, чтобы исправлять один продукт конвейера я придумал другой — параллельная линия выпуска. Сделать так, чтобы при коммите в ветку мастер изменения файлов ядра вносились на разных сайтах-донорах-клиентах.
Без абстракции всё выглядит примерно так: есть мой микро-фреймворк который реализует базовый функционал простого сайта — я его назвал ядром. И всякие модули к нему, например галерея с множественной загрузкой картинок. На одном сайте такой модуль нужен — на другом нет. Но ядро везде одно и тоже.
Вопрос стоит таким образом: как производить обновления основных компонентов сайта (ядра) и при этом не лазить на каждый сайт по фтп?
Разрабатываю один, но поддерживать приходится несколько сайтов моего производства. Критические вещи нужно фиксить. Подумал, что такое ухищрение с гитом решит мою проблему.
В данном материале представлена подробная инструкция по настройке деплоя с помощью PHP-утилиты Deployer.
Установка
Все действия по установке и настройке Deployer необходимо производить на стороне клиента.
Для установки введите следующие команды:
Если вам необходима определенная версия Deployer'а, перейдите по ссылке и скачайте нужную версию.
Инициализация
Теперь можно использовать Deployer. Откройте терминал, перейдите в терминале к папке проекта и запустите команду:
После чего в терминале запустится генератор конфигурационного файла. Для начала выберите тип проекта. Далее вставляем ссылку на репозиторий git. На последнем шаге Deployer попросит вас делиться анонимной статистикой (можно отказаться). После инициализации создастся файл deploy.php в папке проекта. Это конфигурационный файл, его необходимо настроить для деплоя проекта.
В deploy.php прописываются таски, git-репозиторий, хосты (удаленные сервера, локальные, а также инстансы Amazon EC2).
Настройка stage
Для настройки stage в функции host прописываем
Подключение к серверу по SSH-ключу
Для работы Deployer необходима настройка SSH-ключей. Для этого в терминале прописываем
Приватный ключ сохранится в папке /home/.ssh/id_rsa
Публичный ключ сохранится в /home/.ssh/id_rsa.pub
Приватный ключ мы должны хранить на локальной машине. Публичный ключ должен храниться на сервере. Никому не передавайте приватный ключ.
Далее необходимо скопировать публичный ключ на сервер. Для этого сначала скопируем публичный ключ. Отобразить его в терминале можно командой
Копируем ключ и подключаемся к удаленному серверу через root. Меняем пароль пользователю www-data, заново подключаемся, но уже через пользователя www-data. Прописываем в терминале команды для создания папки .ssh и зададим ей права:
Откроем файл authorized_key командой
Откроется текстовый редактор. Необходимо вставить в файл скопированный ранее ключ. Сохраняем файл комбинацией Ctrl+X и далее жмем Enter.
Ограничиваем права папки
Подключение к GitHub по SSH-ключу
Теперь нужно настроить возможность пула проекта с GitHub без ввода пароля с помощью SSH-ключей. Для этого сначала проверяем наличие SSH-ключей на сервере командой
Если ключей нет, на сервере запускаем команду
Она создаст публичный и приватный ключ.
Публичный ключ находится в файле
/.ssh/id_rsa.pub. Открываем его
И копируем публичный ключ в буфер обмена.
После чего заходим в настройки репозитория GitHub, в левом меню нажимаем на Deploy Keys и далее Add deploy key.
Shared-файлы
Shared-файлы и папки - это файлы и папки общие для всех релизов, они не будут изменяться при деплое очередного релиза.
Зададим shared_files и оставим поле shared_dirs пустым.
Таск запуска npm install
Таск запуска миграций
Мы используем Phalcon-миграции, однако можно использовать и другие.
Рецепты
Deployer имеет библиотеку со сторонними рецептами. Рецепты - это предустановки к конфигурационному файлу, упрощающие деплой. Deployer имеет ряд сторонних рецептов для быстрого деплоя.
После этого рецепт нужно подключить к основному конфигурационному файлу. Напимер, для подключения рецепта Slack вставляем в код файла deploy.php
С полным списком рецептов и их подробной установкой можно ознакомиться по этой ссылке.
Основной (common)-рецепт уже включает в себя некоторые параметры. Например, чтобы получить список доступных параметров, используем параметр конфига dump.
Деплой — это процедура развертывания программы в рабочем окружении. Рабочее окружение — это место , где программа будет располагаться, запускаться и быть доступной для пользователей. Деплой свойственен всем программам, которые работают из сети. Например, разместить сайт на хостинге и опубликовать его — это и есть деплой сайта.
Деплой кажется простым процессом. Задеплоить сайт на хостинге — занятие на нескольк о минут, если сайт готов. Деплой простой, когда дело касается небольшого сайта, например , личного блога на Wordpress, который веб-разработчик собрал самостоятельно за день. Но когда дело касается больших проектов, над которыми трудятся десятки программистов, тогда деплой не выглядит простым и у него есть даже собственный жизненный цикл.
Что такое деплой?
код программы разрабатывается на устройстве разработчика;
чтобы запустить код для проверки, его отправляют в специальную среду запуска ; по сути , это некий сервер или десятки серверов, если приложение сложное;
перед отправкой кода в среду запуск а е го добавляют в репозиторий для контроля версий;
если версия программы в репозитории считается работоспособной, тогда ее деплоят на рабочих серверах;
работа над программой продолжается , и все изменения тестируются на среде запуска и фиксируются в репозиториях;
как только уда ется достичь стабильности в коде, его обновляют на рабочих серверах, то есть опять происходит деплой программы в виде ее обновления.
Этапы деплоя
Доставка кода на сервер. Этот процесс может быть выполнен несколькими путями. Простой путь — копирование файлов программы на сервер с Git-систем или с рабочих устройств разработчиков. Это актуально для небольших программ. Но чаще всего доставка кода на сервер осуществляется автоматизировано при помощи тех же Git-систем или при помощи пакетных менеджеров.
Обновление базы данных. Сейчас редко какое приложение не использует базу данных. Поэтому деплой приложения требует обновлени я кода в базах данных. Для этого обычно пишут специальные SQL-скрипты, которы е запускают во время или до того , как происходит деплой.
Перезапуск приложения. Если во время деплоя происходит обновление приложения, значит , будет момент, когда старая версия приложения отключ ится и запус тится новая версия. Некоторые программы так и обновляются: останавливают старую версию и обновляют ее . При таком подходе приложение останавливается на короткое время и происходит простой. В некоторых случаях такой подход чреват для бизнеса, поэтому применяют безостановочный подход в обновлении.
Автоматизация деплоя. Чем больше приложение для деплоя, тем меньше должно быть ручного труда, так как ручной труд — это лишняя трата времени. А скорость в развертывании и внедрении обновления решает многое. Чем быстрее, тем лучше для пользователей и самого приложения. Автоматизируют деплой при помощи разных утилит и программ. Уровень автоматизации деплоя дошел до того, что деплой можно настроить в непрерывном потоке, когда приложение не останавливается для обновления, а внедрения обновлений происходят постепенно.
Непрерывное внедрение деплоя
развитая инфраструктура с балансировщиком, который будет контролировать трафик между разными версиями программы и серверами, где будут располагаться эти программы;
автоматизированный деплой при помощи специального софта;
единая культура написания кода, чтобы версии программы «дружили» между собой и были совместимыми;
база данных, совместимая с разными версиями программы, чтобы внутри БД ничего не приходилось удалять, обновлять или переименовывать для новой версии.
Заключение
Деплой может быть разным по сложности. Но по факту он обозначает один и тот же процесс — развертывание программы на серверах, делая ее доступной для пользователей. Такой программой может быть что угодно: веб-сайт, веб-приложение, игра или приложение для мобильного телефона. Правильный деплой — важная для всех процедура: для пользователей, разработчиков и самого приложения.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Читайте также: