Автоматическое управление номером версии c помощью Azure DevOps

В этой статье я расскажу, как мы организовали последовательное автоматическое увеличение номера версии приложения при выполнении коммита в ветку main с помощью Azure DevOps Pipeline.

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

Задача

В зависимости от архитектуры приложения номер версии может храниться в разных местах. Здесь я приведу пример приложения .NET Core, где номер версии находится в теге AssemblyVersion XML-файла проекта с расширением .csproj. По умолчанию этого тега в проекте нет, инициировать его добавление можно, установив в свойствах проекта его значение, например, 1.0.0.1.

В «классических» приложениях .NET Framework номер версии хранится в файле Properties\AssemblyInfo.cs. Этот уже не XML-файл. Способ поиска и редактирования нужного тега будет несколько отличаться.

При работе с git-репозиторием мы используем trunk-подход, описанный здесь: trunkbaseddevelopment.com. В рамках этого подхода, в отличие от GitFlow, разработчики создают ветки с коротким жизненным циклом от основной ветки main. Эту методологию, в частности, продвигает и Microsoft, мы используем слегка упрощенный подход по сравнению с их Release Flow, описанным в этой статье.

В нашем случае в ветку main код попадает в результате пул-реквестов, но без контрольной автоматической сборки. Поэтому мы запускаем CI-сборку сразу после коммита в мастер. Нам требуется, чтобы, в случае успешного завершения этой сборки, увеличивалась бы последняя цифра в номере версии приложения в AssemblyVersion. Например, было 1.3.4.15, стало 1.3.4.16.

Решение

Сценарий пайплайна в общих чертах выглядит так:

1. Получить содержимое ветки main.

2. Обновить номер версии с помощью PowerShell-скрипта. Для этого на агенте необходимо создать новую ветку. Мы будем делать все изменения в этой ветке, использовать ее для сборки и потом будет объединять ее с веткой main. Эта ветка останется локальной, она не будет отправляться в серверный репозиторий. В конце процесса мы ее удалим.

3. Выполнить сборку.

4. Если сборка прошла успешно, обновить номер версии в репозитории также с помощью PowerShell-скрипта.

Стоит упомянуть несколько важных моментов.

• С момента получения содержимого ветки main и до окончания сборки в ветку main могут попасть новые коммиты. По этой причине Azure-агент получает не содержимое ветки, а конкретный коммит. После получения кода репозиторий становится со "сдвинутой головой" (HEAD detached). Именно поэтому и надо обновлять номер версии в отдельной ветке.

• Azure-агент, который будет обновлять репозиторий, должен в нем дополнительно авторизоваться. Для этого понадобится на уровне пайплайна сохранить персональный ключ доступа (PAT) одного из авторизованных пользователей. Это значение является секретным и должно соответствующим образом сохраняться. Оно будет использоваться при отправке коммита через HTTPS.

• Чтобы не "возбуждать" CI-сборку при попадании нового номера версии в main, при выполнении коммита необходимо в комментарии указать [skip ci].

Реализация

Мы создаем CI-сборку, которая должна запускаться автоматически после того, как код попадает в ветку main. Поэтому скрипт пайплайна начинается с фразы:

trigger:
- main

Далее следует стандартный блок выбора агента, установки базовых переменных и обновления nuget-пакетов:

Pool:
  vmImage: 'windows-latest'

variables:
  solution: '**/*.sln'
  buildPlatform: 'Any CPU'
  buildConfiguration: 'Release'

steps:
- task: NuGetToolInstaller@1
- task: NuGetCommand@2
  inputs:
    restoreSolution: '$(solution)'

Теперь, когда агент получил из репозитория свежее содержимое ветки main, выполняем PoweShell-скрипт.

- task: PowerShell@2
  displayName: 'Assembly Version Generation'
  # первая часть – увеличение номера версии
  # если сборка падает, новый номер версии не сохраняется в репозитории
  inputs:
    targetType: 'inline'
    script: |

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

