Gå til innhold

Utrulling med GitHub Actions

Legg personen til i Vercel så de kan rulle ut. Eller la være.

Slik håndterte en tidligere GitHub Actions-arbeidsflyt et felles stagingmiljø og godkjente produksjonsutgivelser uten et betalt Vercel-sete til hver utvikler.

5 min lesetidAv

Alle artikler

Tilgang til kontrollpanelet er ikke det samme som tilgang til utrulling

Da dette ble implementert, kostet Vercel Pro $20 per sete. Tre utviklere ville kostet $60 i måneden, og fem eller seks ville kostet $100 til $120. Teamet beholdt ett prosjektsete til $20 og flyttet kjøringen av utrullinger til GitHub Actions gjennom Vercel CLI.

Kodelageret oppbevarte VERCEL_TOKEN, VERCEL_ORG_ID og VERCEL_PROJECT_ID som hemmeligheter. Utviklerne kunne levere gjennomgått arbeid gjennom den vanlige, trunkbaserte sammenslåingsbanen uten at alle fikk legitimasjon til kontrollpanelet.

Skill staging fra produksjon

Jeg delte utrullingen i to arbeidsflyter. Sammenslåinger til main oppdaterte staging. Produksjon krevde en manuell utgivelse etter QA, utløst av en godkjent GitHub-aktør.

Pull request -> gjennomgang -> slå sammen til main
  -> automatisk bygging og utrulling til staging
  -> QA
  -> godkjent produksjonsarbeidsflyt
  -> tagg, utgivelse, utrulling, Slack-varsel

Tilgang til kodelageret ga ikke automatisk produksjonstilgang. Den opprinnelige arbeidsflyten lot Elusive7733 utløse produksjon, mens resten av teamet leverte gjennom pull requests og staging.

Automatiser miljøet som brukes til gjennomgang

Hver push til main hentet stagingmiljøet, bygde en forhåndsbygd artefakt med --target=staging og rullet ut nøyaktig dette resultatet. En felles samtidighetsgruppe brukte cancel-in-progress: true, slik at en nyere commit på main erstattet en foreldet stagingutrulling som sto i kø eller allerede kjørte.

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

Gjør produksjonsutrullingen bevisst

Den manuelle produksjonsarbeidsflyten godtok patch, minor eller major. Med full Git-historikk tilgjengelig leste den nyeste tagg, beregnet neste semantiske versjon, opprettet og pushet taggen, hentet produksjonsmiljøet, bygde den forhåndsbygde artefakten og rullet den ut.

En separat skip-tagging-bane gjenbrukte den nyeste versjonen ved ny utrulling. Gjenoppretting trengte dermed ikke opprette et uriktig, nytt utgivelsesnummer bare for å kjøre infrastrukturen på nytt.

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

Legg igjen et driftsspor

Etter en tagget utgivelse produserte gh release create --generate-notes endringsloggen. .github/release.yml grupperte pull requests etter etikett. Arbeidsflyten la til metadata om utrullingen og sendte en formatert utgivelse gjennom en Slack-webhook.

Jeg bygde først en KI-generator for endringsloggen og slettet den tre dager senere. GitHub listet allerede alle sammenslåtte pull requests og lenker, så modellen la til kode uten å tilføre nyttig utgivelsesinformasjon.

Betal for tilgangen systemet faktisk trenger

Arbeidsrekkefølgen var enkel: slå sammen en gjennomgått pull request, rull ut til staging, verifiser den og la deretter en godkjent aktør utløse produksjonsutrullingen. Versjonstagger, GitHub-utgivelser og Slack-meldinger ga et utgivelsesspor utenfor kontrollpanelet i Vercel.

  • Bruk beskyttelse av kodelager og miljø for legitimasjonen som erstatter tilgang til kontrollpanelet.
  • Skill automatiske utrullinger til gjennomgang fra bevisst kjøring i produksjon.
  • Bygg én gang, og rull ut den forhåndsbygde artefakten til hvert miljø.
  • Bruk innebygde utgivelsesnotater som standard før enda et genereringssystem legges til.