Har du lärt dig Git-kommandon men vill förstå hur kontinuerlig integration (Continuous Integration, CI) fungerar i praktiken? Eller kanske du vill optimera dina dagliga uppgifter? Den här kursen ger dig praktiska färdigheter inom kontinuerlig integration med hjälp av ett repository på GitHub. Kursen är inte avsedd att vara en wizard som du bara klickar igenom, utan du kommer att utföra de samma handlingar som människor faktiskt gör i sitt arbete, på det sätt som de gör det. Jag kommer att förklara teorin i takt med att du går igenom de relaterade stegen.

Vad ska vi göra?

Under kursens gång kommer vi gradvis att skapa en lista över typiska CI-steg, vilket är ett utmärkt sätt att komma ihåg denna lista. Med andra ord kommer vi att skapa en lista över de handlingar som utvecklare utför vid kontinuerlig integration. Vi kommer också att använda en enkel uppsättning tester för att närma vår CI-process till verkligheten.

Denna GIF visar schematiskt commits i ditt repository i takt med att du går igenom kursen. Som du ser finns det inget komplicerat här, endast det mest nödvändiga.

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

• Arbeta med en funktion;
• Använda automatiserade tester för att säkerställa kvalitet;
• Implementera en prioriterad uppgift;
• Lösa en merge-konflikt;
• Förekomsten av ett fel i produktionsmiljön.

Vad kommer du att lära dig?

Du kommer att kunna svara på följande frågor:

• Vad är kontinuerlig integration (CI)?
• Vilka typer av automatiserade tester används inom CI och vid vilka åtgärder aktiveras de?
• Vad är en pull request och när behövs de?
• Vad är testdriven utveckling (Test Driven Development, TDD) och hur förhåller den sig till CI?
• Ska jag göra en merge eller applicera ändringar med rebase?
• Ska jag återställa eller fixa det i nästa version?

I början översatte jag saker som "pull request" överallt, men jag bestämde mig för att återgå till engelska fraser på vissa ställen för att minska vansinnet i texten. Jag kommer ibland att använda "programmeringssurzj" som det underbara verbet "commit" där människor faktiskt använder det på jobbet.

Vad är kontinuerlig integration?

Kontinuerlig integration, eller CI, är en teknisk praxis som innebär att varje teammedlem integrerar sin kod i det gemensamma arkivet minst en gång om dagen, och den resulterande koden måste dessutom kunna byggas utan fel.

Det finns olika tolkningar av denna term.

Föremålet för diskussionen är frekvensen av integration. Vissa hävdar att att bara kombinera koden en gång om dagen inte är tillräckligt; integration bör ske kontinuerligt. Ett exempel ges med ett team där alla hämtar färsk kod på morgonen och integrerar en gång på kvällen. Även om detta är ett rimligt invändning, anses det ändå överlag att alternativet "en gång om dagen" är tillräckligt praktiskt, konkret och passar team av olika storlekar.

Ett annat invändning är att C++ inte längre är det enda språket som används vid utveckling, och att det enklare kravet på att bygga utan fel, som en valideringsmetod, är svagt. En viss uppsättning tester (t.ex. enhetstester som körs lokalt) bör också slutföras framgångsrikt. För närvarande har samhället en tendens att vilja att detta krav ska vara obligatoriskt, och i framtiden kommer "bygg + enhetstester" förmodligen att bli allmänt accepterat, om det inte redan har hänt.

Kontinuerlig integration skiljer sig från kontinuerlig leverans (Continuous Delivery, CD) genom att det inte kräver en releasekandidat efter varje integrationscykel.

En lista över steg som vi kommer att använda under kursens gång.

1. Hämta den senaste koden. Skapa en gren från master. Börja arbeta.
2. Skapa commits på din nya gren. Bygg och testa lokalt. Går det bra? Gå till nästa steg. Misslyckas? Åtgärda fel eller tester och försök igen.
3. Skjut upp till ditt fjärrarkiv eller fjärrgren.
4. Skapa en pull-begäran. Diskutera ändringarna, lägg till fler commits i takt med diskussionen fortsätter. Gör testerna godkända på funktionsgrenen.
5. Merg/egrunda commits från master. Gör testerna godkända på resultatet av sammanslagningen.
6. Distribuera från funktionsgrenen till produktion.
7. Om allt ser bra ut i produktion under en viss tidsperiod, slå samman ändringarna till master.

