Har du lärt dig Git-kommandon men vill förstå hur kontinuerlig integration (CI) fungerar i verkligheten? Eller kanske vill du optimera dina dagliga handlingar? Den här kursen ger dig praktiska färdigheter i CI med hjälp av ett GitHub-arkiv. Kursen är inte tänkt att vara någon sorts guide som du bara kan klicka på, istället kommer du att utföra samma handlingar som människor faktiskt gör på jobbet, på samma sätt som de gör det. Jag kommer att förklara teorin allt eftersom du går igenom de relevanta stegen.

Vad ska vi göra?

Allt eftersom vi går vidare kommer vi gradvis att bygga upp en lista över typiska CI-steg, vilket är ett bra sätt att komma ihåg den här listan. Med andra ord kommer vi att bygga upp en lista över de saker utvecklare gör när de utför kontinuerlig integration, när de gör kontinuerlig integration. Vi kommer också att använda en enkel uppsättning tester för att göra vår CI-process mer realistisk.

Denna GIF visar ett schematiskt översikt över commits i ditt repository allt eftersom du går igenom kursen. Som du kan se finns det inget komplicerat här och bara det mest nödvändiga.

Du kommer att gå igenom följande standard CI-scenarier:

• Arbetar med en funktion;
• Använda automatiserade tester för att säkerställa kvalitet;
• Genomförande av en prioriterad uppgift;
• Lösa en konflikt vid sammanslagning av grenar (sammanslagningskonflikt);
• Ett fel uppstår i en produktionsmiljö.

Vad kommer du att lära dig?

Du kommer att kunna svara på frågor som:

• Vad är kontinuerlig integration (CI)?
• Vilka typer av automatiserade tester används i CI, och vilka åtgärder utlöses som svar på?
• Vad är en pull request och när behövs de?
• Vad är testdriven utveckling (TDD) och hur relaterar det till CI?
• Sammanfoga eller ombasera?
• Återställa eller åtgärda i nästa version?

Jag översatte först saker som "pull request" överallt, men bestämde mig så småningom för att återinföra engelska fraser på vissa ställen för att tona ner galenskapen i texten. Jag använder ibland "programmerarens surzhik" som det underbara verbet "закоммить" där folk faktiskt använder det på jobbet.

Vad är kontinuerlig integration?

Fortsatt integration, eller CI, är en teknisk metod där varje teammedlem integrerar sin kod i ett delat arkiv minst en gång om dagen, med den resulterande koden som åtminstone byggs utan fel.

Det finns meningsskiljaktigheter om denna term.

Integrationsfrekvensen är en omstridd fråga. Vissa menar att det inte räcker med att bara sammanfoga kod en gång om dagen för att verkligen integrera kontinuerligt. Ett exempel är ett team där alla hämtar ny kod på morgonen och integrerar en gång på kvällen. Även om detta är en giltig poäng anses definitionen "en gång om dagen" generellt vara praktisk, specifik och lämplig för team av alla storlekar.

En annan invändning är att C++ inte längre är det enda språket som används i utveckling, och att det är svagt att bara kräva en ren version som validering. Vissa uppsättningar tester (t.ex. enhetstester som körs lokalt) måste också godkännas. Den nuvarande communityn lutar åt att göra detta till ett krav, och i framtiden kommer "version + enhetstester" förmodligen att bli normen, om det inte redan är det.

Fortsatt integration annorlunda än kontinuerlig tillförsel (Kontinuerlig leverans, CD) genom att den inte kräver en releasekandidat efter varje integrationscykel.

Listan över steg vi kommer att använda under hela kursen

1. Hämta den senaste koden. Skapa en gren från masterBörja arbeta.
2. Skapa commits på din nya branch. Bygg och testa lokalt. Godkänd? Gå till nästa steg. Misslyckas? Åtgärda fel eller tester och försök igen.
3. Push till ditt fjärrarkiv eller din fjärrgren.
4. Skapa en pull request. Diskutera ändringarna, lägg till fler commits allt eftersom diskussionen fortsätter. Se till att tester på feature-grenen går igenom.
5. Sammanfoga/återanvända commits från master. Få tester att skicka vidare sammanfogningsresultatet.
6. Distribuera från funktionsgrenen till produktion.
7. Om allt är bra i produktion under en viss tid, sammanfoga ändringarna till mastern.

️ Förberedelse

Se till att du har rätt programvara

För att ta den här kursen behöver du node.js и Git-klient.

Du kan använda vilken Git-klient som helst, men jag kommer bara att tillhandahålla kommandon för kommandoraden.

