Generación de canalizaciones de CI/CD con GitHub Copilot
Tip
Consulte la pestaña Texto e imágenes para obtener más detalles.
Una plantilla de Bicep que se encuentra en un repositorio sin ninguna canalización de implementación constituye una infraestructura como código incompleta. La plantilla define el estado deseado, pero sin automatización, alguien todavía tiene que ejecutarse az deployment group create manualmente desde su máquina local. Esto vuelve a introducir los problemas de error humano que iaC estaba destinado a eliminar.
Las canalizaciones de CI/CD cierran esa brecha. Imponen un proceso de implementación consistente: la plantilla se valida antes de la implementación, los cambios pasan por un entorno de preproducción antes de pasar a producción y nadie puede eludir el proceso enviando cambios directamente a un grupo de recursos compartido. La canalización es la capa de gobernanza que se encuentra encima de la plantilla.
GitHub Copilot reduce significativamente el tiempo de escritura de estas canalizaciones. El YAML de canalización es detallado, muy estructurado y sigue patrones que se repiten en distintos proyectos, lo que lo convierte en un candidato ideal para la generación asistida por IA.
estructura de canalización de Azure DevOps
Una canalización de YAML de Azure DevOps se organiza en fases, trabajos y pasos. En el caso de la implementación de infraestructura, una canalización bien estructurada suele tener cuatro fases:
- Validar: compilar y analizar la plantilla, y ejecutar una situación hipotética.
- Despliegue en preproducción: desplegar en un entorno de preproducción, ejecutar pruebas de humo
- Aprobar e implementar producción: requiera una aprobación humana y, a continuación, implemente
- Reversión (condicional): vuelva a implementar la versión anterior si se produce un error en producción.
Generación de una canalización de ADO de varias fases
Generate an Azure DevOps multi-stage YAML pipeline for deploying a Bicep template.
The pipeline should:
Trigger:
- On pushes to the main branch
- Only when files under the infra/ folder change (path filter)
- On pull requests to main (for the Validate stage only)
Variables:
- Use variable groups: "vg-iaclab-staging" for staging values
and "vg-iaclab-production" for production values
Stage 1 - Validate:
- Run on ubuntu-latest
- Steps: az bicep build (lint check), then az deployment group what-if
against the staging resource group using service connection "sc-iaclab-staging"
- Publish the what-if output as a pipeline artifact named "whatif-report"
Stage 2 - Deploy Staging:
- Depends on Validate passing
- Deploy the Bicep template to resource group "rg-iaclab-staging"
using service connection "sc-iaclab-staging"
- Pass environment=staging and costCenter from the variable group
Stage 3 - Deploy Production:
- Depends on Deploy Staging passing
- Requires a manual approval from the "iaclab-approvers" group
before the stage starts
- Deploy to "rg-iaclab-production" using "sc-iaclab-production"
- Pass environment=production and costCenter from the variable group
Stage 4 - Rollback:
- Only runs if Stage 3 fails (condition: failed())
- Downloads the previous successful Bicep artifact and re-deploys it
to the production resource group
All stages run on ubuntu-latest. Use AzureCLI task for deployments.
Conceptos clave para comprobar en la salida de Copilot
Service connections: ADO usa conexiones de servicio para autenticarse en Azure. El azureSubscription parámetro de la AzureCLI tarea hace referencia al nombre de conexión del servicio. Confirme que los nombres de conexión de servicio coinciden con lo que existe en el proyecto de ADO.
Grupos de variables: Se hace referencia a los grupos de variables con la sintaxis group: debajo de variables. Confirme que Copilot usa la sintaxis $(variableName) para valores en tiempo de ejecución, y no ${{ variables.variableName }}, que se evalúa en tiempo de compilación.
Aprobaciones del entorno: En ADO, las aprobaciones se configuran en el environment: recurso del portal, no en la canalización YAML. El YAML hace referencia al entorno por su nombre. La regla de aprobación real se configura por separado en ADO para ese entorno.
Descarga de artefactos para la reversión: La fase de reversión necesita descargar un artefacto específico. Copilot genera la tarea DownloadPipelineArtifact, pero puede que tenga que ajustar los parámetros artifactName y path para que se ajusten a lo que realmente publica la fase Validate.
Adición de una puerta de cumplimiento de directivas
Add a step to the Validate stage that runs az policy state summarize
against the staging resource group and fails the pipeline if any resources
are in a "NonCompliant" state. Parse the JSON output and fail with a clear
message listing the non-compliant resources.
Los controles de directiva impiden implementar en un entorno que ya no cumple los requisitos de conformidad. Se trata de una barrera de protección útil antes de aplicar nuevos cambios de infraestructura.
flujos de trabajo de Acciones de GitHub
Acciones de GitHub usar una estructura YAML diferente, pero cubre los mismos conceptos: desencadenadores, trabajos, pasos, entornos y secretos. Las principales diferencias de las canalizaciones de ADO son:
- Los trabajos reemplazan a las fases como unidad de nivel superior, y la dependencia se expresa mediante
needs:. - Los entornos de GitHub controlan las aprobaciones y las reglas de protección
- La federación de OIDC (no las entidades de servicio con contraseñas) es el método de autenticación recomendado.
- Los flujos de trabajo reutilizables en
.github/workflows/reemplazan las plantillas de canalización de ADO
Generación de un flujo de trabajo de Acciones de GitHub
Generate a GitHub Actions workflow for deploying a Bicep template to Azure.
Trigger:
- On push to main branch when files under infra/ change
- On pull_request to main (validate job only)
Authentication:
- Use OIDC federation via azure/login action
- Secrets: AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID
Jobs:
validate:
- Runs on ubuntu-latest
- Steps: checkout, azure login, az bicep build, az deployment group what-if
against rg-iaclab-staging
- Upload the what-if output as an artifact
deploy-staging:
- Depends on validate succeeding
- Runs in GitHub Environment "staging"
- Steps: checkout, azure login (staging credentials), deploy Bicep to rg-iaclab-staging
deploy-production:
- Depends on deploy-staging succeeding
- Runs in GitHub Environment "production"
(production environment has a required reviewer protection rule)
- Steps: checkout, azure login (production credentials), deploy Bicep to rg-iaclab-production
rollback:
- Runs if deploy-production fails
- Downloads the artifact from validate, re-deploys to rg-iaclab-production
Use ubuntu-latest for all jobs.
Autenticación OIDC
Las entidades de servicio de Azure tradicionales usan un secreto de cliente que debe almacenarse en Secretos de GitHub, rotarse con regularidad y puede filtrarse. La federación de OIDC (OpenID Connect) elimina la contraseña. El proveedor de identidades de GitHub emite un token de corta duración en el que Azure confía directamente.
La configuración requiere:
- Creación de una identidad administrada o un registro de aplicaciones en Azure con una credencial federada
- Configuración de la credencial federada para confiar en tokens de su repositorio y rama de GitHub específicos
- Asignación del rol de Azure RBAC necesario a la identidad
- Almacenar solo los valores no secretos (CLIENT_ID, TENANT_ID, SUBSCRIPTION_ID) en GitHub Secrets
Use este mensaje para generar el script de instalación:
Generate an Azure CLI script that:
1. Creates an App Registration named "gh-actions-iaclab"
2. Creates a federated credential on the registration trusting GitHub Actions
from the repo "myorg/iaclab" on the main branch and on pull requests
3. Assigns the "Contributor" role on resource group "rg-iaclab-staging"
and "rg-iaclab-production"
4. Outputs the CLIENT_ID, TENANT_ID, and SUBSCRIPTION_ID values to add to GitHub Secrets
Flujos de trabajo reutilizables
Los flujos de trabajo reutilizables permiten definir un trabajo de implementación una vez y llamarlo desde varios flujos de trabajo. Eliminar la repetición al implementar en varios entornos con los mismos pasos.
Refactor this GitHub Actions workflow so the deployment job is a reusable
workflow in .github/workflows/deploy-bicep.yml.
The reusable workflow should accept inputs for:
- resource_group (string)
- environment_name (string)
- bicep_file (string, default: main.bicep)
- parameters (string, JSON format)
And secrets for: AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID.
Update the main workflow to call the reusable workflow for both staging
and production deployments, passing different inputs each time.
Traducción entre ADO y Acciones de GitHub
Los equipos que migran entre plataformas suelen necesitar traducir canalizaciones. Copilot controla bien este proceso cuando se le indica explícitamente cómo asignar conceptos:
Translate this Azure DevOps YAML pipeline to a GitHub Actions workflow.
Map the following concepts:
- ADO stages → GitHub Actions jobs with needs: dependencies
- ADO variable groups → GitHub Actions environments and secrets
- ADO service connections → GitHub Actions OIDC credentials
- ADO manual approval (environment) → GitHub Actions environment protection rules
- AzureCLI task → azure/login + run: az ... steps
Preserve all logic. Do not add features that are not in the original pipeline.
[paste ADO pipeline YAML here]
La instrucción de mapeo explícito es importante. Sin ella, Copilot puede perder la equivalencia conceptual entre las construcciones ADO y Acciones de GitHub.
En la tabla siguiente se muestra la correspondencia de conceptos entre las dos plataformas:
| Azure DevOps | Acciones de GitHub |
|---|---|
| Etapa | Tarea (con needs:) |
| Job | Grupo de pasos dentro de una tarea |
| Grupo de variables | Secretos de entorno/ vars contexto |
| Conexión de servicio | Credenciales de OIDC de GitHub Secrets |
| Entorno (con aprobación) | Entorno de GitHub con regla de protección |
AzureCLI tarea |
azure/login acción + run: az ... |
PublishPipelineArtifact |
actions/upload-artifact |
DownloadPipelineArtifact |
actions/download-artifact |
$(variableName) |
${{ vars.VARIABLE_NAME }} |
${{ variables.name }} |
${{ inputs.name }} (flujos de trabajo reutilizables) |
Patrones de canalización de IaC
Validar antes de la implementación
Ejecute siempre az bicep build y az deployment group what-if en una fase dedicada de validación antes de cualquier fase de despliegue. La salida hipotética debe publicarse como un artefacto para que los revisores puedan examinarla antes de aprobar la implementación de producción.
Promoción por fases con aprobaciones
Implemente primero en el entorno de ensayo. Solo se debe pasar a producción una vez que una persona haya revisado la implementación en el entorno de ensayo y la haya aprobado expresamente. En ADO, este flujo se configura mediante reglas de aprobación del entorno. Acciones de GitHub usa reglas de protección de entorno con revisores necesarios.
Reversión condicional
Una fase de reversión solo debe desencadenarse cuando se produce un error en la implementación de producción. Tanto ADO como Acciones de GitHub admiten la ejecución condicional. En ADO, use condition: failed() en la fase de reversión. En Acciones de GitHub, use if: failure() en el trabajo de reversión. La fase de reversión vuelve a implementar el último artefacto correcto conocido en lugar de la plantilla actual.
Desencadenadores filtrados por rutas de acceso
Active el pipeline solo cuando cambien los archivos de infraestructura, no con cada confirmación en el repositorio. Utiliza filtros de ruta (paths: en Acciones de GitHub, include: en trigger.paths en ADO) para limitar el desencadenador al directorio infra/ o a dondequiera que se encuentren tus archivos Bicep. Evitar ejecuciones de canalización innecesarias cuando solo cambia el código de la aplicación.