Настройка Azure DevOps: Boards, Repos, Pipelines, Artifacts

Мы часто видим команды, которые приходят в Azure DevOps из Jira + GitHub + Jenkins и удивляются: всё это уже есть в одном месте. Boards для задач, Repos для кода, Pipelines для CI/CD, Artifacts для пакетов, Test Plans для тестирования. Но «всё в одном месте» не означает «работает само» — настройка под конкретные процессы команды занимает время и требует понимания архитектуры Azure DevOps Organization → Project → Team. Наши инженеры имеют 10+ лет опыта в DevOps и более 50 успешных проектов по миграции на Azure DevOps — мы гарантируем плавный переход и оптимальную конфигурацию под ваши задачи.

Структура: Organization, Project, Team

Organization — верхний уровень, аналог «компании» в Jira. Один URL вида dev.azure.com/mycompany. Биллинг, политики безопасности, пользователи — всё на уровне Organization.

Project — основная рабочая единица. Содержит Boards, Repos, Pipelines, Artifacts и Test Plans. Для разных продуктов лучше заводить отдельные проекты, а не пихать всё в один. Смешивать несвязанные команды в один проект — частая ошибка, которую потом сложно исправить: работы/задачи/пайплайны начинают мешаться.

Team — подмножество проекта с собственными Boards, Sprint Backlog и настройками. Один Project может содержать несколько Teams (frontend-team, backend-team, devops-team).

Boards: Agile, Scrum или CMMI

При создании проекта выбирается процессный шаблон. Для большинства команд — Scrum (с Sprint Backlogs, Velocity и Burndown) или Agile (более гибкий, с User Stories и Tasks). CMMI — для формальных процессов с change requests и approval workflows.

Настройка под команду:

Process → Work Item Types → добавить кастомные поля
Board → Column settings → настроить WIP limits
Sprints → создать спринты с датами
Area Paths → структура по компонентам (backend, frontend, infra)
Iteration Paths → иерархия спринтов (Q1 → Sprint 1, Sprint 2)

Area Paths — особенно важны для фильтрации: каждая Team работает со своей Area, и их Boards не пересекаются.

Как настроить Branch Policies в Azure Repos?

Azure Repos поддерживает Git (и устаревший TFVC, который лучше не трогать). Основная настройка — Branch Policies на main:

• Minimum number of reviewers: 2 (для production-кода)
• Check for linked work items: обязательная связь PR с задачей в Boards
• Check for comment resolution: нельзя смержить с непрезолвленными комментариями
• Build validation: автоматический запуск пайплайна на каждый PR

# Политика через Azure CLI az repos policy approver-count create \
  --allow-downvotes false \
  --blocking true \
  --branch main \
  --creator-vote-counts false \
  --enabled true \
  --minimum-approver-count 2 \
  --project myproject \
  --repository-id <repo-id>

Что выбрать: YAML или Classic pipelines?

Classic pipelines (через UI) — устарели. Новые проекты всегда настраиваем на YAML-пайплайны, которые хранятся в репозитории как azure-pipelines.yml. Code review для пайплайна, history изменений, возможность использовать templates. Подробнее о YAML-схеме можно узнать в официальной документации.

Базовая структура YAML:

trigger:
  branches:
    include:
      - main
      - develop
pool:
  vmImage: ubuntu-latest
stages:
  - stage: Build
    jobs:
      - job: BuildJob
        steps:
          - task: Docker@2
            inputs:
              command: buildAndPush
              repository: myapp
              containerRegistry: myacr-connection
              tags: |
                $(Build.BuildId)
                latest
  - stage: Deploy
    dependsOn: Build
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: DeployProd
        environment: production
        strategy:
          runOnce:
            deploy:
              steps:
                - task: HelmDeploy@0
                  inputs:
                    command: upgrade
                    chartName: myapp
                    releaseName: myapp-prod

Environments и approvals в Pipelines

В разделе Pipelines → Environments создаётся окружение production. Для него настраивается Approvals and checks:

• Approvals: список людей, один из которых должен апрувнуть деплой
• Business hours check: деплой разрешён только в рабочее время (например, пн-пт 09:00-18:00)
• Exclusive lock: только один деплой в это окружение одновременно

Artifacts: внутренний package registry

Azure Artifacts создаёт приватные feeds для npm, NuGet, Maven, Python и Universal Packages. Команда публикует внутренние библиотеки в Artifacts, а не в публичный npm/PyPI.

# Публикация npm-пакета в Artifacts feed
- task: Npm@1
  inputs:
    command: publish
    publishRegistry: useFeed
    publishFeed: myorg/myfeed

Upstream sources позволяют настроить проксирование публичных реестров через Artifacts feed — тогда npm install идёт через внутренний прокси, что позволяет кэшировать пакеты и контролировать доступ к внешним зависимостям.

Service Connections: интеграции с облаком

Для деплоя в Azure, AWS, GCP, Kubernetes нужны Service Connections — безопасное хранилище credentials, к которым pipeline имеет доступ без захардкоженных секретов. Настраивается в Project Settings → Service Connections.

Для Azure Kubernetes Service — Service Connection типа Kubernetes с kubeconfig или сервисным аккаунтом. Для Azure Container Registry — ACR service connection с автоматическим OAuth. Для AWS — AWS Credentials connection с IAM-ролью.

Что входит в настройку Azure DevOps?

Сроки

Базовая настройка нового проекта (Boards, Repos с branch policies, один Pipeline) — 1 день. Полная конфигурация Organization с несколькими проектами, Artifacts feed, Environments с approvals, интеграцией с AKS — 2-3 дня. Миграция с Jira + GitHub + Jenkins — отдельная оценка. Стоимость рассчитывается индивидуально. Свяжитесь с нами, чтобы получить консультацию и точные сроки для вашего проекта. Закажите настройку Azure DevOps у нас — мы гарантируем качество и сопровождение после внедрения.