Se till att du har en Git-klient installerad som stöder kommandoraden.

Om du inte har en kommandoradsklient för Git installerad än kan du hitta installationsinstruktioner här. här.

Förbered förvaret

Du måste skapa en personlig kopia (fork) mallarkiv med kod för kursen på GitHub. Låt oss komma överens om att kalla detta personligt exemplar kursarkiv.

Klar? Om du inte har ändrat standardinställningarna heter ditt kursarkiv förmodligen continuous-integration-team-scenarios-students, den finns i ditt GitHub-konto och URL:en ser ut så här

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

Jag ringer helt enkelt den här adressen <URL репозитория>.

Vinkelparenteser som <тут> kommer att innebära att du måste ersätta ett sådant uttryck med motsvarande värde.

Se till att GitHub-åtgärder är aktiverade för detta kursarkiv. Om de inte är aktiverade, aktivera dem genom att klicka på den stora knappen mitt på sidan, som du når genom att klicka på Åtgärder i GitHub-gränssnittet.

Du kommer inte att kunna slutföra kursen genom att följa mina instruktioner om inte GitHub Actions är aktiverade.

Du kan alltid använda GitHubs möjlighet att rendera Markdown för att se det aktuella läget för listan vi skapar här.

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

Om svaren

Även om det bästa sättet att genomföra den här kursen är att göra den själv, kan du stöta på vissa svårigheter.

Om du känner att du inte förstår vad du ska göra och inte kan fortsätta kan du ta en titt på tråden. solution, som finns i ditt startarkiv.
Vänligen sammanfoga inte solution в master under kursens gång. Du kan använda den här grenen för att lista ut vad du ska göra, eller för att jämföra din kod med författarens, med hjälp av alla möjligheter som Git ger oss. Om du är helt vilse kan du helt ersätta din gren. master på en gren solution och återställ sedan din arbetskatalog till det steg i kursen du behöver.

Använd detta bara om du verkligen behöver det.

Spara din kod

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

Dessa kommandon

• döpa om master в master-backup;
• döpa om solution в master;
• byta (kassa) till en ny filial master och skriva om innehållet i arbetskatalogen;
• skapa en "solution"-gren från "master" (som tidigare var "solution") ifall du behöver en "solution"-gren i framtiden.

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

Efter dessa steg kan du använda git log master för att ta reda på vilken commit du behöver.
Du kan återställa din arbetskatalog till denna commit så här:

git reset --hard <the SHA you need>

Om du är nöjd med resultatet måste du vid någon tidpunkt publicera din version av arkivet till ett fjärrarkiv. Se till att explicit ange fjärrgrenen när du gör detta.

git push --force origin master

Observera att vi använder git push --forceDu vill förmodligen inte göra detta särskilt ofta, men vi har ett väldigt specifikt scenario här med en databasanvändare som också vet vad han gör.

Börjar arbeta

Nu börjar vi bygga vår lista över CI-steg. Normalt sett skulle du börja det här steget genom att hämta den senaste versionen av koden från ett fjärrarkiv, men vi har inget lokalt arkiv än, så vi klonar det från fjärrsystemet istället.

️ Uppgift: uppdatera lokalt arkiv, skapa en gren från master, börja arbeta

1. Klona kursarkivet från <URL репозитория>.
2. Springa npm install i kurskatalogen; vi behöver den för att installera Jest, som vi använder för att köra testerna.
3. Skapa en gren och namnge den featureByt till den här tråden.

4. Lägg till testkod till ci.test.js mellan kommentarer som ber om att få göra det.

   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. Lägg till text med de första fyra stegen i filen 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.  

   kommandon

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

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

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

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

Skapa commits på en ny branch, bygg och testa lokalt

Vi kommer att konfigurera tester som ska köras innan vi committar, och sedan committar vi koden.

Typiska scenarier när tester körs automatiskt

• Lokalt:
  • Kontinuerligt eller som svar på relevanta kodändringar;
  • Vid sparning (för tolkade eller JIT-kompilerade språk);
  • Under montering (när kompilering krävs);
  • Vid beställning;
  • Vid publicering till ett delat arkiv.

• På byggservern eller i byggmiljön:
  • När kod publiceras till en personlig gren/databas.
  • Koden i den här grenen testas.
  • Det potentiella resultatet av fusionen prövas (vanligtvis med master).
  • Som ett steg i en kontinuerlig integration/kontinuerlig leveranspipeline

