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

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

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

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

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

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

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

proxy.php?image=https%3A%2F%2Ftimeweb.com%2Fmedia%2Fdefault%2F0001%2F03%2F148fc0f9cce34f69ca6f7fae8e035d7beb99503e.png&hash=43bae9ca74d908772313d11c59656f01
Но пул-реквест – это не просто оповещение. Это целая платформа для обсуждения и дальнейшей доработки кода другими членами команды. При каждом пул-запросе формируется отдельная страница, где коллеги разработчика могут оставить комментарии или внести дополнительные изменения в его код.

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

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

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

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

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

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

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

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

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

proxy.php?image=https%3A%2F%2Ftimeweb.com%2Fmedia%2Fdefault%2F0001%2F03%2F2ca348ee0fb65c61d4c82d61854be2ecc3af4e0d.jpeg&hash=e7a3da2b3eec163b70a6f3503b5390c8

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

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

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

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

proxy.php?image=https%3A%2F%2Ftimeweb.com%2Fmedia%2Fdefault%2F0001%2F03%2Ffbb40629c2a483e7c2ba6fdb173fd4174b16362d.jpeg&hash=99351213132398841f8d71da086521f5


Pull Request Preview в Hostman

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

proxy.php?image=https%3A%2F%2Ftimeweb.com%2Fmedia%2Fdefault%2F0001%2F03%2F9fb3a4f8ae8c03f8b2ca2186bb095178dba615fb.jpeg&hash=4bb30985ad2a5395b98c8e1deb82df77


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

proxy.php?image=https%3A%2F%2Ftimeweb.com%2Fmedia%2Fdefault%2F0001%2F03%2F084ba86ca151c736d0b0e67eb2c21a2ca08fca04.jpeg&hash=7c1d55dfa4980864cb8d12fbe53daad0


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

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

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

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

Заказчик приложения может вместе с его создателями отслеживать каждый этап разработки, предлагая изменения и дополнения еще до деплоя.​

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

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

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