Ćwiczenie — dodawanie lint i weryfikowanie etapów do potoku

3 min

Rozmawialiśmy z zespołem i podjęto decyzję o dalszej automatyzacji wdrożeń przy użyciu potoku. Chcesz budować większą pewność co do wdrażanych rozwiązań.

W tym ćwiczeniu dodasz etapy weryfikacji do potoku. Następnie uruchomisz linter i walidację wstępną przed każdym wdrożeniem.

Podczas tego procesu wykonasz następujące czynności:

Zaktualizuj istniejący potok, aby dodać dwa nowe etapy do lint i zweryfikować kod Bicep.
Uruchom swój potok.
Rozwiąż wszelkie problemy wykryte przez potok.

Aktualizowanie potoku w celu przygotowania do etapów

Najpierw należy zaktualizować plik potoku, aby zdefiniować etap. Usługa Azure Pipelines automatycznie tworzy jeden etap, ale ponieważ wkrótce dodasz więcej etapów, musisz zaktualizować potok, aby jawnie zdefiniować etapy.

W programie Visual Studio Code otwórz plik azure-pipelines.yml w folderze deploy .
Usuń wszystko w pliku z wiersza 14 do dołu pliku. Pamiętaj również, aby usunąć jobs: wiersz.

W dolnej części pliku dodaj następujący kod:

stages:

- stage: Deploy
  jobs:
  - job: Deploy
    steps:
      - task: AzureResourceManagerTemplateDeployment@3
        name: Deploy
        displayName: Deploy to Azure
        inputs:
          connectedServiceName: $(ServiceConnectionName)
          deploymentName: $(Build.BuildNumber)
          location: $(DeploymentDefaultLocation)
          resourceGroupName: $(ResourceGroupName)
          csmFile: deploy/main.bicep
          overrideParameters: >
            -environmentType $(EnvironmentType)

Napiwek

Pliki YAML są wrażliwe na wcięcia. Bez względu na to, czy wpiszesz, czy wklejasz ten kod, upewnij się, że wcięcie jest poprawne. W następnej sekcji zobaczysz pełną definicję potoku YAML, aby sprawdzić, czy plik jest zgodny.

Dodawanie etapów lint i walidacji do potoku

stages: Poniżej wiersza dodaj etap lint:

- stage: Lint
  jobs:
  - job: LintCode
    displayName: Lint code
    steps:
      - script: |
          az bicep build --file deploy/main.bicep
        name: LintBicepCode
        displayName: Run Bicep linter

Ten etap definiuje jeden krok, który uruchamia az bicep build polecenie w celu lint pliku Bicep.

Poniżej dodanych wierszy dodaj etap weryfikacji:

- stage: Validate
  jobs:
  - job: ValidateBicepCode
    displayName: Validate Bicep code
    steps:
      - task: AzureResourceManagerTemplateDeployment@3
        name: RunPreflightValidation
        displayName: Run preflight validation
        inputs:
          connectedServiceName: $(ServiceConnectionName)
          location: $(deploymentDefaultLocation)
          deploymentMode: Validation
          resourceGroupName: $(ResourceGroupName)
          csmFile: deploy/main.bicep
          overrideParameters: >
            -environmentType $(EnvironmentType)

Ten etap definiuje pojedynczy krok, który uruchamia weryfikację wstępną. Zwróć uwagę, że ten krok zawiera odwołanie do połączenia z usługą, ponieważ proces weryfikacji wstępnej wymaga komunikacji z platformą Azure.

Definicja potoku ma teraz trzy etapy. Pierwszy uruchamia linter w pliku Bicep, drugi wykonuje walidację wstępną, a trzeci wykonuje wdrożenie na platformie Azure.

Zapisz plik.

Konfigurowanie lintera

Domyślnie linter Bicep udostępnia ostrzeżenie, gdy wykryje problem z plikiem. Usługa Azure Pipelines nie traktuje ostrzeżeń linter jako problemów, które powinny zatrzymać potok. Aby dostosować to zachowanie, należy utworzyć plik bicepconfig.json , który ponownie konfiguruje linter.