Generellt sett, ju snabbare en testsvit körs, desto oftare har du råd att köra den. En typisk fasuppdelning kan se ut så här.

• Snabba enhetstester - vid byggnation, i CI-pipeline
• Långsamma enhetstester, snabba komponent- och integrationstester - vid commit, i CI-pipelinen
• Långsamma komponent- och integrationstester i CI-pipelinen
• Säkerhetstestning, belastningstestning och andra långa eller dyra tester – i CI/CD-pipelines, men endast i vissa bygglägen/-steg/-pipelines, till exempel vid förberedelse av en releasekandidat eller när de utlöses manuellt.

Uppgift

Jag föreslår att du kör testerna manuellt först med kommandot npm testNu ska vi lägga till en git-hook för att köra våra tester vid commit. Det finns en hake: Git-hooks anses inte vara en del av repositoriet och kan därför inte klonas från GitHub tillsammans med resten av kursmaterialet. För att installera hooken måste du köra install_hook.sh eller kopiera filen repo/hooks/pre-commit till lokal katalog .git/hooks/.
När du genomför commit ser du att tester körs och de kontrollerar om vissa nyckelord finns i listan.

1. Kör testerna manuellt genom att köra kommandot npm test i din kursarkivsmapp. Se till att testerna har körts.
2. Installera en pre-commit-krok genom att köra install_hook.sh.
3. Spara ändringarna i ditt lokala arkiv.
4. Se till att tester körs innan du genomför överföringen.

Ditt arkiv bör se ut så här efter att du har slutfört dessa steg.

kommandon

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

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

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

Publicera kod till ett fjärrarkiv eller en fjärrgren

När de har arbetat klart lokalt gör utvecklare vanligtvis sin kod allmänt tillgänglig så att den så småningom kan integreras med det delade arkivet. Med GitHub görs detta vanligtvis genom att publicera arbetet antingen till en personlig fork av arkivet eller en personlig branch.

• Med forking klonar en utvecklare ett delat arkiv på distans och skapar en personlig fjärrkopia av det, även känt som en fork. De klonar sedan detta personliga arkiv för att arbeta med det lokalt. När arbetet är klart och commits har skapats, skickar de dem till sin fork, där de är tillgängliga för andra och kan integreras i det delade arkivet. Denna metod används ofta i öppen källkodsprojekt på GitHub. Den används också i min avancerade kurs [Teamarbete och CI med Git] (http://devops.redpill.solutions/).
• Ett annat tillvägagångssätt är att bara använda ett fjärrarkiv och bara räkna grenen master delat arkiv "skyddat". I det här scenariot publicerar enskilda utvecklare sin kod till en gren av ett fjärrarkiv så att andra kan granska koden och, om allt är bra, slå samman den med master gemensamt arkiv.

I den här kursen kommer vi att använda ett arbetsflöde som använder grenar.

Låt oss publicera vår kod.

Uppgift

• Publicera dina ändringar till en fjärrgren med samma namn som din arbetsgren

kommandon

git push --set-upstream origin feature

Skapa en pull request

Skapa en pull request med titeln Stegsgranskning... Installera feature som "huvudgren" och master som "basgren".

Se till att du har installerat master i hans förgreningen av förvaret Som "basgren" kommer jag inte att svara på pull-förfrågningar till kursmaterialförrådet.

I GitHub-slang är "base branch" den gren du baserar ditt arbete på, och "head branch" är den gren som innehåller dina föreslagna ändringar.

Diskutera ändringarna, lägg till nya commits allt eftersom diskussionen fortsätter.

Pull request (PR)

Pull request (PR) — är ett sätt att diskutera och dokumentera kod, samt genomföra en kodgranskning. Pull requests är namngivna efter ett vanligt sätt att integrera enskilda ändringar i den övergripande koden. Vanligtvis klonar en person ett officiellt projektarkiv och arbetar med koden lokalt. Därefter skickar de koden till sitt personliga fjärrarkiv och ber utvecklarna av det officiella arkivet att hämta den.dra) hans kod till sina lokala arkiv, där de granskar och eventuellt integrerar (sammanfoga) det. Detta koncept är även känt under andra namn, till exempel, sammanslagningsbegäran.

Du behöver egentligen inte använda GitHubs pull request-funktion eller liknande plattformar. Utvecklarteam kan använda andra kommunikationsmetoder, inklusive personliga samtal, röstsamtal eller e-post, men det finns fortfarande ett antal anledningar att använda dessa forumliknande pull requests. Här är några:

