Heb je Git-commando's geleerd, maar wil je je voorstellen hoe continue integratie (CI) in werkelijkheid werkt? Of misschien wilt u uw dagelijkse activiteiten optimaliseren? Deze cursus geeft je praktische vaardigheden in continue integratie met behulp van een GitHub-repository. Deze cursus is niet bedoeld als een wizard waar je zomaar doorheen kunt klikken; integendeel, je gaat dezelfde handelingen uitvoeren die mensen ook daadwerkelijk op het werk doen, op dezelfde manier als zij dat doen. Ik zal de theorie uitleggen terwijl je de betrokken stappen doorloopt.

Wat doen we?

Naarmate we verder komen, zullen we geleidelijk een lijst met typische CI-stappen maken, wat een goede manier is om deze lijst te onthouden. Met andere woorden, we zullen een lijst maken met acties die ontwikkelaars ondernemen tijdens het uitvoeren van continue integratie, het uitvoeren van continue integratie. We zullen ook een eenvoudige reeks tests gebruiken om ons CI-proces dichter bij het echte proces te brengen.

Deze GIF toont schematisch de commits in uw repository terwijl u door de cursus vordert. Zoals je kunt zien, is hier niets ingewikkelds en alleen het meest noodzakelijke.

Je doorloopt de volgende standaard CI-scenario’s:

• Werk aan een functie;
• Toepassing van geautomatiseerde tests om de kwaliteit te waarborgen;
• Uitvoering van de prioritaire taak;
• Conflictoplossing bij het samenvoegen van vestigingen (merge conflict);
• Er doet zich een fout voor in een productieomgeving.

Wat ga je leren?

U kunt de volgende vragen beantwoorden:

• Wat is continue integratie (CI)?
• Welke soorten geautomatiseerde tests worden gebruikt in CI, en als reactie op welke acties worden deze geactiveerd?
• Wat zijn pull-requests en wanneer zijn ze nodig?
• Wat is Test Driven Development (TDD) en hoe verhoudt dit zich tot CI?
• Moet ik de wijzigingen samenvoegen of opnieuw baseren?
• Terugdraaien of oplossen in de volgende versie?

In eerste instantie vertaalde ik dingen als “pull-verzoeken” overal, maar als gevolg daarvan besloot ik op sommige plaatsen zinnen in het Engels terug te geven om de mate van waanzin in de tekst te verminderen. Ik gebruik soms 'programmeur surzhik', zoals het prachtige werkwoord 'commit', waar mensen het daadwerkelijk op het werk gebruiken.

Wat is continue integratie?

епрерывная интеграция, of CI, is een technische praktijk waarbij elk teamlid zijn code minstens één keer per dag in een gemeenschappelijke repository integreert, en de resulterende code moet op zijn minst zonder fouten worden gebouwd.

Er zijn meningsverschillen over deze term

Het twistpunt is de frequentie van integratie. Sommigen beweren dat het slechts één keer per dag samenvoegen van code niet voldoende is om daadwerkelijk continu te integreren. Er wordt een voorbeeld gegeven van een team waarbij iedereen 's ochtends nieuwe code pakt en deze 's avonds één keer integreert. Hoewel dit een redelijk bezwaar is, wordt algemeen aangenomen dat de definitie van eenmaal per dag redelijk praktisch, specifiek en geschikt is voor teams van verschillende grootte.

Een ander bezwaar is dat C++ niet langer de enige taal is die bij de ontwikkeling wordt gebruikt, en dat het eenvoudigweg vereisen van foutloze assemblage als manier van validatie zwak is. Een aantal tests (bijvoorbeeld lokaal uitgevoerde unit-tests) moeten ook met succes worden afgerond. Op dit moment is de gemeenschap bezig om dit een vereiste te maken, en in de toekomst zal "build + unit tests" waarschijnlijk een gangbare praktijk worden, als dat nog niet het geval is.

епрерывная интеграция verschilt van continue levering (Continuous Delivery, CD) omdat er na elke integratiecyclus geen release candidate nodig is.