️ Förberedelse

Se till att du har rätt programvara.

För att genomföra denna kurs behöver du Node.js och Git-klient..

Du kan använda vilken Git-klient som helst, men jag kommer endast att ge kommandon för kommandoraden.

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

Om du ännu inte har installerat en Git-klient som stöder kommandoraden kan du hitta installationsanvisningar. här.

Förbered arkivet.

Du behöver skapa en personlig kopia (fork) av mallarkivet med kod för kursen på GitHub. Låt oss komma överens om att kalla denna personliga kopia kursens arkiv..

Har du gjort det? Om du inte har ändrat standardinställningarna kallas din kursrepo troligtvis continuous-integration-team-scenarios-students, det finns i ditt konto på GitHub, och URL:en ser ut så här

https://github.com//continuous-integration-team-scenarios-students

Jag kommer att kalla denna adress helt enkelt <URL репозитория>.

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

Se till att GitHub Actions är aktiverade för detta kursrepo. Om de inte är aktiverade, aktivera dem genom att klicka på den stora knappen i mitten av sidan, som du kan nå genom att klicka på Actions i GitHub-gränssnittet.

Du kommer inte att kunna gå igenom kursen, enligt mina instruktioner, om GitHub Actions inte är aktiverade.

Du kan alltid använda GitHubs möjlighet att visa Markdown för att se den aktuella statusen för listan som vi skapar här

https://github.com//continuous-integration-team-scenarios-students/blob/master/ci.md

Om svar

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

Om du känner att du inte förstår vad du ska göra och inte kan fortsätta, kan du kolla i grenen solution, som finns i ditt startrepo.
Vänligen gör inga sammanslagningar solution på master under kursen. Du kan använda denna gren för att ta reda på vad du ska göra, eller för att jämföra din kod med grundarens kod, med alla möjligheter som Git ger oss. Om du helt har gått vilse kan du helt ersätta din gren master med grenen solution och sedan återställa din arbetskatalog till det steg i kursen som du behöver.

Använd detta endast om det verkligen behövs

Begå (commit) din kod

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

Dessa kommandon

• byter namn på master på master-backup;
• byter namn på solution på master;
• byter (checkout) till den nya grenen master och skriver om innehållet i arbetskatalogen;
• skapar en gren "solution" från "master" (som tidigare var "solution") ifall du behöver "solution"-grenen i framtiden.

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

Efter dessa åtgärder 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

Om du är nöjd med resultatet, kommer du så småningom behöva publicera din version av arkivet till ett fjärrarkiv. Glöm inte att tydligt ange den fjärrgren när du gör detta.

git push --force origin master

Observera att vi använder git push --force. Det är osannolikt att du ofta vill göra detta, men vi har ett mycket speciellt scenario med en användare av arkivet som dessutom förstår vad han gör.

Börjar arbeta

Låt oss börja med att skapa vår lista över CI-steg. Vanligtvis börjar du detta steg med att hämta den senaste versionen av koden från fjärrarkivet, men vi har inte ett lokalt arkiv än, så istället klonar vi det från det fjärrans.

Uppgift: uppdatera det lokala arkivet, skapa en gren från master, börja arbeta

1. Klonar kursens arkiv från <URL репозитория>.
2. Kör npm install i katalogen för kursens arkiv; det behövs för installationen av Jest, som vi använder för att köra tester.
3. Skapa en gren och namnge den funktion. Byt till denna gren.

