деплой что это простыми словами такое
Что такое деплой в программировании
Deploy (деплой) — что это такое? Дословный перевод слова деплой на русский язык означает «развертывать». Давайте разберемся что именно мы развертываем и каким образом.
После того как программный код сайта написан, возникает вопрос: что-же необходимо сделать, чтобы он появился в интернете? Как правило, классический путь состоит из 3-х шагов:
Простыми словами, деплой — это процедура переноса вашего сайта на сервер. Данная операция может быть очень затруднительной и напрямую зависит от применяемых инструментов. Когда программисты начинают реализовывать deploy, они выполняют следующие действия:
Мы привели в пример один из возможных и очевидных вариантов для понимания, на самом деле их бесчисленное множество.
Хочется отметить, что многие web-студии до сих пор реализовывают данный процесс вручную. То есть программист заходит на сервер и включает git pull. После чего реализовывает вышеуказанные пункты. Данный подход к деплоингу — неправильный. Web-deploy подразумевает под собой полную автоматизацию всех задач, которые необходимо выполнить.
По большому счету, на сегодняшний день все работы, связанные с настройкой и обслуживанием серверов должны быть максимально автоматизированы и отточены.
Однако невзирая на множество различных вариантов деплоя проектов, существует одно неотъемлемое правило для каждого — запрещено делать откаты. Другими словами, если в процессе выполнения deploy вы допустили ошибку и все пошло не по плану, то следует «деплоить» по новой версию, которая была ранее.
Помимо этого, deploy можно подразделять на категории откатов и обновлений:
Так же следует отметить такой способ, как канареечный релиз (canary release). Применяя такую методологию переход на обновленную версию происходит поэтапно — первоначально для малого количества пользователей, а потом для всех остальных.
Выбираемый вариант деплоинга напрямую зависит от применяемого хоста, а также метода настройки сервера. Вот перечень основных хостингов:
По большому счету все варианты web-деплоя разделены на 2 составляющих: на PaaS и все прочее.
Теперь вы знаете, что такое деплой для сайта или приложения. Также следует отметить, что существует такое понятие, как Deployer для PHP. Данная опция позволяет загрузить на сервер определенную ветку системы контроля версий. Более того, ему можно написать задачи наподобие выполнения миграции после выкачивания ветки на рабочий сервер.
Надеемся данный материал был для вас полезен. В случае, если вы не смогли найти ответа на ваш вопрос или в чем-то не до конца разобрались — пишите нам в комментарии, и мы обязательно ответим.
Что такое деплой?
Деплой — процесс «разворачивания» веб-сервиса, например, сайта, в рабочем окружении. Рабочее окружение — место, где сайт запускается и доступен для запросов. Это может быть как готовый хостинг, так и своя собственная серверная инфраструктура.
Деплоятся не только веб-сервисы, но любые сервисы, доступные по сети. Даже если эта сеть внутренняя и не доступна для запросов через интернет.
Как это происходит. Разработчики добавляют код в репозиторий. В какой-то момент они решают, что пора доставить его до продакшена. Это может происходить как по регулярному расписанию, например раз в две недели, так и просто по необходимости, вплоть до выкатки после каждого изменения. Во многом количество деплоев зависит от уровня его автоматизации — того, насколько процесс легкий в проведении и откате в случае проблем. На Хекслете деплои выполняются практически после каждого изменения, около 3 деплоев в день.
Каждый раз, когда разработчики решили что все, пора, они создают релиз. Под релизом обычно понимают тег в Git, который фиксирует, что уйдет в деплой. То есть изменения, добавленные в мастер после создания тега, не повлияют на сам тег, а значит мы точно уверены в том, что деплоим.
Для статических сайтов или отдельного фронтенда (только HTML, CSS и статические файлы) деплой сводится к обновлению кода на сервере. В ситуации деплоя бэкенда, как минимум, подключается база данных. В общем случае деплой может быть сложной процедурой, занимающей приличное время. В распределенных системах, состоящих из множества независимых веб-сервисов, вообще не бывает общего деплоя — каждая часть приложения деплоится (выкатывается) независимо.
Стоит сказать, что PaaS-платформы, такие как Heroku, берут деплой полностью на себя. Там достаточно выполнить коммит, и дальше все произойдет само. Цена за это — стоимость самой платформы
Шаги деплоя
Доставка кода на сервер
Возможны разные варианты доставки кода на сервер в зависимости от способа его упаковки. Иногда код просто копируют на сервер как набор файлов, но такое встречается редко, чаще он обновляется через Git. Раньше был популярен способ деплоя через стандартные пакетные менеджеры Linux-дистрибутивов. Сейчас он тоже встречается, и для определенных ситуаций подходит лучше всего.
Обновление базы данных
Новая версия приложения, как правило, требует изменений в базе данных. Для этого во время (или до) деплоя запускают миграции — специальные скрипты, содержащие правила обновления базы данных. Например sql-скрипты:
Запуск и остановка
Где-то в этом процессе происходит остановка старой версии и запуск новой. Если сначала остановить старую версию, а потом выполнить миграции и запустить новую, то мы получим простой (downtime) в работе сервиса. Так действительно работают многие, но это может быть болезненно для бизнеса и частых деплоев. Поэтому самые продвинутые проекты не останавливаются во время деплоя. О том, как это делать — ниже.
Автоматизация
Деплой нужно максимально автоматизировать, от этого зависит Time To Market, ключевая характеристика бизнес-ориентированных приложений. Чем быстрее и чаще мы доставляем изменения пользователю, тем лучше. Быстрее проверяем гипотезы, быстрее вносим исправления, быстрее оправдываем деньги, вложенные в разработку. Без автоматизации разработчики боятся выполнять деплой, он становится обузой, что приводит к снижению числа деплоев и регулярному стрессу для всей команды, с засиживанием на работе до позднего вечера.
Основных способа автоматизации три:
Но даже если автоматизация выполнена, все равно остается задача «запустить деплой». Запуск тоже автоматизируется. Существует целый подход, который называется Непрерывная доставка(continuous delivery). Его сложно внедрить и он не везде подходит, но если получилось, то про деплой забывают. Он выполняется полностью сам без участия людей. Главное в таком варианте — хороший мониторинг и система оповещения (алертинг) для реакции на ошибки.
Zero Downtime Deployment
Если не предпринимать специальных шагов, то каждый деплой будет приводить к остановке (возможно частичной) сервиса. В это время пользователи либо увидят ошибку, либо сообщение о происходящем обновлении. Но такого не происходит на большинстве крупных сервисов в интернете. Почему? Из-за реализации подхода «деплой без даунтайма» (downtime — простои в работе сервиса).
Zero Downtime Deployment выглядит так, как будто сервис никогда не останавливается, но при этом обновляется. Достигается это за счет одновременного запуска старой версии и новой кода. То есть когда деплоится приложение, то сначала поднимается новая версия рядом со старой. И только когда автоматика убеждается, что новая версия запустилась и работает, происходит остановка старой версии. Для выполнения этой процедуры понадобится следующее:
Фронт без релиз-инженера, или Как я перестал бояться и полюбил деплой
Привет, я фронт, и за десять лет разработки в энтерпрайзах, стартапах и некрупных компаниях я впервые деплою свой код сам и отвечаю за его эксплуатацию, а не только за проектирование и разработку сервиса. О том, как я до этого дошел и почему не собираюсь останавливаться, в этой статье.
В нашей компании самостоятельный деплой — это часть workflow многих разработчиков. Такая практика типична, скорее, для стартапов и редка в средних и крупных компаниях. Почему? Мне кажется, решение о полной передаче деплоя выделенным специалистам, играющим роль релиз-инженеров, происходит по вполне понятным причинам:
Разделение ответственности — в ряде случаев ответственность за деплой оказывается высокой.
Необходимость в дополнительных навыках — обычно нужно неплохо знать платформу, через которую происходит деплой, или хотя бы разбираться в скриптах вроде Capistrano.
Сложность инфраструктуры — при деплое приходится учитывать массу поддерживающих сервисов, таких как меш-сети, очереди, воркеры, базы данных и т. д.
Как это происходит у нас
В Учи.ру был создан собственный инструмент для выкатки сервисов и настройки стейджей под названием «Шаман» — по сути кастомный интерфейс к HashiCorp Nomad. Несколько лет назад он помог уйти от исполнения скриптов на локальных машинах, автоматизировать процесс деплоя и позволил разработчикам создавать тестовые конфигурации максимально быстро. Об этом мои коллеги из команды инфраструктуры написали отдельную статью.
Немного истории
С самого начала вся разработка у нас велась внутри одного-единственного монолитного репозитория, поэтому «Шаман» умел собирать его и выкатывать, при этом отлично справляясь со своей задачей. Но компания росла, а вместе с ней осваивались рынки, запускались новые проекты, добавляя перекрестные логические связи и в без того сложный код.
Но аве прогрессу — подходы к разработке эволюционируют вместе с нами. Поэтому в какой-то момент, наевшись боли от того, что в монолит коммитят 200 человек, мы потихоньку начали откусывать от него небольшие семантически связанные куски и выносить их в сервисы. Со временем сервисов отпочковывалось все больше, а им, естественно, нужно как-то коммуницировать друг с другом — сложность настройки приложений экспоненциально увеличивалась.
Да придет спаситель
И здесь «Шаман» действительно выручил, потому что настраивать такие связки вручную правильно и предсказуемо — довольно непростая задача. Он абстрагировал сложность управления новыми машинами с массой параметров, раскладку на них сервисов через докер-контейнеры, настройку и регистрацию эндпоинтов этих сервисов в оркестраторе — в общем, кучу вещей, которые объять каждому разработчику мозгом будет проблематично, да и, положа руку на сердце, не нужно. Вместо этого я вижу суровый, минималистичный, но тем не менее довольно понятный интерфейс, освобождающий меня от необходимости заглядывать в глаза бездне низкоуровневого администрирования.
А что делать, если тебе нужно поднять копию среды для тестирования второго релиза? Не создавать же всю связку целиком заново? А если ее незначительно видоизменить? Для подобного в «Шамане» есть возможность создать шаблон конфигурации, в котором с помощью YAML описана вся россыпь машин, сервисов и эндпоинтов. В результате, если ваша команда поддерживает свой шаблон, поднятие нового инстанса развесистой связки сервисов становится тривиальной задачей.
И, кажется, коллеги со мной согласны:
«Лично для меня в деплое нет ничего сложного. И учитывая, что иногда мне приходится делать больше десяти тестовых выкаток в день, а также развертывания совершенно новых приложений, я очень рад, что не нужно каждый раз подключать кого-то из отдела инфраструктуры. Приложений у нас много, и возможность самостоятельной выкатки сильно упрощает жизнь и ускоряет работу», — Роман Литвинов, ROR разработчик.
Схема связи «Шамана» с кодом
На данный момент почти все наши GitHub-репозитории собираются при помощи GitHub Actions, в результате чего докер-образ пушится в общую приватную докер-репу. Этот workflow можно триггерить как автоматически (пуш в релизную ветку), так и руками, если хочется потестить какой-то сиюминутный фикс. Дальше «Шаман» подцепляет свежий образ и по кнопке раскатывает его на стейдж. Ну не красота, а?
И так как этот процесс находится в ведении разработчиков чуть более чем полностью, у нас есть возможность его упрощать. Меня, например, все-таки расстраивает необходимость сначала идти в GitHub, чтобы посмотреть статус билда, а потом в «Шаман» — чтобы нажать на заветную зеленую кнопку для выкатки образа. После незначительной встряски коллег из инфраструктуры выяснилось, что последний предоставляет API, ручку которого можно дернуть из Github Actions с адресом для деплоя и идентификатором образа для деплоя. А это значит, что деплоить код можно полностью автоматически!
Когда что то идёт не так…
Понятное дело, что после выкатки кода на прод надо убедится, что он ведёт себя так, как задумано. И тут у нас чуть хуже с автоматизацией, но тем не менее всё под контролем. Для мониторинга мы используем сервис Sentry, который нотифицирует как о новых индивидуальных ошибках, так и об изменениях общего фона. Ну и продуктовые дашборды с метриками никто не отменял. А «Шаман», в свою очередь, быстро и непринужденно позволяет откатить бажную версию фронтового приложения в случае серьезных проблем.
Так нужно ли деплоить разработчику?
Мой ответ — да, если есть подобная система, упрощающая жизнь. Потому что твой сервис — твоя крепость. И за него нужно нести ответственность на всех этапах, в том числе и в контексте выкаток. Да, это требует больше знаний, но наш отдел эксплуатации сделал крутую абстракцию, скрывающую большинство низкоуровневых процессов.
Такая схема позволяет не аккумулировать сделанные задачи в большие релизы, которые долго тестируются, а выкатывать их по мере готовности. Больше контроля и меньше вероятность ошибки.
Ну и вопрос времени: деплоить самому куда быстрее, чем отдавать релиз выделенным инженерам. Но, естественно, с допущениями:
Сервисы приходят и уходят, соответственно, шаблон связки сервисов нужно держать актуальным, иначе поднятие новых тестовых стендов превратится в боль.
Стоит держать в голове, что мы работаем с in-house-решением со всеми вытекающими: оно может сломаться. Поэтому здесь нужно быть достаточно открытым и помогать коллегам чинить проблему, а не бранить решение.
Такой подход требует высокого уровня развития процедур и процессов для сохранения качества и стабильности сервиса при высоком ритме выкаток, а также определенной смелости от ключевых стейхолдеров.
Как происходит деплой в вашей компании? Считаете ли вы наш подход с «одной кнопкой» оптимальным или вам нравятся другие варианты выкатки новых сервисов и обновлений? Поделитесь мнением в комментариях.
Docker: На старт. Внимание. Деплой
Как часто вам приходилось настраивать окружения сервера для деплоя вашего приложения (например веб-сайта)? Наверняка чаще чем хотелось бы.
В лучшем случае, у вас был скрипт, который все это делал автоматически. В худшем случае, это могло выглядеть вот так:
Выше я описал то, что называется vendor lock-in. Для разработки приложений, в частности серверного типа, это явление становится большой проблемой. В данной статье мы рассмотрим одно из возможных решений — Docker. Вы узнаете, как создать, задеплоить и запустить приложение на его основе.
/Disclaimer:/ Это не обзорный доклад о Docker. В конце этой статьи приведен список полезной литературы, которая описывает работу с Docker лучше. Это первая точка вхождения для разработчиков, которые планируют деплоить node.js приложения при помощи Docker контейнеров.
Разрабатывая один из своих проектов, я столкнулся с отсутствием подробных статей, что породило немалое количество велосипедов. Этот пост с небольшим опозданием пытается исправить недостаток информации по теме.
Что это такое и с чем его едят?
Простыми словами, Docker — это абстракция над LXC контейнерами. Это значит, что процессы, запущенные при помощи Docker, будут видеть только себя и своих потомков. Такие процессы называются Docker контейнерами.
Для того, чтобы иметь возможность создавать какие-то абстракции на базе таких контейнеров, в Docker существует образ (/docker image/). На базе Docker образа можно конфигурировать и создавать контейнеры.
Существуют тысячи готовых Docker образов с уже предустановленными базами данных, веб серверами и прочими важными элементами. Еще одно преимущество Docker состоит в том, что это очень экономичный по потреблению памяти инструмент, так как он использует только необходимые ему ресурсы.
Знакомимся ближе
На установке долго останавливаться не будем. Процесс за последние несколько релизов упростили до нескольких кликов/команд.
В этой статье мы разберем деплой Docker приложения на примере серверного Node.js приложения. Вот его примитивный, исходный код:
У нас есть как минимум два способа упаковки приложения в Docker контейнер:
Для начала скачаем официальный node.js образ:
Команда docker pull скачивает Docker образ. После этого можно выполнить команду docker run. Это создаст и запустит контейнер на базе скачанного образа.
Эта команда запустит index.js файл, произведет маппинг 3000 порта на 80 и выведет id созданного контейнера. Уже лучше! Но на одном CLI далеко не уедешь. Давайте создадим Dockerfile для нашего сервера.
Данный Dockerfile описывает образ, от какого наследуется текущий вариант, а также директорию, в которой начнут выполнятся команды контейнера и команда копирования файлов из директории, в которой запускается сборка образа. Последняя строчка указывает, какая команда запустится в созданном контейнере.
Наш контейнер готов. Мы можем запускать его при помощи команды docker run. Таким образом, мы решаем vendor lock-in проблему. Запуск приложения уже не зависит от окружения. Код доставляется вместе с Docker образом. Эти два критерия позволяют нам деплоить приложение в любое место, где мы можем запустить Docker.
Деплой
Не так страшны первые 99% как оставшиеся 99%.
После того, как мы выполнили все инструкции выше, сам процесс деплоя уже становится делом техники и вашего окружения разработки. Мы рассмотрим 2 варианта деплоя Docker:
Ручной деплой
Данный вариант хорош, если у вас нет какой-либо среды непрерывной интеграции. Сперва нужно загрузить Docker образ в место, доступное staging серверу. В нашем случае это будет DockerHub. Каждому пользователю он бесплатно предоставляет один приватный репозиторий образа и неограниченное количество публичных репозиториев.
Авторизуемся для доступа к нашему DockerHub:
Загружаем туда наш образ: docker push username/helloworld-with-docker:0.1.0.
Далее заходим на staging сервер (напоминаю, на нем уже должен быть предустановлен Docker).
Для деплоя нашего приложения на сервере нам потребуется выполнить всего одну команду:
И все! Проверьте локальный регистр образов. Если не найдете нужный результат, введите username/helloworld-with-docker для проверки DockerHub регистра. Образ с таким именем найдется в регистре, так как мы его туда уже загрузили. Docker скачает его, создаст на его основе контейнер и запустит в нем ваше приложение.
Теперь каждый раз, когда вам нужно будет обновить версию вашего приложения, вы можете делать push с новым тегом и просто перезапускать каждый раз контейнер на сервере.
P.S. Данный способ не рекомендуется, если есть возможность воспользоваться Travis-CI.
Деплой при помощи Travis-CI
Первым делом добавим в Travis-CI данные DockerHub. Они будут хранится в переменных окружения.
Далее нам нужно авторизоваться и загрузить образ:
Также доставка образа может запускаться из Travis-CI различными способами:
«Не баг, а фича» — учимся понимать язык программистов
Понять смысл IT-терминов можно, только узнав, как они употребляются
Программисты говорят на особом языке, в котором полно терминов и сленга. Эта речь не всегда понятна не только обычным людям, далёким от компьютеров, но и начинающим айтишникам — новичкам в разработке.
Есть куча статей, объясняющих смысл терминов, но неподготовленному человеку от них мало пользы. И если вы общаетесь с программистами или собираетесь стать одним из них, то, скорее всего, во всём придётся разбираться самостоятельно. Иначе можете оказаться в ситуации, похожей на ту, что в клипе:
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Гораздо проще понять, что значит «пичупидо», если знать контекст, в котором употребляются все эти слова. Поэтому попробую объяснить некоторые термины и сленг на примере истории одного программиста (вымышленного).
Дисклеймер. Все совпадения случайны, а персонажи и ситуации вымышлены. В художественных целях они наделены негативными качествами, поэтому не берите с них пример: это касается как профессиональных качеств, так и отношения к алкоголю, курению и энергетическим напиткам. Также некоторые слова используются и в других сферах.
Новая задача
Ваня — обычный джун в веб-студии. Его работа — поддержка бэкенда сайтов старых клиентов студии.
Джуниор ( англ. junior — младший) в данном случае — младший разработчик в веб-студии. Также бывают мидл- ( англ. middle — средний) и сеньор-разработчики ( англ. senior — старший).
Бэкенд или бэк ( англ. back end — задний край) — серверная часть сайта или приложения, которая нужна для обработки и хранения данных. Его противоположность — фронтенд или фронт ( англ. front end — передний край) — видимая часть приложения или сайта. Если же разработчик занимается сразу фронтендом и бэкендом, его называют фуллстек-разработчиком ( англ. full stack — полная куча / полный набор).
Рабочая неделя Вани начинается с митингов, потому что спринт в его компании длится всего неделю.
Митинг — собрание, на котором обсуждается, что успели или не успели сделать сотрудники, а также чем они будут заниматься в новом спринте.
Спринт — период от одной до четырёх недель, за который сотрудники должны успеть выполнить задачу или задачи. Спринты являются частью Скрам.
Скрам ( англ. scrum) — метод управления проектами. Относится к гибкой методологии разработки эджайл ( англ. agile — гибкий).
На этот раз он получил задачу по добавлению валидации в один из интернет-магазинов. До этого вся валидация была на стороне пользователя.
Валидация — проверка данных, которые вводит пользователь.
До пятницы ещё целая неделя, поэтому с митинга Ваня пошёл сразу в курилку. Достав сигарету, он стал слушать разговор мидла и сеньора:
— Недавно залез в репозиторий, а там одни foobar’ы. Целый час голову ломал, а потом махнул рукой и заново переписал.
— Как наберут новых джунов, так всегда говнокод появляется. Как он вообще код ревью проходит?
— Надо проверить в гитхабе историю коммитов.
Тут Ваня поперхнулся, затушил сигарету и заторопился на рабочее место — от греха подальше.
Репозиторий — хранилище исходных файлов проекта.
Foo и Bar — имена функций или переменных, по которым невозможно понять, зачем они нужны. Использование таких имён допускают в учебниках и документации, но не в реальных проектах, потому что они замедляют чтение и понимание кода другими программистами.
Говнокод — очень плохой код.
Код ревью — проверка кода.
Гитхаб — сервис для хранения репозиториев IT-проектов и совместной работы над ними.
Коммит — запись изменений в репозиторий. Коммит содержит в себе данные об изменениях, комментарий и имя автора коммита.
У стола его уже ждал тимлид:
— Ваня, после того как ты добавил функцию загрузки фотографии в личном кабинете, появился баг. Теперь всё ломается, если ввести промокод.
— Вы уверены, что это из-за меня? Мой код вообще промокодов не касался.
— Уверен. Откати сайт и исправь всё до конца недели — нельзя ждать, пока клиент заметит, что одна из фич пропала.
— Но у меня уже есть задача на эту неделю, я не успею всё исправить.
— Это далеко не первый твой факап, поэтому, если не успеешь, мы поставим новый рекорд — так быстро мы джунов ещё не увольняли.
Тимлид ( англ. team leader — лидер команды) в данном случае — программист, который выполняет роль менеджера. Тимлид редко пишет код, вместо этого он следит, чтобы его команда хорошо справлялась с задачами.
Баг ( англ. bug — жук) — неожиданный результат или неожиданное поведение программы, ошибка.
Откатить ( англ. rollback) — отменить изменения, вернуться к прошлой версии.
Фича ( англ. feature — особенность) — полезная (а иногда забавная) функция / особенность программы.
Исправление багов
Дебажить было сложно, но Ваня не мог облажаться и в этот раз. За год его уже успели уволить из трёх компаний, после четвёртого увольнения его резюме будет испорчено окончательно.
Дебаг (англ. debug — устранение багов) — исправление ошибок в коде программы.
Три дня и три ночи Ваня корпел над кодом, но ничего не выходило. В отчаянии он обратился к коллеге, который проводил код ревью для его коммита в прошлый раз.
— Прости, но если бы я знал, что не так в твоём коде, я бы твой пул реквест не заапрувил.
— Но ты же написал lgtm в комментарии!
— И теперь мне за это прилетело. Слушай, я уже сто раз пожалел, что помог тебе сюда устроиться. Тимлид просёк, что я сквозь пальцы смотрю на твой код, поэтому сейчас проблемы у нас обоих. В случае чего я найду новую работу, а ты — вряд ли. Так что сейчас у тебя отличный повод подтянуть знания.
— Ладно, разберусь как-нибудь.
Апрув ( англ. approve) — подтвердить что-нибудь.
Пул реквест ( англ. pull request) — запрос на подтверждение коммита.
LGTM ( англ. looks good to me — На мой взгляд, хорошо) — сокращение, которое часто встречается на гитхаб в комментариях к подтверждению коммитов. Обычно его используют, когда не получается сказать ничего конструктивного по поводу кода.
Осталось всего два дня, чтобы исправить баг и добавить новую фичу, а у Вани не было почти никаких продвижений. После работы он, как обычно, зашёл в магазин, но вместо энергетиков решил взять пиво, потому что вспомнил о Пике Балмера.
Пик Балмера — шуточная теория, что при содержании алкоголя в крови между 0,129 и 0,138% (примерно 2 бутылки пива) программист получает сверхспособности к написанию кода. Теорию выдвинул Стив Балмер, CEO Microsoft с 2000 по 2014 год.
Бессонные ночи и пиво сделали своё дело, поэтому Ваня заснул прямо за компьютером.
Наутро он не сразу понял, что проснулся, и, лёжа лицом на клавиатуре, продолжал слушать разрывающийся будильник. Прошло всего несколько минут, но Ване они показались вечностью.
Ненавидя себя, он поплёлся на работу. Сев за рабочий стол и посмотрев в код, внезапно понял, в чём была ошибка (известно, что многие проблемы в разработке приложений решаются, когда программист спит). Исправив всё за пару минут, он пошёл к тимлиду.
— Я разобрался с багом.
— Отлично, но странно, что у тебя ушло так много времени. Давай протестируем твой код и выгрузим на прод.
Прод или продакшн ( англ. production environment — рабочее окружение) — компьютер (чаще всего сервер), на котором запускается готовое к работе приложение.
Тестирование прошло успешно. И хотя Ване стало спокойнее, он не спешил радоваться — за полтора дня нужно было успеть выполнить задачу, на которую требовалась как минимум неделя.
К счастью, недавно он начал изучать JavaScript, поэтому мог просто скопировать код валидации с фронта и переделать его для бэкенда.
JavaScript — язык фронтенд-разработки.
Помучившись день, он всё-таки закончил. Тимлид оценил усилия:
— Ну вот, можешь же, когда захочешь. Тебе повезло, что мы не деплоим на прод по пятницам, поэтому у тебя ещё есть время до середины понедельника, чтобы ещё раз всё проверить и поправить.
Деплой ( англ. to deploy) — процесс перевода кода в рабочее приложение, чтобы запустить его на каком-нибудь компьютере.
Воодушевлённый успехом, Ваня ещё раз всё протестировал, поэтому к следующему митингу он был спокоен — больше исправлять старые баги ему не придётся.
По крайней мере на этот спринт.
Заключение
Научила ли чему-нибудь Ваню эта история? Возможно. Но вы наверняка стали на один шаг ближе к пониманию программистов. Или даже к тому, чтобы стать одним из них.