Ćwiczenie — publikowanie wyniku w potoku

10 min

W tym momencie możesz utworzyć projekt internetowy Space Game za pomocą potoku.

Ale gdzie idą wyniki kompilacji? W tej chwili dane wyjściowe kompilacji pozostają na tymczasowym serwerze kompilacji. Mara potrzebuje sposobu, aby przekazać tę kompilację Amita, aby mogła rozpocząć testowanie.

Artefakty kompilacji można przechowywać w usłudze Azure Pipelines, aby później były dostępne dla innych osób w zespole po zakończeniu kompilacji. To, co zrobisz tutaj. Dodatkowo refaktoryzujesz również konfigurację kompilacji, aby używać zmiennych, aby ułatwić odczytywanie i aktualizowanie konfiguracji.

Uwaga

Usługa Azure Pipelines umożliwia automatyczne wdrażanie wbudowanej aplikacji w środowisku testowym lub produkcyjnym uruchomionym w chmurze lub w centrum danych. Na razie celem Mary jest tylko tworzenie kompilacji, które może przekazać kontroli jakości przy użyciu istniejących procesów.

Publikowanie kompilacji w potoku

Na platformie .NET możesz spakować aplikację jako plik zip. Następnie możesz użyć wbudowanego PublishBuildArtifacts@1 zadania, aby opublikować plik zip w usłudze Azure Pipelines.

W programie Visual Studio Code zmień plik azure-pipelines.yml , jak pokazano tutaj:

trigger:
- '*'

pool:
  name: 'Default' #replace if needed with name of your agent pool

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK 6.x'
  inputs:
    version: '6.x'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass Tailspin.SpaceGame.Web/wwwroot --output Tailspin.SpaceGame.Web/wwwroot'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: Tailspin.SpaceGame.Web/wwwroot

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

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

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - Release'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration Release --output $(Build.ArtifactStagingDirectory)/Release'
    zipAfterPublish: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

trigger:
- '*'

pool:
  vmImage: ubuntu-latest

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK 6.x'
  inputs:
    version: '6.x'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass Tailspin.SpaceGame.Web/wwwroot --output Tailspin.SpaceGame.Web/wwwroot'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: Tailspin.SpaceGame.Web/wwwroot

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

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

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - Release'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration Release --output $(Build.ArtifactStagingDirectory)/Release'
    zipAfterPublish: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

Ta wersja pliku azure-pipelines.yml wygląda jak poprzednia wersja, ale dodaje dwa dodatkowe zadania.

Pierwsze zadanie używa DotNetCoreCLI@2 zadania do publikowania lub tworzenia pakietów wyników kompilacji aplikacji (w tym jej zależności) w folderze. Argument zipAfterPublish określa, aby dodać skompilowane wyniki do pliku zip.

Drugie zadanie używa PublishBuildArtifacts@1 zadania do opublikowania pliku zip w usłudze Azure Pipelines. condition Argument określa, aby uruchomić zadanie tylko wtedy, gdy poprzednie zadanie powiedzie się. succeeded() jest warunkiem domyślnym, więc nie trzeba go określać. Ale pokazujemy to tutaj, aby pokazać jego użycie.

W zintegrowanym terminalu dodaj plik azure-pipelines.yml do indeksu, zatwierdź zmianę i wypchnij zmianę do usługi GitHub.

Napiwek

Przed uruchomieniem tych poleceń usługi Git pamiętaj, aby zapisać plik azure-pipelines.yml.
```
git add azure-pipelines.yml
git commit -m "Add publish tasks"
git push origin build-pipeline
```
Tak jak wcześniej, w usłudze Azure Pipelines prześledzić kompilację za pomocą każdego z kroków.
Po zakończeniu potoku wróć do podsumowania kompilacji.
W obszarze Powiązane opublikowano 1.
Wybierz artefakt.
Rozwiń folder upuszczania.

Zobaczysz plik zip zawierający skompilowana aplikację i jej zależności:

Jeśli chcesz wypróbować opcjonalne ćwiczenie, możesz pobrać ten plik zip na komputer i eksplorować jego zawartość.

Definiowanie zmiennych w celu zwiększenia czytelności

Mara wraca, aby zbadać swoją pracę. Konfiguracja kompilacji robi to, czego potrzebuje, ale chce się upewnić, że Andy i inni mogą łatwo pomóc w utrzymaniu jej aktualności i rozszerzeniu.

Zmienne umożliwiają definiowanie wartości raz i odwoływanie się do tych wartości w całym potoku. Usługa Azure Pipelines zastępuje każdą zmienną bieżącą wartością po uruchomieniu potoku.

Podobnie jak w innych językach programowania zmienne umożliwiają wykonywanie takich czynności jak:

Zdefiniuj wartości, które mogą ulec zmianie między przebiegami potoku.
Przechowuj informacje powtarzane w całym potoku, takie jak numer wersji lub ścieżka pliku, w jednym miejscu. W ten sposób nie trzeba aktualizować wszystkich wystąpień, gdy trzeba je zmienić.