• organiserade diskussioner relaterade till specifika ändringar i koden;
• som en plats att se feedback på pågående arbete från både automatiserade tester och kollegor;
• formalisering av kodkontroller;
• så att du senare kan ta reda på orsakerna och övervägandena bakom en viss kodstycke.

Vanligtvis skapar du en pull request när du behöver diskutera något eller få feedback. Om du till exempel arbetar med en funktion som kan implementeras på flera sätt kan du skapa en pull request innan du skriver en enda kodrad för att dela dina idéer och diskutera dina planer med samarbetspartners. Om arbetet är enklare öppnar du en pull request när något redan är klart, committat och kan diskuteras. I vissa scenarier kan du öppna en PR enbart av kvalitetskontrollskäl: för att köra automatiserade tester eller initiera en kodgranskning. Oavsett vad du bestämmer dig för, se till att @nämna de personer vars godkännande du behöver i din pull request.

Vanligtvis gör du följande när du skapar en PR:

• Specificera vad du föreslår att ändra och var.
• Skriv en beskrivning som förklarar syftet med ändringen. Du kanske vill:
  • lägg till allt viktigt som inte framgår av koden, eller något som är användbart för att förstå sammanhanget, såsom relevanta #bugs och commit-nummer;
  • @nämn vem du vill börja arbeta med, eller så kan du @nämna dem i kommentarerna senare;
  • be kollegor om hjälp med något eller kontrollera något specifikt.

När du öppnar en PR körs de tester som är konfigurerade att köras i sådana fall. I vårt fall kommer detta att vara samma uppsättning tester som vi körde lokalt, men i ett verkligt projekt kan det finnas ytterligare tester och kontroller.

Vänta tills testerna är klara. Du kan se testernas status längst ner i PR-diskussionen i GitHub-gränssnittet. Fortsätt när testerna är klara.

️ Lägg till en anteckning om godtyckligheten i CI-steglistan

Listan som används i den här kursen är godtycklig och subjektiv, vi måste lägga till en anmärkning om detta.

️ Uppgift: Skapa en pull request för den här anteckningen

1. Byt till filial master.
2. Skapa en gren med namnet bugfix.
3. Lägg till anteckningstext i slutet av filen 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. Genomför ändringarna.
5. Publicera tråden bugfix till fjärrförvaret.
6. Skapa en pull request med namnet Lägga till en kommentar med en huvudgren bugfix och basgrenenmaster.

Se till att du har installerat master i hans förgreningen av förvaret Som "basgren" kommer jag inte att svara på pull-förfrågningar till kursmaterialförrådet.

Så här ska ditt arkiv se ut.

kommandon

# Переключитесь на ветку 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 как описано выше

Godkänn pull request "Lägger till en kommentar"

Uppgift

1. Skapa en pull request.
2. Klicka på "Sammanfoga pull request".
3. Klicka på "Bekräfta sammanslagning".
4. Klicka på "Ta bort gren", vi behöver den inte längre.

Detta är ett diagram över commits efter sammanslagningen.

️ Fortsätt arbeta och lägg till tester

Att samarbeta kring en pull request resulterar ofta i att ytterligare arbete krävs. Detta är vanligtvis resultatet av en kodgranskning eller diskussion, men i vår kurs kommer vi att modellera detta genom att lägga till nya punkter i vår CI-steglista.

Kontinuerlig integration innebär vanligtvis en viss testtäckning. Kraven på testtäckning varierar och finns vanligtvis i ett dokument som heter något i stil med "bidragsriktlinjer". Vi håller det enkelt och lägger till ett test för varje rad i vår checklista.

När du kör uppgifter, försök att genomföra testerna först. Om du har konfigurerat korrekt pre-commit hook tidigare, testet vi just lade till kommer att köras, misslyckas och ingenting kommer att committas. Observera att det är så vi vet att våra tester faktiskt testar något. Intressant nog, om vi hade börjat med koden före testerna, skulle klarade tester kunna innebära antingen att koden fungerar som förväntat, eller att testerna faktiskt inte testar någonting. Om vi ​​inte hade skrivit testerna från första början kanske vi hade glömt bort dem helt och hållet, eftersom det inte skulle finnas något som påminde oss.

Testdriven utveckling (TDD)

TDD rekommenderar att man skriver tester innan man skriver kod. Ett typiskt arbetsflöde med TDD ser ut så här.

1. Lägg till ett test.
2. Kör alla tester och se till att det nya testet misslyckas.
3. Skriv koden.
4. Kör testerna, se till att alla tester blir godkända.
5. Omstrukturera din kod.
6. Upprepa.

