Что значит деплоить

Задеплоить: что это за термин и что означает задеплоить приложение?

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

Задеплоить — что это

• зарелизить приложение — это сделать приложение открытым и доступным для пользователей, то есть опубликовать приложение;

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

Термин «задеплоить» простыми словами

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

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

3. Сама сборка детского шкафа — это не что иное , как «ко д инг» или «программирование».

4. Итак, вы собрали детский шкаф прямо в прихожей, теперь вам надо перенести его в место его постоянной дислокации — в детскую комнату, то есть вам нужно «развернуть» шкаф в том месте, где он должен выполнять свои функции. Неважно , перенесете вы шкаф целиком или частями. Сам процесс будет называться «задеплоить» шкаф в детской.

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

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

Заключение

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Фронт без релиз-инженера, или Как я перестал бояться и полюбил деплой

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

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

Разделение ответственности — в ряде случаев ответственность за деплой оказывается высокой.

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

Сложность инфраструктуры — при деплое приходится учитывать массу поддерживающих сервисов, таких как меш-сети, очереди, воркеры, базы данных и т. д.

Как это происходит у нас

В Учи.ру был создан собственный инструмент для выкатки сервисов и настройки стейджей под названием «Шаман» — по сути кастомный интерфейс к HashiCorp Nomad. Несколько лет назад он помог уйти от исполнения скриптов на локальных машинах, автоматизировать процесс деплоя и позволил разработчикам создавать тестовые конфигурации максимально быстро. Об этом мои коллеги из команды инфраструктуры написали отдельную статью.

Немного истории

С самого начала вся разработка у нас велась внутри одного-единственного монолитного репозитория, поэтому «Шаман» умел собирать его и выкатывать, при этом отлично справляясь со своей задачей. Но компания росла, а вместе с ней осваивались рынки, запускались новые проекты, добавляя перекрестные логические связи и в без того сложный код.

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

Да придет спаситель

И здесь «Шаман» действительно выручил, потому что настраивать такие связки вручную правильно и предсказуемо — довольно непростая задача. Он абстрагировал сложность управления новыми машинами с массой параметров, раскладку на них сервисов через докер-контейнеры, настройку и регистрацию эндпоинтов этих сервисов в оркестраторе — в общем, кучу вещей, которые объять каждому разработчику мозгом будет проблематично, да и, положа руку на сердце, не нужно. Вместо этого я вижу суровый, минималистичный, но тем не менее довольно понятный интерфейс, освобождающий меня от необходимости заглядывать в глаза бездне низкоуровневого администрирования.

А что делать, если тебе нужно поднять копию среды для тестирования второго релиза? Не создавать же всю связку целиком заново? А если ее незначительно видоизменить? Для подобного в «Шамане» есть возможность создать шаблон конфигурации, в котором с помощью YAML описана вся россыпь машин, сервисов и эндпоинтов. В результате, если ваша команда поддерживает свой шаблон, поднятие нового инстанса развесистой связки сервисов становится тривиальной задачей.

И, кажется, коллеги со мной согласны:

«Лично для меня в деплое нет ничего сложного. И учитывая, что иногда мне приходится делать больше десяти тестовых выкаток в день, а также развертывания совершенно новых приложений, я очень рад, что не нужно каждый раз подключать кого-то из отдела инфраструктуры. Приложений у нас много, и возможность самостоятельной выкатки сильно упрощает жизнь и ускоряет работу», — Роман Литвинов, ROR разработчик.

Схема связи «Шамана» с кодом

На данный момент почти все наши GitHub-репозитории собираются при помощи GitHub Actions, в результате чего докер-образ пушится в общую приватную докер-репу. Этот workflow можно триггерить как автоматически (пуш в релизную ветку), так и руками, если хочется потестить какой-то сиюминутный фикс. Дальше «Шаман» подцепляет свежий образ и по кнопке раскатывает его на стейдж. Ну не красота, а?

И так как этот процесс находится в ведении разработчиков чуть более чем полностью, у нас есть возможность его упрощать. Меня, например, все-таки расстраивает необходимость сначала идти в GitHub, чтобы посмотреть статус билда, а потом в «Шаман» — чтобы нажать на заветную зеленую кнопку для выкатки образа. После незначительной встряски коллег из инфраструктуры выяснилось, что последний предоставляет API, ручку которого можно дернуть из Github Actions с адресом для деплоя и идентификатором образа для деплоя. А это значит, что деплоить код можно полностью автоматически!

Когда что то идёт не так…

Понятное дело, что после выкатки кода на прод надо убедится, что он ведёт себя так, как задумано. И тут у нас чуть хуже с автоматизацией, но тем не менее всё под контролем. Для мониторинга мы используем сервис Sentry, который нотифицирует как о новых индивидуальных ошибках, так и об изменениях общего фона. Ну и продуктовые дашборды с метриками никто не отменял. А «Шаман», в свою очередь, быстро и непринужденно позволяет откатить бажную версию фронтового приложения в случае серьезных проблем.