Usługa Azure Pipelines udostępnia wiele wbudowanych zmiennych. Te zmienne opisują aspekty procesu kompilacji, takie jak identyfikator kompilacji i nazwy katalogów, w których oprogramowanie jest kompilowane i przygotowane.

Możesz również zdefiniować własne zmienne. Oto przykład pokazujący zmienną o nazwie buildConfiguration definiującą konfigurację kompilacji wydania:

variables:
  buildConfiguration: 'Release'

Użyj zmiennych podczas wielokrotnego powtarzania tej samej wartości lub gdy wartość, taka jak wersja zależności, może ulec zmianie.

Nie musisz tworzyć zmiennej dla każdej części konfiguracji kompilacji. W rzeczywistości zbyt wiele zmiennych może utrudnić innym osobom odczytywanie i zrozumienie kodu potoku.

Pośmiń chwilę na sprawdzenie pliku azure-pipelines.yml. Zwróć uwagę, że te wartości są powtarzane:

Konfiguracja kompilacji: Release.
Lokalizacja katalogu wwwroot: Tailspin.SpaceGame.Web/wwwroot.
Wersja zestawu .NET SDK: 6.x.

Teraz użyjesz zmiennych, aby zdefiniować te wartości jednorazowo. Następnie odwołujesz się do zmiennych w całym potoku.

W programie Visual Studio Code zmień plik azure-pipelines.yml , jak pokazano tutaj:

trigger:
- '*'

pool:
  name: 'Default' #replace if needed with name of your agent pool

variables:
  buildConfiguration: 'Release'
  wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
  dotnetSdkVersion: '6.x'

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK $(dotnetSdkVersion)'
  inputs:
    version: '$(dotnetSdkVersion)'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: $(wwwrootDir)

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Build the project - $(buildConfiguration)'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration $(buildConfiguration)'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - $(buildConfiguration)'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
    zipAfterPublish: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

trigger:
- '*'

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: 'Release'
  wwwrootDir: 'Tailspin.SpaceGame.Web/wwwroot'
  dotnetSdkVersion: '6.x'

steps:
- task: UseDotNet@2
  displayName: 'Use .NET SDK $(dotnetSdkVersion)'
  inputs:
    version: '$(dotnetSdkVersion)'

- task: Npm@1
  displayName: 'Run npm install'
  inputs:
    verbose: false

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

- task: gulp@1
  displayName: 'Run gulp tasks'

- script: 'echo "$(Build.DefinitionName), $(Build.BuildId), $(Build.BuildNumber)" > buildinfo.txt'
  displayName: 'Write build info'
  workingDirectory: $(wwwrootDir)

- task: DotNetCoreCLI@2
  displayName: 'Restore project dependencies'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Build the project - $(buildConfiguration)'
  inputs:
    command: 'build'
    arguments: '--no-restore --configuration $(buildConfiguration)'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'Publish the project - $(buildConfiguration)'
  inputs:
    command: 'publish'
    projects: '**/*.csproj'
    publishWebProjects: false
    arguments: '--no-build --configuration $(buildConfiguration) --output $(Build.ArtifactStagingDirectory)/$(buildConfiguration)'
    zipAfterPublish: true

- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'
  condition: succeeded()

Zwróć uwagę na sekcję variables , która definiuje następujące zmienne:

buildConfiguration: określa konfigurację kompilacji.
wwwrootDir: określa ścieżkę do katalogu wwwroot .
dotnetSdkVersion: określa wersję zestawu .NET SDK do użycia.

Aby odwołać się do tych zmiennych, użyj $() składni tak samo jak w przypadku zmiennych wbudowanych. Oto krok, który uruchamia sygnatury dostępu węzła w celu przekonwertowania plików Sass na arkusz CSS. Aby uzyskać ścieżkę do katalogu wwwroot , odwołuje się do zmiennej wwwrootDir .

- script: './node_modules/.bin/node-sass $(wwwrootDir) --output $(wwwrootDir)'
  displayName: 'Compile Sass assets'

Polecenie skryptu używa zmiennej do definiowania zarówno katalogu źródłowego dla plików Sass, jak i katalogu, w którym mają być zapisywane pliki CSS. Używa również zmiennej do definiowania nazwy zadania wyświetlanej w interfejsie użytkownika.

W zintegrowanym terminalu dodaj plik azure-pipelines.yml do indeksu, zatwierdź zmianę i wypchnij zmianę do usługi GitHub.
```
git add azure-pipelines.yml
git commit -m "Refactor common variables"
git push origin build-pipeline
```
Z poziomu usługi Azure Pipelines prześledzić kompilację za pomocą każdego z kroków.

Zobaczysz, że zmienne są zastępowane wartościami podczas uruchamiania kompilacji. UseDotNet@2 Oto zadanie, które ustawia wersję zestawu .NET SDK do użycia.

Tak jak wcześniej, aby zobaczyć artefakt po zakończeniu kompilacji, możesz przejść do podsumowania kompilacji.

Gratulacje! Pomyślnie użyto usługi Azure Pipelines i utworzono pierwszy artefakt kompilacji.

Kontynuuj

Ćwiczenie — publikowanie wyniku w potoku

Publikowanie kompilacji w potoku

Definiowanie zmiennych w celu zwiększenia czytelności

Opinia