4. Lägg till testkod i ci.test.js mellan kommentarerna med begäran att göra detta.

   it('1. dra senaste koden', () => {
     expect(/.*pull.* /ig.test(fileContents)).toBe(true);
   });
   
   it('2. lägg till commits', () => {
     expect(/.*commit.* /ig.test(fileContents)).toBe(true);
   });
   
   it('3. tryck till den fjärrgren med samma namn', () => {
     expect(/.*push.* /ig.test(fileContents)).toBe(true);
   });
   
   it('4. skapa en pull-begäran och fortsätta arbeta', () => {
     expect(/.*pulls+request.* /ig.test(fileContents)).toBe(true);
   });

5. Lägg till text med de första 4 stegen i filen ci.md.

   1. Dra in den senaste koden. Skapa en gren från `master`. Börja arbeta.    
   2. Skapa commits i din nya gren. Bygg och testa lokalt.  
   Passar? Gå till nästa steg. Misslyckas? Åtgärda fel eller tester och försök igen.  
   3. Tryck till ditt fjärrarkiv eller fjärrgren.  
   4. Skapa en pull-begäran. Diskutera förändringarna, lägg till fler commits  
   som diskussionen fortsätter. Få tester att gå igenom på funktionsgrenen.  

   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 i den nya grenen, bygg och testa lokalt

Vi kommer att konfigurera tester så att de körs före commit, och sedan commitera koden.

Typiska scenarier där tester körs automatiskt

• Lokalt:
  • Konstant eller som svar på relevanta kodförändringar;
  • Vid sparande (för tolkade eller JIT-kompilerade språk);
  • Vid byggande (när kompilering krävs);
  • Vid commit;
  • Vid publicering till ett gemensamt arkiv.

• På byggservern eller i byggmiljön:
  • När koden publiceras till en personlig gren / arkiv.
  • Testar koden i denna gren.
  • Testar det potentiella resultatet av sammanslagning (vanligtvis med master).
  • Som ett steg i kontinuerlig integration/delivery-pipeline

Generellt sett, ju snabbare ett testset körs, desto oftare kan du tillåta att det körs. En typisk fördelning av stegen kan se ut så här.

• Snabba modulära tester – vid byggnation, i CI-pipelinen
• Långsamma modulära tester, snabba komponent- och integrationstester – vid commit, i CI-pipelinen
• Långsamma komponent- och integrationstester – i CI-pipelinen
• Säkerhetstester, belastningstester och andra långvariga eller kostsamma tester – i CI/CD-pipelines, men bara i vissa lägen/steg/byggpipelines, exempelvis vid förberedelse av en release-kandidat eller vid manuell körning.

️ Uppgift

Jag föreslår att vi först kör testerna manuellt med kommandot npm test. Därefter låt oss lägga till en git hook för att köra våra tester vid commit. Det finns en hake: Git hooks räknas inte som en del av repositoriet och kan därför inte klonas från GitHub tillsammans med övrigt kursmaterial. För att installera hooken måste du köra install_hook.sh eller kopiera filen repo/hooks/pre-commit till den lokala katalogen .git/hooks/.
Vid commit ser du att testerna körs, och de kontrollerar om vissa nyckelord finns i listan.

1. Kör testerna manuellt genom att utföra kommandot npm test i mappen för ditt kursrepository. Se till att testerna har körts.
2. Installera hook vid commit (pre-commit hook) genom att köra install_hook.sh.
3. Commita ändringarna till det lokala repositoriet.
4. Se till att testerna körs innan commit.

Ditt repository ska se ut så här efter att ha genomfört dessa åtgärder.

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 koden i det fjärran repositoriet eller en fjärrbranch

När utvecklare har slutfört sitt arbete lokalt gör de vanligtvis sin kod offentlig för att den ska kunna integreras med den gemensamma. Med hjälp av GitHub uppnås detta vanligtvis genom att publicera arbetet antingen i en personlig kopia av repositoriet (personal fork) eller i en personlig branch.

