Despliegue en producción con puertas de aprobación
Aprenda a promover compilaciones de forma segura de staging a producción mediante las reglas de protección de entornos de GitHub Actions, las aprobaciones manuales y las puertas de despliegue.
Despliegue en producción con puertas de aprobación es una lección gratuita de DevOps Bootcamp en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de DevOps Bootcamp, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de DevOps Bootcamp incluye 4 lecciones en total.
Por qué producción necesita controles
El despliegue continuo publica código automáticamente, pero enviarlo directamente a producción sin ningún punto de control es arriesgado. Una versión defectuosa puede afectar al instante a todos los usuarios.
Un control de aprobación es una pausa deliberada en la que una persona (o una comprobación automatizada) confirma que el despliegue debe continuar.
- Reduce el alcance de los errores
- Crea un registro de auditoría de quién aprobó qué
- Permite separar los niveles de confianza de
stagingyproduction
Entornos de GitHub
GitHub Actions tiene una función llamada Environments. Un entorno (como production) puede tener sus propios secretos, variables y reglas de protección.
Haga referencia a un entorno desde un trabajo mediante la clave environment. Esta es la base para añadir controles de aprobación.
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- run: echo 'Deploying to production'Revisores obligatorios
En la configuración del repositorio, en Settings > Environments > production, puede activar Required reviewers.
Cuando un trabajo tiene como destino ese entorno, la ejecución del flujo de trabajo se pausa y espera hasta que uno de los revisores indicados haga clic en Approve.
- Se pueden configurar hasta 6 revisores
- Cualquier aprobación (de forma predeterminada) desbloquea el trabajo
- La persona que aprueba no puede ser quien inició la ejecución, según la configuración
Flujo de trabajo completo con controles
Aquí se ejecuta primero un trabajo build; después, un trabajo deploy depende de él mediante needs y tiene como destino el entorno protegido production.
El despliegue no comenzará hasta que el revisor obligatorio lo apruebe en la interfaz de Actions.
name: Deploy
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo 'build artifact'
deploy:
needs: build
runs-on: ubuntu-latest
environment:
name: production
url: https://myapp.example.com
steps:
- run: echo 'deploy to prod'Temporizadores de espera
Además de revisores, los entornos admiten un temporizador de espera. Esto impone un retraso (de hasta 30 días) antes de que pueda continuar un despliegue.
Un temporizador de espera breve resulta útil como periodo de enfriamiento de seguridad: proporciona al equipo un margen para cancelar una ejecución antes de que llegue a producción.
Restricciones de ramas de despliegue
Los entornos pueden restringir qué ramas tienen permiso para desplegar. Para production, normalmente solo se permite main (o etiquetas de versión).
Esto evita un despliegue accidental en producción desde una rama de funcionalidad.
- Ramas protegidas — solo ramas con reglas de protección
- Ramas seleccionadas — una lista explícita de ramas permitidas o un patrón de etiquetas
Secretos específicos del entorno
Cada entorno tiene sus propios secretos. Un entorno production puede contener PROD_DB_URL, mientras que staging contiene STAGING_DB_URL.
Los secretos definidos en el entorno solo están disponibles para los trabajos que tienen como destino ese entorno, lo que añade otra capa de aislamiento.
steps:
- name: Deploy
env:
DB_URL: ${{ secrets.PROD_DB_URL }}
run: ./deploy.shSeguimiento del estado del despliegue
Establecer una url en el entorno añade un enlace en el que se puede hacer clic al despliegue en la interfaz de GitHub y registra un objeto de despliegue mediante la API de Deployments.
Esto proporciona un historial visible: qué commit llegó a producción, cuándo y quién lo hizo.
environment:
name: production
url: https://myapp.example.comAprobar una ejecución pendiente
Cuando un trabajo con controles está esperando, verá un banner amarillo de Review deployments en la página de ejecución del flujo de trabajo.
- Abra la ejecución en la pestaña Actions
- Haga clic en
Review deployments - Seleccione el entorno y haga clic en
Approve and deployoReject
También puede dejar un comentario para explicar la decisión.
Combinar varios controles
El control de producción más sólido combina varias reglas:
- Revisores obligatorios (aprobación humana)
- Un temporizador de espera (periodo de enfriamiento)
- Restricciones de ramas (solo
main) - Secretos del entorno (aislamiento)
La combinación de estas medidas crea un proceso de promoción sólido de staging a production.
Omitir controles de forma segura
A veces necesita una corrección urgente. En lugar de eliminar las reglas de protección, considere un flujo de trabajo de hotfix independiente y con un alcance limitado, sus propios registros y revisores más estrictos.
No desactive nunca los controles de forma permanente por comodidad, ya que eso anula el propósito del mecanismo de seguridad.
Comprobación rápida
Compruebe su comprensión de los controles de aprobación para producción.
Resumen
Ha aprendido a añadir controles de aprobación para los despliegues en producción mediante los entornos de GitHub.
- Use la clave
environmentpara seleccionar un entorno protegido - Los revisores obligatorios añaden aprobación humana
- Los temporizadores de espera añaden un periodo de enfriamiento
- Las restricciones de ramas y los secretos del entorno añaden aislamiento
En conjunto, estos controles hacen que la promoción de staging a production sea segura y auditable.
Aprende DevOps Bootcamp con un tutor de IA — gratis
Escribe y ejecuta código real en tu navegador, obtén ayuda instantánea de un tutor de IA disponible 24/7 y continúa donde lo dejaste en la web o en la aplicación.
- Cursos
- 142
- Lecciones
- 568
Preguntas frecuentes
¿La lección «Despliegue en producción con puertas de aprobación» es gratis?
Sí — el texto completo de «Despliegue en producción con puertas de aprobación» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de DevOps Bootcamp, actualiza a CoddyKit PRO. El curso de DevOps Bootcamp incluye 4 lecciones en total.
¿Qué aprenderé en «Despliegue en producción con puertas de aprobación»?
Aprenda a promover compilaciones de forma segura de staging a producción mediante las reglas de protección de entornos de GitHub Actions, las aprobaciones manuales y las puertas de despliegue. Practicas DevOps Bootcamp con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar DevOps Bootcamp?
No se requiere experiencia previa. DevOps Bootcamp en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.
¿Cuánto tiempo toma la lección «Despliegue en producción con puertas de aprobación»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de DevOps Bootcamp?
Sí. Cada lección de DevOps Bootcamp incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Introducción al despliegue continuo
- Despliegue en un entorno de staging
- Variables de entorno y secretos
- Despliegue en producción con puertas de aprobación