Сборка, тестирование и развертывание приложений .NET Core


Отправка кода

Upload код в новый GitHub webapp или Azure Repos:

Вход в Azure Pipelines

Войдите в Azure Pipelines. После входа в браузере откроется https://dev.azure.com/my-organization-name и отобразится панель мониторинга Azure DevOps.

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

Создание конвейера

  1. Войдите в свою организацию Azure DevOps и откройте нужный проект.

  2. перейдите в Pipelines, а затем выберите создать конвейер.

  3. Пройдите через шаги мастера, выбрав GitHub в качестве расположения исходного кода.

  4. Возможно, вам придется выполнить вход в GitHub. Для этого введите учетные данные GitHub.

  5. Когда появится список репозиториев, выберите свой репозиторий.

  6. Возможно, вы перейдете на сайт GitHub, чтобы установить приложение Azure Pipelines. Если да, выберите утвердить установку.

Когда появится вкладка Настройка , выберите ASP.NET Core.

  1. Когда появится новый конвейер, Взгляните на YAML, чтобы увидеть, что он делает. Когда будете готовы, выберите сохранить и запустить.

    Кнопка

  2. Вам будет предложено зафиксировать новый файл Азуре-пипелинес. yml в репозитории. Когда вы будете рады с сообщением, выберите сохранить и запустить еще раз.

    Если вы хотите просмотреть конвейер в действии, выберите Задание сборки.

    вы только что создали и запустили конвейер, который мы создали автоматически, потому что ваш код хорошо подходит для шаблона ASP.NET Core .

    Теперь у вас есть рабочий конвейер YAML ( azure-pipelines.yml ) в репозитории, который готов к настройке.

  3. когда вы будете готовы внести изменения в конвейер, выберите его на странице Pipelines , а затем измените файл.

  4. В разделах ниже приведены некоторые из наиболее распространенных способов настройки конвейера.

YAML

  1. Добавьте azure-pipelines.yml файл в репозиторий. Настройте этот фрагмент кода для сборки.
trigger:
- master

pool: Default

variables:
  buildConfiguration: 'Release'

# do this before all your .NET Core tasks
steps:
- task: DotNetCoreInstaller@2
  inputs:
    version: '2.2.402' # replace this value with the version that you need for your project
- script: dotnet build --configuration $(buildConfiguration)
  displayName: 'dotnet build $(buildConfiguration)'
  1. Создайте конвейер (если вы не умеете, см. раздел Создание первого конвейера) и для шаблона выберите YAML.

  2. Задайте Пул агентов и путь к файлу YAML для конвейера.

  3. Сохраните конвейер и постройте в очередь сборку. Когда появится сообщение в очереди сборки #nnnnnnnn. n , щелкните ссылку Number (номер), чтобы увидеть конвейер в действии.

  4. Когда вы будете готовы внести изменения в конвейер, измените его.

  5. В разделах ниже приведены некоторые из наиболее распространенных способов настройки конвейера.

Классическая

  1. Создание конвейера (если вы не узнаете, как это сделать, см. статью Создание первого конвейера). Выберите пустой конвейер для шаблона.

  2. В каталоге задач найдите и добавьте задачу .NET Core . Эта задача будет выполнена dotnet build для сборки кода в примере репозитория.

  3. Сохраните конвейер и постройте в очередь сборку. Когда появится сообщение в очереди сборки #nnnnnnnn. n , щелкните ссылку Number (номер), чтобы увидеть конвейер в действии.

    Теперь у вас есть рабочий конвейер, готовый для настройки!

  4. Когда вы будете готовы внести изменения в конвейер, измените его.

  5. В разделах ниже приведены некоторые из наиболее распространенных способов настройки конвейера.

Среда сборки

используйте Azure Pipelines для создания проектов .net Core на Windows, Linux или macOS без необходимости настраивать собственную инфраструктуру. агенты, размещенные корпорацией майкрософт в Azure Pipelines, включают несколько выпущенных версий пакетов sdk для .net Core.

Ubuntu 18,04 задается здесь в файле YAML.

pool:
  vmImage: 'ubuntu-18.04' # examples of other options: 'macOS-10.15', 'windows-2019'

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

Агенты, размещенные корпорацией Майкрософт, не включают некоторые из старых версий пакет SDK для .NET Core. Они также обычно не включают предварительные версии. Если вам нужны эти пакеты SDK на агентах, размещенных в корпорации Майкрософт, добавьте задачу UseDotNet@2 в файл YAML.

Чтобы установить предварительную версию пакета SDK 5.0. x для создания и 3.0. x для выполнения тестов, предназначенных для .NET Core 3.0. x, добавьте следующий фрагмент кода:

steps:
- task: UseDotNet@2
  inputs:
    version: '5.0.x'
    includePreviewVersions: true # Required for preview versions

- task: UseDotNet@2
  inputs:
    version: '3.0.x'
    packageType: runtime

Windows агенты уже включают среду выполнения .net Core. Чтобы установить более новый пакет SDK, задайте performMultiLevelLookup для значение true в следующем фрагменте кода:

steps:
- task: UseDotNet@2
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 5.0.x
    performMultiLevelLookup: true
    includePreviewVersions: true # Required for preview versions

Совет

В качестве альтернативы можно настроить самостоятельно размещенный агент и снизить затраты на запуск установщика средств. См. раздел Linux, MacOSили Windows. Можно также использовать собственные агенты, чтобы сэкономить время при наличии большого репозитория или при выполнении добавочных сборок. саморазмещенный агент также может помочь в использовании предварительной версии или частных пакетов sdk, которые не поддерживаются Azure DevOps или доступны только в корпоративных или локальных средах.

вы можете создавать проекты .net Core с помощью пакет SDK для .NET Core и среды выполнения на Windows, Linux или macOS. Сборки выполняются на собственном агенте. Убедитесь, что на агенте установлена необходимая версия пакет SDK для .NET Core и среды выполнения.

Восстановить зависимости

NuGet — это популярный способ зависеть от кода, который вы не создаете. вы можете скачать NuGet пакеты и средства для конкретных проектов, указанные в файле проекта, выполнив dotnet restore команду либо с помощью задачи dotnet restore , либо непосредственно в скрипте в конвейере.

пакеты NuGet можно скачать из Azure Artifacts, NuGet. org или другого внешнего или внутреннего репозитория NuGet. задача .net Core особенно полезна для восстановления пакетов из NuGet каналов, прошедших проверку подлинности.

В этом конвейере dotnet restore в dotnet restoreиспользуется веб-канал артефактов.

trigger:
- master

pool:
  vmImage: 'windows-latest'

variables:
  buildConfiguration: 'Release'

steps:
- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    feedsToUse: 'select'
    vstsFeed: 'my-vsts-feed' # A series of numbers and letters

- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    arguments: '--configuration $(buildConfiguration)'
  displayName: 'dotnet build $(buildConfiguration)'

пакеты NuGet можно скачать из NuGet. org.

dotnet restore внутренне использует версию NuGet.exe , упакованную с пакет SDK для .NET Core. dotnet restore может восстанавливать только пакеты, указанные в файлах проекта .NET Core .csproj . если в решении также имеется проект Microsoft платформа .NET Framework или используется package.json для указания зависимостей, необходимо также использовать задачу package.json для восстановления этих зависимостей.

В пакет SDK для .NET Core версии 2,0 и более поздних пакеты восстанавливаются автоматически при выполнении других команд, таких как dotnet build .

В пакет SDK для .NET Core версии 2,0 и более поздних пакеты восстанавливаются автоматически при выполнении других команд, таких как dotnet build . Однако при использовании веб-канала с проверкой подлинности может потребоваться восстановление пакетов с помощью задачи .NET Core .

если сборки периодически завершаются сбоем при восстановлении пакетов из NuGet. org из-за проблем с подключением, можно использовать Azure Artifacts с вышестоящими источниками и кэшировать пакеты. Учетные данные конвейера автоматически используются при подключении к Azure Artifacts. эти учетные данные обычно являются производными от учетной записи службы сборки Project Collection .

если вы хотите указать репозиторий NuGet, вставьте url-адреса в NuGet.config файл в репозитории. если веб-канал прошел проверку подлинности, управление учетными данными осуществляется путем создания подключения NuGet службы на вкладке " службы " в разделе Project Параметры.

Если вы используете агенты, размещенные в Майкрософт, при каждом запуске сборки вы получаете новый компьютер, что означает восстановление пакетов каждый раз. Это восстановление может занять значительное время. чтобы устранить эту ошибку, можно использовать либо Azure Artifacts, либо локально размещенный агент. в этом случае вы получаете преимущество использования кэша пакетов.

Чтобы восстановить пакеты из внешнего пользовательского веб-канала, используйте задачу .NET Core :

# do this before your build tasks
steps:
- task: DotNetCoreCLI@2
  displayName: Restore
  inputs:
    command: restore
    projects: '**/*.csproj'
    feedsToUse: config
    nugetConfigPath: NuGet.config    # Relative to root of the repository
    externalFeedCredentials: <Name of the NuGet service connection>
