CI/CD для Azure DevOps: YAML, AKS та автоматизація

CI/CD для Azure DevOps: YAML, AKS та автоматизація

Ручний деплой через веб-інтерфейс Azure DevOps перестає бути надійним при частоті релізів раз на тиждень. Помилки, простої, втрачені секрети — знайома картина. Кожного місяця в середньому 3 інциденти через ручний деплой. Ми проєктуємо multi-stage YAML pipeline з інтеграцією ACR, AKS та Key Vault, щоб автоматизувати деплой без сюрпризів. За 5 років ми виконали понад 30 проєктів з міграції та налаштування Azure DevOps — цей досвід дозволяє передбачити типові помилки та уникати простоїв.

Проблеми, які вирішуємо

Класичні пайплайни замість YAML. Microsoft оголосила Classic Release Pipelines deprecated, але багато компаній продовжують їх використовувати. Це техборг: Classic не підтримує GitOps, approval checks на рівні середовищ, багатоетапні сценарії. Classic пайплайни в 2 рази частіше призводять до помилок при деплої. Ми допомагаємо мігрувати на YAML без зупинки поточних релізів.

Відсутність безпечного підключення до Azure-ресурсів. Service Principal з секретами — це ризик: секрети можуть застаріти, потрапити в лог або репозиторій. Workload Identity Federation (WIF) вирішує цю проблему. Пайплайн отримує тимчасовий токен через OIDC — жодних ротацій, жодних витоків. Workload Identity Federation

Довгі та нестабільні деплої. Без multi-stage pipeline деплой на staging та production часто робиться вручну або через окремі релізні пайплайни. Це уповільнює постачання та збільшує ймовірність помилки. Ми будуємо єдиний YAML пайплайн з умовними stages, які автоматично запускаються на push в main або тег. Порівняння: YAML pipeline скорочує час циклу постачання в 3 рази порівняно з Classic за рахунок автоматизації кроків та паралельного виконання.

Як ми це робимо

Розберемо реальний кейс: команда з 8 осіб, .NET-мікросервіси, AKS, PostgreSQL через Azure Database. Раніше деплой виглядав так: збірка в Classic Build, ручний push в ACR, потім релізний пайплайн з купою ручних кроків. Ми запропонували єдиний YAML pipeline з трьома стадіями:

• Build: npm ci, lint, test, docker build & push в ACR.
• DeployStaging: автоматично при push в main; Helm upgrade з перевіркою pod ready.
• DeployProduction: тільки за тегом v*; вимагає approval від техліда; використовує канаркову стратегію (replicaCount=3, traffic split).

Ось спрощена версія такого пайплайну:

---
# azure-pipelines.yml
trigger:
  branches:
    include:
      - main
  tags:
    include:
      - 'v*'
variables:
  containerRegistry: 'myapp-acr'
  imageRepository: 'myapp'
  dockerfilePath: '$(Build.SourcesDirectory)/Dockerfile'
  tag: '$(Build.SourceVersion)'
stages:
  - stage: Build
    displayName: 'Build and Test'
    jobs:
      - job: BuildJob
        pool:
          vmImage: 'ubuntu-22.04'
        steps:
          - task: NodeTool@0
            inputs:
              versionSpec: '20.x'
          - script: |
              npm ci
              npm run lint
              npm run test -- --reporters=jest-junit
            displayName: 'Build and Test'
          - task: PublishTestResults@2
            inputs:
              testResultsFormat: 'JUnit'
              testResultsFiles: '**/junit.xml'
          - task: Docker@2
            displayName: 'Build and Push to ACR'
            inputs:
              command: buildAndPush
              containerRegistry: '$(containerRegistry)'
              repository: '$(imageRepository)'
              dockerfile: '$(Dockerfile)'
              tags: |
                $(tag)
                latest
  - stage: DeployStaging
    displayName: 'Deploy to Staging'
    dependsOn: Build
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    jobs:
      - deployment: DeployStaging
        environment: 'staging'
        pool:
          vmImage: 'ubuntu-22.04'
        strategy:
          runOnce:
            deploy:
              steps:
                - task: HelmDeploy@0
                  inputs:
                    connectionType: 'Azure Resource Manager'
                    azureSubscription: 'MyAzureSubscription'
                    azureResourceGroup: 'myapp-rg'
                    kubernetesCluster: 'myapp-aks-staging'
                    namespace: 'staging'
                    command: 'upgrade'
                    chartType: 'FilePath'
                    chartPath: '$(Pipeline.Workspace)/charts/myapp'
                    releaseName: 'myapp'
                    overrideValues: 'image.tag=$(tag)'
                    waitForExecution: true
  - stage: DeployProduction
    displayName: 'Deploy to Production'
    dependsOn: DeployStaging
    condition: and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/tags/v'))
    jobs:
      - deployment: DeployProduction
        environment: 'production'
        pool:
          vmImage: 'ubuntu-22.04'
        strategy:
          runOnce:
            deploy:
              steps:
                - task: HelmDeploy@0
                  inputs:
                    connectionType: 'Azure Resource Manager'
                    azureSubscription: 'MyAzureSubscription'
                    azureResourceGroup: 'myapp-rg'
                    kubernetesCluster: 'myapp-aks-prod'
                    namespace: 'production'
                    command: 'upgrade'
                    chartType: 'FilePath'
                    chartPath: '$(Pipeline.Workspace)/charts/myapp'
                    releaseName: 'myapp'
                    overrideValues: 'image.tag=$(tag),replicaCount=3'
                    waitForExecution: true

