Ejercicio: Adición de fases de linting y validación a la canalización

3 minutos

Ha hablado con el equipo y ha decidido automatizar aún más las implementaciones mediante una canalización. Quiere generar más confianza en lo que implementa.

En este ejercicio, agregará fases de validación a la canalización. Después, ejecutará la validación de linter y preparatoria antes de cada implementación.

Durante el proceso, hará lo siguiente:

Actualizar la canalización existente para agregar dos nuevas fases de linting y validación del código de Bicep.
Ejecutar la canalización.
Corrija los problemas que detecte la canalización.

Actualización de la canalización para prepararse para las fases

En primer lugar, debe actualizar el archivo de canalización para definir una fase. Azure Pipelines crea automáticamente una sola fase, pero como pronto agregará más, deberá actualizar la canalización para que las defina de forma explícita.

En Visual Studio Code, abra el archivo azure-pipelines.yml en la carpeta deploy.
Quite todo el contenido del archivo desde la línea 14 hasta el final. Asegúrese de quitar también la línea jobs:.

En la parte inferior del archivo, agregue el código siguiente:

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)

Sugerencia

Los archivos YAML son sensibles a la sangría. Tanto si escribe o pega este código, asegúrese de que la sangría es correcta. En la sección siguiente verá la definición de canalización de YAML completa para que pueda comprobar que el archivo coincide.

Adición de fases de linting y validación a la canalización

Debajo de la línea stages:, agregue una fase de linting:

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

Esta fase define un solo paso que ejecuta el comando az bicep build para comprobar errores en el archivo de Bicep.

Debajo de las líneas que acaba de agregar, agregue una fase de validación:

- 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)

Esta fase define un solo paso que ejecuta la validación preparatoria. Tenga en cuenta que en este paso se incluye una referencia a la conexión de servicio, ya que el proceso de validación preparatoria necesita comunicarse con Azure.

La definición de canalización ahora tiene tres fases. El primero ejecuta linter en el archivo de Bicep, el segundo realiza una validación preparatoria y el tercero realiza la implementación en Azure.

Guarde el archivo.

Configuración del linter

De forma predeterminada, el linter de Bicep proporciona una advertencia cuando detecta un problema con el archivo. Azure Pipelines no trata las advertencias de linter como problemas que deban detener la canalización. Para personalizar este comportamiento, debe crear un archivo bicepconfig.json que vuelva a configurar el linter.

Agregue un archivo nuevo en la carpeta deploy, con el nombre asíbicepconfig.json.

Copie el código siguiente en el archivo:

{
  "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"
        }
      }
    }
  }
}

Guarde el archivo.

Comprobación y confirmación de la definición de canalización

Compruebe que el archivo azure-pipelines.yml es similar al archivo siguiente:

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)

Si no es así, actualícelo para que coincida con este ejemplo y después guárdelo.

Confirme e inserte los cambios en el repositorio de Git mediante la ejecución de los comandos siguientes en el terminal de Visual Studio Code:
```
git add .
git commit -m "Add lint and validation stages"
git push
```
Inmediatamente después de la inserción, Azure Pipelines inicia una nueva ejecución de canalización.

Visualización de la ejecución de canalización

En el explorador, vaya a Canalizaciones.
Seleccione la ejecución más reciente de la canalización.

Si la canalización sigue en ejecución, espere hasta que finalice. Aunque Azure Pipelines actualiza de forma automática la página con el estado más reciente, es recomendable actualizarla ocasionalmente.
Observe que ahora la ejecución de canalización muestra las tres fases que ha definido en el archivo YAML. Observe también que se ha producido un error en la fase Lint.
Seleccione la fase Lint para ver sus detalles.
Seleccione el paso Run Bicep linter (Ejecutar linter de Bicep) para ver el registro de canalización.

Observe que el error que se muestra es similar al siguiente:

Error no-unused-params: el parámetro "storageAccountNameParam" se declara pero nunca se usa.

Este error indica que el linter ha encontrado una infracción de regla en el archivo de Bicep.

Corrección del error de linter

Ahora que ha identificado el problema, puede corregirlo en el archivo de Bicep.

En Visual Studio Code, abra el archivo main.bicep de la carpeta deploy.
Observe que el linter de Bicep también ha detectado que no se usa el parámetro storageAccountNameParam. Visual Studio Code indica el parámetro sin usar con una línea ondulada. Normalmente, la línea sería amarilla para indicar una advertencia. Pero como ha personalizado el archivo bicepconfig.json, el linter trata el código como un error y muestra la línea en rojo.
```
param storageAccountNameParam string = uniqueString(resourceGroup().id)
```
Elimine el parámetro storageAccountNameParam.
Guarde el archivo.
Confirme e inserte los cambios en el repositorio de Git mediante la ejecución de los comandos siguientes en el terminal de Visual Studio Code:
```
git add .
git commit -m "Remove unused parameter"
git push
```
Como antes, Azure Pipelines desencadena automáticamente una nueva ejecución de canalización.

Nueva visualización de la ejecución de canalización

En el explorador, vaya a la canalización.
Seleccione la ejecución más reciente.

Espere hasta que finalice la ejecución de la canalización. Aunque Azure Pipelines actualiza de forma automática la página con el estado más reciente, es recomendable actualizarla ocasionalmente.
Observe que la fase Lint se ha completado correctamente, pero ahora se ha producido un error en la fase Validate (Validación).
Seleccione la fase Validate (Validación) para ver sus detalles.
Seleccione el paso Run preflight validation (Ejecutar validación preparatoria) para ver el registro de canalización.

Observe que el error que se muestra en el registro incluye el mensaje siguiente:

mystorageresourceNameSuffix no es un nombre de cuenta de almacenamiento válido. El nombre de la cuenta de almacenamiento debe tener entre 3 y 24 caracteres, y solo puede contener números y letras minúsculas.

Este error indica que el nombre de la cuenta de almacenamiento no es válido.

Corrección del error de validación

Ha encontrado otro problema en el archivo de Bicep. Aquí, corregirá el problema.

En Visual Studio Code, abra el archivo main.bicep de la carpeta deploy.

Mire la definición de la variable storageAccountName:

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

Parece haber un error ortográfico y la interpolación de cadenas no se ha configurado correctamente.

Actualice la variable storageAccountName para que use correctamente la interpolación de cadenas:
```
var storageAccountName = 'mystorage${resourceNameSuffix}'
```
Guarde el archivo.
Confirme e inserte los cambios en el repositorio de Git mediante la ejecución de los comandos siguientes en el terminal de Visual Studio Code:
```
git add .
git commit -m "Fix string interpolation"
git push
```

Visualización de la ejecución de canalización correcta

En el explorador, vaya a la canalización.
Seleccione la ejecución más reciente.

Espere hasta que finalice la ejecución de la canalización. Aunque Azure Pipelines actualiza de forma automática la página con el estado más reciente, es recomendable actualizarla ocasionalmente.
Observe que las tres fases de la canalización han finalizado correctamente:

Ahora tiene una canalización que detecta correctamente errores en el código de Bicep al principio del proceso de implementación y, después, se implementa en Azure si no hay errores.