Lijst met stappen die we tijdens de cursus zullen gebruiken

1. Voer de nieuwste code in. Maak een vertakking van master. Begin met werken.
2. Maak commits aan voor uw nieuwe branch. Lokaal bouwen en testen. Doorgang? Ga naar de volgende stap. Mislukking? Herstel fouten of tests en probeer het opnieuw.
3. Push naar uw externe repository of externe branch.
4. Maak een pull-aanvraag. Bespreek de wijzigingen en voeg meer commits toe naarmate de discussie voortduurt. Zorg ervoor dat tests de functievertakking doorgeven.
5. Commits van master samenvoegen/rebaseen. Laat tests het samenvoegresultaat doorgeven.
6. Implementeer van de functievertakking naar productie.
7. Als alles gedurende een bepaalde periode goed is in de productie, voegt u de wijzigingen samen met de master.

️ Voorbereiding

Zorg ervoor dat u over de juiste software beschikt

Om deze cursus te volgen heb je nodig Node.js и Git-client.

Je kunt elke Git-client gebruiken, maar ik geef alleen opdrachten voor de opdrachtregel.

Zorg ervoor dat je een Git-client hebt geïnstalleerd die de opdrachtregel ondersteunt

Als je nog geen Git-client hebt die de opdrachtregel ondersteunt, kun je installatie-instructies vinden hier.

Bereid de opslagplaats voor

U moet een persoonlijke kopie maken (fork) sjabloonrepository met code voor de cursus op GitHub. Laten we afspreken dat we dit een persoonlijke kopie noemen cursus repository.

Klaar? Als je de standaardinstellingen niet hebt gewijzigd, wordt hoogstwaarschijnlijk je cursusrepository aangeroepen continuous-integration-team-scenarios-students, deze bevindt zich in uw GitHub-account en de URL ziet er als volgt uit

https://github.com/<ваше имя ползователя на GitHub>/continuous-integration-team-scenarios-students

Ik zal dit adres gewoon bellen <URL репозитория>.

Hoekbeugels zoals <тут> betekent dat u een dergelijke uitdrukking moet vervangen door de juiste waarde.

Zeker weten dat GitHub-acties opgenomen voor deze cursusrepository. Als ze niet zijn ingeschakeld, schakel ze dan in door op de grote knop in het midden van de pagina te klikken, die je kunt bereiken door op Acties in de GitHub-interface te klikken.

Je kunt de cursus niet voltooien door mijn instructies te volgen als GitHub-acties niet zijn ingeschakeld.

Je kunt altijd de mogelijkheid van GitHub gebruiken om Markdown weer te geven om de huidige status te zien van de lijst die we hier samenstellen

https://github.com/<your GitHub user name>/continuous-integration-team-scenarios-students/blob/master/ci.md

Over de antwoorden

Hoewel de beste manier om deze cursus te voltooien is door het zelf te doen, kunt u tegen enkele problemen aanlopen.

Als u het gevoel heeft dat u niet begrijpt wat u moet doen en niet verder kunt gaan, kunt u de draad bekijken solution, die zich in uw startrepository bevindt.
Gelieve niet samen te voegen solution в master tijdens de cursus. Je kunt deze branch gebruiken om erachter te komen wat je moet doen, of om jouw code te vergelijken met die van de auteur, waarbij je alle mogelijkheden gebruikt die Git ons biedt. Als u helemaal verdwaald bent, kunt u uw tak volledig vervangen master op een tak solution en reset vervolgens uw werkmap naar de cursusstap die u nodig hebt.

Gebruik dit alleen als je het echt nodig hebt

Voer uw code in

git add .
git commit -m "Backing up my work"

Deze commando's

• hernoemen master в master-backup;
• hernoemen solution в master;
• afrekenen naar een nieuw filiaal master en herschrijf de inhoud van de werkmap;
• Maak een "solution" -vertakking van "master" (wat vroeger "solution" was) voor het geval u in de toekomst een "solution" -vertakking nodig heeft.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

