Waarom Git gebruiken voor je organisatie
Overschakelen van een gecentraliseerd versiebeheersysteem naar Git verandert de manier waarop je ontwikkelingsteam software maakt. En als je een bedrijf bent dat afhankelijk is van software voor bedrijfskritieke toepassingen, heeft een wijziging van je ontwikkelingsworkflow gevolgen voor je hele bedrijf.
Git voor ontwikkelaars
Workflow voor functie-branches
Een van de grootste voordelen van Git is de branch-mogelijkheden. In tegenstelling tot gecentraliseerde versiebeheersystemen zijn Git-branches goedkoop en eenvoudig samen te voegen. Dit vergemakkelijkt de workflow van de functie-branches die populair is bij veel Git-gebruikers.
Functie-branches bieden een geïsoleerde omgeving voor elke wijziging in je codebase. Als een ontwikkelaar ergens aan wil gaan werken, hoe groot of klein ook, dan maken ze een nieuwe branch aan. Dit zorgt ervoor dat de main branch een code voor de productiekwaliteit bevat.
Het gebruik van functie-branches is niet alleen betrouwbaarder dan het rechtstreeks bewerken van de productiecode, maar het biedt ook organisatorische voordelen. Ze stellen je in staat om ontwikkelingswerk even gedetailleerd weer te geven als je agile backlog. Je zou bijvoorbeeld een beleid kunnen invoeren waarbij elk Jira-ticket wordt geadresseerd in zijn eigen functie-branch.
gerelateerd materiaal
Git cheat sheet
Oplossing bekijken
Git leren met Bitbucket Cloud
Gedistribueerde ontwikkeling
In SVN krijgt elke ontwikkelaar een werkkopie die verwijst naar één centrale repository. Git is echter een gedistribueerd versiebeheersysteem. In plaats van een werkkopie krijgt elke ontwikkelaar zijn eigen lokale repository, compleet met een volledige geschiedenis van commits.
Met een volledige lokale geschiedenis is Git snel, omdat je dus geen netwerkverbinding nodig hebt om commits te maken, vorige versies van een bestand te inspecteren of om diffs tussen commits uit te voeren.
Gedistribueerde ontwikkeling maakt het ook makkelijker om je technische team op te schalen. Als iemand de productiebranch in SVN uitbreidt, kunnen andere ontwikkelaars hun wijzigingen pas toepassen als ze zijn opgelost. Met Git bestaat dit soort blokkering niet. Iedereen kan zijn werkzaamheden blijven uitvoeren in zijn eigen lokale repository's.
En net als bij functie-branches zorgt gedistribueerde ontwikkeling voor een betrouwbaardere omgeving. Zelfs als een ontwikkelaar zijn eigen repository vernietigt, kan hij gewoon die van iemand anders klonen en opnieuw beginnen.
Pull-aanvragen
Veel tools voor broncodebeheer, zoals Bitbucket, verbeteren de kernfunctionaliteit van Git met pull requests. Een pull request is een manier om een andere ontwikkelaar te vragen een van je branches samen te voegen in hun repository. Hierdoor wordt het niet alleen gemakkelijker voor projectleiders om wijzigingen bij te houden, maar kunnen ontwikkelaars ook discussies starten over hun werk voordat ze het integreren met de rest van de codebase.
Aangezien het in wezen een reeks met opmerkingen is die gekoppeld is aan een functie-branch, zijn pull requests zeer veelzijdig. Als een ontwikkelaar vastloopt bij een moeilijk probleem, kan deze een pull request indienen om de rest van het team om hulp te vragen. Als alternatief kunnen junior ontwikkelaars erop vertrouwen dat ze niet het hele project vernietigen door pull requests te behandelen als een formele codebeoordeling.
Community
In veel kringen is Git het verwachte versiebeheersysteem geworden voor nieuwe projecten. Als je team Git gebruikt, is de kans groot dat je nieuwe medewerkers niet hoeft te trainen in je workflow, want zij zijn al bekend met gedistribueerde ontwikkeling.
Bovendien is Git erg populair bij opensource-projecten. Dit betekent dat het eenvoudig is om gebruik te maken van externe bibliotheken en anderen aan te moedigen om je opensource-code te vertakken.
Snellere releasecyclus
Het uiteindelijke resultaat van functie-branches, gedistribueerde ontwikkeling, pull requests en een stabiele community is een snellere releasecyclus. Deze mogelijkheden maken een agile workflow mogelijk waarbij ontwikkelaars worden aangemoedigd om kleinere wijzigingen vaker te delen. Veranderingen kunnen op hun beurt sneller in de implementatie-pipeline worden gezet dan de monolithische releases die gebruikelijk zijn bij gecentraliseerde versiebeheersystemen.
Zoals je zou verwachten, werkt Git heel goed in omgevingen met continue integratie en continue levering. Met Git hooks kun je scripts uitvoeren als bepaalde gebeurtenissen zich voordoen in een repository, waardoor je de implementatie naar hartenlust kunt automatiseren. Je kunt zelfs code bouwen of implementeren van specifieke branches naar verschillende servers.
Misschien wil je Git bijvoorbeeld zo configureren dat de meest recente commit van de 'develop'-branch naar een testserver wordt geïmplementeerd wanneer iemand er een pull request aan toevoegt. Door dit soort automatisering te combineren met peer-review, heb je het grootst mogelijke vertrouwen in je code als deze van ontwikkeling naar stagen naar productie gaat.
Git voor marketing
Om te begrijpen welke invloed de overstap op Git heeft op de marketingactiviteiten van je bedrijf, moet je je eens voorstellen dat je ontwikkelingsteam drie duidelijke wijzigingen heeft gepland die in de komende weken zullen worden voltooid:
- Het hele team is bezig met de laatste stappen van een baanbrekende functie waaraan ze de afgelopen zes maanden hebben gewerkt.
- Mary implementeert een kleinere, niet-gerelateerde functie die alleen van invloed is op bestaande klanten.
- Rick is bezig met een aantal broodnodige aanpassingen in de gebruikersinterface.
Als je een traditionele ontwikkelingsworkflow gebruikt die gebaseerd is op een gecentraliseerde VCS, dan zouden al deze wijzigingen waarschijnlijk samengebracht worden in één release. Marketing kan maar één aankondiging doen die zich primair richt op de baanbrekende functie, en het marketingpotentieel van de andere twee updates wordt in feite genegeerd.
De kortere ontwikkelingscyclus, mogelijk gemaakt door Git, maakt het veel gemakkelijker om deze in afzonderlijke releases op te delen. Dit geeft marketeers vaker meer om over te praten. In het bovenstaande scenario kan de marketing uit drie campagnes bestaan die rond elke functie zijn opgebouwd, en dus gericht zijn op zeer specifieke marktsegmenten.
Ze kunnen bijvoorbeeld een grote PR-actie voorbereiden voor de baanbrekende functie, een zakelijke blogartikel en nieuwsbrief voor de functie van Mary, en een aantal gastenberichten over de onderliggende UX-theorie van Rick voor het verzenden van externe ontwerpblogs. Al deze activiteiten kunnen worden gesynchroniseerd met een afzonderlijke release.
Git voor productbeheer
De voordelen van Git voor productbeheer zijn vrijwel dezelfde als die voor marketing. Frequentere releases betekenen meer feedback van klanten en snellere updates als reactie op die feedback. In plaats van over 8 weken op de volgende release te wachten, kun je net zo snel een oplossing naar klanten pushen als dat je ontwikkelaars de code kunnen schrijven.
De workflow voor functie-branches biedt ook flexibiliteit wanneer prioriteiten veranderen. Als je bijvoorbeeld halverwege een releasecyclus zit en je wilt een functie uitstellen in plaats van een andere tijdskritieke functie, dan is dat geen probleem. Die eerste functie kan in zijn eigen branch blijven bestaan totdat engineering tijd heeft om daarop terug te komen.
Dezelfde functionaliteit maakt het eenvoudig om innovatieprojecten, bètatesten en snelle prototypes als onafhankelijke codebases te beheren.
Git voor ontwerpers
Functie-branches lenen zich uitstekend voor snelle prototyping. Of je UX-/UI-ontwerpers nu een geheel nieuwe gebruikersstroom willen implementeren of gewoon enkele pictogrammen willen vervangen: als je een nieuwe branch bezoekt, krijg je een sandbox-omgeving om mee te spelen. Zo kunnen ontwerpers zien hoe hun wijzigingen eruit zullen zien in een echte werkkopie van het product, zonder het risico te lopen bestaande functionaliteit te onderbreken.
Door dergelijke wijzigingen in de gebruikersinterface samen te vatten, is het eenvoudig om updates aan andere belanghebbenden te presenteren. Als de technisch directeur bijvoorbeeld wil zien waar het ontwerpteam aan heeft gewerkt, hoeven ze alleen maar tegen de directeur te zeggen dat deze de betreffende branch moet uitchecken.
Pull requests gaan nog een stap verder en bieden geïnteresseerde partijen een formele plek om de nieuwe interface te bespreken. Ontwerpers kunnen alle nodige wijzigingen aanbrengen en de daaruit voortvloeiende commits worden weergegeven in de pull request. Dit nodigt iedereen uit om deel te nemen aan het iteratieproces.
Misschien wel het beste van prototyping met branches is dat het net zo eenvoudig is om de veranderingen in de productie samen te voegen als om ze weg te gooien. Er is geen druk om een van beide te doen. Dit moedigt ontwerpers en UI-ontwikkelaars aan om te experimenteren en er tegelijkertijd voor te zorgen dat alleen de beste ideeën bij de klant terechtkomen.
Git voor klantenondersteuning
Klantenondersteuning en klantsucces hebben vaak een andere kijk op updates dan productmanagers. Wanneer een klant hen belt, hebben ze meestal een probleem. Als dat probleem wordt veroorzaakt door de software van je bedrijf, moet deze bug zo snel mogelijk worden opgelost.
De gestroomlijnde ontwikkelingscyclus van Git voorkomt dat bugfixes worden uitgesteld tot de volgende monolithische release. Een ontwikkelaar kan het probleem verhelpen en meteen naar de productie versturen. Snellere oplossingen betekenen tevreden klanten en minder terugkerende ondersteuningstickets. In plaats van standaard "Sorry, daar komen we snel op terug” te horen, kan je klantenserviceteam nu reageren met "We hebben het al opgelost!
Git voor Human Resources
In zekere mate bepaalt je workflow voor softwareontwikkeling wie je aanneemt. Het helpt altijd om engineers in te huren die thuis zijn in je technologieën en workflows, maar het gebruik van Git biedt ook andere voordelen.
Werknemers voelen zich aangetrokken tot bedrijven die carrièremogelijkheden bieden, en begrijpen hoe je Git kunt inzetten in zowel grote als kleine organisaties is een voordeel voor elke programmeur. Door Git te kiezen als versiebeheersysteem, neem je de beslissing om toekomstgerichte ontwikkelaars aan te trekken.
Git voor iedereen die een budget beheert
Bij Git draait alles om efficiëntie. Voor ontwikkelaars wordt alles geëlimineerd, van de tijd die verloren gaat bij het doorgeven van commits via een netwerkverbinding tot het aantal manuren dat nodig is om wijzigingen te integreren in een gecentraliseerd versiebeheersysteem. Het maakt zelfs beter gebruik van junior ontwikkelaars door ze een veilige omgeving te bieden om in te werken. Dit alles heeft invloed op de bedrijfsresultaten van je technische afdeling.
Maar vergeet niet dat deze efficiëntieverbeteringen zich ook buiten je ontwikkelingsteam uitstrekken. Ze voorkomen dat marketing energie in functies steekt die niet populair zijn. Ze lieten ontwerpers nieuwe interfaces testen op het eigenlijke product met weinig overhead. Ze laten je onmiddellijk reageren op klachten van klanten.
Bij agile draait het om zo snel mogelijk uit te zoeken wat werkt, het vergroten van de inspanningen die succesvol zijn en het elimineren van inspanningen die dat niet zijn. Git dient als een vermenigvuldiger voor al je bedrijfsactiviteiten door ervoor te zorgen dat elke afdeling haar werk efficiënter doet.
Deel dit artikel
Volgend onderwerp
Aanbevolen artikelen
Bookmark deze resources voor meer informatie over soorten DevOps-teams of voor voortdurende updates over DevOps bij Atlassian.
Bitbucket-blog
DevOps-leertraject
