Alltför många brancher i en kodbas med komplicerad integration skapar ofta problem i utvecklingsorganisationer. Genom att införa versions­hanterings-metodiken Gitflow så slipper du många problem och förvirring kring versions­hanteringen under din mjukvaruutveckling. Gitflow kan vara lösning på dina problem men beror på hur din utvecklings- och deployment-process ser ut och hur ofta man levererar.

Utmaning att hålla koll på kodbrancher

Matherey Nunez är konsult på Citerus inom modern kvalitetsarbete, med lång erfarenhet av testning. Hon har arbetat på många olika företag i rollen som testutvecklare och testledare

Matherey berättar om ett projekt med releaser var tredje vecka, där var det en utmaning med flera kodbrancher och problem att hålla både master-branchen och dev-branchen stabil.

Ofta pushades ny kod in i master direkt där det borde gått via dev. Det saknades även heltäckande enhetstester, automatiserade tester och verifikation. De manuella testerna och bristfälligt dokumenterade testfall som fanns gav tveksamt resultat och tog lång tid att utföra.

Med många parallella brancher blev det svårt att ha kontroll över all kod och hantera integration. Det var ständiga problem kring merge-konflikter när ny kod skulle in i dev-branchen.

Git flow. Before (2)

Bättre struktur med git flow

Efter att Gitflow infördes så skapades det en bättre struktur på arbetsflödet med hanterbara repo och begriplig kodmassa. För att slippa problem och förvirring kring versions­hantering så rekommenderas användning av en versions­hanterings-metodik som kallas för Gitflow.

Läs gärna vidare: //danielkummer.github.io/git-flow-cheatsheet

Gitflow är ett bra sätt att hålla ordning på alla kodbaser om man inte har dagliga releaser direkt från master-branchen. I tabellen nedan finns exempel på hur det kan se ut:

Git flow. After

Branch                                Förklaring                                             Kommentar                                                   
master    Stabil kod Ska alltid fungera
release    Skapas från develop Merge till master och develop när  färdigt
hotfix    Skapas från master Merge till master och develop när färdigt
develop    Normalt sprintens bas Merge till master o dev efter release
feature    En per user story etc. Merge till develop när storyn är färdig

QA/test är den som oftast ansvarar för att godkänna att acceptanskriterierna i en user story är uppfylld och färdigtestad. Allt detta ovan gör att du får en lyckad resa i din mjukvaruutveckling.

Skriv en kommentar