Настройте рабочие элементы Azure DevOps, чтобы улучшить свои проекты (часть 1)

Опубликовано: 1 Марта, 2023
Настройте рабочие элементы Azure DevOps, чтобы улучшить свои проекты (часть 1)

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

Настройка рабочих элементов Azure DevOps: наш сценарий

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

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

Когда мы создаем новый проект, мы можем определить процесс. По умолчанию у нас есть Agile, Basic, CMMI и Scrum. Они обеспечивают хорошую основу, но Azure DevOps обеспечивает исключительный уровень настройки, чтобы проект мог сосредоточиться на том, что требуется, а не на стандартном интерфейсе.

Мы собираемся создать новый проект под названием AP6Industries Cloud, но сначала мы создадим процесс рабочих элементов Azure DevOps, чтобы учесть все наши настройки для нашего будущего проекта.

На портале Azure DevOps щелкните Параметры организации, расположенные в левом нижнем углу, а затем щелкните Процессы.

В новом окне назовите новый процесс (мы будем использовать AP6Industries Cloud Agile Process) и дайте описание. Нажмите «Создать процесс».

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

Настройка процесса

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

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

Будут отображаться рабочие элементы процесса Agile по умолчанию. Щелкните Новый тип рабочего элемента.

В новом диалоговом окне назначьте имя для нового типа рабочего элемента и описание. Мы также можем определить значок и цвет, которые будут использоваться для этого рабочего элемента. Мы назовем это «Требования к сети». Нажмите «Создать».

Новая страница будет иметь поля по умолчанию в новом рабочем элементе. Первый шаг — настроить группы, которые являются областями на вкладке. Мы собираемся настроить новую под названием «Информация о виртуальной сети» и разместим ее в средней части, как показано на изображении ниже.

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

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

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

На вкладке «Макет» мы можем воспользоваться уже созданными группами для размещения наших новых полей.

Имейте в виду, что при выборе текста (несколько строк) Azure DevOps автоматически создаст группу. Мы не можем назначить его существующей группе.

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

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

  • Имя виртуальной сети
  • Количество подсетей (целое число)
    • Имя подсети (веб-уровня)
    • Имя подсети (уровня приложений)
    • Имя подсети (уровня базы данных)
  • Группа безопасности сети
  • Область сводки собрания
  • Сведения о группе безопасности приложений
  • Сведения о группе безопасности сети

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

Рабочие элементы Azure DevOps: дополнительные сведения во второй части

Целью этой первой статьи было продемонстрировать, как создавать настраиваемые рабочие элементы в Azure DevOps. Следуя той же логике, мы должны создать рабочий элемент для типа приложения. В этом новом рабочем элементе у нас должна быть вся информация о приложении, которое мы собираемся включить в наш проект. Мы должны добавить некоторую информацию, связанную с приложением и бизнесом, некоторые поля, о которых следует помнить: владелец приложения, центр затрат, описание приложения, SLA, RTO/RPO, аварийное восстановление и так далее.

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