Lint i zweryfikuj kod Bicep

  • 5 min

Teraz, gdy już wiesz, jakie etapy potoku dotyczą, rozważmy pierwszy zestaw kroków weryfikacji, które można dodać do potoku wdrażania Bicep. W tej lekcji dowiesz się więcej o weryfikowaniu szablonów Bicep. Dowiesz się również o dwóch działaniach, które zazwyczaj wykonują etap weryfikacji: linting i wstępne sprawdzanie poprawności.

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ć, są prawidłowe. A gdy zasoby zdefiniowane w pliku są wdrażane, pozostają 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. Te kroki są częścią procesu nazywanego linting. Aby sprawdzić inne problemy, należy 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ż w przypadku wdrożenia nieprawidłowego pliku Bicep platforma Azure może wdrożyć lub zmienić tylko podzbiór 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.

Kompilowanie i lint Bicep kodu

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 dla każdego typu zasobu.

Ponadto Bicep uruchamia linter nad plikami. Linting to proces sprawdzania kodu pod kątem zestawu zaleceń. Linter Bicep sprawdza plik i sprawdza, czy zostały sprawdzone najlepsze rozwiązania dotyczące łatwości konserwacji, poprawności, elastyczności i rozszerzalności.

Linter zawiera wstępnie zdefiniowany zestaw reguł dla 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 w żadnym miejscu 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 ostrzega, jeśli ustawisz wartości domyślne dla parametrów oznaczonych dekoratorem @secure() . Wartość domyślna bezpiecznego parametru jest złą praktyką, ponieważ zapewnia bezpieczny parametr wartości czytelnej dla człowieka, 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 rozwiązań. Linting odbywa się automatycznie podczas wdrażania pliku Bicep na platformie Azure.

Jednak w potoku zazwyczaj należy uruchomić kroki weryfikacji i linting przed wdrożeniem pliku. Możesz powiedzieć 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

Uwaga

Po uruchomieniu build polecenia Bicep również transpiluje kod Bicep do szablonu usługi ARM w formacie JSON. Zazwyczaj nie potrzebujesz pliku, który generuje, więc możesz go zignorować.

Ponieważ chcesz, aby linter sprawdzał szablony Bicep za każdym razem, gdy ktoś zaewidencjonuje kod w repozytorium, możesz dodać etap lint i zadanie do potoku:

Diagram przedstawiający potok ze etapem lint zawierającym jedno zadanie uruchamiające linter w pliku.

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 linter

Domyślnie linter emituje ostrzeżenie, gdy wykryje, że plik Bicep naruszył regułę. Ostrzeżenia, że linter Bicep emituje nie są traktowane jako błąd, więc nie zatrzymają uruchomienia potoku ani nie zatrzymają kolejnych etapów działania.

To zachowanie można zmienić, konfigurując Bicep, aby traktować naruszenia reguł linter jako błędy zamiast ostrzeżeń. 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.

Napiwek

Plik bicepconfig.json kontroluje również sposób, w jaki program Visual Studio Code wyświetla błędy i ostrzeżenia w edytorze. Wyświetla czerwone i żółte linie w nieprawidłowo skonfigurowanych częściach szablonu Bicep. Wskaźniki te zapewniają jeszcze szybsze opinie podczas pisania kodu Bicep, co jeszcze bardziej zmniejsza prawdopodobieństwo wystąpienia błędu.

Po ponownym skonfigurowaniu linteru w celu emitowania błędów za każdym razem, gdy linter wykryje problem, potok przestanie działać, a kolejne zadania lub etapy nie są uruchamiane. Ta konfiguracja pomaga zapewnić, że problematyczny kod Bicep nie zostanie wdrożony.

Walidacja wstępna

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 więcej testów, które wymagają podania informacji przez platformę Azure. Tego rodzaju kontrole obejmują:

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

Walidacja wstępna wymaga komunikacji z platformą Azure, ale nie wdraża żadnych zasobów.

Diagram przedstawiający potok z etapami lint i validate, z których każdy zawiera jedno zadanie. Etap weryfikacji komunikuje się z platformą Azure.

Możesz użyć AzureResourceManagerTemplateDeployment zadania , aby przesłać plik Bicep na potrzeby weryfikacji wstępnej i skonfigurować element 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 użytego już zadania wdrażania, ale w rzeczywistości 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 magazynu. Weryfikacja wstępna sprawdzi, czy inne konto magazynu ma już wybraną nazwę. Sprawdza również, czy nazwa wybrana dla konta magazynu jest zgodna z konwencjami nazewnictwa.

Polecenie sprawdzania poprawności wstępnej uruchamia również linter Bicep. Jednak zwykle dobrym pomysłem jest uruchomienie linter oddzielnie. W ten sposób, jeśli występują jakiekolwiek błędy linter, można je szybko wykryć zamiast czekać na zakończenie procesu weryfikacji. Walidacja trwa dłużej.

Ważne

Po uruchomieniu weryfikacji wstępnej każdy z dostawców zasobów platformy Azure wykonuje własne kontrole. Niektórzy dostawcy zasobów nie uruchamiają wielu testów, podczas gdy inni nie mogą polegać na weryfikacji wstępnej, aby mieć pewność, że plik jest prawidłowy. Niemniej jednak jest to przydatne narzędzie i warto je uwzględniać w potoku.

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ść.