Dodaj nowy plik w folderze deploy i nadaj mu nazwę bicepconfig.json.

Skopiuj następujący kod do pliku:

{
  "analyzers": {
    "core": {
      "enabled": true,
      "verbose": true,
      "rules": {
        "adminusername-should-not-be-literal": {
          "level": "error"
        },
        "max-outputs": {
          "level": "error"
        },
        "max-params": {
          "level": "error"
        },
        "max-resources": {
          "level": "error"
        },
        "max-variables": {
          "level": "error"
        },
        "no-hardcoded-env-urls": {
          "level": "error"
        },
        "no-unnecessary-dependson": {
          "level": "error"
        },
        "no-unused-params": {
          "level": "error"
        },
        "no-unused-vars": {
          "level": "error"
        },
        "outputs-should-not-contain-secrets": {
          "level": "error"
        },
        "prefer-interpolation": {
          "level": "error"
        },
        "secure-parameter-default": {
          "level": "error"
        },
        "simplify-interpolation": {
          "level": "error"
        },
        "protect-commandtoexecute-secrets": {
          "level": "error"
        },
        "use-stable-vm-image": {
          "level": "error"
        }
      }
    }
  }
}

Zapisz plik.

Weryfikowanie i zatwierdzanie definicji potoku

Sprawdź, czy plik azure-pipelines.yml wygląda następująco:

trigger:
  batch: true
  branches:
    include:
    - main

pool:
  vmImage: ubuntu-latest

variables:
  - name: deploymentDefaultLocation
    value: westus3

stages:

- stage: Lint
  jobs:
  - job: LintCode
    displayName: Lint code
    steps:
      - script: |
          az bicep build --file deploy/main.bicep
        name: LintBicepCode
        displayName: Run Bicep linter

- stage: Validate
  jobs:
  - job: ValidateBicepCode
    displayName: Validate Bicep code
    steps:
      - task: AzureResourceManagerTemplateDeployment@3
        name: RunPreflightValidation
        displayName: Run preflight validation
        inputs:
          connectedServiceName: $(ServiceConnectionName)
          location: $(deploymentDefaultLocation)
          deploymentMode: Validation
          resourceGroupName: $(ResourceGroupName)
          csmFile: deploy/main.bicep
          overrideParameters: >
            -environmentType $(EnvironmentType)

- stage: Deploy
  jobs:
  - job: Deploy
    steps:
      - task: AzureResourceManagerTemplateDeployment@3
        name: Deploy
        displayName: Deploy to Azure
        inputs:
          connectedServiceName: $(ServiceConnectionName)
          deploymentName: $(Build.BuildNumber)
          location: $(DeploymentDefaultLocation)
          resourceGroupName: $(ResourceGroupName)
          csmFile: deploy/main.bicep
          overrideParameters: >
            -environmentType $(EnvironmentType)

Jeśli tak nie jest, zaktualizuj go tak, aby był zgodny z tym przykładem, a następnie zapisz go.

Zatwierdź i wypchnij zmiany do repozytorium Git, uruchamiając następujące polecenia w terminalu programu Visual Studio Code:
```
git add .
git commit -m "Add lint and validation stages"
git push
```
Natychmiast po wypchnięciu usługa Azure Pipelines uruchamia nowe uruchomienie potoku.

Wyświetlanie przebiegu potoku

W przeglądarce przejdź do pozycji Potoki.
Wybierz najnowszy przebieg potoku.

Jeśli potok jest nadal uruchomiony, zaczekaj na jego zakończenie. Chociaż usługa Azure Pipelines automatycznie aktualizuje stronę o najnowszym stanie, warto odświeżyć stronę od czasu do czasu.
Zwróć uwagę, że uruchomienie potoku pokazuje teraz trzy etapy zdefiniowane w pliku YAML. Zwróć również uwagę, że etap lint zakończył się niepowodzeniem.
Wybierz etap Lint, aby wyświetlić jego szczegóły.
Wybierz krok Uruchom linter Bicep, aby wyświetlić dziennik potoku.

Zwróć uwagę, że wyświetlany błąd jest podobny do następującego:

Błąd no-unused-params: Parametr "storageAccountNameParam" jest zadeklarowany, ale nigdy nie został użyty.

Ten błąd wskazuje, że linter odnalazł naruszenie reguły w pliku Bicep.

Naprawianie błędu linter

Po zidentyfikowaniu problemu możesz go rozwiązać w pliku Bicep.

W programie Visual Studio Code otwórz plik main.bicep w folderze deploy .
Zwróć uwagę, że linter Bicep wykrył również, że storageAccountNameParam parametr nie jest używany. Program Visual Studio Code wskazuje nieużywany parametr z zwijanym wierszem. Zwykle linia będzie żółta, aby wskazać ostrzeżenie. Ale ponieważ dostosowano plik bicepconfig.json , linter traktuje kod jako błąd i wyświetla wiersz na czerwono.
```
param storageAccountNameParam string = uniqueString(resourceGroup().id)
```
storageAccountNameParam Usuń parametr .
Zapisz plik.
Zatwierdź i wypchnij zmiany do repozytorium Git, uruchamiając następujące polecenia w terminalu programu Visual Studio Code:
```
git add .
git commit -m "Remove unused parameter"
git push
```
Po raz kolejny usługa Azure Pipelines automatycznie wyzwala nowy przebieg potoku.

Ponowne wyświetlanie przebiegu potoku

W przeglądarce przejdź do potoku.
Wybierz najnowszy przebieg.

Poczekaj na zakończenie przebiegu potoku. Chociaż usługa Azure Pipelines automatycznie aktualizuje stronę o najnowszym stanie, warto odświeżyć stronę od czasu do czasu.
Zwróć uwagę, że etap lint zakończył się pomyślnie, ale teraz etap Weryfikacji zakończył się niepowodzeniem.
Wybierz etap Weryfikuj, aby wyświetlić jego szczegóły.
Wybierz krok Uruchom weryfikację wstępną, aby wyświetlić dziennik potoku.

Zwróć uwagę, że błąd wyświetlany w dzienniku zawiera następujący komunikat:

mystorageresourceNameSuffix nie jest prawidłową nazwą konta magazynu. Nazwa konta magazynu musi mieć długość od 3 do 24 znaków, a tylko cyfry i małe litery.

Ten błąd wskazuje, że nazwa konta magazynu jest nieprawidłowa.

Naprawianie błędu sprawdzania poprawności

W pliku Bicep znaleziono kolejny problem. W tym miejscu rozwiążesz problem.

W programie Visual Studio Code otwórz plik main.bicep w folderze deploy .

Przyjrzyj się definicji zmiennej storageAccountName :

var appServiceAppName = 'toy-website-${resourceNameSuffix}'
var appServicePlanName = 'toy-website'
var applicationInsightsName = 'toywebsite'
var logAnalyticsWorkspaceName = 'workspace-${resourceNameSuffix}'
var storageAccountName = 'mystorageresourceNameSuffix'

Wydaje się, że jest literówka, a interpolacja ciągów nie została poprawnie skonfigurowana.

Zaktualizuj zmienną, storageAccountName aby prawidłowo używała interpolacji ciągów:
```
var storageAccountName = 'mystorage${resourceNameSuffix}'
```
Zapisz plik.
Zatwierdź i wypchnij zmiany do repozytorium Git, uruchamiając następujące polecenia w terminalu programu Visual Studio Code:
```
git add .
git commit -m "Fix string interpolation"
git push
```

Wyświetlanie pomyślnego uruchomienia potoku

W przeglądarce przejdź do potoku.
Wybierz najnowszy przebieg.

Poczekaj na zakończenie przebiegu potoku. Chociaż usługa Azure Pipelines automatycznie aktualizuje stronę o najnowszym stanie, warto odświeżyć stronę od czasu do czasu.
Zwróć uwagę, że wszystkie trzy etapy potoku zakończyły się pomyślnie:

Masz teraz potok, który pomyślnie wykrywa błędy w kodzie Bicep na wczesnym etapie procesu wdrażania, a następnie wdraża na platformie Azure, jeśli nie ma żadnych błędów.