Sprawdź i zweryfikuj kod Bicep

Teraz, gdy już wiesz, czemu służą etapy potoku, rozważmy pierwszy zestaw kroków weryfikacyjnych, które można dodać do potoku wdrażania Bicep. W tej jednostce dowiesz się o weryfikowaniu szablonów Bicep. Dowiesz się również o dwóch działaniach, które zazwyczaj wykonuje etap walidacji: "linting" i walidacja wstępna.

Co to jest prawidłowy plik Bicep?

Prawidłowy plik Bicep jest taki, który nie zawiera żadnych błędów składniowych. Ponadto definicje zasobów platformy Azure, które planujesz wdrożyć, muszą być prawidłowe. A gdy zasoby zdefiniowane w pliku są wdrażane, muszą pozostać w granicach przydziałów i limitów, które istnieją w ramach subskrypcji platformy Azure.

Niektóre testy są wykonywane w pliku Bicep w izolacji, takie jak sprawdzanie błędów składniowych, prawidłowe definicje zasobów platformy Azure i jakość kodu. Kroki te są częścią procesu zwanego linting. Aby sprawdzić inne problemy, musisz poprosić o zweryfikowanie szablonu przez usługę Azure Resource Manager i uwzględnienie środowiska platformy Azure.

Prawidłowy szablon Bicep ma większe szanse na pomyślne wdrożenie. Otrzymasz opinię bez wdrażania szablonu Bicep. Walidacja jest dobrym rozwiązaniem, ponieważ jeśli wdrożysz nieprawidłowy plik Bicep, platforma Azure może wdrożyć lub zmienić tylko podzestaw zasobów opisanych w szablonie. Wynikiem może być to, że stan środowiska jest niespójny i może nie zachowywać się w oczekiwany sposób.

Budowanie i sprawdzanie kodu Bicep

Podczas wdrażania pliku Bicep narzędzie Bicep najpierw uruchamia kilka podstawowych kroków weryfikacji. Te kroki są takie same, które są uruchamiane podczas modyfikowania pliku przy użyciu programu Visual Studio Code. Sprawdzają, czy słowa kluczowe języka Bicep zostały poprawnie użyte i czy zasoby platformy Azure zostały zdefiniowane zgodnie z wymaganiami dotyczącymi poszczególnych typów zasobów.

Ponadto Bicep uruchamia linter dla plików. Linting to proces sprawdzania kodu pod kątem zestawu zaleceń. Linter Bicep przegląda Twój plik i sprawdza, czy zastosowano najlepsze praktyki w zakresie utrzymywalności, poprawności, elastyczności i rozszerzalności.

Linter zawiera wstępnie zdefiniowany zestaw reguł do każdej z tych kategorii. Przykładowe reguły linter obejmują:

• Nieużywane parametry. Linter skanuje pod kątem żadnych parametrów, które nie są używane nigdzie w pliku Bicep. Eliminując nieużywane parametry, można ułatwić wdrażanie szablonu, ponieważ nie trzeba podawać niepotrzebnych wartości. Zmniejszasz również zamieszanie, gdy ktoś próbuje pracować z plikiem Bicep.
• Interpolacja ciągów. Linter sprawdza, czy plik używa concat() funkcji zamiast interpolacji ciągów Bicep. Interpolacja ciągów sprawia, że pliki Bicep są bardziej czytelne.
• Wartości domyślne dla bezpiecznych parametrów. Linter wyświetli ostrzeżenie, jeśli ustawisz wartości domyślne dla parametrów oznaczonym dekoratorem @secure(). Wartość domyślna bezpiecznego parametru jest złą praktyką, ponieważ zapewnia bezpieczny parametr czytelną dla człowieka wartość, a osoby mogą nie zmieniać go przed wdrożeniem.

Linter Bicep jest uruchamiany automatycznie podczas korzystania z narzędzi Bicep. Za każdym razem, gdy tworzysz plik Bicep, linter sprawdza go pod kątem najlepszych praktyk. Linting odbywa się automatycznie podczas wdrażania pliku Bicep na platformie Azure. W potoku zadań zazwyczaj chcesz wykonać kroki weryfikacji i linting przed wdrożeniem pliku. Możesz skonfigurować aplikację Bicep, aby zweryfikować plik, ręcznie tworząc plik Bicep za pomocą interfejsu wiersza polecenia Bicep:

az bicep build --file main.bicep

bicep build main.bicep

Ponieważ chcesz, aby linter sprawdzał szablony Bicep za każdym razem, gdy ktoś zatwierdza kod do repozytorium, możesz dodać do potoku CI/CD etap lintowania oraz zadanie:

Możesz wyrazić ten dodatek w pliku YAML potoku w następujący sposób:

stages:

- stage: Lint
  jobs: 
  - job: Lint
    steps:
      - script: |
          az bicep build --file deploy/main.bicep

Ostrzeżenia i błędy lintera

Domyślnie linter wyświetla ostrzeżenie, gdy wykryje, że plik Bicep naruszył regułę. Ostrzeżenia, które są emitowane przez linter Bicep, nie są traktowane jako błędy, więc nie zatrzymają uruchomienia potoku ani nie zatrzymają kolejnych etapów.

Możesz zmienić to zachowanie, konfigurując Bicep tak, aby traktował naruszenia reguł lintera jako błędy, a nie ostrzeżenia. Tę konfigurację należy wykonać, dodając plik bicepconfig.json do folderu zawierającego plik Bicep. Możesz zdecydować, które problemy linter powinny być traktowane jako błędy i które powinny pozostać jako ostrzeżenia. W dalszej części tego modułu zobaczysz, jak zaktualizować reguły linter.

Po skonfigurowaniu lintera do zgłaszania błędów, gdy tylko linter wykryje problem, potok przestaje działać, a kolejne zadania lub etapy nie zostaną uruchomione. Ta konfiguracja pomaga zapewnić, że problematyczny kod Bicep nie został wdrożony.

Walidacja przed lotem

Należy również sprawdzić, czy szablon Bicep prawdopodobnie zostanie pomyślnie wdrożony w środowisku platformy Azure. Ta kontrola jest nazywana weryfikacją wstępną i uruchamia testy, które wymagają informacji z platformy Azure. Tego rodzaju kontrole obejmują:

• Czy nazwy określone dla zasobów Bicep są prawidłowe?
• Czy nazwy określone dla zasobów Bicep są już zajęte?
• Czy regiony, w których wdrażasz zasoby, są prawidłowe?

Walidacja przedwstępna wymaga komunikacji z platformą Azure, jednak nie prowadzi do wdrożenia żadnych zasobów.

Możesz użyć zadania AzureResourceManagerTemplateDeployment, aby przesłać plik Bicep na potrzeby weryfikacji wstępnej. Skonfiguruj deploymentMode do Validation:

- stage: Validate
  jobs:
  - job: Validate
    steps:
      - task: AzureResourceManagerTemplateDeployment@3
        inputs:
          connectedServiceName: 'MyServiceConnection'
          location: $(deploymentDefaultLocation)
          deploymentMode: Validation
          resourceGroupName: $(ResourceGroupName)
          csmFile: deploy/main.bicep

To polecenie jest podobne do zadania wdrażania, które już użyłeś, ale tak naprawdę nie wdraża żadnych zasobów. Wykonuje dodatkowe kontrole zasobów używanych w szablonie.

Załóżmy na przykład, że plik Bicep zawiera konto magazynowe. Sprawdzanie wstępne sprawdza, czy inne konto magazynowe ma już wybraną nazwę. Sprawdza również, czy wybrana nazwa dla konta magazynu jest zgodna z konwencjami nazewnictwa.

Polecenie walidacji przedstartowej uruchamia linter Bicep. Jednak zwykle dobrym pomysłem jest uruchomienie linter oddzielnie. W ten sposób, jeśli występują jakiekolwiek błędy linter, wykrywasz je szybko zamiast czekać na zakończenie procesu weryfikacji. Walidacja trwa dłużej.

Dodając etapy weryfikacji do potoku, aby uruchomić linter i przeprowadzić walidację wstępną, przed wdrożeniem pliku Bicep będziesz mieć większą pewność.