Na deze stappen kunt u gebruik maken van git log master om erachter te komen welke commit je nodig hebt.
Je kunt je werkmap als volgt resetten naar deze commit:

git reset --hard <the SHA you need>

Als u tevreden bent met het resultaat, zult u op een gegeven moment uw versie van de repository naar een externe repository moeten publiceren. Vergeet niet om expliciet de externe vertakking op te geven wanneer u dit doet.

git push --force origin master

Houd er rekening mee dat we gebruiken git push --force. Het is onwaarschijnlijk dat je dit heel vaak wilt doen, maar we hebben hier een heel specifiek scenario met één repositorygebruiker die bovendien begrijpt wat hij doet.

Beginnen met werken

Laten we beginnen met het samenstellen van onze lijst met CI-stappen. Normaal gesproken zou je deze stap beginnen door de nieuwste versie van de code uit de externe repository te bekijken, maar we hebben nog geen lokale repository, dus klonen we deze in plaats daarvan vanuit de externe repository.

️ Taak: update de lokale repository, maak een branch van master, Begin met werken

1. Kloon de cursusrepository van <URL репозитория>.
2. Rennen npm install in de cursusrepository; We hebben het nodig om Jest te installeren, die we gebruiken om tests uit te voeren.
3. Maak een vertakking en geef deze een naam feature. Schakel over naar dit onderwerp.