# ...

дополнительные сведения о подключении к службам NuGet см. в статье публикация в NuGet веб-каналах.

  1. Выберите задачи в конвейере. Выберите задание, которое выполняет задачи сборки. Затем выберите + , чтобы добавить в задание новую задачу.

  2. В каталоге задач найдите и добавьте задачу .NET Core .

  3. Выберите задачу и, для команды, выберите восстановить.

  4. Укажите любые другие параметры, необходимые для этой задачи. Затем сохраните сборку.

Примечание

убедитесь, что пользовательский веб-канал указан в NuGet.config файле и что учетные данные указаны в подключении к службе NuGet.

Сборка проекта

Чтобы создать проект .NET Core, можно выполнить dotnet build команду в конвейере или с помощью задачи .NET Core.

Чтобы выполнить сборку проекта с помощью задачи .NET Core, добавьте в файл следующий фрагмент azure-pipelines.yml :

steps:
- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    command: build
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)' # Update this to match your need

В конвейере можно выполнить любую пользовательскую команду DotNet. В следующем примере показано, как установить и использовать глобальное средство .NET дотнетсай:

steps:
- task: DotNetCoreCLI@2
  displayName: 'Install dotnetsay'
  inputs:
    command: custom
    custom: tool
    arguments: 'install -g dotnetsay'

Сборка

  1. Выберите задачи в конвейере. Выберите задание, которое выполняет задачи сборки. Затем выберите + , чтобы добавить в задание новую задачу.

  2. В каталоге задач найдите и добавьте задачу .NET Core .

  3. Выберите задачу и, для команды, выберите Сборка или опубликовать.

  4. Укажите любые другие параметры, необходимые для этой задачи. Затем сохраните сборку.

Установка средства

чтобы установить глобальное средство .net Core, например дотнетсай , в сборку, работающую на Windows, выполните следующие действия.

  1. Добавьте задачу .NET Core и задайте следующие свойства:

    • Команда: Custom.
      • Путь к проектам: оставьте пустым.
    • Пользовательская команда: инструмент.
    • Аргументы: .
  2. Добавьте задачу командной строки и задайте следующие свойства:

    • Скрипт: .

Выполнение тестов

Если в репозитории имеются тестовые проекты, используйте задачу .NET Core для выполнения модульных тестов с помощью таких платформ тестирования, как MSTest, xUnit и NUnit. Для этой функции тестовый проект должен ссылаться на Microsoft. NET. Test. SDK версии 15.8.0 или более поздней. Результаты теста автоматически публикуются в службе. Затем эти результаты становятся доступными в сводке сборки и могут использоваться для устранения неудачных тестов и анализа времени тестирования.

Добавьте следующий фрагмент кода в azure-pipelines.yml файл:

steps:
# ...
# do this after other tasks such as building
- task: DotNetCoreCLI@2
  inputs:
    command: test
    projects: '**/*Tests/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

В качестве альтернативы можно выполнить dotnet test команду с конкретным средством ведения журнала, а затем использовать задачу dotnet test .

steps:
# ...
# do this after your tests have run
- script: dotnet test <test-project> --logger trx
- task: PublishTestResults@2
  condition: succeededOrFailed()
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'

Используйте задачу .NET Core с набором команд для проверки. Путь к проектам должен ссылаться на тестовые проекты в решении.

Получение покрытия кода

при построении на Windowsной платформе метрики покрытия кода можно собирать с помощью встроенного сборщика данных о покрытии. Для этой функции тестовый проект должен ссылаться на Microsoft. NET. Test. SDK версии 15.8.0 или более поздней. При использовании задачи .NET Core для выполнения тестов данные о покрытии автоматически публикуются на сервере. Coverage – файл можно скачать из сводки по сборке для просмотра в Visual Studio.

Добавьте следующий фрагмент кода в azure-pipelines.yml файл:

steps:
# ...
# do this after other tasks such as building
- task: DotNetCoreCLI@2
  inputs:
    command: test
    projects: '**/*Tests/*.csproj'
    arguments: '--configuration $(buildConfiguration) --collect "Code coverage"'

Если вы решили выполнить dotnet test команду, укажите средства ведения журнала результатов теста и параметры покрытия. Затем используйте задачу « публикация результаты теста :

steps:
# ...
# do this after your tests have run
- script: dotnet test <test-project> --logger trx --collect "Code coverage"
- task: PublishTestResults@2
  inputs:
    testRunner: VSTest
    testResultsFiles: '**/*.trx'
  1. Добавьте задачу .NET Core в задание сборки и задайте следующие свойства:

    • Команда: Test.
    • Путь к проектам: должен ссылаться на тестовые проекты в решении.
    • Аргументы: .
  2. Убедитесь, что параметр опубликовать результаты теста остается выбранным.

