Упражнение совместной работы Azure Repos с запросами на вытягивание
Если проблемы с кодом обнаруживаются быстрее, то их проще и дешевле устранять. Таким образом, группы разработчиков стремятся к тому, чтобы специалисты по разработке по возможности проверяли качество кода.
Как явствует из названия, политики ветвления предоставляют набор готовых политик, которые можно применить к ветвям на сервере.
Все изменения, которые отправляются в ветви сервера, должны соблюдать эти политики, прежде чем можно будет принять изменения.
Политики обеспечивают качество кода команды и соблюдение стандартов управления изменениями. В этом рецепте вы узнаете, как настроить политики ветвления в главной ветви.
Подготовка
Встроенные политики ветвления включают несколько политик, таких как проверка сборки и применение стратегии слияния. Мы сосредоточимся только на политиках ветвей, необходимых для настройки рабочего процесса проверки кода в этом рецепте.
Как это сделать
Откройте представление ветвей для репозитория myWebApp Git на портале группы Parts Unlimited. Выберите главную ветвь, а затем в раскрывающемся меню выберите пункт «Политики ветви»:
В представлении политик представлены готовые политики. Установите минимальное число рецензентов равным 1:
Параметр "Разрешить запросившим сторонам утверждать собственные изменения" позволяет поставщикам самостоятельно утверждать свои изменения.
Хотя это может быть приемлемым для зрелых команд, в целом это следует избежать.
Используйте политику проверки с политикой разрешения комментариев. Это позволяет принудительно разрешать комментарии к проверке кода перед принятием изменений. Инициатор запроса может взять отзыв из комментария и создать новый рабочий элемент и разрешить изменения. По крайней мере, при этом гарантируется, что комментарии к проверке кода не будут потеряны при принятии кода в главную ветвь:
Это требование инициирует изменение кода в командном проекте. Если рабочий элемент, который инициировал работу, не связан с изменением, со временем становится трудно понять, почему это изменение было внесено. Это особенно полезно при просмотре журнала изменений. Настройте проверку для политики связанных рабочих элементов, чтобы заблокировать изменения, которые не имеют связанного с ними рабочего элемента:
Выберите этот параметр, чтобы автоматически включать рецензентов при автоматическом создании запроса на вытягивание. Вы можете сопоставлять добавляемых рецензентов в зависимости от изменяемой области кода:
Принцип работы
После настройки политик ветвления главная ветвь является полностью защищенной.
Единственный способ передать изменения в главную ветвь — сначала внести изменения в другую ветвь, а затем вызвать запрос на вытягивание, чтобы активировать рабочий процесс принятия изменений.
Выберите создание новой ветви из одной из существующих пользовательских историй в концентраторе рабочих элементов.
При создании новой ветви на основе рабочего элемента этот рабочий элемент автоматически связывается с ветвью.
При необходимости можно добавить несколько рабочих элементов с ветвью в рабочий процесс создания.
Префикс в имени при создании ветви позволяет создать папку для размещения ветви.
В предыдущем примере ветвь отправляется в папку. Это отличный способ организовать ветви в средах с высокой нагрузкой.
После выбора новой созданной ветви на веб-портале измените файл HomeController.cs, чтобы добавить в него следующий фрагмент кода и зафиксировать изменения в ветви.
На приведенном ниже рисунке видно, что можно напрямую зафиксировать изменения после редактирования файла, нажав на кнопку «Фиксация».
Элемент управления «Путь к файлу» на портале группы поддерживает функцию поиска.
Начните вводить путь к файлу, чтобы просмотреть все файлы в репозитории Git в этом каталоге, имена которых начинаются с указанных букв в раскрывающемся списке результатов поиска путей к файлу.
В редакторе кода на веб-портале доступно несколько новых функций Azure DevOps Server, например поддержка сопоставления скобок и переключения пробелов.
Для загрузки палитры команд можно нажать на нее. Помимо множества других новых возможностей, теперь можно также переключать файл с помощью функций мини-сопоставления, свертывания и развертывания файлов, а также других стандартных операций.
Чтобы отправить эти изменения из новой ветви в главную ветвь, создайте запрос на вытягивание из представления «Запрос на вытягивание».
Выберите новую ветвь в качестве источника, а в качестве целевой — главную ветвь.
Новая форма запроса на вытягивание поддерживает синтаксиса Markdown, поэтому можно добавить описание с помощью синтаксиса Markdown.
Окно описания также поддерживает упоминания @ и # для связывания рабочих элементов:
Создается запрос на вытягивание. На странице обзора приведена сводная информация об изменениях и статусе политик.
На вкладке «Файлы» отображается список изменений и разница между предыдущей и текущей версиями.
Все обновления, переданные в файлы кода, появятся на вкладке «Обновления», а список всех фиксаций отображается на вкладке «Фиксации».
Откройте вкладку «Файлы». Это представление поддерживает комментарии к коду на уровне строки, на уровне файла и на общем уровне.
Комментарии поддерживают как @ для упоминаний, так и # для связывания рабочих элементов, а текст поддерживает синтаксис Markdown:
Комментарии к коду сохраняются в рабочем процессе запроса на вытягивание. Комментарии к коду поддерживают несколько итераций проверок и работу с вложенными ответами.
Политика рецензента позволяет выполнить рабочий процесс проверки кода в рамках принятия изменений.
Это отличный инструмент для совместной работы команды над любыми изменениями кода, отправленными в главную ветвь.
Когда требуемое число рецензентов утверждает запрос на вытягивание, запрос может быть выполнен.
Можно также пометить запрос на вытягивание для автозавершения после проверки. При этом выполняется автозавершение запросов на вытягивание после успешной компиляции всех политик.
И это еще не все
Вам когда-нибудь доводилось случайно удалять ветвь? Иногда непросто понять, что произошло.
Azure DevOps Server теперь поддерживает поиск удаленных ветвей. Эта функция помогает понять, кто и когда удалил ветвь. Этот интерфейс также позволяет повторно создать ветвь.
Удаленные ветви отображаются только тогда, когда вы ищете их по точному имени, чтобы избавиться от неподходящих результатов поиска.
Для поиска удаленных ветвей введите полное имя ветви в поле поиска ветви. Поиск вернет все существующие ветви, соответствующие этому тексту.
Вы также увидите команду для поиска точного совпадения в списке удаленных ветвей.
Если совпадение найдено, вы увидите, кто и когда удалил ветвь. Также можно восстановить ветвь. При восстановлении ветви выполняется ее повторное создание в той фиксации, на которую она указывала последней.
Однако политики и разрешения не восстанавливаются.