• När en utvecklare använder forkar klonar hen ett avlägset gemensamt repository, vilket skapar en personlig avlägsen kopia, också känd som en fork. Därefter klonar hen detta personliga repository för att arbeta med det lokalt. När arbetet är klart och commits har gjorts, lägger hen dem i sin fork, där de är tillgängliga för andra och kan integreras i det gemensamma repositoryt. Denna metod används vanligtvis i projekt med öppen källkod på GitHub. Den används också i min avancerade kurs [Team Work and CI with Git]http://devops.redpill.solutions/).
• Ett annat tillvägagångssätt är att använda endast ett avlägset repository och betrakta endast grenen master av det gemensamt använda repositoryt som "skyddad". I detta scenario publicerar separata utvecklare sin kod i grenar av det avlägsna repositoryt så att andra kan se koden, och om allt är i sin ordning kan den slås samman med master det gemensamma repositoryt.

I denna specifika kurs kommer vi att använda ett arbetsflöde som involverar grenar.

Låt oss publicera vår kod.

️ Uppgift

• Publicera ändringarna i den avlägsna grenen med samma namn som din arbetsgren

Kommandon

git push --set-upstream origin feature

Skapa en pull request

Skapa en pull request med titeln Steps review. Ställ in funktion som "head branch" och master som "base branch".

Se till att du har ställt in master , i sin forken av repositoryt som "base branch", jag kommer inte att svara på förändringsförfrågningar till repositoryt med kursmaterial.

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

Diskutera ändringarna, lägg till nya commits när diskussionen fortsätter

Pull request (PR)

Pull request (PR) är ett sätt att diskutera och dokumentera kod samt att genomföra kodgranskning (code review). Pull requests är uppkallade efter det gemensamma sättet att integrera individuella ändringar i den gemensamma koden. Vanligtvis klonar en person det avlägsna officiella repositoryt för projektet och arbetar på koden lokalt. Efter det lägger hen koden i sin personliga avlägsna repository och ber de ansvariga för det officiella repositoryt att hämtapull) sin kod till sina lokala repositories, där de granskar och eventuellt integrerarmerge) den. Detta begrepp är också känt under andra namn, till exempel, merge request.

I verkligheten behöver du inte nödvändigtvis använda pull request-funktionen på GitHub eller liknande plattformar. Utvecklarteam kan använda andra sätt att kommunicera, inklusive personliga möten, röstsamtal eller e-post, men det finns ändå en rad skäl att använda sådana pull requests i stil med forumdiskussioner. Här är några av dem:

• organiserade diskussioner relaterade till specifika förändringar i koden;
• som en plats för att granska feedback på oavslutat arbete från både automatiska tester och kollegor;
• formalisering av kodgranskningar;
• för att senare kunna klargöra orsaker och överväganden bakom en viss koddel.

Vanligtvis skapar du en pull request när du behöver diskutera något eller få feedback. Till exempel, om du arbetar med en funktion som kan genomföras på flera sätt, kan du skapa en ändringsbegäran även innan du har skrivit den första raden kod för att dela dina idéer och diskutera dina planer med medförfattare. Om arbetet är enklare, öppnas pull requesten när något redan är gjort, förankrat och kan diskuteras. I vissa scenarier kan du öppna PR endast av kvalitetskontrollskäl: för att köra automatiska tester eller initiera en kodgranskning. Vad du än väljer, kom ihåg att @nämna personer vars godkännande krävs i din pull request.

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

• Ange vad du föreslår att ändra och var.
• Skriv en beskrivning som förklarar syftet med förändringarna. Du kanske vill:
  • lägga till något som är viktigt och inte uppenbart från koden, eller något användbart för att förstå kontexten, till exempel relaterade #buggar och commit-nummer;
  • @nämna alla som du vill börja samarbeta med, eller så kan du @nämna dem i kommentarerna senare;
  • be kollegor om hjälp med något eller att granska något specifikt.

När du har öppnat PR körs tester som är inställda för att aktiveras i sådana fall. I vårt fall kommer det att bli samma uppsättning tester som vi kört lokalt, men i ett verkligt projekt kan det finnas ytterligare tester och kontroller.

Vänligen vänta tills testerna är klara. Du kan se teststatus i botten av PR-diskussionen i GitHub-gränssnittet. Fortsätt när testerna är klara.

️ Lägg till en anmärkning om godtyckligheten av CI-steglistan