Eftersom resultaten av tester som misslyckas vanligtvis visas i rött och de som klaras visas i grönt, kallas cykeln även för "röd-grön-refaktorering".

Uppgift

Försök först att genomföra testerna och låta dem misslyckas, lägg sedan till och genomför själva CI-steglistan. Du kommer att se att testerna klarar testet ("grönt").
Skicka sedan den nya koden till fjärrarkivet och titta på testerna som körs i GitHub-gränssnittet längst ner i diskussionen om pull requests och PR-statusuppdateringen.

1. Byt till filial feature.

2. Lägg till dessa tester till ci.test.js efter det senaste samtalet 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. Försök att genomföra testerna. Om pre-commit hooken är satt, kommer ett försök att committa att misslyckas.
4. Lägg sedan till den här texten 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. Gör och bekräfta dina ändringar lokalt.
6. Publicera ändringar i grenen feature.

Nu borde du ha något liknande detta

kommandon

# Переключительна ветку 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

Konflikt vid fusion

Gå vidare till ändringsbegäran Stegsgranskning.

Även om vi inte har gjort något fel och testerna för vår kod har klarats, kan vi fortfarande inte sammanfoga grenen. feature и masterDetta beror på att den andra grenen bugfix slogs samman med master medan vi arbetade med denna PR.
Detta skapar en situation där den fjärrstyrda filialen master har en nyare version än den vi baserade grenen på featurePå grund av detta kan vi inte bara spola tillbaka HEAD master till slutet av grenen featureI den här situationen behöver vi antingen sammanfoga eller tillämpa commits feature rebase masterGitHub kan faktiskt göra en automatisk sammanslagning om det inte finns några konflikter. Tyvärr har båda grenarna i vår situation konkurrerande ändringar i filen. ci.mdDen här situationen kallas en sammanslagningskonflikt och vi måste lösa den manuellt.

Sammanfoga eller omforma basen

Sammanfoga

• Skapar en ytterligare merge-commit och sparar arbetets historik.
  • Bevarar de ursprungliga branch-commits med deras ursprungliga tidsstämplar och författare.
  • Bevarar commit SHA:er och referenser till dem i diskussioner om pull requests.
• Kräver engångskonfliktlösning.
• Gör berättelsen icke-linjär.
  • Historiken kan vara svårläst på grund av det stora antalet grenar (liknar en IDE-kabel).
  • Komplicerar automatisk felsökning, till exempel gör git bisect mindre användbart - den kommer bara att hitta merge-commiten.

Ombas

• Spelar upp commits från den aktuella grenen ovanpå basgrenen en efter en.
  • Nya commits genereras med nya SHA:er, vilket resulterar i commits i GitHub som matchar de ursprungliga pull requests men inte motsvarande kommentarer.
  • Commits kan kombineras om och ändras längs vägen, eller till och med slås samman till ett.
• Det kan finnas flera konflikter att lösa.
• Gör att du kan upprätthålla en linjär berättelse.
  • Berättelsen kan vara lättare att läsa om den inte av goda skäl är för lång.
  • Automatisk felsökning och felsökning är lite enklare: det gör det möjligt git bisect, kan göra automatiska återställningar tydligare och mer förutsägbara.
• Kräver publicering av en branch med flyttade commits med en flagga --force när den används med ändringsförfrågningar.

Vanligtvis är team överens om att alltid använda samma strategi när de behöver sammanfoga ändringar. Detta kan vara en "ren" sammanfogning, eller en "ren" apply-on-top, eller något däremellan, som att göra en interaktiv apply-on-top(git rebase -i) lokalt för grenar som inte publiceras till det publika arkivet, men sammanfogas för "publika" grenar.

Här kommer vi att använda sammanslagning.

Uppgift

1. Se till att koden finns på en lokal filial master uppdaterad från fjärrarkivet.
2. Byt till filial feature.
3. Initiera en sammanslagning med en gren masterEn sammanslagningskonflikt som involverar konkurrerande ändringar i ci.md.
4. Lös konflikten så att både vår lista över CI-steg och anmärkningen om den finns kvar i texten.
5. Publicera en merge-commit till en fjärrfilial feature.
6. Kontrollera statusen för pull-förfrågan i GitHub-gränssnittet och vänta tills sammanslagningen är löst.

kommandon

# Убедитесь, что код в локальное ветке `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, дождитесь пока слияние не будет разрешено.

Bra jobbat!

Du har arbetat klart med listan och nu behöver du godkänna pull request i master.