Опция --quiet при вызове git указывается, чтобы пайплайн не воспринимал служебные сообщения от git как сообщения об ошибках и не останавливал процесс.

          # имя XML-файла проекта, в который будут вноситься изменения
          $ProjectFile = '.\azure-devops-versioning\azure-devops-versioning.csproj'  

          # создаем новую ветку
          git branch DevOps/test_$(Build.BuildNumber) –quiet        
          # переключаемся в новую ветку
          git checkout DevOps/test_$(Build.BuildNumber) –quiet    

          # ищем строку, содержащую тег <AssemblyVersion>
          foreach($line in Get-Content -Path $ProjectFile) 
          {$AssemblyVersionLine = $line | Select-String -Pattern '<AssemblyVersion>' -CaseSensitive
           if ($AssemblyVersionLine) {break} 
          }

          # ищем номер версии в строке через операцию -match
          $AssemblyVersionLine -match ('(<AssemblyVersion>)(.+)(</AssemblyVersion>)$')    
          # получаем строку версии
          $Version = $Matches[2]
          #  разбиваем строку на массив
          $VerParts = $Version.split('.')
          # получаем последнюю часть массива и увеличиваем на 1
          $VerParts[3] = ([int]$VerParts[3] + 1)
          # собираем обратно в строку через точку
          $NewVersion = $VerParts -join '.'
          # получаем новую строку с тегом <AssemblyVersion> и новым номером версии
          $NewAssemblyVersionLine = $AssemblyVersionLine -replace $Version, $NewVersion    

          # заменяем старую строку с тегом <AssemblyVersion> на новую
          (Get-Content $ProjectFile) | Foreach-Object { $_ -replace $AssemblyVersionLine, $NewAssemblyVersionLine } | Set-Content $ProjectFile        

          # вводим информацию о пользователе-агенте
          git config user.email "azure.agent@profinfotech.ru"
          git config user.name "Azure Agent"
          # индексируем измененный файл
          git add $ProjectFile
          # фиксируем изменения в локальном репозитории с комментарием
          git commit -m "[skip ci] Pipeline Modification: AssemblyVersion = $NewVersion"         

В этом скрипте мы создали новую локальную ветку с использованием номера билда, который в Azure DevOps является уникальным. То есть, при каждой CI-сборке на агенте будет создаваться новая локальная ветка. Мы переключились на эту новую ветку, нашли нужный файл и заменили в нем AssemblyVersion, увеличив последний номер на 1. Мы сделали коммит в локальный репозиторий и запускаем сборку с помощью стандартного блока:

- task: VSBuild@1
  inputs:
    solution: '$(solution)'
    msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

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

Если же сборка завершилась успешно, мы запускаем PowerShell-скрипт.

- task: PowerShell@2
  displayName: 'Send new version to main'
      # вторая часть – после успешной сборки новая версия отправляется в серверный репозиторий
  inputs:
    targetType: 'inline'
    script: |

Этот скрипт переключит нас в main, получит обновление main, объединит нашу ветку с веткой main, удалит нашу ветку и сделает push в центральный репозиторий, авторизовавшись с помощью PAT-токена:

          # переключаемся на ветку main
          git checkout main –quiet
          # обновляем локальную ветку main
          git pull –quiet

          # объединяем нашу ветку с веткой main, в комментарии указываем номер версии
          git merge DevOps/test_$(Build.BuildNumber) -m "[skip ci] Pipeline Modification: AssemblyVersion = $NewVersion" –quiet
         
          # удаляем локальную ветку
          git branch -d DevOps/test_$(Build.BuildNumber)

          # отправляем локальную ветку main в серверный репозиторий
          # PAToken – это переменная пайплайна, содержащая значение персонального ключа
          git push https://kanailov:$(PAToken)@github.com/Kanailov/azure-devops-versioning.git main –quiet

В приведенном примере git-репозиторий находится в GitHub. В том случае, если используется git-репозиторий, встроенный в Azure DevOps, формат HTTPS-запроса немного отличается:

git push https://Personal%20Access%20Token:$(PAToken)@<URL_git-репозитория> main --quiet

Ссылка

Пример проекта выложен на Github. В репозитории находится yml-скрипт azure-pipelines.yml.