Hva er en utgivelsesbasert arbeidsflyt?

Fullført

Her diskuterer vi hvordan du kan opprette en utgivelsesbasert arbeidsflyt ved hjelp av GitHub.

Hva er en utgivelsesbasert arbeidsflyt?

En utgivelsesbasert arbeidsflyt er et sett med mønstre og policyer som fokuserer på å lansere programvare. Selv om denne forestillingen kan virke som et åpenbart mål for et utviklingsteam, er verdien av dette perspektivet mer nyansert. I denne enheten diskuterer vi hvordan den driver tre ulike deler av utgivelsessyklusen: administrasjon av prosjektet, valg av forgreningsstrategi og lansering til kunder.

Planlegge arbeid med GitHub-prosjekttavler

Fra en planleggingstankegang betyr det å være utgivelsessentrisk at problemene deles opp i distinkte gjentakelser som produserer en ny versjon. Disse gjentakelsene kalles ofte sprinter, og er tidsbokset i omtrent like perioder for å produsere trinnvise endringer. Andre team foretrekker å pakke hele versjoner til én enkelt gjentakelse som kan vare noen måneder eller lenger. I GitHub administreres disse gjentakelsene som prosjekter.

Den dominerende funksjonen i et prosjekt er tavle. Tavlen er den sentrale planen for gjentakelsen og inneholder alle kortene som skal løses. Et kort kan representere et problem, en pull-forespørsel eller bare et generisk notat.

Som standard starter hvert kort i Hvis du vil gjøre-kolonnen og flyttes til Pågår etter at arbeidet begynner før du slutter på Ferdig. Du kan tilpasse disse kolonnene, legge til flere kolonner eller bruke automatisering på bevegelsen av disse kortene og egenskapene deres for å tilpasse teamets prosess.

Lær mer om administrasjon av prosjekttavler.

Kortets prosjektstatus er integrert på tvers av repositoriet. Hvis du for eksempel drar et kort fra Gjør til Pågår endrer statusen, og oppdaterer den visuelle indikatoren ved siden av prosjektets tittel. Den grønne delen angir delen av kortene som er merket som Ferdig, mens lilla brukes for kort Pågår. Gjenstående plass representerer antall kort som ennå ikke har begynt. I tillegg til å dra kort rundt på tavlen, kan du oppdatere dem fra hovedvisningen.

Når du bruker en prosjekttavle, har alle interessenter en enkel måte å forstå statusen og hastigheten til et prosjekt på. Du kan også opprette tavler som er begrenset til individuelle brukere eller en samling repositorier som eies av en organisasjon.

Lær mer om spore fremdriften i arbeidet med prosjekttavler.

Sporing av bestemte milepæler

For team, eller muligens delsett av team, tilbyr GitHub milepæl sporing.

Milepæler ligner på prosjektsporing ved at det legges vekt på prioritert fullføring av problemer og pull-forespørsler. Men der et prosjekt kan være fokusert på teamets prosess, er en milepæl fokusert på produktet.

Lær mer om spore fremdriften i arbeidet med milepæler.

Velge en forgreningsstrategi

Repositorier som har flere utviklere som arbeider parallelt, trenger en veldefinert forgreningsstrategi. Å slå seg ned på en enhetlig tilnærming tidlig i prosjektet sparer forvirring og frustrasjon som team og kodebaseskala.

GitHub-flyten

I tillegg til å tilby en plattform for utvikling av samarbeidende programvare, tilbyr GitHub også en foreskrevet arbeidsflyt som er utformet for å optimalisere bruken av de ulike funksjonene. Selv om GitHub kan arbeide med nesten alle programvareutviklingsprosesser, anbefaler vi at du vurderer GitHub-flyten hvis teamet ikke er avgjort på en prosess ennå.

Arbeide med langvarige grener

