Налаштування 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 для пайплайну, історія змін, можливість використовувати templates. Докладніше про YAML-схему можна дізнатися в офіційній документації.
| Параметр | Classic Pipelines | YAML Pipelines |
|---|---|---|
| Зберігання | В Azure DevOps UI | В репозиторії (azure-pipelines.yml) |
| Code review | Ні | Так, через PR |
| Історія змін | Ні | В Git історії |
| Підтримка templates | Ні | Так |
Базова структура 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?
| Компонент | Що робимо | Результат |
|---|---|---|
| Organization & Project | Створюємо структуру, налаштовуємо безпеку, політики | Готовий проект з областями та ітераціями |
| Boards | Вибираємо шаблон, налаштовуємо WIP limits, спринти | Робоча дошка з backlog та board |
| Repos | Імпортуємо код, налаштовуємо branch policies, CI triggers | Репозиторій з захищеним main та автоматичними перевірками |
| Pipelines | Пишемо YAML-пайплайни, налаштовуємо stages та environments | CI/CD від коміту до продакшену з approvals |
| Artifacts | Створюємо feeds, налаштовуємо upstream sources | Приватний registry для внутрішніх пакетів |
| Service Connections | Підключаємо хмари, контейнерні registry | Безпечний доступ без секретів в коді |
Строки
Базове налаштування нового проекту (Boards, Repos з branch policies, один Pipeline) — 1 день. Повна конфігурація Organization з кількома проектами, Artifacts feed, Environments з approvals, інтеграцією з AKS — 2-3 дні. Міграція з Jira + GitHub + Jenkins — окрема оцінка. Вартість розраховується індивідуально. Зв'яжіться з нами, щоб отримати консультацію та точні строки для вашого проекту. Замовте налаштування Azure DevOps у нас — ми гарантуємо якість і супровід після впровадження.
