Я пришел из GitLab и его .gitlab-ci.yml, и я экспериментирую с многоступенчатыми конвейерами Azure DevOps, но я совершенно не понимаю, как это работает и какова лучшая стратегия даже после прочтения нескольких статей документации на https://docs.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops
Пожалуйста, позвольте мне задать несколько связанных вопросов для базового сценария, который я пробую: скомпилировать, запустить модульные тесты, упаковать пакет nuget для всего решения (он может содержать несколько проектов/ nuGet packages) и опубликуйте пакет в канале nuGet (если ветвь является master, версия выпуска, в противном случае - версия перед выпуском). Это хранилище, из которого я беру код: https://github.com/sasw-diego/sasw-test-support Это сгенерирует только пакет nuGet, но у меня есть другие мультипроектные решения, которые должны генерировать много пакетов nuGet
Это мой azure-pipelines.yml
на данный момент:
trigger:
- master
- feature/*
pool:
vmImage: ubuntu-latest
variables:
NUGET_FOLDER_NAME: nupkgs
NUGET_REPOSITORY: https://whatever
PRERELEASE_SUFFIX: $(Build.BuildId)
PIPELINE_ARTIFACT_NAME: $(Build.BuildNumber)
stages:
- stage:
displayName: 'Build'
jobs:
- job: 'Build'
steps:
- task: NuGetAuthenticate@0
displayName: 'Authenticate in NuGet feed'
- script: dotnet restore --no-cache --force
displayName: 'Restore dependencies'
- script: dotnet build --configuration Release --no-restore
displayName: 'Build for Release'
- script: ls $(System.DefaultWorkingDirectory)
displayName: 'List content'
- publish: $(System.DefaultWorkingDirectory)
artifact: $(PIPELINE_ARTIFACT_NAME)
- stage:
displayName: 'Automated Tests'
condition: succeeded()
jobs:
- job:
displayName: 'Unit Tests'
steps:
- download: current
artifact: $(PIPELINE_ARTIFACT_NAME)
- script: ls -a
displayName: 'View'
- script: ls ./test
displayName: 'View test'
- script: ls ./test/Sasw.TestSupport.UnitTests
displayName: 'View folder'
- script: dotnet vstest test/*UnitTests/bin/Release/**/*UnitTests.dll
displayName: 'Run unit tests'
- stage:
displayName: 'NuGet Package'
condition: succeeded()
jobs:
- job:
displayName: 'Pack Preview Version'
condition: ne(variables['Build.SourceBranch'], 'refs/heads/master')
steps:
- script: dotnet pack *.sln --configuration Release --output $(NUGET_FOLDER_NAME)
displayName: 'Pack'
- job:
displayName: 'Pack Stable Version'
condition: eq(variables['Build.SourceBranch'], 'refs/heads/master')
steps:
- script: dotnet pack *.sln --configuration Release --output $(NUGET_FOLDER_NAME) --version-suffix $(PRERELEASE_SUFFIX) --include-source --include-symbols -p:SymbolPackageFormat=snupkg
displayName: 'Pack'
- Какая "лучшая" стратегия для многоступенчатой? Я вижу, что в конвейерах Azure DevOps есть концепция Stage> Jobs> Task, но все онипохожи на меня. Поэтому я решил разделить процесс на этапы, такие как
Build - AutomatedTests - NuGet Package - Publish
Как вы можете видеть, это последовательный процесс, в котором каждому этапу нужно что-то из предыдущего. Автоматизированным тестам нужен встроенный код (dll), пакету nuGet также необходим доступ к встроенному коду, публикации нужен доступ к сгенерированному nupkg и т. Д. Я не знаю, нормально ли следовать этой стратегии или лучше иметьодин этап с несколькими заданиями или даже одно задание с несколькими заданиями. Как я уже сказал, я не совсем понимаю, насколько полезно иметь такое количество концепций и как они соответствуют моим потребностям. - Предполагается ли, что многоступенчатые конвейеры Azure заменят старую версию Build и Release как отдельные концепции? Для меня имеет смысл иметь CI / CD в одном месте с многоэтапным подходом и сценариями, чтобы сделать его версионным в репозитории контроля версий. Но я все еще рассматриваю концепцию Release как отдельную концепцию в настоящее время в DevOps Azure. Так что, вероятно, мне следует использовать лазурные конвейеры yml до тех пор, пока пакет не «шагнет», а затем с помощью Release перейдите, возьмите этот nupkg и опубликуйте его в каком-то канале. Не уверен, какая польза будет от этого.
- У меня проблемы с выводом этапа в качестве ввода следующего, и, возможно, это из-за того, что я не до конца его понимаю. В приведенном выше сообщении этап сборки завершается успешно , но этап автоматического тестирования завершается с ошибкой при выполнении задания Run Unit Tests с ошибкой
No test source files were specified
. Я подтвердил, что это происходит, потому что нет сгенерированной папки bin
вообще. Это кажется странным, так как я копирую все с предыдущего этапа (а предыдущий этап генерировал папки bin с помощью dll), но затем на следующем этапе, несмотря на возможность загрузки всего, он не может найти тесты.
Это журнал для этапа, который не проходит: https://gist.github.com/sasw-diego/df66eccf71bbfc044a4d72be96268c9a
Было бы очень полезно, если бы кто-то заметил, что мне не хватает, чтобы понять этот процесс. Любая ссылка, чтобы уточнить все эти понятия будет высоко ценится. Ta
PS: Это аналогичный универсальный CI / CD, который у меня был в GitLab для загрузки 1 или нескольких nuGets в канал: https://gist.github.com/sasw-diego/bf46258cb1ad0aa5241e8d1866b53f48