4. Voeg testcode toe aan ci.test.js tussen de opmerkingen waarin mij wordt gevraagd dit te doen.

   it('1. pull latest code', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. add commits', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push to the remote branch with the same name', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. create a pull request and continue working', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. Voeg tekst toe met de eerste 4 stappen aan het bestand ci.md.

   1. Pull in the latest code. Create a branch from `master`. Start working.    
   2. Create commits on your new branch. Build and test locally.  
   Pass? Go to the next step. Fail? Fix errors or tests and try again.  
   3. Push to your remote repository or remote branch.  
   4. Create a pull request. Discuss the changes, add more commits  
   as discussion continues. Make tests pass on the feature branch.  

   Команды

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

Maak commits op een nieuwe branch, bouw en test lokaal

We gaan de tests opzetten die moeten worden uitgevoerd voordat we committen, en vervolgens de code committen.

Typische scenario's waarin tests automatisch worden uitgevoerd

• lokaal:
  • Continu of als reactie op passende codewijzigingen;
  • Over opslaan (voor geïnterpreteerde of JIT-gecompileerde talen);
  • Tijdens de montage (wanneer compilatie vereist is);
  • Op commit;
  • Bij publicatie naar een gedeelde opslagplaats.

• Op de buildserver of buildomgeving:
  • Wanneer code wordt gepubliceerd naar een persoonlijke branch/repository.
  • De code in deze thread wordt getest.
  • Het potentiële resultaat van de fusie wordt getoetst (meestal met master).
  • Als een continue integratiefase/continue leveringspijplijn

Normaal gesproken geldt: hoe sneller een testpakket draait, hoe vaker u het zich kunt veroorloven om het uit te voeren. Een typische podiumverdeling zou er als volgt uit kunnen zien.

• Snelle unit-tests - tijdens de build, in CI-pijplijn
• Langzame unit-tests, snelle component- en integratietests - op commit, in de CI-pijplijn
• Trage component- en integratietests - in de CI-pijplijn
• Beveiligingstests, belastingtests en andere tijdrovende of dure tests - in CI/CD-pijplijnen, maar alleen in bepaalde modi/fasen/pijplijnen van de build, bijvoorbeeld bij het voorbereiden van een release candidate of bij handmatig uitvoeren.

️Taak

Ik stel voor om de tests eerst handmatig uit te voeren met behulp van de opdracht npm test. Laten we daarna een git hook toevoegen om onze tests op commit uit te voeren. Er zit één addertje onder het gras: Git-hooks worden niet beschouwd als onderdeel van de repository en kunnen daarom niet samen met de rest van het cursusmateriaal uit GitHub worden gekloond. Om de haak te installeren, moet je rennen install_hook.sh of kopieer het bestand repo/hooks/pre-commit naar de lokale map .git/hooks/.
Wanneer u zich vastlegt, ziet u dat er tests worden uitgevoerd en wordt gecontroleerd of bepaalde zoekwoorden in de lijst voorkomen.

1. Voer de tests handmatig uit door de opdracht uit te voeren npm test in de map met de cursusrepository. Controleer of de tests zijn voltooid.
2. Stel een commit hook (pre-commit hook) in door te draaien install_hook.sh.
3. Leg uw wijzigingen vast in uw lokale repository.
4. Zorg ervoor dat er tests worden uitgevoerd voordat u een commit uitvoert.

Uw repository zou er zo uit moeten zien na het volgen van deze stappen.

Команды

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

Publiceer code naar een externe opslagplaats of externe vertakking

Zodra ze klaar zijn met lokaal werken, maken ontwikkelaars hun code doorgaans openbaar, zodat deze uiteindelijk met het publiek kan worden geïntegreerd. Met GitHub wordt dit doorgaans bereikt door het werk te publiceren naar een persoonlijke kopie van de repository (persoonlijke fork) of een persoonlijke branch.

• Met forks kloont een ontwikkelaar een externe gedeelde repository en maakt er een persoonlijke externe kopie van, ook wel een fork genoemd. Vervolgens wordt deze persoonlijke repository gekloond om er lokaal mee te werken. Wanneer het werk voltooid is en de commits zijn gedaan, duwt hij ze naar zijn fork, waar ze beschikbaar zijn voor anderen en kunnen worden geïntegreerd in de gemeenschappelijke repository. Deze aanpak wordt vaak gebruikt in open source-projecten op GitHub. Het wordt ook gebruikt in mijn gevorderdencursus [Teamwerk en CI met Git] (http://devops.redpill.solutions/).
• Een andere benadering is om slechts één externe repository te gebruiken en alleen de vertakkingen te tellen master gedeelde repository "beschermd". In dit scenario publiceren individuele ontwikkelaars hun code naar vertakkingen van een externe repository, zodat anderen deze code kunnen bekijken. Als alles in orde is, kunt u deze samenvoegen met master gedeelde opslagplaats.

In deze specifieke cursus gebruiken we een workflow die gebruikmaakt van vertakkingen.

Laten we onze code publiceren.

️Taak

• Publiceer wijzigingen naar een externe vertakking met dezelfde naam als uw werkvertakking

Команды

git push --set-upstream origin feature

Maak een pull-aanvraag

Maak een pull-aanvraag met een titel Stappenoverzicht... Installeren feature zoals "hoofdtak" en master zoals "basistak".

Zorg ervoor dat je geïnstalleerd bent master in zijn vork de repository Als "basistak" zal ik niet reageren op verzoeken om wijzigingen in de repository voor cursusmateriaal.

In GitHub-jargon is de "base branch" de branch waarop je je werk baseert, en de "head branch" is de branch die de voorgestelde wijzigingen bevat.

Bespreek de wijzigingen, voeg nieuwe commits toe naarmate de discussie voortduurt

Pull-verzoek (PR)

Pull-verzoek (PR) is een manier om code te bespreken en te documenteren, en om code te beoordelen. Pull-aanvragen zijn genoemd naar de algemene manier om individuele wijzigingen in de algehele code te integreren. Doorgaans kloont iemand de externe officiële repository van het project en werkt hij lokaal aan de code. Hierna plaatst hij de code in zijn persoonlijke externe repository en vraagt ​​hij degenen die verantwoordelijk zijn voor de officiële repository om deze op te halen(trek) de code ervan in hun lokale opslagplaatsen, waar ze deze bekijken en mogelijk integreren(samensmelten) zijn. Dit concept is ook bekend onder andere namen, bijvoorbeeld samenvoegverzoek.

U hoeft de pull-request-functie van GitHub of soortgelijke platforms niet daadwerkelijk te gebruiken. Ontwikkelteams kunnen andere communicatiemethoden gebruiken, zoals face-to-face communicatie, telefoongesprekken of e-mail, maar er zijn nog steeds een aantal redenen om pull-requests in forumstijl te gebruiken. Hier zijn er een aantal:

• georganiseerde discussies met betrekking tot specifieke codewijzigingen;
• als een plek om feedback over onderhanden werk van zowel autotesters als collega's te bekijken;
• formalisering van codebeoordelingen;
• zodat u later de redenen en overwegingen achter dit of dat stukje code kunt achterhalen.

Normaal gesproken maakt u een pull-verzoek aan als u iets wilt bespreken of feedback wilt krijgen. Als u bijvoorbeeld aan een functie werkt die op meer dan één manier kan worden geïmplementeerd, kunt u een pull-request maken voordat u de eerste regel code schrijft, om uw ideeën te delen en uw plannen met uw medewerkers te bespreken. Als het werk eenvoudiger is, wordt een pull-request geopend als iets al is gedaan, vastgelegd en kan worden besproken. In sommige scenario's wilt u misschien alleen een PR openen om redenen van kwaliteitscontrole: om geautomatiseerde tests uit te voeren of codebeoordelingen te initiëren. Wat u ook besluit, vergeet niet de mensen van wie u goedkeuring wilt in uw pull-verzoek te @vermelden.

Wanneer u een PR maakt, doet u doorgaans het volgende.

• Geef aan wat u wilt veranderen en waar.
• Schrijf een beschrijving waarin u het doel van de wijzigingen uitlegt. Je wilt misschien:
  • voeg iets belangrijks toe dat niet duidelijk uit de code blijkt, of iets dat nuttig is om de context te begrijpen, zoals relevante #bugs en commit-nummers;
  • @mention iedereen met wie u wilt gaan werken, of u kunt ze later @vermelden in de reacties;
  • vraag collega’s om ergens mee te helpen of iets specifieks te controleren.

Zodra u de PR opent, worden de tests uitgevoerd die zijn geconfigureerd om in dergelijke gevallen te worden uitgevoerd. In ons geval zal dit dezelfde reeks tests zijn die we lokaal hebben uitgevoerd, maar in een echt project kunnen er aanvullende tests en controles zijn.

Een ogenblik geduld terwijl de tests zijn voltooid. Je kunt de status van de tests onderaan de PR-discussie in de GitHub-interface zien. Ga verder wanneer de tests zijn voltooid.

️ Voeg een opmerking toe over de willekeur van de lijst met CI-stappen

De lijst die in deze cursus wordt gebruikt is willekeurig en subjectief, we moeten hier een opmerking over maken.

️ Taak: maak een pull-verzoek voor deze reactie

1. Schakel over naar filiaal master.
2. Maak een vertakking met de naam bugfix.
3. Voeg notitietekst toe aan het einde van het bestand ci.md.

   > **GitHub flow** is sometimes used as a nickname to refer to a flavor of trunk-based development  
   when code is deployed straight from feature branches. This list is just an interpretation  
   that I use in my [DevOps courses](http://redpill.solutions).  
   The official tutorial is [here](https://guides.github.com/introduction/flow/).

4. Leg de veranderingen vast.
5. Publiceer de draad bugfix naar een externe opslagplaats.
6. Maak een pull-aanvraag met de naam Een opmerking toevoegen met een hoofdtak bugfix en de basistakmaster.

Zorg ervoor dat je geïnstalleerd bent master in zijn vork de repository Als "basistak" zal ik niet reageren op verzoeken om wijzigingen in de repository voor cursusmateriaal.

Dit is hoe uw repository eruit zou moeten zien.

Команды

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

Pull request "Een opmerking toevoegen" goedkeuren

️Taak

1. Maak een pull-aanvraag.
2. Klik op 'Pullverzoek samenvoegen'.
3. Klik op "Samenvoeging bevestigen".
4. Klik op "Verwijder filiaal", deze hebben wij niet meer nodig.

Dit is een diagram van commits na een merge.

‼ Blijf werken en tests toevoegen

Het samenwerken aan een pull request levert vaak extra werk op. Dit is meestal het resultaat van een codebeoordeling of discussie, maar in onze cursus gaan we dit modelleren door nieuwe items toe te voegen aan onze lijst met CI-stappen.

Continue integratie omvat doorgaans enige testdekking. De vereisten voor testdekking variëren en zijn meestal te vinden in een document dat zoiets als "bijdragerichtlijnen" heet. We houden het simpel en voegen voor elke regel een test toe aan onze checklist.

Probeer bij het uitvoeren van opdrachten eerst de tests uit te voeren. Als u correct hebt geïnstalleerd pre-commit hook eerder, de nieuw toegevoegde test wordt uitgevoerd, mislukt en er wordt niets vastgelegd. Merk op dat dit is hoe we weten dat onze tests daadwerkelijk iets testen. Interessant is dat als we vóór de tests met de code zouden beginnen, het slagen voor de tests zou kunnen betekenen dat de code werkte zoals verwacht, of dat de tests eigenlijk niets testten. Bovendien, als we de tests niet hadden geschreven, waren we ze misschien helemaal vergeten, omdat niets ons eraan zou hebben herinnerd.

Testgestuurde ontwikkeling (TDD)

TDD raadt aan om tests vóór code te schrijven. Een typische workflow met TDD ziet er als volgt uit.

1. Voeg een toets toe.
2. Voer alle tests uit en zorg ervoor dat de nieuwe test mislukt.
3. Schrijf de code.
4. Voer de tests uit en zorg ervoor dat alle tests slagen.
5. Refactoreer uw code.
6. Herhalen.

Omdat de resultaten van mislukte tests meestal in het rood worden weergegeven, en de resultaten van geslaagde tests meestal in het groen, wordt de cyclus ook wel een rood-groen-refactor genoemd.

️Taak

Probeer eerst de tests vast te leggen en deze te laten mislukken, en voeg vervolgens de tekst van de CI-stappenlijst zelf toe en voer deze vast. Je zult zien dat de tests slagen ("groen").
Publiceer vervolgens de nieuwe code naar de externe repository en bekijk de tests die worden uitgevoerd in de GitHub-interface onderaan de pull-request-discussie en de PR-statusupdate.

1. Schakel over naar filiaal feature.

2. Voeg deze tests toe aan ci.test.js na de laatste oproep it (...);.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Probeer de tests uit te voeren. Als pre-commit hook is geïnstalleerd, zal de commit-poging mislukken.
4. Voeg dan deze tekst toe ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. Lokaal wijzigingen aanbrengen en vastleggen.
6. Wijzigingen in het filiaal doorvoeren feature.

Je zou nu zoiets als dit moeten hebben

Команды

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

Conflict samenvoegen

Ga naar Wijzigingsverzoek Stappenoverzicht.

Hoewel we niets verkeerd hebben gedaan en de tests voor onze code zijn geslaagd, kunnen we de branch nog steeds niet samenvoegen feature и master. Het komt omdat het andere draadje bugfix werd samengevoegd met master terwijl we aan deze PR werkten.
Hierdoor ontstaat een situatie waarin de externe vestiging master heeft een nieuwere versie dan degene waarop we de branch hebben gebaseerd feature. Hierdoor kunnen we HEAD niet zomaar terugspoelen master tot het einde van de draad feature. In deze situatie moeten we commits samenvoegen of toepassen feature rebase master. GitHub kan daadwerkelijk automatische samenvoegingen uitvoeren als er geen conflicten zijn. Helaas hebben beide vestigingen in onze situatie concurrerende wijzigingen in het bestand ci.md. Deze situatie staat bekend als een samenvoegconflict en we moeten dit handmatig oplossen.

Samenvoegen of opnieuw baseren

gaan

• Creëert een extra merge commit en slaat de werkgeschiedenis op.
  • Behoudt de originele commits van branches met hun originele tijdstempels en auteurs.
  • Slaat de SHA van commits op en linkt ernaar in discussies over wijzigingsverzoeken.
• Vereist eenmalige conflictoplossing.
• Maakt het verhaal niet-lineair.
  • Het verhaal kan lastig leesbaar zijn door het grote aantal vertakkingen (doet denken aan een IDE-kabel).
  • Maakt automatisch debuggen moeilijker, b.v. git bisect minder nuttig - het zal alleen de merge commit vinden.

rebase

• Speelt commits van de huidige vertakking één voor één af bovenop de basisvertakking.
  • Er worden nieuwe commits met nieuwe SHA's gegenereerd, waardoor de commits in GitHub overeenkomen met de originele pull-aanvragen, maar niet met de bijbehorende opmerkingen.
  • Commits kunnen tijdens het proces opnieuw worden gecombineerd en gewijzigd, of zelfs tot één geheel worden samengevoegd.
• Mogelijk moeten meerdere conflicten worden opgelost.
• Hiermee kunt u een lineair verhaal behouden.
  • Het verhaal is misschien gemakkelijker te lezen, zolang het niet te lang is zonder redelijke reden.
  • Automatisch debuggen en probleemoplossing is iets eenvoudiger: maakt het mogelijk git bisect, kan automatische terugdraaiingen duidelijker en voorspelbaarder maken.
• Vereist het publiceren van een branch met gemigreerde commits met een vlag --force bij gebruik met pull-aanvragen.

Doorgaans komen teams overeen om altijd dezelfde strategie te gebruiken wanneer ze wijzigingen moeten samenvoegen. Dit kan een "pure" merge zijn of een "pure" commit erbovenop, of iets daar tussenin, zoals interactief een commit erboven doen(git rebase -i) lokaal voor vertakkingen die niet in de openbare repository zijn gepubliceerd, maar worden samengevoegd voor "openbare" vertakkingen.

Hier zullen we samenvoegen gebruiken.

️Taak

1. Zorg ervoor dat de code zich in een lokaal filiaal bevindt master bijgewerkt vanuit een externe opslagplaats.
2. Schakel over naar filiaal feature.
3. Start een samenvoeging met een vertakking master. Een fusieconflict als gevolg van concurrerende wijzigingen in de ci.md.
4. Los het conflict op, zodat zowel onze lijst met CI-stappen als een opmerking daarover in de tekst blijven staan.
5. Publiceer een merge commit naar een externe branch feature.
6. Controleer de status van de pull-aanvraag in de GitHub-gebruikersinterface en wacht tot de samenvoeging is opgelost.

Команды

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Goed werk!

U bent klaar met de lijst en nu moet u de pull-aanvraag goedkeuren master.

️ Taak: Pull-verzoek goedkeuren "Stappenbeoordeling"

1. Open een pull-aanvraag.
2. Klik op 'Pullverzoek samenvoegen'.
3. Klik op "Samenvoeging bevestigen".
4. Klik op "Verwijder tak", aangezien we deze niet langer nodig hebben.

Dit is momenteel uw opslagplaats

Productfout

Er wordt gezegd dat “testen kan worden gebruikt om de aanwezigheid van fouten aan te tonen, maar nooit om de afwezigheid ervan aan te tonen.” Hoewel we tests hadden en deze geen fouten lieten zien, kroop er een verraderlijke bug in de productie.

In een scenario als dit moeten we zorgen voor:

• wat er in de productie wordt ingezet;
• code in de draad master met een fout, van waaruit ontwikkelaars nieuw werk kunnen beginnen.

Moet ik het terugdraaien of in de volgende versie repareren?

Terugdraaien is het proces van het implementeren van een bekende goede eerdere versie naar productie en het terugdraaien van commits die de fout bevatten. "Fixing forward" is de toevoeging van een fix aan de master en de nieuwe versie zo snel mogelijk implementeren. Omdat API's en databaseschema's veranderen naarmate de code in productie wordt genomen, is het terugdraaien doorgaans veel moeilijker en riskanter dan het herstellen ervan in de volgende versie, met continue levering en goede testdekking.

Omdat terugdraaien in ons geval geen enkel risico met zich meebrengt, zullen we deze route volgen, omdat dit ons de mogelijkheid biedt

• verhelp de fout aan het product zo snel mogelijk;
• code erin maken master direct geschikt voor het starten van een nieuwe baan.

️Taak

1. Schakel over naar filiaal master lokaal
2. Werk de lokale opslagplaats bij vanaf de externe opslagplaats.
3. Zet de PR-samenvoeging terug Stappenoverzicht в master.
4. Publiceer wijzigingen naar een externe opslagplaats.

Dit is de geschiedenis van een repository waarbij een merge commit is teruggedraaid

Команды

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ Zelftest

Zeker weten dat ci.md bevat niet langer de tekst "sneaky bug" na het terugdraaien van een merge commit.

Corrigeer de lijst met CI-stappen en stuur deze terug naar de master

We hebben de merge commit van de branch volledig teruggedraaid. feature. Het goede nieuws is dat we er nu geen fout meer in hebben master. Het slechte nieuws is dat onze kostbare lijst van continue integratiestappen ook verdwenen is. Dus idealiter moeten we de oplossing toepassen op de commits van feature en stuur ze terug naar master samen met de correctie.

We kunnen het probleem op verschillende manieren benaderen:

• een commit terugdraaien die een merge ongedaan maakt feature с master;
• verplaats commits van de eerste feature.

Verschillende ontwikkelingsteams gebruiken in dit geval verschillende benaderingen, maar we zullen nuttige commits naar een aparte branch verplaatsen en een aparte pull-request voor deze nieuwe branch aanmaken.

️Taak

1. Maak een draad aan met de naam feature-fix en schakel ernaar toe.

2. Migreer alle commits van de vorige branch feature naar een nieuw draadje. Los samenvoegconflicten op die tijdens de migratie zijn opgetreden.

   

3. Voeg een regressietest toe ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. Voer de tests lokaal uit om er zeker van te zijn dat ze niet mislukken.
5. Verwijder de tekst "met een stiekeme bug" in ci.md.
6. Voeg testwijzigingen en stappenlijstwijzigingen toe aan de index en voer deze door.
7. Publiceer de vertakking naar een externe opslagplaats.

Je zou moeten eindigen met iets soortgelijks als dit:

Команды

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

Maak een pull-aanvraag.

Maak een pull-aanvraag met een titel De functie repareren... Installeren feature-fix zoals "hoofdtak" en master zoals "basistak".
Een ogenblik geduld terwijl de tests zijn voltooid. Onderaan de PR-discussie kunt u de status van de testen zien.

Zorg ervoor dat je geïnstalleerd bent master in zijn vork de repository Als "basistak" zal ik niet reageren op verzoeken om wijzigingen in de repository voor cursusmateriaal.

Pull-aanvraag goedkeuren "De functie repareren"

Bedankt voor correctie! Gelieve de wijzigingen goed te keuren master van pull-verzoek.

️Taak

1. Klik op 'Pullverzoek samenvoegen'.
2. Klik op "Samenvoeging bevestigen".
3. Klik op "Verwijder tak", aangezien we deze niet langer nodig hebben.

Dit is wat je op dit moment zou moeten hebben.

Gefeliciteerd!

U heeft alle stappen voltooid die mensen normaal gesproken nemen tijdens een continue integratie.

Als u problemen met de cursus opmerkt of weet hoe u deze kunt verbeteren, maak dan een probleem aan in repository's met cursusmateriaal. Deze cursus heeft dat ook interactieve versie GitHub Learning Lab als platform gebruiken.

Bron: www.habr.com