0
Forest st., Moscow
+79266800080

Pull Request Preview – что это такое и с чем его едят

Pull Request Preview – что это такое и с чем его едят

Работа над крупным проектом – это всегда командная работа. И в этой команде каждый программист занимается реализацией отдельной задачи, работая в своей функциональной ветке GitHub, GitLab, Bitbucket или любого другого репозитория.

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

Но это если не брать в расчет такой этап работы, как Pull Request…

Что такое Pull Request и зачем он нужен?

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

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

По сути, такое уведомление – это и есть пул-реквест. То есть запрос на слияние написанного разработчиком кода с основной веткой для дальнейшей публикации.

Pull RequestНо пул-реквест – это не просто оповещение. Это целая платформа для обсуждения и дальнейшей доработки кода другими членами команды. При каждом пул-запросе формируется отдельная страница, где коллеги разработчика могут оставить комментарии или внести дополнительные изменения в его код.

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

Почему одного пул-реквеста недостаточно?

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

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

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

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

И тогда программистам приходится начинать сначала или радикально менять написанный код. Из-за этого увеличивается срок сдачи проекта и затраты, а также нарастает необходимость в возможности проверить Pull Request не только отделом разработки.

На помощь приходит Pull Request Preview

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

Pull Request Preview

Функция Pull Request Preview – это как деплой, но только в закрытое (временное) окружение, а не в production. Вы можете в полной мере оценить все обновления, что предлагают программисты, не зная кода. Попользоваться ими, проверить на практике или попробовать сломать. И все это – до объединения ветки разработки с основной веткой, то есть без угрозы для действующего продукта.

Такую функцию предлагает Hostman – хостинг для упрощенной публикации сайтов, приложений, баз данных и других продуктов прямо из GitHub или GitLab.

Принцип работы Pull Request Preview в Hostman

Хостинг-провайдер Hostman, партнер Timeweb, недавно запустил функцию Pull Request Preview для своих пользователей. И она позволяет без лишних движений проводить основательное тестирование внедряемых функций всей командой еще до деплоя.

Pull request preview в Hostman

Pull Request Preview в Hostman

Почему я делаю акцент на «без лишних движений»? Потому что все происходит в автоматическом режиме:

  1. Программист делает Pull Request удобным для него способом.
  2. Предлагаемый разработчиком код тут же публикуется на серверах Hostman. Причем на полноценный временный домен с бесплатным SSL-сертификатом и полным набором инструментов, необходимых для полноценного тестирования.
  3. Вебмастер, заведующий сервером, получает временную ссылку, пройдя по которой можно увидеть разрабатываемый проект с уже внедренным кодом из Pull Request. Здесь все будет выглядеть и работать так, будто команда программистов сделала деплой и внедрила все изменения в основную ветку проекта.
  4. После этого, независимо от того, сделали разработчики мердж или отправили код на доработку, временная ссылка самоустраняется.

Пур-реквест

Как работает Pull Request

Пул-реквест превью

Как работает Pull Request Preview

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

  • Тестировщики могут взаимодействовать с кодом в реальном времени, видя все изменения, что вносит разработчик, и отлавливая баги в тот же момент без задержек. А как только найденные ошибки поправят, они могут приступать к повторному тестированию.
  • Дизайнеры в одно время с тестировщиками и другими разработчиками могут проверить свою зону ответственности, предлагая правки визуальной составляющей продукта еще на стадии работы с пул-реквестом, а не после деплоя, как это было раньше.
  • Заказчик приложения может вместе с его создателями отслеживать каждый этап разработки, предлагая изменения и дополнения еще до деплоя.

Вместо заключения

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

Pull Request Preview позволит ускорить процесс разработки, сократит количество времени, которое уходит на тестирование продукта, что повлечет за собой сокращение потраченных на разработку человеко-часов и бюджета компании. В итоге это позволит реализовывать даже самые смелые задумки (новые функции, масштабную смену дизайна) в короткие сроки и поможет «обогнать конкурентов на поворотах». Там, где другие компании находятся в невыгодном положении, тратя много времени на работу с каждым пул-реквестом, бизнес, использующий Pull Request Review, сможет быстрее принимать решения и идти в ногу с потребностями рынка.

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

источник

Related Posts
Leave a Reply