Ajoutez cette personne à Vercel pour qu’elle puisse déployer. Ou ne le faites pas.

Au moment de cette implémentation, Vercel Pro coûtait 20 $ par siège. Trois ingénieurs coûtaient 60 $ par mois et cinq ou six coûtaient de 100 à 120 $. L’équipe a conservé un siège de projet à 20 $ et déplacé l’exécution des déploiements dans GitHub Actions au moyen de la CLI Vercel.

Le dépôt stockait VERCEL_TOKEN, VERCEL_ORG_ID et VERCEL_PROJECT_ID comme secrets. Les ingénieurs pouvaient livrer le travail revu au moyen du parcours de fusion trunk-based habituel sans recevoir chacun des identifiants pour le tableau de bord.

J’ai séparé le déploiement en deux flux de travail. Les fusions dans main mettaient à jour la préproduction ; la mise en production devait être déclenchée manuellement après la QA par un acteur GitHub autorisé.

Pull request -> revue -> fusion dans main
  -> construction et déploiement automatiques en préproduction
  -> QA
  -> flux de travail de production autorisé
  -> tag, publication, déploiement, notification Slack

L’accès au dépôt n’accordait pas automatiquement l’accès à la production. Le flux de travail d’origine autorisait Elusive7733 à déclencher la production, tandis que le reste de l’équipe livrait son travail au moyen de pull requests et de la préproduction.

Chaque push vers main récupérait l’environnement de préproduction, construisait un artefact précompilé avec --target=staging, puis déployait exactement cette sortie. Un groupe de concurrence partagé utilisait cancel-in-progress: true afin qu’un commit main plus récent remplace un déploiement de préproduction obsolète, en attente ou en cours.

concurrency:
  group: staging-deploy
  cancel-in-progress: true

- run: vercel pull --yes --environment=staging --token=$VERCEL_TOKEN
- run: vercel build --target=staging --token=$VERCEL_TOKEN
- run: vercel deploy --prebuilt --target=staging --token=$VERCEL_TOKEN

Le flux de travail de production manuel acceptait patch, minor ou major. Avec l’historique Git complet, il lisait le dernier tag, calculait la version sémantique suivante, créait et publiait le tag, récupérait l’environnement de production, construisait l’artefact précompilé et le déployait.

Un chemin skip-tagging distinct réutilisait la dernière version pour un redéploiement. La reprise d’une publication n’avait pas besoin de créer un faux numéro de version uniquement pour relancer l’infrastructure.

on:
  workflow_dispatch:
    inputs:
      version_type:
        type: choice
        options: [patch, minor, major]
      skip_tagging:
        type: boolean
        default: false

Après une publication avec tag, gh release create --generate-notes produisait le journal des modifications. .github/release.yml regroupait les pull requests par étiquette. Le flux de travail ajoutait les métadonnées de déploiement et envoyait un avis de publication mis en forme au moyen d’un webhook Slack.

J’ai d’abord conçu un générateur de journal des modifications par IA, puis je l’ai supprimé trois jours plus tard. GitHub répertoriait déjà chaque pull request fusionnée avec son lien. Le modèle ajoutait donc du code sans fournir d’informations utiles sur la publication.

La séquence opérationnelle était simple : fusionner une pull request revue, déployer en préproduction, vérifier, puis laisser un acteur autorisé déclencher la production. Les tags de version, les publications GitHub et les messages Slack conservaient une trace des publications hors du tableau de bord Vercel.

• Utilisez les protections du dépôt et de l’environnement pour les identifiants qui remplacent l’accès au tableau de bord.
• Séparez les déploiements automatiques de revue de l’exécution délibérée en production.
• Construisez une fois, puis déployez l’artefact précompilé pour chaque environnement.
• Utilisez par défaut les notes de publication natives avant d’ajouter un autre système de génération.