Een codestroomstrategie kiezen
- 8 minuten
Het is belangrijk om een codestroomstrategie te kiezen die past bij de manier waarop uw team werkt. U moet rekening houden met verschillende strategieën. Aan het einde van de module kunt u opties verkennen. Het Tailspin-webteam besluit een codestroomstrategie te ontwikkelen die is gebaseerd op Git en GitHub.
Tijdens het instellen van Azure Boards hebben Mara en haar team een aantal initiële taken geïdentificeerd waarnaar ze moeten kijken. Eén taak was het maken van een op Git gebaseerde werkstroom.
Laten we eens luisteren hoe het team een betere manier probeert te vinden om samen te werken. Momenteel gebruiken ze een gecentraliseerd versiebeheersysteem, maar het plan is om over te stappen op Git, een gedistribueerd systeem.
Mara is hard aan het werk aan de aan haar toegewezen functies terwijl Andy langskomt.
Andy: Hallo Mara. In de leiderschapsvergadering vanmorgen is het op de hoogte gebracht dat ons team en het gameontwikkelingsteam verschillende versiebeheersystemen gebruiken. Om te stroomlijnen hoe we resources delen tussen teams, is ons gevraagd om over te stappen op een gedistribueerd versiebeheersysteem dat de samenwerking beter kan afhandelen.
Mara: Dat is goed om te weten. Als je je herinnert, zetten we het op ons bord. Momenteel gebruiken we een gecentraliseerd versiebeheersysteem. Het werkt nu prima voor ons, maar ik ben het ermee eens dat een gedistribueerd versiebeheersysteem een betere keuze is wanneer we beginnen te delen tussen teams en ons team groter wordt. Het is ook een taak in ons bestuur om de zichtbaarheid te vergroten, zodat alle belanghebbenden weten wat iedereen doet. Ik denk dat een gedistribueerd broncodebeheersysteem zoals Git ook zou helpen.
Andy: Ik wilde Git al een tijdje proberen. Ik heb nooit de tijd. Is het moeilijk om te leren of in te stellen? Als het te doen is, zouden we er nu wel aan kunnen werken. Ik ben het beu om dingen altijd voor me uit te schuiven. En het zou leuk zijn om te zien wat iedereen doet en om toegang te hebben tot de hele opslagplaats. OK, waar hebben we het over?
Mara: Laat me het uitleggen en dan kun je beslissen of het lijkt op iets wat we meteen willen implementeren.
Mara en Andy gaan naar het whiteboard voor een bespreking over versiebeheer.
Wat is Git en gedistribueerd versiebeheer?
Mara: De tekening aan de linkerkant is gecentraliseerd versiebeheer, zoals wat we nu gebruiken. We hebben een centrale versie van de codebasis 
in Team Foundation Version Control (TFVC) die iedereen gebruikt. We werken aan de bestanden die we moeten wijzigen en voegen ze vervolgens weer samen in de hoofdopslagplaats wanneer we klaar zijn.
Andy: Ja, en dat werkt voor ons. Behalve toen ik die tijd werd geblokkeerd toen een wijziging die fouten maakte, werd samengevoegd in de centrale opslagplaats.
Mara: Juist! Je was geblokkeerd 
. We hebben een vertakkingsstrategie met TFVC nodig om het blokkeringsprobleem op te lossen, maar in de huidige configuratie wordt samenvoegen dan misschien iets gecompliceerder. En toen we die belangrijke wijziging 
hadden, kon niemand werk doen totdat we dat opgelost hadden. Dat probleem is altijd verleiden, omdat we allemaal dezelfde kopie van de code gebruiken.
Rechts zie je een tekening van gedistribueerd versiebeheer. We hebben nog steeds een centrale opslagplaats 
die de stabiele versie van de codebasis is, maar elke ontwikkelaar heeft een eigen kopie 
van waaruit ze kunnen werken. Hierdoor kunnen we experimenteren en verschillende benaderingen proberen zonder dat dit van invloed is op de centrale opslagplaats.
Gedistribueerd versiebeheer zorgt er ook voor dat alleen de werkende code 
wordt samengevoegd in de centrale opslagplaats. We kunnen deze zelfs zo instellen dat code pas kan worden samengevoegd nadat deze is gecontroleerd.
Wat cool is met Azure DevOps, is dat het goed werkt met gecentraliseerde versiebeheersystemen en gedistribueerde versiebeheersystemen.
Andy: Wat gebeurt er wanneer meerdere personen hetzelfde bestand wijzigen?
Mara: Vaak kan Git meerdere wijzigingen automatisch samenvoegen. Natuurlijk willen we er altijd voor zorgen dat de combinatie van wijzigingen resulteert in code die werkt. Als Git wijzigingen niet automatisch kan samenvoegen, worden de conflicten rechtstreeks in de bestanden gemarkeerd, zodat een ontwikkelaar kan kiezen welke wijzigingen hij/zij wilt accepteren.
Andy: Op dit moment wordt onze code opgeslagen op onze eigen server. Als we overstappen op gedistribueerd versiebeheer, waar wordt de code opgeslagen?
Mara: Ik ben blij dat je het gevraagd hebt. Hier komt hosting om de hoek kijken.
Waar kan ik mijn opslagplaats hosten?
Mara: Wanneer we bepalen waar we onze opslagplaatsen moeten hosten, hebben we een aantal opties. We kunnen ze bijvoorbeeld hosten op een lokale server, in Bitbucket of in GitHub. Bitbucket en GitHub zijn webhostingoplossingen. Ze zijn overal toegankelijk.
Andy: Heb je een van beide gebruikt?
Mara: Ik heb GitHub in het verleden gebruikt. Het bevat functies die belangrijk zijn voor ontwikkelaars, zoals eenvoudige toegang tot het wijzigen van logboeken en functies voor versiebeheer vanaf de opdrachtregel of de onlineportal.
Andy: Hoe werkt Git?
Hoe kan ik met Git werken?
Mara: Zoals ik eerder heb genoemd, hebben ontwikkelaars met gedistribueerde systemen toegang tot elk bestand dat ze nodig hebben zonder dat dit invloed heeft op het werk van andere ontwikkelaars omdat ze hun eigen kopie van de opslagplaats hebben. Een kloon is jouw lokale kopie van een opslagplaats.
Wanneer we aan een functie of oplossing werken, willen we meestal verschillende benaderingen uitproberen totdat we de beste oplossing hebben gevonden. Het is echter geen goed idee om code uit te proberen op uw kopie van de hoofdcodebasis, omdat u de eerste paar pogingen mogelijk niet wilt behouden.
Om u een betere optie te bieden, heeft Git een functie met de naam vertakking, waar u zoveel kopieën kunt onderhouden als u wilt en alleen de kopie die u wilt behouden, kunt samenvoegen. Zo blijft de hoofdvertakking stabiel.
Andy: Ik krijg de concepten tot nu toe. Hoe kan ik mijn code inchecken?
Hoe krijgen mijn lokale wijzigingen toegang tot de hoofdcodebasis?
Mara: In Git wordt de standaardbranch of trunk meestal genoemd main.
Wanneer u denkt dat uw code klaar is om te worden samengevoegd met de main vertakking in de centrale opslagplaats die wordt gedeeld door alle ontwikkelaars, maakt u een pull-aanvraag. Wanneer u een pull-aanvraag maakt, vertelt u de andere ontwikkelaars dat u code hebt die u wilt controleren en wilt u deze samenvoegen in de main vertakking. Wanneer uw pull-aanvraag is goedgekeurd en vervolgens wordt samengevoegd, wordt deze onderdeel van de centrale codebasis.
Hoe ziet een vertakkingswerkstroom eruit?
Stap 1: Wanneer u aan een nieuwe functie of foutoplossing begint te werken, is het eerste wat u wilt doen ervoor zorgen dat u begint met de meest recente stabiele codebasis. Daartoe synchroniseer je de lokale kopie van de main-vertakking met de kopie van de server. Hiermee haalt u alle andere wijzigingen van ontwikkelaars op die sinds de laatste synchronisatie naar de main vertakking op de server zijn gepusht.
Stap 2: Als u ervoor wilt zorgen dat u alleen aan uw kopie van de code werkt, maakt u een nieuwe vertakking alleen voor die functie of foutoplossing. Zoals u zich kunt voorstellen, kan het lastig zijn om veel vertakkingen te hebben voor alle dingen die u doet, dus het gebruik van een goede naamconventie is essentieel.
Voordat u wijzigingen aanbrengt in een bestand, bekijkt u een nieuwe vertakking, zodat u weet dat u aan de bestanden van die vertakking werkt en niet vanuit een andere vertakking. Je kunt op elk gewenst moment tussen vertakkingen schakelen door die vertakking uit te checken.
Stap 3: Je kunt nu alle gewenste wijzigingen aanbrengen, omdat deze wijzigingen zich alleen in jouw branch bevinden. Terwijl u werkt, kunt u uw wijzigingen doorvoeren in uw vertakking om ervoor te zorgen dat u geen werk kwijtraakt. Dit biedt ook een manier om eventuele wijzigingen die u in eerdere versies hebt aangebracht, terug te draaien. Voordat je wijzigingen kunt doorvoeren, moet je je bestanden faseren zodat Git weet welke bestanden je wilt doorvoeren.
Stap 4: De volgende stap is het pushen of uploaden van uw lokale vertakking naar de externe opslagplaats (zoals GitHub), zodat anderen kunnen zien waaraan u werkt. Geen zorgen, je gaat de wijzigingen nog niet samenvoegen. Je kunt je werk zo vaak pushen als je wilt. Dat is zelfs een goede manier om een back-up van uw werk te maken of om uzelf vanaf meerdere computers te laten werken.
stap 5: deze stap is een veelvoorkomende, maar niet vereist. Wanneer u tevreden bent dat uw code naar wens werkt, kunt of samenvoegen in uw lokale main vertakking. Daar hebben wijzigingen plaatsgevonden waarover je lokale main-vertakking nog niet beschikt. Nadat u de externe main vertakking hebt gesynchroniseerd met die van u, voegt u uw lokale main vertakking samen in uw werkbranch en test u de build opnieuw.
Met dit proces controleer je of jouw functie met de meest recente code werkt. Het helpt er tevens voor te zorgen dat je werk probleemloos kan worden geïntegreerd wanneer je je pull-aanvraag indient.
Stap 6: Uw lokale code moet nu worden doorgevoerd en naar de gehoste opslagplaats worden gepusht. Dit is hetzelfde als de stappen 3 en 4.
Stap 7: U bent eindelijk klaar om uw wijzigingen aan de externe main vertakking voor te stellen. Daartoe start je een pull-aanvraag. Wanneer deze stap is geconfigureerd in Azure Pipelines of een ander CI/CD-systeem, wordt het buildproces geactiveerd en kunt u uw wijzigingen bekijken door de pijplijn. Nadat de build is geslaagd en anderen uw pull-aanvraag goedkeurden, kan uw code worden samengevoegd in de externe main vertakking. (Het is nog steeds aan een mens om de wijzigingen samen te voegen.)
Andy: Dit ziet er allemaal ingewikkeld en moeilijk te leren uit.
Mara: Git kan intimiderend lijken omdat het zo krachtig is, maar nadat je de stroom hebt opgehangen, begint het natuurlijk te voelen.
U gebruikt dagelijks slechts enkele opdrachten. Hier volgt een samenvatting:
| Categorie | Om deze taak uit te voeren | Gebruik je de volgende opdracht |
|---|---|---|
| Beheer van opslagplaats | Een Git-opslagplaats maken | git init |
| Een externe opslagplaats downloaden | git clone |
|
| Vertakking | Een vertakking maken | git checkout |
| Wijzigingen faseren en doorvoeren | Zien welke bestanden er zijn gewijzigd | git status |
| Bestanden faseren om door te voeren | git add |
|
| Bestanden doorvoeren naar uw vertakking | git commit |
|
| Externe synchronisatie | Een vertakking downloaden van een externe opslagplaats | git pull |
| Een vertakking uploaden naar een externe opslagplaats | git push |
Andy: Dat klinkt als een geweldig uitgangspunt. Dat is te overzien. Ik kan de geavanceerdere opdrachten altijd nog bekijken wanneer ik ze nodig heb.