Funksjonsgren

Hva er en featuregren?

En featuregren er en kopi av hovedkodebasen der en enkeltperson eller et team av programvareutviklere kan jobbe med en ny funksjon helt til den er ferdig.

Når mange ingeniører jobber i samme kodebase, er det viktig å ha en strategi for hvordan de jobber sammen. For å unngå å overstyre hverandres endringer, oppretter ingeniørene sine egne kopier av kodebasen, kalt grener. I analogi med et tre kalles master-grenen noen ganger for stammen. Prosessen med å innlemme endringene i den enkeltes kopi i hovedstammen kalles sammenslåing.

Utviklingsprosessen for funksjonsgrener

Ved utvikling av funksjonsgrener fletter ikke individuelle ingeniører eller team av ingeniører sammen grenen sin før en funksjon er ferdig, og noen ganger jobber de i flere uker eller måneder av gangen på en separat kopi. Denne lange perioden kan gjøre sammenslåingsprosessen vanskelig fordi stammen eller masteren sannsynligvis har endret seg fordi andre ingeniører har slått sammen sine grener. Dette kalles en sammenslåingskonflikt.

Utvikling av featuregrener og sammenslåing av kildekode håndteres i versjonskontrollprogramvare som Git, mest kjent som tjenesten Github. Hovedgrenen og funksjonsgrenene ligger i dette kodedepotet (eller repoet), og utviklere sjekker ut kode for å opprette en ny gren å jobbe ut fra.

Når endringene er gjort i koden, sender utvikleren en såkalt pull request, eller en forespørsel om å få andre utviklere i teamet til å gjennomgå koden for å sikre at den lokale grenen ikke har noen feil, og at den heller ikke vil forårsake noen feil når den slås sammen med hovedgrenen. Når en gren har blitt grundig gjennomgått, kan den slås sammen med hovedgrenen og bli en del av hovedrepoenget.

Git-grenutvikling er én metode for å administrere mange ingeniører som jobber med samme kodebase. Moderne team er ofte avhengige av kontinuerlig integrasjon og trunk-basert utvikling for å unngå problemer med feilrettinger og sammenslåingskonflikter som oppstår som følge av forgreningsmodellen for kodeutvikling. Dette bidrar til å forhindre problemer med flere personer som jobber på samme kodebase, og fører en detaljert logg over hvilken kodebit som ble lagt til av hvem, når og hvor. Denne prosessen kalles også rebasing.

Hva du skal gjøre hvis det oppstår problemer med en featuregren

En av fordelene med å utvikle i en featuregren er at det ikke påvirker hovedkoden din før du fletter den inn igjen. Ved hjelp av en git-arbeidsflyt kan du rulle tilbake til tidligere versjoner ved hjelp av versjonskontrollfunksjonene.

Her er et par vanlige git-funksjoner som kan hjelpe deg med å diagnostisere og rulle ut en hotfix

Bruk git pull for å laste ned den nyeste koden fra hovedgrenen. Hvis du trekker fra hovedgrenen, er denne kommandoen et synonym for git pull master origin.
Bruk git push for å sende tilbake koden du har oppdatert til utviklingsgrenen din.
Git branch var sannsynligvis kommandoen du kjørte for å forgrene deg fra hovedgrenen.
Git checkout lar deg bytte til forskjellige versjoner av en gren. Dette forteller Git hvilken versjon du ønsker å registrere endringene du gjør i koden, før du sender den ut igjen.
Gitmerge er egentlig det motsatte av en git branch, og lar deg slå sammen endringene dine tilbake til hovedkoden du forgrenet deg fra, og rydde opp ved å fjerne grenen din.

Ved hjelp av disse kommandoene kan devops-teamet evaluere utviklingsarbeidet sitt og bruke versjonskontrollsystemet til å feilsøke spesifikke versjoner og rulle tilbake der det er nødvendig. Hvis du er i en organisasjon med mange teammedlemmer som jobber på samme kodebase og bruker funksjonsforgreninger, kan dette bidra til å diagnostisere problemer raskt.

Hvorfor bruke forgreningsstrategier

Ved å bruke featuregrener isolerer du hver enkelt funksjon i et eget område som overvåkes av versjonskontrollprogramvaren (vanligvis git). Dette gjør det mulig å jobbe med nye, eksperimentelle funksjoner uten å påvirke hovedkoden direkte, men likevel hente ned alle nye versjoner og oppdateringer som måtte ha skjedd mens du jobbet med den nye funksjonen. Dette er spesielt nyttig i team der flere teammedlemmer jobber på det samme sentrale kodelageret.

En separat gren isolerer problemer og utviklinger til en releasegren, som kan flettes inn igjen når den er ferdig. En git-arbeidsflyt og klare kommunikasjonslinjer mellom utviklere og ingeniører kan bidra til å fjerne konflikter, og gjøre det mulig å utvikle ulike grener av koden samtidig uten å forstyrre hverandre.

Som en del av en grenstrategi er det viktig å ikke bare fokusere på git-arbeidsflyten, men også på arbeidsflytpraksiser som navngivningskonvensjoner for grener og kodegjennomgang. Versjonskontrollen er en svært nyttig funksjonalitet som gjør det mulig for flere teammedlemmer å gå gjennom koden før den sendes ut.

Noen vanlige navnekonvensjoner for funksjonsgrener:

Vær beskrivende: Hvilken funksjon er det snakk om?
Vær kort, ikke bruk flere ord enn nødvendig. Hvis det er behov for mer forklaring, kan du legge det til i beskrivelsen
Skriv det på en måte som gjør at andre utviklere og ingeniører kan forstå hva det jobbes med

Selv om du jobber med flere nye funksjoner samtidig, er det fortsatt god praksis å lage grener for hver enkelt funksjon, slik at de ikke kommer i konflikt med hverandre.

Når du er klar, kan du bruke en pull-forespørsel for å få andre teammedlemmer til å se gjennom koden din og slå den sammen igjen i det sentrale depotet. Det er dårlig praksis å flette og gjennomgå din egen kode. Det kan alltid dukke opp uforutsette problemer med akkurat din funksjon som andre kan oppdage i gjennomgangen.

Kontinuerlig integrasjon og funksjonsgrener

Et alternativ til feature branch-arbeidsflyten er kontinuerlig integrasjon, som er en metode for programvareutvikling som innebærer at man kontinuerlig integrerer nye kodeendringer i hovedgrenen i stedet for å vente til en ny feature branch har vært under utvikling i uker eller måneder og har avviket fra hovedgrenen.

Kontinuerlig integrasjon, også kjent som trunk-basert utvikling, bidrar til å minimere sammenslåingskonflikter ved at endringer kontinuerlig slås sammen til én enkelt kilde for å forhindre funksjonsforgrening. Kontinuerlig integrasjon, sammen med metoder som funksjonsflagging, kan hjelpe utviklere med å distribuere kode raskere og bruke mindre tid på å prøve å forene ulike versjoner av koden.