En langvarig gren er en Git-gren som aldri slettes. Noen lag foretrekker å unngå dem helt til fordel for kortvarige funksjoner og bug-fix grener. For disse teamene er målet med enhver innsats å produsere en pull-forespørsel som slår sammen arbeidet tilbake til main. Denne fremgangsmåten kan være effektiv for prosjekter som aldri har behov for å se tilbake, for eksempel førsteparts webprogrammer som ikke støtter en tidligere versjon.

Det finnes imidlertid visse scenarier der en langvarig gren tjener det beste for et team. Det vanligste tilfellet for en langvarig gren er når et produkt har flere versjoner som må støttes i en lengre periode. Når et team må planlegge for denne forpliktelsen, bør repositoriet følge en standardkonvensjon, for eksempel release-v1.0, release-v2.0og så videre. Disse grenene bør også merkes som beskyttet i GitHub, slik at skrivetilgang kontrolleres, og de kan ikke slettes ved et uhell.

Teams bør fortsatt opprettholde main ettersom rotgrenen og sammenslåing av utgivelsesgrenen endres oppstrøms så lenge de passer inn i prosjektets fremtid. Når tiden er inne, bør release-v3.0 basere seg på main slik at servicearbeid for release-v2.0 ikke kompliserer repositoriet.

Vedlikehold av langvarige grener

La oss si at en feilretting ble slått sammen til release-v2.0 gren, og deretter slått sammen igjen oppstrøms til main. Det ble senere oppdaget at denne feilen også eksisterte i den release-v1.0 grenen, og løsningen som måtte backporteres for kunder som fortsatt bruker denne versjonen. Hva er den beste måten å backportere denne løsningen på?

Sammenslåing av main gren ned til release-v1.0 ville ikke være et mulig alternativ, siden det ville inneholde et betydelig antall forpliktelser som ikke var ment å være en del av den versjonen. Av samme grunn, rebasing release-v1.0 på gjeldende main utføring ville ikke være et alternativ.

Et alternativ ville være å manuelt reimplementere løsningen på release-v1.0 gren, men denne tilnærmingen ville kreve mye omarbeiding og ikke skalere godt på tvers av flere versjoner. Git tilbyr imidlertid en automatisert løsning på dette problemet i form av kommandoen cherry-pick.

Hva er Gits cherry-pick-kommando?

git cherry-pick er en kommando som lar deg bruke bestemte utføringer fra én gren til en annen. Den gjentakelser ganske enkelt de valgte utføringene og bruker dem på målgrenen som nye utføringer. Om nødvendig kan utviklere slå sammen eventuelle konflikter før de fullfører bakporten.

Finn ut mer om Git's cherry-pick.

Slippe til forbrukere

Når en produktversjon er klar til å lanseres, forenkler GitHub prosessen med å pakke den opp og varsle forbrukerne.

Det er like enkelt å opprette en versjon som å fylle ut skjemaet:

• Skriv inn en Git-kode som skal brukes, som skal følge semantisk versjonskontroll, for eksempel v1.0.2. GitHub administrerer prosessen med å opprette Git-koden du angir.
• Skriv inn et navn for utgivelsen. Noen vanlige fremgangsmåter er å:
  • Bruke et beskrivende navn
  • Bruk Git-versjonen
  • Bruk et kortfattet sammendrag av hvordan utgivelsen endret seg siden den forrige
  • Bruke et kodenavn eller et tilfeldig uttrykk
• Oppgi produktmerknader. Du kan automatisere denne oppgaven med Release Drafter-appen, som analyserer endringene siden forrige versjon og inkluderer de tilknyttede pull-forespørselstitlene.
• Hvis du vil oppgi filer som en del av utgivelsen, for eksempel forhåndsbygde installasjonsprogram, kan du dra og slippe dem på skjemaet. Du trenger ikke å pakke kilden som GitHub håndterer det automatisk.
• Angi om versjonen er forhåndsutgitt ved å merke av for denne boksen. Denne indikasjonen hjelper kundene med å unngå forhåndsutleieversjoner hvis de vil.

Når en utgivelse er publisert, mottar alle som ser repositoriet et varsel.

Lær mer om GitHub-utgivelser.