Работа над крупным проектом – это всегда командная работа. И в этой команде каждый программист занимается реализацией отдельной задачи, работая в своей функциональной ветке GitHub, GitLab, Bitbucket или любого другого репозитория.
После того как разработчик решит задачу, необходимо выполнить слияние результатов с основной веткой проекта для того, чтобы другие участники команды могли использовать разработанные им функции. Содержимое основной ветки собирается и доставляется в production, став достоянием коллег из других отделов или заказчиков.
Но это если не брать в расчет такой этап работы, как Pull Request…
Что такое Pull Request и зачем он нужен?
Как я уже отметил выше, каждый программист в команде занимается разработкой в своей функциональной ветке. Она не затрагивает главную ветку, поэтому изменения, внесенные в код конкретным разработчиком, не появляются в приложении автоматически.
Когда разработчик заканчивает работу над функцией или исправлением бага, он должен уведомить об этом других членов команды, чтобы те провели аудит кода.
По сути, такое уведомление – это и есть пул-реквест. То есть запрос на слияние написанного разработчиком кода с основной веткой для дальнейшей публикации.
Но пул-реквест – это не просто оповещение. Это целая платформа для обсуждения и дальнейшей доработки кода другими членами команды. При каждом пул-запросе формируется отдельная страница, где коллеги разработчика могут оставить комментарии или внести дополнительные изменения в его код.
Если другие разработчики заметят в коде ошибки, то смогут исправить их или предложить более элегантные варианты реализации ожидаемой функции. Если же все в порядке, то код из ветки разработки объединяют с основной (совершают так называемый мердж), а потом публикуют его (эту процедуру называют деплоем), и он попадает непосредственно в приложение. Но не факт, что все будет в порядке…
Почему одного пул-реквеста недостаточно?
Разработчикам приходится создавать отдельные структурные элементы продукта, минимально коммуницируя с другими сотрудниками команды. Да, за качеством кода следят программисты, и они действительно могут обнаружить логические ошибки во внедряемой функции или проконтролировать корректность оформления и структурированность кода.
Но маркетолог, менеджер или заказчик приложения может ничего не понимать в языках программирования. Поэтому он не в силах адекватно оценить, насколько хороша та реализация, которую предлагает разработчик, как она повлияет на текущее состояние продукта, соответствует ли предложенный код техническому заданию заказчика, нужно ли что-то скорректировать, дополнить и т.п. Приходится ждать непосредственного запуска новой функции или сервиса, чтобы все могли оценить его в полной мере. До этого момента коллеги программистов слепо надеются на то, что итоговый результат будет соответствовать общим ожиданиям.
Такой подход негативно сказывается на скорости разработки и периодичности появления новых функций, потому что отсутствие возможности полноценно оценить код всей командой увеличивает временные промежутки между внесением правок в код и последующим тестированием этих правок после деплоя.
В итоге это сильно усложняет процесс разработки в целом, потому что далеко не всегда тот код, что успешно прошел проверку на этапе пул-реквеста, становится тем кодом, который нравится заказчику и другим участникам команды.
И тогда программистам приходится начинать сначала или радикально менять написанный код. Из-за этого увеличивается срок сдачи проекта и затраты, а также нарастает необходимость в возможности проверить Pull Request не только отделом разработки.
На помощь приходит 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 удобным для него способом.
- Предлагаемый разработчиком код тут же публикуется на серверах Hostman. Причем на полноценный временный домен с бесплатным SSL-сертификатом и полным набором инструментов, необходимых для полноценного тестирования.
- Вебмастер, заведующий сервером, получает временную ссылку, пройдя по которой можно увидеть разрабатываемый проект с уже внедренным кодом из Pull Request. Здесь все будет выглядеть и работать так, будто команда программистов сделала деплой и внедрила все изменения в основную ветку проекта.
- После этого, независимо от того, сделали разработчики мердж или отправили код на доработку, временная ссылка самоустраняется.
Как работает Pull Request
Как работает Pull Request Preview
Рабочий процесс никак не затрагивает программистов. Они действуют по той же схеме, что и раньше, а другие сотрудники получают новые возможности:
- Тестировщики могут взаимодействовать с кодом в реальном времени, видя все изменения, что вносит разработчик, и отлавливая баги в тот же момент без задержек. А как только найденные ошибки поправят, они могут приступать к повторному тестированию.
- Дизайнеры в одно время с тестировщиками и другими разработчиками могут проверить свою зону ответственности, предлагая правки визуальной составляющей продукта еще на стадии работы с пул-реквестом, а не после деплоя, как это было раньше.
- Заказчик приложения может вместе с его создателями отслеживать каждый этап разработки, предлагая изменения и дополнения еще до деплоя.
Вместо заключения
Возможность до мерджа всем штатом сотрудников опробовать продукт, найти в нем ошибки и принять решение о дальнейшем внедрении – отличное подспорье для бизнеса.
Pull Request Preview позволит ускорить процесс разработки, сократит количество времени, которое уходит на тестирование продукта, что повлечет за собой сокращение потраченных на разработку человеко-часов и бюджета компании. В итоге это позволит реализовывать даже самые смелые задумки (новые функции, масштабную смену дизайна) в короткие сроки и поможет «обогнать конкурентов на поворотах». Там, где другие компании находятся в невыгодном положении, тратя много времени на работу с каждым пул-реквестом, бизнес, использующий Pull Request Review, сможет быстрее принимать решения и идти в ногу с потребностями рынка.
Впрочем, оценить все прелести Pull Request Preview можно самостоятельно. Hostman предлагает новым клиентам бесплатно создать до трех статических сайтов, подключить GitHub и попробовать Pull Request Preview, чтобы на практике увидеть, как работает эта функция и как сильно она может помочь вашему бизнесу.
Комментарии