W nowym wpisie czas na kolejny etap: Pipelines (wcześniej nazywane Builds), czyli budowanie aplikacji. Zaczynamy!

Po kliknięciu przycisku „Create Pipeline”, przechodzimy do formularza:

Nasz kod jest na Azure DevOps, więc wybieramy opcję numer jeden. Ewentualnie moglibyśmy wybrać ostatnią opcję (Use the classic editor), żeby nie tworzyć pliku YAML. Ale YAML jest fajny, więc wybieramy opcję pierwszą: Azure Repos Git (YAML).

Następnie wybieramy repozytorium:

Kolejny krok to konfiguracja:

Tutaj mamy zagwozdkę, co zrobić? Aplikacja jest napisana z wykorzystaniem .NET Core. Wybierzmy więc opcję ASP.NET Core (.NET Framework).

Ostatni krok to weryfikacja utworzonego automatycznie pliku o formacie yml (YAML):

azure-pipelines.yml

Przeanalizujmy wygenerowaną treść pliku azure-pipelines.yml:

# ASP.NET Core (.NET Framework)
# Build and test ASP.NET Core projects targeting the full .NET Framework.
# Add steps that publish symbols, save build artifacts, and more:
# https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core

trigger:
- master

pool:
  vmImage: 'windows-latest'

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

steps:
- task: NuGetToolInstaller@1

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

- 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)'

- task: VSTest@2
  inputs:
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

Najpierw mamy komentarze, które opisują template i zawierają link do dokumentacji.

Trigger

trigger:
- master

Trigger, który definiuje, że po spushowaniu zmian do brancha master uruchomi się pipeline (build).

Pool

pool:
  vmImage: 'windows-latest'

Definicja środowiska wirtualnej maszyny, na której będzie wykonywany build. Domyślna wartość ‚windows-latest’ wskazuje na Windows Server 2019 with Visual Studio 2019 (dokumentacja).

Variables

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

Zmienne pipelinu. Domyślna konfiguracja to Release, platform Any CPU i plik solucji powinien znajdować się w podkatalogu i mieć rozszerzenie .sln.

Steps

Mamy 4 taski:

steps:
- task: NuGetToolInstaller@1

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

- 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)'

- task: VSTest@2
  inputs:
    platform: '$(buildPlatform)'
    configuration: '$(buildConfiguration)'

1. Instalacja nugeta
2. Restore pakietów z wykorzystaniem nugeta
3. Build solucji z odpowiednimi parametrami (część z nich została ustawiona w poprzedniej sekcji variables)
4. Uruchomienie testów

Spróbujmy zaufać ustawieniom domyślnym – zapiszmy i puścimy pipeline (przycisk po prawej u góry „Save and run”).

Automatycznie wyświetla się formularz tworzenia commita. Tak jest! Plik yml jest w repozytorium i wszelkie zmiany na nim robione (więc zmiany pipelinu) są traktowane jak zmiany w kodzie. Zapiszmy go i wykonajmy pierwszy build.

Wygląda to tak:

Możemy kliknąć w wiersz Job i zostaniemy przekierowani do szczegółów Joba:

Po paru minutach widać wynik:

Widzimy, że wszystko się udało (zielone ptaszki), poza taskiem VSTest (czerwony krzyżyk). Klikając w problematyczny wiersz możemy zobaczyć logi w konsoli. Tam możemy dojść do szczegółów błędu:

Wygląda na to, że tylko że jest jakiś problem z konfiguracją (komunikat błędu poniżej). Będzie trzeba to poprawić!

Unable to find d:\a\1\s\src\DevAdventCalendarCompetition\DevAdventCalendarCompetition.TestResultService.Tests\bin\Release\netcoreapp2.2\DevAdventCalendarCompetition.TestResultService.deps.json. Make sure test project has a nuget reference of package „Microsoft.NET.Test.Sdk”.

Dodatkowo jeśli wrócimy do podglądu całego pipelinu (strzałka wstecz u góry po lewej) zobaczymy pełną listę błędów:

Możemy przejść do edycji pipelinu:

Nasze testy są napisane w xUNIT, zmieńmy więc task i puśćmy je w inny sposób. W tym celu rozwińmy asystenta (przycisk „Show assistant” u góry po prawej)

I wybierzmy pierwszy task .NET Core:

Otwiera nam się specjalny formularz. Wypełnijmy go:

Chcemy wywołać task test na wszystkich projektach testowych: według konwencji powinny one się znajować w dowolnym podkatalogu i nazwa ich plików .csproj powinna kończyć się na Tests.

Po kliknięciu przycisku „Add” na dole po prawej doda nam się nowa sekcja do pliku YAML:

- task: DotNetCoreCLI@2
  inputs:
    command: 'test'
    projects: '**/*.Tests.csproj'

Usuńmy wcześniejszy task VSTest@2, zapiszmy zmiany i sprawdźmy, czy naprawiliśmy błąd.

Wygląda na to, że teraz wszystko działa! Gdy klikniemy link 100% tests z outputu, zostaniemy przekierowani do widoku szczegółowego testów:

Widać, że puszczono 36 testów, 100% przeszło. Ten widok jest szczególnie przydatny, gdy jakiś test się sypie i chcemy zobaczyć jego output z komunikatem błędu.

Kilka uwag

Jak widzicie, nazwy stepów w pipeline (np. VSTest@2) niewiele mówią. O wiele lepiej byłoby je odpowiednio nazwać 🙂

Dodatkowo testy powinny przejść automatycznie przy pierwszym podejściu, gdyby każdy z nich miał referencję do paczki „Microsoft.NET.Test.Sdk”.