Получение метрик покрытия кода с помощью Коверлет

При создании в Linux или macOS можно использовать коверлет или аналогичное средство для сбора метрик покрытия кода.

Результаты покрытия кода можно опубликовать на сервере с помощью задачи " опубликовать результаты покрытия кода ". Чтобы использовать эту функцию, средство покрытия должно быть настроено для создания результатов в формате покрытия Cobertura или JaCoCo.

Чтобы запустить тесты и опубликовать покрытие кода с помощью Коверлет, выполните следующие действия.

  • добавьте ссылку на coverlet.msbuild пакет NuGet в тестовых проектах для проектов .net ниже .net 5. для .net 5 добавьте ссылку на coverlet.collector пакет NuGet.
  • Добавьте этот фрагмент в azure-pipelines.yml файл:
- task: UseDotNet@2
  inputs:
    version: '5.0.x'
    includePreviewVersions: true # Required for preview versions
  
- task: DotNetCoreCLI@2
  displayName: 'dotnet build'
  inputs:
    command: 'build'
    configuration: $(buildConfiguration)
  
- task: DotNetCoreCLI@2
  displayName: 'dotnet test'
  inputs:
    command: 'test'
    arguments: '--configuration $(buildConfiguration) --collect:"XPlat Code Coverage" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=cobertura'
    publishTestResults: true
    projects: 'MyTestLibrary' # update with your test project directory
  
- task: PublishCodeCoverageResults@1
  displayName: 'Publish code coverage report'
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

Упаковка и доставка кода

после сборки и тестирования приложения можно передать выходные данные сборки в Azure Pipelines или TFS, создать и опубликовать NuGet пакет или упаковать выходные данные сборки в файл .zip, который будет развернут в веб-приложении.

Публикация артефактов в Azure Pipelines

Чтобы опубликовать выходные данные сборки.NET,

  • Выполните dotnet publish --output $(Build.ArtifactStagingDirectory) команду на CLI или добавьте задачу DotNetCoreCLI@2 с помощью команды Publish.
  • Опубликуйте артефакт с помощью задачи «публикация артефакта».

Добавьте следующий фрагмент кода в azure-pipelines.yml файл:

steps:

- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)' 
    artifactName: 'myWebsiteName'

Примечание

dotNetCoreCLI@2Задача имеет publishWebProjects входные данные, для которых по умолчанию задано dotNetCoreCLI@2 . По умолчанию все веб-проекты в репозитории публикуются. Дополнительную справку и сведения можно найти в задаче с открытым исходным кодом на GitHub.

Чтобы скопировать дополнительные файлы в каталог сборки перед публикацией, используйте служебную программу: Copy Files.

публикация в веб-канале NuGet

чтобы создать и опубликовать пакет NuGet, добавьте следующий фрагмент кода:

steps:
# ...
# do this near the end of your pipeline in most cases
- script: dotnet pack /p:PackageVersion=$(version)  # define version variable elsewhere in your pipeline
- task: NuGetAuthenticate@0
  input:
    nuGetServiceConnections: '<Name of the NuGet service connection>'
- task: NuGetCommand@2
  inputs:
    command: push
    nuGetFeedType: external
    publishFeedCredentials: '<Name of the NuGet service connection>'
    versioningScheme: byEnvVar
    versionEnvVar: version

дополнительные сведения об управлении версиями и публикации пакетов NuGet см. в разделе publish to NuGet feeds.

Развертывание веб-приложения

Чтобы создать .zip файлового архива, готового к публикации в веб-приложении, добавьте следующий фрагмент кода:

steps:
# ...
# do this after you've built your app, near the end of your pipeline in most cases
# for example, you do this before you deploy to an Azure web app on Windows
- task: DotNetCoreCLI@2
  inputs:
    command: publish
    publishWebProjects: True
    arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
    zipAfterPublish: True

Сведения о публикации этого архива в веб-приложении см. в статье Развертывание веб-приложений Azure.

Публикация артефактов в Azure Pipelines

используйте задачу publish Artifacts , чтобы опубликовать выходные данные сборки в Azure Pipelines или TFS.

публикация в веб-канале NuGet

если вы хотите опубликовать код в NuGet веб-канале, выполните следующие действия.

  1. Используйте задачу .NET Core с набором команд "Pack".

  2. опубликуйте пакет в веб-канале NuGet.

