Voeg deze persoon toe aan Vercel zodat die kan deployen. Of doe het gewoon niet.

Ten tijde van deze implementatie kostte Vercel Pro 20 dollar per licentie. Drie engineers zouden 60 dollar per maand kosten en vijf of zes 100 tot 120 dollar. Het team behield één projectlicentie van 20 dollar en verplaatste de uitvoering van implementaties via de Vercel CLI naar GitHub Actions.

De repository sloeg VERCEL_TOKEN, VERCEL_ORG_ID en VERCEL_PROJECT_ID op als geheimen. Engineers konden beoordeeld werk via het normale trunkgebaseerde mergepad opleveren zonder dat iedereen dashboardreferenties kreeg.

Ik verdeelde de implementatie over twee workflows. Merges naar main werkten staging bij; productie vereiste na QA een handmatige release door een geautoriseerde GitHub-actor.

Pull request -> beoordeling -> merge naar main
  -> automatische stagingbuild en -implementatie
  -> QA
  -> geautoriseerde productieworkflow
  -> tag, release, implementatie en Slack-melding

Repositorytoegang gaf niet automatisch toegang tot productie. In de oorspronkelijke workflow mocht Elusive7733 productie activeren, terwijl de rest van het team via pull requests en staging opleverde.

Elke push naar main haalde de stagingomgeving op, bouwde een vooraf gebouwd artefact met --target=staging en implementeerde exact die uitvoer. Een gedeelde gelijktijdigheidsgroep gebruikte cancel-in-progress: true, zodat een nieuwere main-commit een verouderde, wachtende of draaiende stagingimplementatie verving.

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

De handmatige productieworkflow accepteerde patch, minor of major. Met de volledige Git-geschiedenis beschikbaar las deze de nieuwste tag, berekende de volgende semantische versie, maakte en pushte de tag, haalde de productieomgeving op, bouwde het vooraf gebouwde artefact en implementeerde het.

Een afzonderlijk skip-tagging-pad gebruikte de nieuwste versie opnieuw voor een herimplementatie. Voor herstel hoefde geen onterecht nieuw releasenummer te worden aangemaakt om alleen infrastructuur opnieuw uit te voeren.

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

Na een getagde release maakte gh release create --generate-notes het wijzigingsoverzicht. .github/release.yml groepeerde pull requests per label. De workflow voegde implementatiemetadata toe en stuurde een opgemaakte release via een Slack-webhook.

Ik bouwde eerst een AI-generator voor wijzigingsoverzichten en verwijderde deze drie dagen later. GitHub vermeldde elk gemerged pull request en elke koppeling al, dus het model voegde code toe zonder nuttige release-informatie toe te voegen.

De werkwijze was eenvoudig: merge een beoordeeld pull request, implementeer staging, verifieer die omgeving en laat daarna een geautoriseerde actor productie activeren. Versietags, GitHub-releases en Slack-berichten lieten buiten het Vercel-dashboard een releasespoor achter.

• Gebruik repository- en omgevingsbeveiliging voor de referenties die dashboardtoegang vervangen.
• Scheid automatische beoordelingsimplementaties van doelbewuste productie-uitvoering.
• Bouw één keer en implementeer het vooraf gebouwde artefact voor elke omgeving.
• Gebruik standaard native releaseopmerkingen voordat je een extra generatiesysteem toevoegt.