Hvad er en udgivelsesbaseret arbejdsproces?

Fuldført

Her diskuterer vi, hvordan du kan oprette en udgivelsesbaseret arbejdsproces ved hjælp af GitHub.

Hvad er en udgivelsesbaseret arbejdsproces?

En udgivelsesbaseret arbejdsproces er et sæt mønstre og politikker, der fokuserer på udgivelse af software. Selvom denne opfattelse kan virke som et åbenlyst mål for et udviklingsteam, er værdien af dette perspektiv mere nuanceret. I dette undermodul drøfter vi, hvordan det styrer tre forskellige dele af udgivelsescyklussen: administration af projektet, valg af en forgreningsstrategi og frigivelse til kunder.

Planlægningsarbejde med GitHub-projektforummer

Fra et planlægningstankesæt betyder udgivelsescentreret, at problemer er opdelt i forskellige gentagelser, der producerer en ny version. Disse gentagelser kaldes ofte sprintsog er tidsbokse i omtrent lige perioder for at skabe trinvise ændringer. Andre teams foretrækker at pakke hele udgivelsesversioner til en enkelt gentagelse, der kan vare et par måneder eller længere. I GitHub administreres disse gentagelser som projekter.

Det dominerende træk ved et projekt er dets bestyrelse. Tavlen er den centrale plan for registrering af gentagelsen og indeholder alle de kort, der skal løses. Et kort kan repræsentere et problem, en pullanmodning eller endda blot en generisk note.

Hvert kort starter som standard i kolonnen At gøre og flytter til Igangværende, når arbejdet starter, før det slutter med Udført. Du kan tilpasse disse kolonner, tilføje flere kolonner eller anvende automatisering på flytningen af disse kort og deres egenskaber, så de passer til dit teams proces.

Få mere at vide om administration af projektforummer.

Kortets projektstatus er integreret på tværs af lageret. Hvis du f.eks. trækker et kort fra Gør for at Igangværende ændrer dets status og opdaterer visualiseringsindikatoren ud for projektets titel. Den grønne sektion angiver den del af kortene, der er markeret som Udført, mens lilla bruges til kort Igangværende. Den resterende plads repræsenterer antallet af kort, der endnu ikke er begyndt. Ud over at trække kort rundt på tavlen kan du opdatere dem fra deres hovedvisning.

Når du bruger en projekttavle, har alle interessenter en nem måde at forstå status og hastighed på et projekt på. Du kan også oprette tavler, der er beregnet til individuelle brugere eller en samling af lagre, der ejes af en organisation.

Få mere at vide om sporing af status for dit arbejde med projektforummer.

Sporing af specifikke milepæle

GitHub tilbyder milepælssporing for teams eller muligvis undersæt af teams.

Milepæle svarer til projektsporing, da der lægges vægt på prioriteret fuldførelse af problemer og pullanmodninger. Men hvor et projekt kan være fokuseret på teamets proces, er en milepæl fokuseret på produktet.

Få mere at vide om sporing af status for dit arbejde med milepæle.

Valg af en forgreningsstrategi

Lagre, hvor flere udviklere arbejder parallelt, har brug for en veldefineret forgreningsstrategi. Hvis du vælger en samlet tilgang tidligt i projektet, sparer det forvirring og frustration som team- og codebase-skala.

GitHub-flowet

Ud over at levere en platform til samarbejdsbaseret softwareudvikling tilbyder GitHub også en foreskrevet arbejdsproces, der er designet til at optimere brugen af de forskellige funktioner. Selvom GitHub kan arbejde med stort set enhver softwareudviklingsproces, anbefaler vi, at du overvejer GitHub-flowet, hvis dit team endnu ikke er afgjort på en proces.

Arbejde med langlivede forgreninger

