Lint i zweryfikuj kod Bicep

  • 5 min

Teraz, gdy już wiesz, jakie zadania przepływu pracy dotyczą, rozważmy pierwszy zestaw kroków weryfikacji, które można dodać do przepływu pracy wdrażania Bicep. W tej lekcji dowiesz się więcej o weryfikowaniu szablonów Bicep. Zapoznasz się również z dwoma działaniami weryfikacji, które są często używane: linting i walidacja wstępna.

Co to jest prawidłowy plik Bicep?

Prawidłowy plik Bicep 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 faktycznego wdrożenia 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. Wdrożenie częściowe może oznaczać, że stan środowiska jest niespójny i może nie zachowywać się zgodnie z oczekiwaniami.

Kompilowanie i tworzenie 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 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 w zakresie 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 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. Narzędzie linter wyświetli ostrzeżenie, jeśli ustawisz wartości domyślne parametrów oznaczonych dekoratorem @secure() . Ustawienie wartości domyślnych dla bezpiecznych parametrów jest złą praktyką, ponieważ zapewnia bezpieczny parametr wartości czytelnej dla człowieka, a osoby mogą nie zmieniać ich 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ń. Ta kontrola odbywa się automatycznie podczas wdrażania pliku Bicep na platformie Azure.

Jednak w przepływie pracy 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ż szablony Bicep mają być linted za każdym razem, gdy ktoś zaewidencjonuje kod w repozytorium, możesz dodać zadanie lint do przepływu pracy:

Diagram przedstawiający przepływ pracy z zadaniem lint zawierającym jedno zadanie, które uruchamia linter w pliku.

Możesz wyrazić ten dodatek w pliku YAML przepływu pracy w następujący sposób:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - 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 narusza regułę. Ostrzeżenia, że emituje linter Bicep nie są traktowane jako błędy, więc nie zatrzymują uruchomienia przepływu pracy ani nie zatrzymują kolejnych zadań.

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. Skonfigurujesz linter w dalszej części tego modułu.

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 lintera w celu emitowania błędów za każdym razem, gdy linter wykryje problem, przepływ pracy przestanie działać, a kolejne zadania nie są uruchamiane. Ta konfiguracja pomaga zapewnić, że problematyczny kod Bicep nie został wdrożony.

Walidacja wstępna

Należy również sprawdzić, czy szablon Bicep prawdopodobnie zostanie pomyślnie wdrożony w środowisku platformy Azure. Ten proces jest nazywany weryfikacją wstępną i uruchamia testy, 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 określone dla zasobów Bicep są już zajęte?
  • 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 przepływ pracy z lint i weryfikowaniem zadań, z których każdy zawiera jedno zadanie. Zweryfikowane zadanie komunikuje się z platformą Azure.

Aby przesłać plik Bicep na potrzeby weryfikacji wstępnej, należy użyć arm-deploy akcji i ustawić wartość na deploymentMode Validate:

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      name: Run preflight validation
      with:
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        deploymentMode: Validate

Możesz również użyć polecenia interfejsu wiersza polecenia platformy az deployment group validate Azure.

Walidacja wstępna jest podobna do normalnego wdrożenia, 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. Sprawdzanie poprawności wstępnej sprawdza, czy inne konto magazynu już miało 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, wykrywasz je szybko 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 to robią. Dlatego nie można 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 przepływie pracy.

Dodając zadania weryfikacji do przepływu pracy w celu uruchomienia linteru i przeprowadzenia weryfikacji wstępnej, będziesz mieć większą pewność przed wdrożeniem pliku Bicep.