environment: 'production' у цьому пайплайні — не просто назва. В Azure DevOps Environments ми додали Approval Checks: перед деплоєм на production запитується підтвердження від керівника відділу. Також налаштовані бізнес-години (деплой лише з 9 до 18 за UTC) та автоматичний відкат при невдачі.

Чому варто відмовитися від Classic Pipelines?

Classic Pipelines — це спадщина, яка заважає автоматизації. У них немає версіонування, approval checks на базі Environments, підтримки умов stages. Порівняння показує різницю:

YAML пайплайн — мінімальний стандарт для сучасної CI/CD.

Як підключити Azure Key Vault до пайплайну?

Без Key Vault секрети часто потрапляють у змінні пайплайну у відкритому вигляді. Ми налаштовуємо задачу AzureKeyVault@2:

---
- task: AzureKeyVault@2
  inputs:
    azureSubscription: 'MyAzureSubscription'
    KeyVaultName: 'myapp-keyvault'
    SecretsFilter: 'DB-PASSWORD,API-KEY'
    RunAsPreJob: true
"}

Після цього $(DB-PASSWORD) доступна як змінна, її значення маскується в логах. Якщо пароль змінили в Key Vault — пайплайн підхопить зміни автоматично, без перезапуску.

Що входить у роботу

Ми надаємо повний комплекс послуг з налаштування CI/CD пайплайну:

• Аудит поточної інфраструктури: аналіз існуючих пайплайнів, Service Connections, Environments та RBAC.
• Проектування: архітектура multi-stage pipeline, вибір стратегії деплою (canary, blue-green, rolling).
• Реалізація: написання YAML-шаблонів, налаштування WIF, підключення Key Vault та ACR.
• Тестування: запуск пайплайну в тестовому середовищі, перевірка approval checks та відкатів.
• Документація: опис пайплайну, інструкція з додавання нових сервісів.
• Навчання: демо-сесія для команди, відповіді на питання.
• Підтримка: місяць пост-релізної підтримки для вирішення можливих проблем.

Етапи роботи

1. Аналітика — аудит поточних пайплайнів, узгодження вимог (1-2 дні).
2. Проектування — розробка схеми pipeline, вибір стратегій, узгодження (1 день).
3. Реалізація — написання YAML-коду, налаштування Environments, Service Connections (2-4 дні).
4. Тест — прогін пайплайнів у staging, замір часу, коригування (1-2 дні).
5. Деплой — перенесення інфраструктури під управління пайплайном (1 день).
6. Навчання та підтримка — передача документації, ОЗ, 1 місяць підтримки.

Орієнтовні терміни

Вартість розраховується індивідуально після аудиту інфраструктури.

Отримайте консультацію з налаштування CI/CD пайплайну — наші інженери оцінять вашу інфраструктуру та запропонують оптимальне рішення. Замовте аудит вашої CI/CD інфраструктури, щоб виявити вузькі місця та підвищити швидкість релізів на 40%. Зв'яжіться з нами, щоб обговорити ваш проєкт.

Джерело: документація Microsoft Azure Pipelines