Approvegate es una solución de gestión de cambios que verifica tu despliegue contra un registro de aprobación firmado y documentación antes de que llegue a producción — y lo bloquea, con una razón, si no es real.
# etapa de despliegue
deploy_ledger-api_prod:
stage: deploy
environment:
name: production
script:
- approvegate check
--service ledger-api
# SHA + release se leen automáticamente —
# el release viene del tag cuando el pipeline
# se ejecuta por un push de tag, ej. v2.14.3.
# los despliegues por rama necesitan --release explícito.
# falla el job si no está aprobadov2.14.3 no ha sido aprobado para el despliegue en producción. Tickets de despliegue aprobados activos - www.approvegate.io/team/approvegate/active
exit 1 · pipeline detenido antes de la promoción
La protección de ramas verifica que un diff fue revisado antes de la fusión. No dice nada sobre si esta build está habilitada para desplegarse a producción ahora mismo — bajo la política actual, fuera de cualquier congelamiento. Approvegate es esa segunda verificación.
"El PR fue revisado y fusionado. Tres semanas después esa build estaba en la cola, lista para desplegarse — y nadie había vuelto a autorizar el despliegue."
Approvegate no es un portal al que migras. Es una API que tu pipeline llama, respaldada por un registro mínimo de quién aprobó qué.
Una GitHub Action o paso de GitLab CI que agregas a tu job de despliegue existente. Llama a la API de Approvegate con la versión del artefacto y el nombre del servicio — y el pipeline falla de forma segura si la respuesta es no.
Justo la superficie necesaria para crear una solicitud de cambio vinculada a un artefacto, registrar quién la aprobó y adjuntar la política que la gobernó. No es un planificador de lanzamientos. No es un segundo Jira.
Todavía no conocerás la build exacta — el pipeline aún no se ha ejecutado. Aprueba el lanzamiento y quién puede firmarlo; el artefacto se fija automáticamente en el momento en que se construye. Define una caducidad, y una aprobación vencida no podrá autorizar un despliegue semanas después sin que nadie recuerde revocarla.
Este es el mismo control que habría detectado la build de tres semanas de antigüedad de antes — una aprobación vencida no puede autorizar un despliegue, sin importar si alguien recuerda verificarlo.
La verificación nos llama en cada despliegue, así que la disponibilidad importa — construimos y monitoreamos hacia un 99.99% de uptime. Pero un SLA por sí solo no es suficiente para un P1. Tú configuras tu propio camino de emergencia, en tu propio pipeline, en tus propios términos.
deploy_ledger-api_prod_emergency:
stage: deploy
environment:
name: production
script:
- approvegate check
--service ledger-api
--release v2.14.4-hotfix
--force-approve
--reason "sev1-incident-4821"
# omite la verificación estándar, registrado como despliegue de emergenciaDeclara una excepción acotada en el tiempo en lugar de editar el pipeline bajo presión. Sin archivo que confirmar, sin bandera que recordar quitar — vuelve a tu política normal por sí sola.
Esto no está aquí para convencerte de que la aprobación de cambios importa. Es para equipos que ya creen eso, ya tienen un proceso, y están cansados de que sea papeleo en lugar de protección.
Cada verificación — permitida, bloqueada o escalada — queda en un registro append-only: artefacto, aprobador, política y resultado. Expórtalo cuando un evaluador lo pida. No hiciste nada extra para obtenerlo.
Ver una exportación de muestraUn número reducido de socios de diseño obtiene el paquete instalado en un pipeline, un servicio de producción — ejecutándose contra un despliegue real en producción o non-prod.
Agrega el Action/paso de CI a un job de despliegue real.
Ejecuta la verificación contra un despliegue real, donde sea que lo ejecutes — un entorno de staging o directo a producción.
Tú defines qué significa "aprobado" para tu equipo — nosotros lo hacemos cumplir.
Tell me a little about your team and I’ll follow up to schedule a demo.
Opens your email app with the subject and message filled in.