Listan som används i den här kursen är godtycklig och subjektiv; vi bör lägga till en anmärkning om detta.

️ Uppgift: skapa en pull request för den här anmärkningen

1. Byt till grenen master.
2. Skapa en gren med namnet bugfix.
3. Lägg till texten till anmärkningen i slutet av filen ci.md.

   > **GitHub-flöde** används ibland som ett smeknamn för en variant av trunkbaserad utveckling  
   när kod distribueras direkt från funktionsgrenar. Denna lista är bara en tolkning  
   som jag använder i mina [DevOps-kurser](http://redpill.solutions).  
   Den officiella handledningen är [här](https://guides.github.com/introduction/flow/).

4. Kommitta ändringar.
5. Publicera grenen bugfix till det fjärrlagret.
6. Skapa en pull request med namnet Lägger till en anmärkning med huvudgrenen bugfix och basgrenenmaster.

Se till att du har ställt in master , i sin forken av repositoryt som "base branch", jag kommer inte att svara på förändringsförfrågningar till repositoryt med kursmaterial.

Så här bör ditt lager 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 anmärkning"

️ Uppgift

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

Detta är diagrammet över commits efter sammanslagningen.

️ Fortsätt arbeta och lägg till tester

Samarbete kring en pull request leder ofta till behovet av ytterligare arbete. Det är vanligtvis ett resultat av kodgranskning eller diskussion, men i vår kurs ska vi simulera detta genom att lägga till nya punkter i vår CI-steglista.

Vid kontinuerlig integration tillämpas vanligtvis viss testtäckning. Kraven på testtäckning varierar och finns oftast i ett dokument med titeln något i stil med "bidragsriktlinjer". Vi kommer att göra det enkelt och lägga till en test för varje rad i vår checklist.

När du utför uppgifter, försök först att kommitta testerna. Om du har installerat pre-commit hook tidigare, kommer det just tillagda testet att köras, inte godkännas, och inget kommer att kommittas. Observera: på så sätt får vi veta att våra tester faktiskt kontrollerar något. Intressant nog, om vi skulle ha börjat med koden före testerna, skulle godkännandet av testerna kunna betyda antingen att koden fungerar som förväntat, eller att testerna faktiskt inte kontrollerar något. Dessutom, om vi inte hade skrivit tester i första hand, skulle vi kunna glömma dem helt, eftersom inget skulle påminna oss om dem.

Utveckling genom testning (TDD)

TDD rekommenderar att skriva tester innan koden. Den vanliga arbetsprocessen med TDD ser ut så här.

1. Lägg till ett test.
2. Kör alla tester och säkerställ att det nya testet inte passerar.
3. Skriv koden.
4. Kör testerna, se till att alla tester passerar.
5. Refaktorisera koden.
6. Upprepa.

Eftersom resultaten av tester som inte har passerat vanligtvis visas i rött, medan de som har passerat visas i grönt, kallas cykeln också för "röd-grön-refaktorering".

️ Uppgift

Försök först att commita testerna och låt dem avslutas utan att passera, sedan lägg till och commita själva texten till CI-steglistan. Du kommer att se att testerna passerar ("gröna").
Publicera sedan den nya koden i det fjärrlagrade arkivet och se hur testerna körs i GitHub-gränssnittet längst ner i diskussionen om begäran om att göra ändringar, och uppdatera PR-statusen.

1. Byt till grenen funktion.

2. Lägg till dessa tester i ci.test.js efter den senaste anropet it (...);.

   it('5. Sammanfoga/Rebasera commits från master. Gör testerna godkända för sammanfogningsresultatet.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Distribuera från funktionsgrenen till produktion.', () => {
     expect(/.*Deploy.*to production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. Om allt är bra i produktion under en tidsperiod, sammanfoga ändringar till master.', () => {
     expect(/.*merge.*to master.*/ig.test(fileContents)).toBe(true);
   });

3. Försök att commita testerna. Om pre-commit hooken är installerad, kommer commitsförsöket att misslyckas.
4. Lägg sedan till denna text i ci.md.

   5. Sammanfoga/Rebasera commits från master. Gör testerna godkända för sammanfogningsresultatet.  
   6. Distribuera från funktionsgrenen med en smygbugg till produktion.
   7. Om allt är bra i produktion under en tidsperiod, sammanfoga ändringar till master. 

5. Gör och commita ändringar lokalt.
6. Publicera ändringarna i grenen funktion.

Nu bör du ha något som ser ut som 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

Sammanfogningskonflikt

Gå till förfrågan om att göra ändringar Steps review.

Trots att vi inte har gjort något fel, och testerna för vår kod har passerat, kan vi fortfarande inte genomföra sammanfogningen av grenen funktion och master. Detta beror på att en annan gren bugfix har sammanfogats med master medan vi arbetade med denna PR.
Detta skapar en situation där den fjärrliggande grenen master har en nyare version än den vi baserade grenen på funktion. På grund av detta kan vi inte bara spola tillbaka HEAD master till slutet av grenen funktion. I denna situation måste vi antingen genomföra en sammanfogning (merge) eller tillämpa commits funktion ovanför (rebase) masterGitHub kan faktiskt utföra 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 (merge conflict), och vi måste lösa den manuellt.

Merge eller rebase

Merge

• Skapar ett extra sammanslagningscommit (merge commit) och bevarar arbetshistoriken.
  • Bevarar de ursprungliga commitarna från grenarna med ursprungliga tidsstämplar och författare.
  • Bevarar SHA för commitarna och hänvisningar till dem i diskussionerna om ändringsförslag.
• Kräver enstaka lösningar på konflikter.
• Gör historiken icke-linjär.
  • Historiken kan vara svår att läsa på grund av det stora antalet grenar (påminner om IDE-kablar).
  • Kommer att komplicera automatisk felsökning, till exempel, git bisect blir mindre användbar — den hittar bara sammanslagningscommit.

Rebase

• Återskapar commitarna från den aktuella grenen ovanpå basen en efter en.
  • Nya commitar med nya SHA skapas, vilket gör att commitarna i GitHub kopplas till de ursprungliga pull requestarna, men inte till de motsvarande kommentarer.
  • Commitarna kan rekonstrueras och ändras under processen eller till och med slås ihop till en.
• Det kan krävas att lösa flera konflikter.
• Möjliggör att upprätthålla en linjär historik.
  • Historiken kan vara lättare att läsa, så länge den inte är alltför lång utan rimlig anledning.
  • Automatisk felsökning och problemidentifiering är något enklare: gör det möjligt att git bisect, kan göra automatiska återställningar tydligare och mer förutsägbara.
• Kräver publicering av grenen med flyttade commit med flaggan --force vid användning med ändringsförfrågningar.

Ofta enas team om att alltid använda samma strategi när de behöver sammanfoga ändringar. Det kan vara en "ren" sammanslagning eller "ren" tillämpning av commit ovanpå eller något däremellan, som att utföra tillämpning av commit i interaktivt läge (git rebase -i) lokalt för grenar som inte har publicerats i den gemensamma repositorien, men sammanslagning för "offentliga" grenar.

Här kommer vi att använda sammanslagning.

️ Uppgift

1. Se till att koden i den lokala grenen master är uppdaterad från det fjärranslutna repot.
2. Byt till grenen funktion.
3. Initiera sammanslagning med grenen master. Det kommer att rapporteras om en sammanslagningskonflikt kopplad till konkurrerande ändringar. ci.md.
4. Lös konflikten så att både vår CI-checklista och kommentarer om den finns kvar i texten.
5. Publicera sammanslagningskommittén till den fjärrgren. funktion.
6. Kontrollera statusen för pull requesten i GitHub-användargränssnittet och vänta tills sammanslagningen har blivit 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 avslutat arbetet med checklistan och nu behöver du godkänna pull requesten i master.

️ Uppgift: Godkänn pull requesten "Steps review".

1. Öppna pull requesten.
2. Klicka på "Merge pull request".
3. Klicka på "Bekräfta sammanslagning".
4. Klicka på "Delete branch" eftersom den inte längre behövs.

Detta är ditt repository just nu.

Fel på produktionen.

Det sägs att "testning kan användas för att visa på förekomsten av fel, men aldrig för att visa på deras frånvaro". Trots att vi hade tester som inte visade några fel, så smög det sig in ett lömskt fel i produktionen.

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

• det som är deployat på produktionen;
• koden på grenen master med felet, där utvecklarna kan börja arbeta igen.

Rulla tillbaka eller fixa i nästa version?

"Rullning tillbaka" (rolling back) innebär att man deployar en tidigare version som man vet är felfri till produktionsmiljön och revertar (återställer) commits som innehåller fel. "Att fixa i nästa version" (fixing forward) innebär att lägga till en fix i master och deploya en ny version så snabbt som möjligt. Eftersom API:er och databasstrukturer ändras när koden deployas i produktionsmiljön, är rullning tillbaka i regel mycket svårare och mer riskfyllt än att fixa i nästa version, särskilt med kontinuerlig leverans och bra testtäckning.

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

• att fixa felet på produktionen så snabbt som möjligt;
• att göra koden i master omedelbart redo för att påbörja nytt arbete.

️ Uppgift

1. Byt till grenen master lokalt.
2. Uppdatera det lokala repositoryt från det fjärranslutna repositoryt.
3. Återkalla sammanslagningskommittén för PR. Steps review på master.
4. Publicera ändringar till det fjärranslutna repositoryt.

Detta är historiken för repositoryt med den återkallade sammanslagningskommittén.

Kommandon

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

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

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

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

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

️ Självgranskning

Se till att ci.md innehåller inte längre texten "sneaky bug" efter att ha återkallat sammanslagningskommittén.

Korrigera checklistan för CI och återför den till master.

Vi har helt återkallat sammanslagningskommittén för grenen. funktion. Den goda nyheten är att vi nu inte längre har något fel. masterDen dåliga nyheten är att vår värdefulla lista över kontinuerlig integration har försvunnit. Så i idealfallet behöver vi tillämpa en fix på commit-erna från funktion och återföra dem till master tillsammans med fixen.

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

• återkalla (revert) commit som upphäver sammanslagningen funktion med master;
• flytta commit:erna från den tidigare funktion.

Olika utvecklingsteam använder olika angreppssätt i det här fallet, vi kommer att flytta användbara commit:ar till en separat gren och skapa en separat pull request för denna nya gren.

️ Uppgift

1. Skapa en gren som heter feature-fix och växla till den.

2. Flytta alla commit:ar från den tidigare grenen funktion till den nya grenen. Lös sammanslagningskonflikter som uppstår vid flytten.

   

3. Lägg till en regressions-test i 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 se till att de inte körs framgångsrikt.
5. Ta bort texten " with a sneaky bug" i ci.md.
6. Lägg till förändringar av testerna och ändringar i stegen i indexet och commita dem.
7. Publicera grenen till det fjärrlagret.

Du bör i slutändan ha något som liknar

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 Fixing the feature. Ställ in feature-fix som "head branch", och master som "base branch".
Var vänlig vänta tills testerna är klara. Du kan se teststatusen i den nedre delen av PR-diskussionen.

Se till att du har ställt in master , i sin forken av repositoryt som "base branch", jag kommer inte att svara på förändringsförfrågningar till repositoryt med kursmaterial.

Godkänn pull request "Fixing the feature"

Tack för fixen! Var god godkänn ändringarna i master från pull request.

️ Uppgift

1. Klicka på "Merge pull request".
2. Klicka på "Bekräfta sammanslagning".
3. Klicka på "Delete branch" eftersom den inte längre behövs.

Detta är vad du ska ha just nu

Grattis!

Du har genomfört alla åtgärder som folk vanligtvis vidtar i processen för kontinuerlig integration.

Om du har lagt märke till några problem med kursen eller vet hur den kan förbättras, skapa en issue i förrådet med kursmaterialet. Denna kurs har också en interaktiv version som använder GitHub Learning Lab som plattform.

Källa: habr.com