Approvegate est une solution de gestion des changements qui vérifie votre déploiement par rapport à un enregistrement d'approbation signé et à la documentation avant qu'il n'atteigne la production — et le bloque, avec une raison, s'il n'est pas réel.
# étape de déploiement
deploy_ledger-api_prod:
stage: deploy
environment:
name: production
script:
- approvegate check
--service ledger-api
# SHA + release lus automatiquement —
# le release vient du tag quand le pipeline
# s'exécute suite à un push de tag, ex. v2.14.3.
# les déploiements déclenchés par une branche
# nécessitent --release explicitement.
# échoue le job si non approuvév2.14.3 n'a pas été approuvé pour le déploiement en production. Tickets de déploiement approuvés actifs - www.approvegate.io/team/approvegate/active
exit 1 · pipeline arrêté avant la promotion
La protection de branche vérifie qu'un diff a été revu avant la fusion. Cela ne dit rien sur le fait que cette build soit autorisée à être déployée en production maintenant — selon la politique actuelle, en dehors de tout gel. Approvegate est cette seconde vérification.
"La PR a été revue et fusionnée. Trois semaines plus tard, cette build était dans la file, prête à partir — et personne n'avait ré-autorisé le déploiement."
Approvegate n'est pas un portail vers lequel vous migrez. C'est une API que votre pipeline appelle, adossée à un registre minimal de qui a approuvé quoi.
Une GitHub Action ou une étape GitLab CI que vous ajoutez à votre job de déploiement existant. Elle appelle l'API Approvegate avec la version de l'artefact et le nom du service — et le pipeline échoue de façon sûre si la réponse est non.
Juste assez de surface pour créer une demande de changement liée à un artefact, enregistrer qui l'a approuvée et joindre la politique qui l'a régie. Pas un planificateur de mise en production. Pas un second Jira.
Vous ne connaîtrez pas encore la build exacte — le pipeline n'a pas encore tourné. Approuvez la mise en production et qui est habilité à signer ; l'artefact se verrouille automatiquement dès qu'il est construit. Définissez une expiration, et une approbation périmée ne pourra pas autoriser un déploiement des semaines plus tard sans que personne ne pense à la révoquer.
C'est le même contrôle qui aurait détecté la build vieille de trois semaines de tout à l'heure — une approbation expirée ne peut pas autoriser un déploiement, que quelqu'un pense à vérifier ou non.
La vérification nous contacte à chaque déploiement, donc la disponibilité compte — nous construisons et surveillons pour atteindre 99,99 % de disponibilité. Mais un SLA seul ne suffit pas pour un P1. Vous configurez votre propre chemin d'urgence, dans votre propre pipeline, selon vos propres conditions.
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"
# contourne la vérification standard, journalisé comme déploiement d'urgenceDéclarez une exception limitée dans le temps plutôt que de modifier le pipeline sous pression. Aucun fichier à valider, aucun indicateur à penser à retirer — cela revient à votre politique normale tout seul.
Ceci n'est pas là pour vous convaincre que l'approbation des changements compte. C'est pour les équipes qui le croient déjà, ont déjà un processus, et en ont assez qu'il soit de la paperasse plutôt qu'une protection.
Chaque vérification — autorisée, bloquée ou escaladée — atterrit dans un journal append-only : artefact, approbateur, politique et résultat. Exportez-le quand un évaluateur le demande. Vous n'avez rien fait de plus pour l'obtenir.
Voir un exemple d'exportUn petit nombre de partenaires de conception installent le paquet sur un pipeline, un service de production — en conditions réelles, en production ou hors production.
Ajoutez l'Action/l'étape CI à un vrai job de déploiement.
Exécutez la vérification sur un vrai déploiement, où que vous l'exécutiez — un environnement de staging ou directement en production.
Vous définissez ce que "approuvé" signifie pour votre équipe — nous l'appliquons.
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.
