Tänk om jag sa att det faktiskt är bra för en mjukvaruutvecklare att göra dagliga commit till Git/Mercurial? Många skulle hävda att det inte är nödvändigt och att de hellre tar några dagar på sig för att ”ordentligt” utforma en commit.
Programmering är en konst, och det kräver noggrann kodning och sammanfogning, eller hur? Varför skynda sig och göra frekventa commit?
Erfarna utvecklare vet att dagliga commit är oerhört viktiga.
Sanningen är att några av de bästa bidragsgivarna på GitHub gör dagliga commit eller har en hög commitfrekvens. Till exempel harTJ Holowaychuk(skaparen av Node.js Express) en mycket bra commitfrekvens:
Men snygga diagram och statistik är inte syftet med denna disciplin, och det finns beprövade metoder man kan lära sig för att bli en som bidrar dagligen.
När vi införde dagliga commit vid Ministry of Programming förklarade vi det som en bästa praxis inom kontinuerlig integration.
Oväntat nog tolkades denna regel fel av några av våra teammedlemmar.
Utvecklarna började göra commit bara för att ha ett dagligt commit, och vissa av dem började göra X commit per dag som egentligen inte hade någon mening – bara för att det skulle se bra ut i statistiken och för att följa den regel vi hade fastställt.
Vad är problemet med dessa commit? De tillför visserligen ett visst mervärde till kodbasen, men det är detaljerna som avgör.
Dagliga commit är en metod inom kontinuerlig integration som förespråkas av Jez Humble, en av de mest kända DevOps-påverkarna.
Det är faktiskt en av de frågor som Jez ställer för att kontrollera om ett team tillämpar kontinuerlig integration:
”Lägger alla utvecklare upp sin kod i trunk/master (inte i funktionsgrenar) varje dag?” — Jez Humble
Varför är dagliga commit så värdefulla? Av följande skäl:
Rapporten ”The State of DevOps” identifierar högpresterande team utifrån deras driftsättningsfrekvens. Hur kan man uppnå en hög driftsättningsfrekvens utan dagliga commit?
Utan en daglig commit blir det ingen daglig build.
Regelbundna driftsättningar möjliggör dagliga byggningar och förkortar tiden till marknadslansering för en produkt, vilket ökar chanserna till framgång. Jag tror att alla vill arbeta med framgångsrika produkter, och regelbundna lanseringar är en beprövad metod inom produktledning.
Det värsta som kan hända en utvecklare och ett produktteam är att utveckla något som ingen använder eller som kommer att misslyckas. Det är viktigt att så snart som möjligt upptäcka om så är fallet. Duktiga mjukvaruteam gör flera utgivningar per dag till produktionsmiljön.
En väl genomtänkt commit är rentanvändar- eller affärsvärdeförpackat i form av en kodbit.
En bra commit har följande egenskaper:
Ett exempel på detta från vår kodbas:
Den här committen är mycket liten, den har en tydlig koppling till en funktion som ger affärs- och användarvärde, den innehåller en tydlig beskrivning av vad som levereras (vilket även ingår i den relaterade PR:en) och den är redo att släppas till produktionsanvändare.
Att dessutom göra inlämningar ofta på det här sättet minskar risken för att en stor inlämning ska orsaka problem vid sammanfogningen.
Detta är ett tydligt exempel på hur en utvecklare skapar mervärde, och det ökar sannolikheten för att en produkt eller ett projekt ska bli framgångsrikt.
Att ha en sådan daglig commit skapar förtroende inom teamet och främjar hög produktivitet, eftersom alla vill leverera mer och mer till produktionsanvändarna och fira framgångar eller dra lärdom av misslyckanden.
Slutligen är väl genomförda dagliga commit det bästa måttet på produktivitet och disciplin. Det känns fantastiskt att leverera varje dag.
För att skapa en bra daglig commit och upprätthålla frekvensen behöver du en ”genomförandeplan” för ditt dagliga utvecklingsarbete.
Ett bra tips är att koka lite kaffe och sätta ihop en checklista i början av dagen, så att du vet vad du ska lägga in i en commit.
Slösa inte bort chansen att planera din dag och kasta dig direkt in i din IDE för att koda, eftersom det blir mycket svårare att förstå hur man skapar en bra daglig commit om du inte noggrant planerar vilka komponenter/moduler du tänker lägga till eller ändra och hur du gör din kod redo för lansering till produktionsanvändare.
Utan planering i förväg riskerar du att hamna i”yak-shaving”och arbeta med olika komponenter och till och med olika uppgifter. Detta minskar dina möjligheter att sammanställa och leverera en daglig commit, eftersom du inte fokuserar på leveransen utan på kodningen.
Skjut aldrig upp kontinuerlig integration bara för att det är bekvämare för dig själv. Tänk på ditt team och din produkt.
Det är inte själva kodningen som skapar värde, utan lanseringen.
Du hittar fler tips om hur man skapar bra dagliga commit iboken om kontinuerlig leveransav Jez Humble.
Jag anser att dagliga commit är en viktig disciplin för att minska riskerna och skapa värde för slutanvändarna av en produkt eller ett projekt. Det är ren och skär kontinuerlig integration och leverans i praktiken.
Men det är detaljerna som avgör, och en daglig commit som inte är ordentligt utformad tillför inget verkligt värde, utan är bara brus och onödigt arbete.
Och slutligen bör en daglig commit inte vara en koreografi, utan ett sätt att leverera värde.
Du bör inte göra några åtaganden, utom när det gäller något som skapar användar- eller affärsvärde eller något som minskar framtida integrationsrisker.
Om du är osäker är det bättre att inte åta dig något, men fråga dig ändå: ”När och hur ska jag skapa verkligt värde?”
Jag skulle vilja höra om era egna erfarenheter av dagliga commit och PR:er samt vilka effekter den här regeln har haft i ert team.
