Azure DevOps: идеальный инструмент для управления инфраструктурой как кодом

Azure DevOps — это полный пакет и инструмент управления для планирования и отслеживания задач и команд, контроля версий вашего кода, автоматизации развертываний, тестирования, документации и многого другого. Иногда специалисты по инфраструктуре упускают его из виду как основной инструмент для управления Microsoft Azure. Azure DevOps может стать единым местом для управления всеми вашими подписками по принципу «инфраструктура как код» (IaaC) и сэкономить ваше время и деньги с помощью интегрированного инструмента с платформой Microsoft.

В этой статье у нас будет организация в Azure DevOps и единый проект для управления всей средой с использованием шаблонов и сценариев ARM. Хотя мы не будем вдаваться в технические подробности в этой статье, мы планируем использовать группы ресурсов для объединения всех ресурсов любой заданной рабочей нагрузки проекта/службы в единое целое. У нас будет репозиторий для каждого приложения/службы, который будет соответствовать группе ресурсов.

Определение процесса, используемого в вашем проекте Azure DevOps.

При создании нового проекта администратор облака может выбрать процесс, который будет использоваться в Azure Boards. Это процессы, доступные по умолчанию: варианты Agile, Basic, CMMI и Scrum.

Процесс определит, как рабочие элементы и их структура будут доступны для команды проекта. Например, при использовании Basic доступными рабочими элементами являются Epic, Issue и Task. Если мы выберем Agile, у нас будут следующие рабочие элементы: Epic, Feature, User Story, Task, Bug и Issue.

Начало работы с Azure Boards

Все начинается с рабочих элементов (пункт 2). Мы используем процесс Basic, поэтому у нас есть три типа рабочих элементов: Epic, Issue и Task.

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

В нашем сценарии мы собираемся создать Epic для развертывания Hub-CoreNetwork, развертывания App6 и развертывания брандмауэра. Я предпочитаю использовать короткие имена для эпиков и использовать это же имя как часть имени рабочего элемента задачи. Делая это, мы можем понять иерархию с одного взгляда.

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

Чтобы начать создавать рабочие элементы, нажмите «Доски», «Рабочие элементы». Нажмите «Новый рабочий элемент» и выберите нужный рабочий элемент.

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

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

В области «Доски» есть несколько функций, и мы собираемся сделать краткий обзор некоторых интересных функций этого представления. Сначала, чтобы попасть туда, нажмите на доски (пункт 1), а затем нажмите на доски (пункт 2).

Есть два возможных представления наших рабочих элементов: эпики и задачи. Мы собираемся выбрать «Проблемы» (элемент 3), и список всех доступных проблем будет указан в столбце «Задачи».

Кнопка «Новый элемент» (элемент 5) позволяет легко создавать задачи (поскольку это текущее представление), и мы можем развернуть любую заданную проблему и добавить задачи, используя ссылку «Добавить задачу» (элемент 6), которая помогает при группировании задач и задач. связанных с ним.

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

Одним из преимуществ использования досок по сравнению с рабочими элементами является то, что структура родительских и дочерних элементов создается автоматически, когда мы открываем Issue 18 (например, CoreNetwork: Design Session with the team).

У нас будет соответствующая рабочая область свойств этой проблемы с правильно настроенными родительскими (Epic) и дочерними (задачи). Вы можете делать подобные вещи с рабочими элементами. Однако для организации Заданий требуется больше труда.

Мы настроили доску немного иначе, чем вид по умолчанию. Во-первых, у нас есть столбец под названием «Продавец» (элемент 7), и мы собираемся использовать его для назначения проблем, назначенных поставщику. Другой элемент — это дорожки для плавания (элемент 4), которые создают визуализацию приоритета для команды. Должны быть решены все проблемы, но ресурс может выбрать одну из них, которая является более актуальной для бизнеса или общей важности.

Чтобы настроить дорожки для плавания, нажмите «Настройки», а затем перейдите на вкладку «Дорожки для плавания» и определите их там. Чтобы установить дополнительный столбец, нажмите «Столбцы» и внесите необходимые изменения. Нажмите «Сохранить и закрыть», чтобы применить изменения.

Работа с бэклогом и спринтами

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

Планировать, что делать, когда, кто и как использует ваши ресурсы. Нам нужно начать организовывать, и Azure DevOps упрощает эту задачу, используя Sprints и Backlogs.

Во-первых, давайте перейдем к Backlogs (элемент 1), и список всех проблем (опять же, вы можете выбрать представление между проблемами и эпиками) будет указан (элемент 4). С правой стороны (пункт 3) у нас будет список всех существующих спринтов с датами их начала и окончания, мы также можем создать новый спринт, нажав «Новый спринт» (пункт 3).

Мы можем перемещать задачи (включая их дочерние задачи) в любой заданный спринт путем перетаскивания. Проблемы, которые вы видите слева, — это те, которые все еще находятся в невыполненной работе. Как только мы переместим их в спринт, они будут удалены из представления невыполненной работы и будут найдены в конкретном спринте.

Чтобы просмотреть все задачи в любом заданном спринте, нажмите на него.

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

Мы всегда можем включить родителей с помощью кнопки «Параметры просмотра», и это меняет правила игры.

Результаты дают полное представление о структуре, включая Эпопею, Выпуск и Задачи с одного взгляда (Элемент 1). Для тех задач, которые не назначены эпику, они будут отображаться как задачи без родителей.

В разделе «Спринт» убедитесь, что вы находитесь на доске задач (элемент 1), а в первом столбце слева у нас будут задачи, назначенные текущему спринту. Мы можем перемещать задачи между To Do, Doing и Done.

Текущий спринт определен в пункте 2, и мы можем использовать эту область для переключения между существующими спринтами. У нас также есть небольшая картинка с графической информацией о Burndown Trend. Когда у нас есть правильно настроенные задачи, в том числе назначенные, время, необходимое для выполнения задачи, действия и т. д., мы можем увидеть страницу сведений о работе (мы можем включить ее, нажав «Параметры просмотра »).

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

Azure DevOps как средство управления планированием и отслеживанием: только начало

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