Integración continua

Analiza cada despliegue y entérate de lo que se ha roto antes que tus usuarios.

La idea

Después de desplegar, lanzas un análisis contra la URL recién publicada, esperas al resultado y decides si la build pasa o falla según la puntuación. No hace falta instalar nada en el runner: son dos llamadas HTTP.

Guarda tu clave de API como secreto del repositorio (en GitHub, Settings → Secrets and variables → Actions) con el nombre QA_AI_KEY.

GitHub Actions

.github/workflows/qa.yml

name: QA tras el despliegue

on:
  deployment_status:

jobs:
  analizar:
    # Sólo cuando el despliegue ha terminado bien
    if: github.event.deployment_status.state == 'success'
    runs-on: ubuntu-latest
    steps:
      - name: Lanzar el análisis
        id: lanzar
        run: |
          RESPUESTA=$(curl -sS -X POST "$QA_URL/api/tests" \
            -H "Authorization: Bearer $QA_AI_KEY" \
            -H "Content-Type: application/json" \
            -d "{
              \"name\": \"Despliegue ${{ github.sha }}\",
              \"url\": \"${{ github.event.deployment_status.target_url }}\",
              \"testTypes\": [\"FUNCTIONAL\",\"UI\",\"PERFORMANCE\",\"ACCESSIBILITY\",\"SEO\",\"SECURITY\"],
              \"devices\": [\"DESKTOP\",\"MOBILE\"]
            }")
          echo "id=$(echo "$RESPUESTA" | jq -r .test.id)" >> "$GITHUB_OUTPUT"
        env:
          QA_AI_KEY: ${{ secrets.QA_AI_KEY }}
          QA_URL: https://tu-dominio.com

      - name: Esperar el resultado
        run: |
          for i in $(seq 1 40); do
            sleep 5
            TEST=$(curl -sS "$QA_URL/api/tests/${{ steps.lanzar.outputs.id }}" \
              -H "Authorization: Bearer $QA_AI_KEY")
            ESTADO=$(echo "$TEST" | jq -r .test.status)
            echo "Estado: $ESTADO"
            [ "$ESTADO" = "COMPLETED" ] && break
            if [ "$ESTADO" = "FAILED" ] || [ "$ESTADO" = "CANCELLED" ]; then
              echo "El análisis no pudo completarse"; exit 1
            fi
          done

          PUNTUACION=$(echo "$TEST" | jq -r .test.score)
          CRITICOS=$(echo "$TEST" | jq '[.test.issues[] | select(.severity=="CRITICAL")] | length')

          echo "### Análisis QA: $PUNTUACION/100" >> "$GITHUB_STEP_SUMMARY"
          echo "$TEST" | jq -r '.test.issues[] | "- **\(.severity)** \(.title)"' >> "$GITHUB_STEP_SUMMARY"

          # La build falla si aparece algo crítico o la puntuación baja de 70
          if [ "$CRITICOS" -gt 0 ] || [ "$PUNTUACION" -lt 70 ]; then
            echo "Análisis por debajo del umbral"; exit 1
          fi
        env:
          QA_AI_KEY: ${{ secrets.QA_AI_KEY }}
          QA_URL: https://tu-dominio.com

Elegir el umbral

Empieza sin bloquear nada: lanza el análisis y publica el resumen, pero deja que la build pase siempre. Ejecuta así una o dos semanas para ver qué puntuación da tu proyecto en un día normal, y pon el umbral unos puntos por debajo. Un umbral demasiado exigente el primer día sólo consigue que el equipo lo desactive.

Lo que sí conviene bloquear desde el principio son los problemas críticos: son los que dejan la aplicación rota o los datos al descubierto.

Coste

Cada ejecución consume un crédito. Si despliegas veinte veces al día, son unos 600 créditos al mes: el plan Pro. Si quieres gastar menos, lanza el análisis sólo en los despliegues a producción y no en los de vista previa.