Diese Person zu Vercel hinzufügen, damit sie bereitstellen kann. Oder einfach nicht.

Zum Zeitpunkt dieser Implementierung kostete Vercel Pro 20 US-Dollar pro Lizenzplatz. Drei Entwickler hätten monatlich 60 US-Dollar gekostet, fünf oder sechs Entwickler 100 bis 120 US-Dollar. Das Team behielt einen Projektlizenzplatz für 20 US-Dollar und verlagerte die Ausführung der Bereitstellung über die Vercel CLI in GitHub Actions.

Das Repository speicherte VERCEL_TOKEN, VERCEL_ORG_ID und VERCEL_PROJECT_ID als Geheimnisse. Entwickler konnten geprüfte Arbeit über den normalen trunkbasierten Merge-Weg ausliefern, ohne jeweils eigene Dashboard-Anmeldedaten zu erhalten.

Ich teilte die Bereitstellung in zwei Arbeitsabläufe. Merges nach main aktualisierten das Staging; der Produktivbetrieb erforderte nach der QA ein manuelles Release durch einen autorisierten GitHub-Akteur.

Pull Request -> Prüfung -> Merge nach main
  -> automatischer Staging-Build und Bereitstellung
  -> QA
  -> autorisierter Produktiv-Arbeitsablauf
  -> Tag, Release, Bereitstellung, Slack-Hinweis

Repositoryzugriff gewährte nicht automatisch Produktivzugriff. Der ursprüngliche Arbeitsablauf erlaubte Elusive7733, die Produktivbereitstellung auszulösen, während der Rest des Teams über Pull Requests und Staging auslieferte.

Jeder Push auf main rief die Staging-Umgebung ab, baute mit --target=staging ein vorgebautes Artefakt und stellte genau diese Ausgabe bereit. Eine gemeinsame Nebenläufigkeitsgruppe nutzte cancel-in-progress: true, damit ein neuerer main-Commit eine überholte Bereitstellung in der Warteschlange oder in Ausführung ersetzte.

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

Der manuelle Produktiv-Arbeitsablauf akzeptierte patch, minor oder major. Mit vollständigem Git-Verlauf las er den neuesten Tag, berechnete die nächste semantische Version, erstellte und pushte den Tag, rief die Produktivumgebung ab, baute das vorgefertigte Artefakt und stellte es bereit.

Ein getrennter skip-tagging-Weg verwendete für eine erneute Bereitstellung die neueste Version. Zur Wiederherstellung musste keine falsche neue Releasenummer erstellt werden, nur um Infrastruktur erneut auszuführen.

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

Nach einem mit Tag versehenen Release erzeugte gh release create --generate-notes das Änderungsprotokoll. .github/release.yml gruppierte Pull Requests nach Label. Der Arbeitsablauf ergänzte Bereitstellungsmetadaten und sendete ein formatiertes Release über einen Slack-Webhook.

Ich entwickelte zuerst einen KI-Änderungsprotokollgenerator und löschte ihn drei Tage später. GitHub führte bereits jeden zusammengeführten Pull Request samt Link auf, daher fügte das Modell Code hinzu, aber keine nützlichen Releaseinformationen.

Die funktionierende Abfolge war einfach: einen geprüften Pull Request zusammenführen, im Staging bereitstellen und prüfen und anschließend einen autorisierten Akteur die Produktivbereitstellung auslösen lassen. Versions-Tags, GitHub-Releases und Slack-Nachrichten hinterließen außerhalb des Vercel-Dashboards eine Releasespur.

• Schützen Sie die Anmeldedaten, die den Dashboardzugriff ersetzen, auf Repository- und Umgebungsebene.
• Trennen Sie automatische Prüfbereitstellungen von der bewussten Ausführung im Produktivbetrieb.
• Bauen Sie einmal, und stellen Sie das vorgefertigte Artefakt für jede Umgebung bereit.
• Nutzen Sie integrierte Releasehinweise als Standard, bevor Sie ein weiteres Erzeugungssystem ergänzen.