Развертывание веб-приложения

  1. Используйте задачу .NET Core с набором команд для публикации.

  2. Убедитесь, что выбран параметр создания .zip файлового архива.

  3. Сведения о публикации этого архива в веб-приложении см. в статье Развертывание веб-приложений Azure.

Создание образа и отправка в реестр контейнеров

Для приложения можно также создать образ и отправить его в реестр контейнеров.

Устранение неполадок

если вы можете создать проект на компьютере разработки, но у вас возникли проблемы при его создании на Azure Pipelines или TFS, изучите следующие возможные причины и действия по исправлению:

  • Мы не устанавливаем предварительные версии пакет SDK для .NET Core на агентах, размещенных в Майкрософт. после выпуска новой версии пакет SDK для .NET Core может пройти несколько недель, чтобы выполнить ее развертывание во всех центрах обработки данных, которые Azure Pipelines. Вам не нужно ждать завершения этого развертывания. Установщик средств .NET Coreможно использовать, как описано в этом руководстве, чтобы установить требуемую версию пакет SDK для .NET Core на агентах, размещенных в корпорации Майкрософт.
  • Убедитесь, что версии пакет SDK для .NET Core и среды выполнения на компьютере разработки соответствуют агентам. dotnet --versionЧтобы напечатать версию пакет SDK для .NET Core, можно включить в конвейер сценарий командной строки. Либо используйте установщик средств .NET Core, как описано в этом руководстве, чтобы развернуть ту же версию на агенте, или обновите проекты и компьютер разработки до более новой версии пакет SDK для .NET Core.

  • возможно, вы используете в Visual Studio IDE некоторую логику, которая не кодируется в конвейере. Azure Pipelines или TFS выполняет каждую из команд, указанных в задачах один за другим в новом процессе. просмотрите журналы из Azure Pipelines или сборки TFS, чтобы просмотреть точные команды, которые выполнялись как часть сборки. Повторите те же команды в том же порядке, что и на компьютере разработки, и нахождение проблемы.

  • при наличии смешанного решения, включающего некоторые проекты .net Core и некоторые платформа .NET Framework проекты, следует также использовать задачу NuGet для восстановления пакетов, указанных в файлах. аналогичным образом необходимо добавить MSBuild или Visual Studio задач сборки для построения проектов платформа .NET Framework.

  • если при восстановлении пакетов произошел сбой при временной ошибке сборки, то NuGet. org испытывает проблемы или возникают сетевые проблемы между центром обработки данных Azure и NuGet. org. они не управляются нашим элементом управления, и вам может потребоваться узнать, используете ли Azure Artifacts с NuGet. org в качестве вышестоящего источника, что повышает надежность сборок.

  • иногда при обновлении размещенных образов до новой версии пакет SDK для .NET Core или Visual Studio что-то может нарушить сборку. это может произойти, например, если в пакет SDK поставляется более новая версия или компонент средства NuGet. Чтобы изолировать эти проблемы, используйте задачу установщика средств .NET Core , чтобы указать версию пакет SDK для .NET Core, используемую в сборке.

Вопросы и ответы

где можно узнать больше о Azure Artifacts и службе Управление пакетами TFS?

Управление пакетами в Azure Artifacts и TFS

Где можно узнать больше о командах .NET Core?

Средства .NET Core CLI

Где можно узнать больше о запуске тестов в моем решении?

Модульное тестирование в проектах .NET Core

Где можно узнать больше о задачах?

Задачи сборки и выпуска

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | Team Foundation Server 2018 | Team Foundation Server 2017

Используйте конвейер для автоматической сборки и тестирования проектов .NET Core. Вы узнаете, как выполнять следующие задачи:

Примечание

справку по платформа .NET Framework проектам см. в разделе сборка ASP.NET приложений с помощью платформа .NET Framework.

Примечание

В Microsoft Team Foundation Server (TFS) 2018 и предыдущих версий конвейеры сборки и выпуска называются определениями, выполнения называются сборками, подключения к службам называются конечными точками служб, этапы называются средами, а задания называются этапами.

Примечание

Это руководство относится к TFS версии 2017,3 и более поздним версиям.

Создание первого конвейера

Вы не знакомы с Azure Pipelines? Если да, то рекомендуется использовать этот раздел перед переходом к другим разделам.

Создание проекта .NET

если у вас нет проекта .net для работы, создайте новый и отправьте код в репозиторий GitHub или Azure Repos. Начните с установки последнего пакета SDK для .net 6,0.

Создайте новый webapp .NET 6.

dotnet new webapp -f net6.0

В том же сеансе терминала запустите приложение локально с помощью dotnet run команды из каталога проекта.

dotnet run