En langlivet forgrening er en Git-forgrening, der aldrig slettes. Nogle teams foretrækker at undgå dem helt til fordel for kortlivede funktioner og fejlrettelsesforgreninger. For disse teams er målet for enhver indsats at oprette en pullanmodning, der fletter deres arbejde tilbage til main. Denne fremgangsmåde kan være effektiv for projekter, der aldrig har behov for at se tilbage, f.eks. webprogrammer fra førstepart, der ikke understøtter en tidligere version.

Der er dog visse scenarier, hvor en langlivet forgrening tjener et teams bedste interesser. Det mest almindelige tilfælde for en langlivet forgrening er, når et produkt har flere versioner, der skal understøttes i en længere periode. Når et team skal planlægge denne forpligtelse, skal lageret følge en standardkonvention, f.eks. release-v1.0, release-v2.0osv. Disse forgreninger skal også markeres som beskyttet i GitHub, så skriveadgang styres, og de kan ikke slettes ved et uheld.

Teams bør stadig bevare main, da rodgrenen og fletter deres udgivelsesgrene opstrøms, så længe de passer ind i projektets fremtid. Når tiden er inde, skal release-v3.0 basere sig på main, så servicearbejde for release-v2.0 ikke komplicerer lageret.

Servicering af langlivede grene

Antag, at en fejlrettelse blev flettet med forgreningen release-v2.0 og derefter flettet igen opstrøms i main. Det blev derefter senere opdaget, at denne fejl også eksisterede i forgreningen release-v1.0, og at rettelsen skulle tilbageporteres for kunder, der stadig bruger denne version. Hvad er den bedste måde at backporte denne rettelse på?

Det ville ikke være muligt at flette forgreningen main ned i release-v1.0, da den ville indeholde et betydeligt antal bekræftelser, der ikke var beregnet til at være en del af den pågældende version. Af samme grund ville det ikke være en mulighed at ombasere release-v1.0 på den aktuelle main commit.

En alternativ mulighed kan være manuelt at genimplementere rettelsen på forgreningen release-v1.0, men denne fremgangsmåde kræver meget omarbejde og skaleres ikke godt på tværs af flere versioner. Git tilbyder dog en automatiseret løsning på dette problem i form af kommandoen cherry-pick.

Hvad er Git's cherry-pick kommando?

git cherry-pick er en kommando, der giver dig mulighed for at anvende bestemte bekræftelser fra én forgrening til en anden. Den gentager blot de valgte bekræftelser og anvender dem på målgrenen som nye bekræftelser. Hvis det er nødvendigt, kan udviklere flette eventuelle konflikter, før de afslutter backporten.

Få mere at vide om Gits.

Frigivelse til forbrugere

Når en produktversion er klar til at blive frigivet, forenkler GitHub processen med at pakke den op og give forbrugerne besked.

Oprettelse af en version er lige så ligetil som at udfylde formularen:

• Angiv et Git-mærke, der skal anvendes, som skal følge semantiske versionering, f.eks. v1.0.2. GitHub administrerer processen med at oprette det Git-mærke, du angiver.
• Angiv et navn til din udgivelse. Nogle almindelige fremgangsmåder er at:
  • Brug et beskrivende navn
  • Brug Git-versionen
  • Brug en kort oversigt over, hvordan udgivelsen er ændret siden den forrige
  • Brug et kodenavn eller et tilfældigt udtryk
• Angiv produktbemærkninger. Du kan automatisere denne opgave med appen Release Drafter, som analyserer ændringerne siden den tidligere version og indeholder de tilknyttede pullanmodningstitler.
• Hvis du vil angive filer som en del af udgivelsen, f.eks. færdigbyggede installationsprogrammer, kan du trække og slippe dem til formularen. Du behøver ikke at pakke kilden, da GitHub håndterer det for dig automatisk.
• Angiv, om versionen er foreløbig, ved at markere afkrydsningsfeltet. Denne indikation hjælper kunderne med at undgå foreløbige versioner, hvis de vil.

Når en udgivelse er publiceret, modtager alle, der ser lageret, en meddelelse.

Få mere at vide om GitHub-udgivelser.