Так нужно ли деплоить разработчику?

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

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

Ну и вопрос времени: деплоить самому куда быстрее, чем отдавать релиз выделенным инженерам. Но, естественно, с допущениями:

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

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

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

Как происходит деплой в вашей компании? Считаете ли вы наш подход с «одной кнопкой» оптимальным или вам нравятся другие варианты выкатки новых сервисов и обновлений? Поделитесь мнением в комментариях.

What is Deployment?

Deployment is the process of web service “deployment”, e.g. of a website, in the operating environment. An operating environment is a place where a website is started and available for requests. This can be ready-made hosting as well as your own server infrastructure.

Not only web services but also any services available over the network are deployed. Even if this network is internal and not available for requests over the Internet.

To understand deployment, you need to understand the code life cycle. The application code is built on the developer’s workstation and run in another place called production. Production is a startup environment (also called a live environment). In the case of a simple application, it may consist of a single server, but for truly complex applications it can be thousands and tens of thousands of servers.

How does it work? Developers add the code to the information repository. At some point, they decide it’s time to bring it to production. This can be done on a regular schedule such as every two weeks or just as needed up to the release after each change. In many cases, the number of deployments depends on the automation level, i.e. to which extent the process is easy to conduct and rollback. At Hexlet, deployments are performed almost after each change, approximately three deployments a day.

When developers decide now it’s time, they create a release. Release usually refers to a Git tag that marks things to be deployed. Namely, changes added to a master branch after the tag has been created won’t affect the tag itself, which means that we are sure about what we will be deploying.

For static websites or a separate frontend (HTML, CSS, and static files only), deployment comes down to updating the code on the server. In the case of backend deployment, the database is connected at the very least. In general, deployment can be a complicated procedure taking decent time. In distributed systems consisting of many independent web services, there is no regular deployment at all — each part of the application is deployed (released) independently.

It’s worth mentioning that such PaaS platforms as Heroku take the deployment completely upon themselves. There you just have to make a commit, and then everything will happen by itself. The price for this is the cost of the platform itself.

Deployment stages

Code delivery to the server

There are different options for code delivery to the server, depending on its packaging. Sometimes the code is directly transmitted to the server as a set of files, but more often it’s updated via Git. Back in the day, the deployment method through standard package managers of Linux distributions was popular. It’s still in use today and best suited for certain situations.

• Git: git checkout tag-name
• Docker: docker pull image-name:tag-name
• Apt (package): apt-install application-package-name

Database update

In general, a new application version requires changes in the database. To do this, migrations — special scripts containing database update rules — are run during (or before) deployment. For instance, SQL scripts:

Start and stop

Somewhere in this process, the old version stops, and the new one starts. If we first stop the old version, then execute migrations and start the new version, we will get service downtime. This is a really common thing for many, but it can be sensitive for business and frequent deployments. So, the most advanced projects don’t stop during deployment. There is a description below of how to do it.

Automation

Deployment should be automated as much as possible; Time To Market, a key characteristic of business-oriented applications, depends on it. The faster and more often we deliver changes to the user, the better. The faster we check hypotheses, the faster we introduce changes, and the faster the money invested in development pays its way. Developers are afraid to perform deployment without automation, it becomes a burden that leads to a decrease in deployments and regular stress for the whole team, working long hours.

There are three main automation ways:

1. Using utilities created for specific languages. For example, it’s Capistrano in Ruby, one of the first and best-known utilities of its kind, which has become popular far beyond Ruby. The main problem with such tools is strong binding with the language
2. Using Ansible with an already built-in module for deployment. It’s relevant for most deployment situations on managed servers
3. Kubernetes-type orchestration systems. If they are used, you can’t do without automated deployment

However, even if automation is executed, the task of “running deployment” remains. The start is also automated. There is a whole approach called Continuous Delivery. It’s difficult to implement and is not suitable everywhere, but if it works, you can forget about deployment. It’s performed entirely on its own without human involvement. The main thing in this option is good monitoring and alerting system.

Zero Downtime Deployment

If no special steps are taken, each deployment will cause the service to stop (possibly partially). At this time users will either see an error or a message that an update is in progress. But this does not happen on most major Internet services. Why? Due to the implementation of the “Zero Downtime Deployment” approach (downtime means service operational downtime).

Zero Downtime Deployment is when the service never stops running, but in the meantime, it’s being updated. This is achieved by simultaneously running the old version and the new code. Namely, when an application is deployed, the new version arises next to the old one. And only when the automatics make sure that the new version has started and run, the old version is stopped. The following is required to perform this procedure: