Работа с Azure Repos и репозиториями GitHub

Завершено

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

Чтобы узнать, как разработка на основе магистрали будет функционировать на практике, вы изучите процесс обновления кода как с помощью Azure DevOps, так и с помощью GitHub. В любое время может потребоваться изменить код рабочих процессов машинного обучения. Таким образом, вы будете использовать гибкое планирование, чтобы решить, когда следует обновлять код и упорядочивать свою работу.

Гибкое планирование

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

Чтобы спланировать и организовать работу, которую необходимо выполнить, специалист по обработке и анализу данных может использовать Azure Boards в Azure DevOps или GitHub issues.

Azure DevOps

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

Совет

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

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

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

Снимок экрана: элeменты невыполненной работы в Azure Boards.

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

Снимок экрана: обзор доски Azure Boards.

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

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

Снимок экрана: сведения о рабочем элементе Azure Boards.

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

Снимок экрана: ветвь в Azure Repos.

Теперь, когда ветвь создана, вы можете работать в ветви, чтобы вносить любые изменения в код. Как правило, вы клонируете ветвь в интегрированную среду разработки (IDE), например Visual Studio Code для локальной разработки и тестирования перед фиксацией и отправкой изменений в основной репозиторий.

GitHub

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

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

Снимок экрана: пример проблемы в GitHub с выделенной областью задач.

После создания проблемы вы сможете назначить работу себе или другому пользователю GitHub. Если вы хотите решить эту проблему, можно создать ветвь из элемента управления Разработка.

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

Снимок экрана: ветвь репозитория GitHub, созданная на основе проблемы.

Если вы вернетесь на вкладку Код, чтобы просмотреть репозиторий, вы сможете переключаться между ветвями и видеть созданную новую ветвь.

Снимок экрана: создание ветви в репозитории GitHub.

После того как вы выбрали рабочий элемент в Azure DevOps или проблему в GitHub и создали ветвь для редактирования кода, вам потребуется разработать код локально. Репозиторий Git можно клонировать из Azure DevOps или GitHub и работать над ним из любой интегрированной среды разработки.