Azure DevOps — це потужний набір інструментів, розроблений, щоб допомогти командам розробників оптимізувати життєвий цикл розробки програмного забезпечення. Одним із ключових аспектів Azure DevOps є його підтримка безперервної інтеграції та безперервного розгортання (CI/CD) за допомогою Azure Pipelines. CI/CD є критично важливою практикою в сучасній розробці програмного забезпечення, що дозволяє командам автоматизувати процес збірки, тестування та розгортання застосунків, щоб гарантувати швидке та надійне доставку змін до кінцевих користувачів.

У цій статті ми ознайомимось із процесом налаштування процесу CI/CD за допомогою Azure DevOps для ASP.NET Core застосунку. Для налаштування процесу CI/CD в Azure DevOps існують Azure Pipelines або просто Pipelines. Ми будемо створювати Pipeline за допомогою YAML. Pipelines складатиметься з кількох етапів: збірки застосунку, його розгортання в тестовому середовищі в Azure, очікування затвердження QA та, нарешті, розгортання застосунку у робочому середовищі, також розміщеному в Azure. Ми також розглянемо використання заміни слотів, це функція в Azure, яка дозволяє легко перемикатися між різними версіями веб застосунку (App Service/Web App), з мінімальним простоєм.

Для початку створення Pipeline нам необхідно щоб в нашому Azure DepOps вже був Git репозиторій, та ми мали підпуску в Microsoft Azure. Якщо це все є, ми можемо починати.

Спочатку нам необхідно екземпляр Azure App Service та створити слот для тестового середовищ.

Для того щоб створи екземпляряр Azure App Service:

• Увійдіть на портал Azure (https://portal.azure.com/).
• Натисніть кнопку “Create a resource” у верхньому лівому куті.
• Знайдіть “Web App” і виберіть його серед результатів.
• Натисніть “Create” , щоб розпочати процес створення служби додатків.

Заповніть відчинившуюся сторінку.

• Оберіть підписку в якій необхідно розгорнути ресурс.
• В полі “Resource group” оберіть існуючу групу, або ви можете створити нову ресурсну групи, натиснувши “Create new” і введіть ім’я для< нової групи.
• В полі “Name” введіть унікальну назву для свого AppService.
• В полі “Publish” виберіть “Code” як варіант розгортання.
• Оберіть необхідну версію .net, в полі “Runtime stack”
• Оберіть регіон а також App Service Plan. Якщо у вас немає існуючого App Service Plan, ви можете створити новий, натиснувши “Create new” і вибравши потрібні параметри.
• Натисніть “Review + create”, щоб переглянути свої налаштування, і натисніть “Create”, щоб створити екземпляр AppService (Web App).

Після створення App Service необхідно створити слот. Для цього:

• Відкрийте щойно створений App Service
• На панелі навігації App Service прокрутіть униз до розділу “Deployment” і натисніть “Deployment slots”.
• У верхній частині панелі “Deployment slots” натисніть кнопку “+ Add Slot”.
• На панелі “Add a slot” в полі “Name” введіть “staging”.

За бажанням ви можете клонувати налаштування з наявного слота розгортання, вибравши його зі спадного меню “Clone settings from”.

Щоб pipeline міг взаємодіяти з ресурсами Azure, необхідно створити підключення служби між Azure DevOps і вашою підпискою Azure.

• Перейдіть до свого проекту Azure DevOps і перейдіть до “Project Settings” в нижньому лівому куті інформаційної панелі.
• На сторінці “Project Settings” клацніть “Service connections” в розділі “Pipelines”.
• Натисніть кнопку “New service connection” та виберіть “Azure Resource Manager” зі списку доступних служб. Та натисніть копку “Next”
• Оберіть тип автентифікацію
• Дотримуйтеся вказівок, щоб пройти автентифікацію за допомогою облікового запису Azure і надати Azure DevOps доступ до вашої підписки.
• Після встановлення підключення ви побачите нове підключення до служби Azure Resource Manager у списку “Service connections”

Тепер, коли ви створили в Azure App Service, а також додатковий слот для розгортання, ми можемо почати створення pipeline для розгортання вашого ASP.NET Core застосунку.

Для початку треба додати наші Environment, для цього необхідно виконати наступні кроки

• Увійдіть в Azure DevOps і перейдіть до свого проекту
• Натисніть “Pipelines” на лівій бічній панелі
• Натисніть “Environments” на верхній панелі
• Натисніть “Create Environment”
• Введіть “Test” як назву середовища
• За бажанням ви можете додати опис цього середовища
• Натисніть “Create”
• Знову натисніть “Create Environment”
• Введіть “Production” як назву середовища
• За бажанням ви можете додати опис цього середовища
• Натисніть “Create”
• Клацніть щойно створене середовище “Production”, щоб відкрити його
• Натисніть меню з трьома крапками (⋮) у верхньому правому куті та виберіть “Approvals and checks”
• Натисніть “+ New check” і виберіть зі списку “Approval”
• Додайте користувачів або групи в поле “Approvers”, які відповідатимуть за затвердження розгортань у Production середовищі
• Додайте пояснення в поле “Instructions to approvers”
• Натисніть “Create”, щоб зберегти налаштування затвердження

Тепер у вас є тестове та робоче середовища, створені в Azure DevOps. Щоразу, коли запускається розгортання для виробничого середовища, призначені особи, які затверджують, отримають сповіщення про схвалення або відхилення розгортання.

• Увійдіть в Azure DevOps і перейдіть до свого проекту
• Натисніть “Pipelines” на лівій бічній панелі
• Натисніть “Create Pipeline”
• Виберіть місце, де розміщено ваш код (Azure Repos Git, GitHub, Bitbucket Cloud або інший Git)
• Виберіть репозиторій, який містить ваш застосунок
• Azure DevOps запропонує шаблон обрати шаблон, оберіть будь який шаблон
• На відчинившийся сторінці знаходить редактор YAML, видаліть весь тест, який знаходиться в редакторі

Тепер почнемо створювати наш YAML. С початку опишемо правило, при якому, буде запускатись pipeline. Для цього напишемо

trigger:
- main

Тепер давайте опишемо перший етап. Для цього додайте наступний код

stages:
- stage: Build
  displayName: 'Build and Test'
  jobs:
  - job: BuildJob
    displayName: 'Build Job'
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - task: DotNetCoreCLI@2
      displayName: 'Restore Packages'
      inputs:
        command: 'restore'
        projects: '**/*.csproj'

    - task: DotNetCoreCLI@2
      displayName: 'Build Solution'
      inputs:
        command: 'build'
        projects: '**/*.csproj'
        arguments: '--configuration Release'

    - task: DotNetCoreCLI@2
      displayName: 'Run Tests'
      inputs:
        command: 'test'
        projects: '**/*Tests/*.csproj'
        arguments: '--configuration Release'

    - task: DotNetCoreCLI@2
      displayName: 'Publish Artifacts'
      inputs:
        command: 'publish'
        publishWebProjects: true
        arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory)'
        zipAfterPublish: true

    - task: PublishBuildArtifacts@1
      displayName: 'Upload Artifacts'
      inputs:
        pathtoPublish: '$(Build.ArtifactStagingDirectory)'
        artifactName: 'drop'

Цей код YAML описує етап Build, ось деталі:

• stage: Build – початок етапу Build. Цей етап включає в себе всі завдання, які будуть виконуватися в процесі збірки.
• displayName: ‘Build and Test’ – зрозуміла для людини назва етапу збірки.
• jobs – список завдань для виконання на етапі збірки. Роботи є основною одиницею роботи в конвеєрі, і вони виконуються незалежно одне від одного. У цьому випадку є одне завдання: BuildJob.
• job: BuildJob – початок BuildJob. Ця робота включає всі завдання, які будуть виконуватися під час цієї роботи.
• pool – вказує пул агентів, який використовуватиметься для виконання завдання.
• steps – список кроків, які потрібно виконати.
• task: DotNetCoreCLI@2 – використовує завдання .NET Core CLI версії 2 для виконання різних команд .NET Core. Тут використовуються чотири завдання, кожне з яких має окрему команду:
• task: PublishBuildArtifacts@1 – публікує результати збірки для використання на наступних етапах конвеєра або для зберігання:
  • command: ‘restore’: відновлює пакети NuGet, необхідні для проектів .NET Core. command: ‘build’: збирає проекти .NET Core із конфігурацією Release.
  • command: ‘test’: запускає модульні тести в будь-яких проектах, які закінчуються на “Tests”.
  • command: ‘publish’: публікує веб-проекти .NET Core. Вихідні дані заархівовуються та поміщаються в проміжний каталог Build Artifact.

Наступним корком буде етап публікації застосунку в staging слот

- stage: DeployTest
  displayName: 'Deploy to Test Environment'
  dependsOn: Build
  condition: succeeded('Build')
  jobs:
  - deployment: DeployTestJob
    displayName: 'Deploy Test Job'
    environment: 'Test'
    pool:
      vmImage: 'ubuntu-latest'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: DownloadBuildArtifacts@0
            displayName: 'Download Artifacts'
            inputs:
              buildType: 'current'
              artifactName: 'drop'
              downloadPath: '$(System.ArtifactsDirectory)'

          - task: AzureWebApp@1
            displayName: 'Deploy to Test Environment'
            inputs:
              azureSubscription: '$(AzureSubscriptionName)'
              appName: '$(AppServiceName)'
              appType: 'webApp'
              package: '$(System.ArtifactsDirectory)/drop/**/*.zip'
              slotName: 'staging'

• stage: DeployTest – визначає новий етап під назвою “DeployTest”.
• displayName: ‘Deploy to Test Environment’ – зрозуміла для людини назва цього етапу, яка відображається в інтерфейсі користувача.
• dependentOn: Build – Це означає, що етап “DeployTest” залежить від етапу “Build”. Він буде виконано лише в тому випадку, якщо етап “Build” завершиться успішно.
• condition: succeeded(‘Build’) – це умова, яка перевіряє, чи успішно завершився етап “Build”. Якщо етап “Build” не завершився успішно, етап “DeployTest” не буде запущено.
• jobs – Цей розділ містить завдання для етапу “DeployTest”.
• deployment: DeployTestJob – розгортання під назвою “DeployTestJob”. Завдання розгортання мають додаткові можливості порівняно зі звичайними завданнями, як-от доступ до історії розгортання та змінних середовища.
• environment: “Test” – це вказує, що буде розгорнуто в середовищі під назвою “Test”.
• pool – Це вказує пул агентів, який використовуватиметься для виконання завдання. У цьому випадку він використовуватиме найновіший образ Ubuntu.
• strategy – Цей розділ визначає стратегію розгортання. У цьому випадку стратегією є runOnce, що означає, що розгортання буде виконано один раз.
• task: DownloadBuildArtifacts@0 – завантажує артефакти збірки з попереднього етапу “Build”. Він завантажує артефакт “drop”, який було створено на етапі “Build”.
• task: AzureWebApp@1 – розгортає завантажені артефакти у веб-програмі Azure. Він використовує змінні AzureSubscriptionName і AppServiceName для підписки Azure та назви служби додатків. (як додати змінні читайте нижще)

І останній етап, це перенесення застосунку з тестового(staging) слоту, в основний. Нижче приведено код для цього етапу.

- stage: DeployProduction
  displayName: 'Deploy to Production Environment'
  dependsOn: DeployTest
  condition: succeeded('DeployTest')
  jobs:
  - deployment: DeployProductionJob
    displayName: 'Deploy Production Job'
    environment: 'Production'
    pool:
      vmImage: 'ubuntu-latest'
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureAppServiceManage@0
            displayName: 'Swap Slots'
            inputs:
              azureSubscription: '$(AzureSubscriptionName)'
              action: 'Swap Slots'
              webAppName: '$(AppServiceName)'
              ResourceGroupName: '$(RgName)'
              sourceSlot: 'staging'

• stage : DeployProduction – це визначає новий етап під назвою “DeployProduction”.
• displayName: ‘Deploy to Production Environment’ – це зрозуміла для людини назва цього етапу, яка відображається в інтерфейсі користувача.
• dependsOn: DeployTest – це означає, що етап “DeployProduction” залежить від етапу “DeployTest”. Він буде виконано, лише якщо етап “DeployTest” завершиться успішно.
• condition: succeeded(‘DeployTest’) – це умова, яка перевіряє, чи етап “DeployTest” завершився успішно.
• jobs: – цей розділ містить завдання для етапу “DeployProduction”
• deployment: DeployProductionJob – розгортання під назвою “DeployProductionJob”.
• environment: ‘ Production’ – це вказує, що буде розгорнуто в середовищі під назвою “Виробництво”.
• pool – це визначає пул агентів, який використовуватиметься для виконання завдання.
• strategy – цей розділ визначає стратегію розгортання. У цьому випадку стратегією є runOnce, що означає, що розгортання буде виконано один раз.
• Steps – цей розділ містить кроки, які будуть виконані як частина цього завдання.
• task: AzureAppServiceManage@0 – керує службою додатків Azure. У цьому випадку він використовується для того, щоб поміняти місцями проміжні та робочі слоти. Заміна слотів – це спосіб розгортання програм без простою.

Так як в нашому YAML ми використовуємо змінні, їх значення необхідно додати для цього pipeline. Щоб це зробити необхідно виконати наступні кроки:

• Згори, з правого боку натисніть на кнопку “Variables”.
• Натисніть кнопку “New variable”, щоб створити нову змінну конвеєра.
  • У поле Name введіть AzureSubscriptionName
  • У поле Value введіть назву вашого підключення до Azure
  • Ви можете зробити змінну секретною, перемкнувши перемикач “Keep this value secret”. Секретні змінні зашифровані та не відоюражуються в журналах.
  • Натисніть “Ok”, щоб зберегти змінну.
• Також же створити 2 змінні, а саме AppServiceName в якій буде зберігатись назва вашого App Service таRgName, яка зберігає назву ресурсної групи, в якій разгорнут App Serivce.
• Натисніть “ОК”, щоб зберегти змінні.

Після всіх змін треба натиснути Save and Run

Повну версію YAML файла ви можете знвайти тут