️ Uppgift: Godkänn pull request "Steggranskning"

1. Öppna en pull request.
2. Klicka på "Sammanfoga pull request".
3. Klicka på "Bekräfta sammanslagning".
4. Klicka på "Ta bort gren" eftersom vi inte behöver den längre.

Detta är ditt arkiv för tillfället.

Fel vid produktion

Det sägs att "tester kan användas för att visa förekomsten av buggar, men aldrig för att visa deras frånvaro." Även om vi hade tester och de inte visade oss några buggar, smög sig en smygande bugg in i produktionen.

I ett sådant scenario behöver vi ta hand om:

• det som används i produktionen;
• kod i grenen master med ett fel från vilket utvecklare kan starta nytt arbete.

Återställa eller åtgärda i nästa version?

"Att återställa" är handlingen att driftsätta en tidigare version som är känd för att fungera till produktion och återställa de commits som innehåller buggen. "Att åtgärda framåt" är handlingen att lägga till korrigeringen till master och driftsätta den nya versionen så snart som möjligt. Eftersom API:er och databasscheman ändras allt eftersom kod driftsätts till produktion, med kontinuerlig leverans och god testtäckning, är det vanligtvis mycket svårare och mer riskabelt att återställa kod än att åtgärda det i nästa version.

Eftersom att gå tillbaka inte medför någon risk i vårt fall, kommer vi att gå den här vägen, eftersom det tillåter oss

• åtgärda felet på produkten så snart som möjligt;
• skapa kod i master omedelbart lämplig för att börja ett nytt jobb.

Uppgift

1. Byt till filial master lokalt.
2. Uppdatera ditt lokala arkiv från fjärrarkivet.
3. Återställ PR-sammanslagningscommit Stegsgranskning в master.
4. Publicera ändringar till fjärrarkivet.

Detta är historiken för ett arkiv med en återställd merge-commit.

kommandon

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

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

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

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

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

️ Självkontroll

Se till att ci.md innehåller inte längre texten "smygande bugg" efter att en merge-commit har återställts.

Åtgärda CI-steglistan och skicka tillbaka den till mastern

Vi återställde helt och hållet branch merge-commiten featureDen goda nyheten är att vi inte längre har någon bugg i masterDen dåliga nyheten är att vår värdefulla CI-steglista också är borta. Så helst vill vi tillämpa korrigeringen på commits från feature och återlämna dem till master tillsammans med korrigeringen.

Vi kan närma oss problemet på olika sätt:

• återställa en commit som ångrar en sammanslagning feature с master;
• överföringsförpliktelser från tidigare feature.

Olika utvecklingsteam använder olika metoder i det här fallet, men vi kommer att flytta användbara commits till en separat branch och skapa en separat pull request för denna nya branch.

Uppgift

1. Skapa en gren som heter feature-fix och byta till det.

2. Flytta alla commits från den tidigare grenen feature till den nya grenen. Lös eventuella sammanslagningskonflikter som uppstod under flytten.

   

3. Lägg till ett regressionstest till ci.test.js:

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

4. Kör testerna lokalt för att säkerställa att de misslyckas.
5. Ta bort texten "med en smygande bugg" i ci.md.
6. Lägg till teständringarna och steglistan i indexet och spara dem.
7. Publicera grenen till fjärrdatabasen.

Du borde få fram något liknande detta

kommandon

# Создайте ветку под названием 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

Skapa en pull request.

Skapa en pull request med titeln Åtgärda funktionen... Installera feature-fix som "huvudgren", och master som "basgren".
Vänta tills testerna är klara. Du kan se testernas status längst ner i PR-diskussionen.

Se till att du har installerat master i hans förgreningen av förvaret Som "basgren" kommer jag inte att svara på pull-förfrågningar till kursmaterialförrådet.

Godkänn pull request "Åtgärdar funktionen"

Tack för rättelsen! Vänligen godkänn ändringarna i master från pull request.

Uppgift

1. Klicka på "Sammanfoga pull request".
2. Klicka på "Bekräfta sammanslagning".
3. Klicka på "Ta bort gren" eftersom vi inte behöver den längre.

Det här är vad du borde ha just nu.

Grattis!

Du har gjort allt som folk vanligtvis gör i en kontinuerlig integrationsprocess.

Om du märker några problem med kursen eller vet hur du kan förbättra den, skapa ett ärende i arkiv med kursmaterialDenna kurs har också interaktiv version använder GitHub Learning Lab som plattform.

Källa: will.com