Har du lært Git-kommandoer, men ønsker at forstå, hvordan Continuous Integration (CI) fungerer i praksis? Eller måske vil du optimere dine daglige aktiviteter? Dette kursus vil give dig praktiske færdigheder inden for CI ved at bruge et repository på GitHub. Kurset er ikke designet som en slags wizard, som du bare kan klikke dig igennem; tværtimod vil du udføre de samme opgaver, som folk faktisk gør på jobbet, på samme måde som de gør det. Jeg vil forklare teorien, mens du gennemgår de relevante trin.

Hvad skal vi gøre?

Som vi skrider frem, vil vi gradvist opbygge en liste over typiske CI-trin, hvilket er en fremragende metode til at huske denne liste. Med andre ord, vil vi oprette en liste over de handlinger, udviklere udfører, når de implementerer CI. Vi vil også bruge et enkelt sæt tests for at bringe vores CI-proces tættere på virkeligheden.

Denne GIF skitserer commits i dit repository, som du skrider frem i kurset. Som du kan se, er der ikke noget kompliceret her; kun det mest nødvendige.

Du vil gennemgå følgende standard CI-scenarier:

• arbejde på en feature;
• anvende autotests for at sikre kvaliteten;
• implementere en prioriteret opgave;
• løse merge-konflikter;
• en fejl opstår i produktionsmiljøet.

Hvad vil du lære?

Du vil kunne svare på følgende spørgsmål:

• Hvad er Continuous Integration (CI)?
• Hvilke typer autotests bruges i CI, og hvilke handlinger udløser dem?
• Hvad er et pull request, og hvornår er de nødvendige?
• Hvad er Test Driven Development (TDD), og hvordan relaterer det sig til CI?
• Skal man merge eller rebase?
• Skal man rulle tilbage eller fikse i næste version?

I starten oversatte jeg ting som "pull request" overalt, men besluttede senere at tilbageføre nogle engelske fraser for at reducere tekstens kompleksitet. Jeg vil nogle gange bruge "programmerer-slang" som det sjove verbum "commit" i de tilfælde, hvor folk faktisk bruger det på jobbet.

Hvad er Continuous Integration?

Continuous Integration, eller CI, er en teknisk praksis, der indebærer, at hvert teammedlem integrerer sin kode i et fælles repository mindst én gang om dagen, og den resulterende kode skal i det mindste kunne kompilere uden fejl.

Der er forskellige fortolkninger af dette begreb.

Emnet for diskussionen er integrationsfrekvensen. Nogle hævder, at det ikke er tilstrækkeligt at integrere koden kun én gang om dagen; integrationen bør faktisk ske kontinuerligt. Et eksempel er et team, hvor alle tager den nyeste kode om morgenen og integrerer én gang om aftenen. Selvom dette er et rimeligt modargument, betragtes det generelt, at definitionen 'én gang dagligt' er tilstrækkelig praktisk, præcis og passende for teams af forskellige størrelser.

Et andet modargument er, at C++ ikke længere er det eneste sprog, der bruges i udviklingen, og det simple krav om at kompilere uden fejl som valideringsmetode er svagt. Et sæt tests (f.eks. enhedstest, der køres lokalt) skal også fuldføres med succes. I øjeblikket er der en tendens i samfundet til, at dette krav skal være obligatorisk, og i fremtiden vil 'kompilering + enhedstest' sandsynligvis blive standard, hvis det ikke allerede er sket.

Continuous Integration adskiller sig fra kontinuerlig levering (Continuous Delivery, CD) ved at det ikke kræver en release-kandidat efter hver integrationscyklus.

Listen over trin, som vi vil bruge i løbet af kurset

1. Hent den seneste kode. Opret en gren fra master. Begynd at arbejde.
2. Opret commits på din nye gren. Byg og test lokalt. Pass? Gå til næste trin. Fail? Ret fejl eller tests og prøv igen.
3. Push til dit fjerne repository eller fjerne gren.
4. Opret en pull-anmodning. Diskuter ændringerne, tilføj flere commits, mens diskussionen fortsætter. Få tests til at bestå på funktionsgrenen.
5. Merge/rebase commits fra master. Få tests til at bestå på merge-resultatet.
6. Deploy fra funktionsgrenen til produktion.
7. Hvis alt er godt i produktion i et stykke tid, skal ændringerne merges til master.

️ Forberedelse

Sørg for, at det nødvendige software er tilgængeligt.

For at gennemføre dette kursus har du brug for Node.js og Git-klient.

Du kan bruge enhver Git-klient, men jeg vil kun give kommandoer til kommandolinjen.

Sørg for, at du har en Git-klient, der understøtter kommandolinjen.

Hvis du endnu ikke har installeret en Git-klient, der understøtter kommandolinjen, kan du finde installationsvejledninger. her.

Forbered repository

Du skal oprette en personlig kopi (fork) af templates-repositoryet med koden til kurset på GitHub. Lad os blive enige om at kalde denne personlige kopi kursus-repository..

Har du gjort det? Hvis du ikke har ændret standardindstillingerne, hedder dit kursusrepository sandsynligvis continuous-integration-team-scenarios-students, det ligger i din konto på GitHub, og URL'en ser således ud

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

Jeg vil blot kalde denne adresse <URL репозитория>.

Vinklerne som <тут> vil betyde, at du skal erstatte sådan en udtryk med den relevante værdi.

Sørg for at GitHub actions er aktiveret for dette kursusrepository. Hvis de ikke er aktiveret, bedes du aktivere dem ved at klikke på den store knap i midten af siden, som du kan få adgang til ved at klikke på Actions i GitHub-grænsefladen.

Du kan ikke gennemføre kurset ved at følge mine instruktioner, hvis GitHub Actions ikke er aktiveret.

Du kan altid bruge GitHubs evne til at vise Markdown for at se den nuværende status af listen, vi skriver her

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

Om svarene

Selvom den bedste måde at gennemføre dette kursus på er at gøre alt selv, kan du støde på problemer.

Hvis du føler, at du ikke forstår, hvad du skal gøre, og ikke kan fortsætte, kan du kigge i grenen solution, som findes i dit startrepository.
Vær venlig ikke at udføre sammenfletninger solution i master under kurset. Du kan bruge denne gren til at finde ud af, hvad du skal gøre, eller til at sammenligne din kode med forfatterens, ved at bruge alle de muligheder, Git giver os. Hvis du er helt fortabt, kan du helt sikker erstatte din gren master med grenen solution og så nulstille din arbejdsmappe til det trin i kurset, du har brug for.

Brug dette kun, hvis du virkelig har brug for det

Commit dit kode

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

Disse kommandoer

• omdøber master i master-backup;
• omdøber solution i master;
• skifter (checkout) til en ny gren master og skriver indholdet i arbejdsdirektoriet om;
• opretter grenen "solution" fra "master" (som tidligere var "solution") i tilfælde af, at du har brug for grenen "solution" i fremtiden.

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

Efter disse handlinger kan du bruge git log master for at finde ud af, hvilken commit du har brug for.
Du kan nulstille din arbejdsmappe til denne commit sådan her:

git reset --hard

Hvis du er tilfreds med resultatet, vil du på et tidspunkt have brug for at offentliggøre dine versioner af dit repository til et fjernt repository. Glem ikke at angive den fjerne gren, når du gør dette.

git push --force origin master

Bemærk venligst, at vi bruger git push --force. Det er usandsynligt, at du ofte vil gøre dette, men vi har et meget specifikt scenario med en bruger af repository'et, som desuden forstår, hvad han laver.

Start arbejde

Lad os begynde at opbygge vores liste over CI-trin. Normalt starter du dette trin med at hente den nyeste version af koden fra det fjerne repository, men vi har endnu ikke et lokalt repository, så i stedet kloner vi det fra det fjerne.

️ Opgave: opdater det lokale repository, opret en gren fra master, begynd at arbejde

1. Klon kursusrepository'et fra <URL репозитория>.
2. Kør npm install i katalogen af kursusrepository'et; det er nødvendigt for at installere Jest, som vi bruger til at køre test.
3. Opret en gren og kald den feature. Skift til denne gren.

4. Tilføj testkoden til ci.test.js mellem kommentarer der beder om at gøre dette.

   it('1. hent den nyeste kode', () => {
     expect(/.*pull.*?/ig.test(fileContents)).toBe(true);
   });
   
   it('2. tilføj commits', () => {
     expect(/.*commit.*?/ig.test(fileContents)).toBe(true);
   });
   
   it('3. push til den fjerne gren med samme navn', () => {
     expect(/.*push.*?/ig.test(fileContents)).toBe(true);
   });
   
   it('4. opret en pull-anmodning og fortsæt med arbejde', () => {
     expect(/.*pulls+request.*?/ig.test(fileContents)).toBe(true);
   });

5. Tilføj teksten med de første 4 trin til filen ci.md.

   1. Hent den nyeste kode. Opret en gren fra `master`. Begynd at arbejde. 
   2. Opret commits på din nye gren. Byg og test lokalt. Pass? Gå til næste trin. Mislykkedes? Ret fejl eller tests og prøv igen. 
   3. Push til dit fjerne repository eller fjerne gren. 
   4. Opret en pull-anmodning. Diskuter ændringerne, tilføj flere commits, mens diskussionen fortsætter. Sørg for, at testene består i funktionsgrenen.  

   Kommandoer

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

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

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

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

Opret commits i den nye gren, byg og test lokalt

Vi vil sørge for, at testene kører før commit, og derefter committe koden.

Typiske scenarier, hvor testene kører automatisk

• Lokalt:
  • Konstant eller som respons på relevante kodeændringer;
  • Ved gemning (for fortolkede eller JIT-kompilerede sprog);
  • Ved bygning (når kompilering kræves);
  • Ved commit;
  • Når der offentliggøres til et offentligt repository.

• På build-serveren eller i bygge-miljøet:
  • Når koden offentliggøres til en personlig gren/repository.
  • Koden testes i denne gren.
  • Det potentielle resultat af sammenfletning testes (normalt med master).
  • Som et trin i kontinuerlig integration/konstant levering

Generelt, jo hurtigere et test sæt udføres, jo oftere kan du tillade dig at køre det. En typisk fordeling af etaper kan se sådan ud.

• Hurtige modulære tests — ved opbygning, i CI-pipelinen
• Langsomme modulære tests, hurtige komponent- og integrationstests — ved commit, i CI-pipelinen
• Langsomme komponent- og integrationstests — i CI-pipelinen
• Sikkerhedstest, belastningstest og andre langsomme eller dyre tests — i CI/CD-pipelines, men kun i bestemte tilstande/etaper/byggepipeliner, for eksempel ved forberedelse af en release-kandidat eller ved manuel kørsel.

️ Opgave

Jeg foreslår, at vi først kører testene manuelt ved hjælp af kommandoen npm test. Derefter lad os tilføje en git hook for at køre vores tests ved commit. Der er et problem: Git hooks betragtes ikke som en del af repository'et og kan derfor ikke klones fra GitHub sammen med de øvrige kursusmaterialer. For at installere hook'en skal du køre install_hook.sh eller kopiere filen repo/hooks/pre-commit til den lokale mappe .git/hooks/.
Ved commit vil du se, at testene køres, og de tjekker, om visse nøgleord er til stede i listen.

1. Kør testene manuelt ved at udføre kommandoen npm test i mappen for dit kursusrepository. Sørg for, at testene er blevet udført.
2. Installer hook'en ved commit (pre-commit hook) ved at køre install_hook.sh.
3. Commit ændringerne til det lokale repository.
4. Sørg for, at testene kører, før du foretager commit.

Dit repository skal se sådan ud efter at have udført disse handlinger.

Kommandoer

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

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

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

Publicer koden i det eksterne repository eller den eksterne gren

Når udviklerne er færdige med at arbejde lokalt, gør de normalt deres kode offentlig til fælles integration. Med GitHub opnås dette typisk ved at offentliggøre arbejdet enten i en personlig kopi af repository'et (personal fork) eller i en personlig gren.

• Når en udvikler bruger forks, kloner de det fjerne, fælles repository for at lave en personlig, fjern kopi, også kendt som en fork. Derefter kloner de dette personlige repository for at arbejde med det lokalt. Når arbejdet er afsluttet, og commits er oprettet, placerer de dem i deres fork, hvor de er tilgængelige for andre og kan integreres i det fælles repository. Denne tilgang bruges typisk i open source-projekter på GitHub. Den bruges også i mit udvidede kursus [Team Work and CI with Git]http://devops.redpill.solutions/).
• En anden tilgang er at bruge kun ét fjernrepository og kun betragte grenen master af det fælles repository som "beskyttet". I dette scenarie publicerer individuelle udviklere deres kode i grene af det fjerne repository, så andre kan se denne kode og, hvis alt er i orden, samle med master det fælles repository.

I dette specifikke kursus vil vi bruge en arbejdsgang, der anvender grene.

Lad os offentliggøre vores kode.

️ Opgave

• Publicer ændringerne til den fjerne gren med det samme navn som din arbejdsgren

Kommandoer

git push --set-upstream origin feature

Opret en pull request

Opret en pull request med titlen Steps review. Sæt feature som "head branch" og master som "base branch".

Sørg for, at du har angivet master i din fork af repositoryet som "base branch", jeg vil ikke besvare ændringsanmodninger til repositoryet med kursusmaterialer.

På GitHub-sprog er "base branch" den gren, som du baserer dit arbejde på, mens "head branch" er den gren, der indeholder de foreslåede ændringer.

Diskuter ændringerne, tilføj nye commits, mens diskussionen fortsætter

Pull request (PR)

Pull request (PR) er en måde at diskutere og dokumentere koden samt udføre en code review af koden. Pull requests er navngivet efter den almindelige metode til at integrere individuelle ændringer i den fælles kode. Normalt kloner en person det officielle, fjerne repository for projektet og arbejder på koden lokalt. Derefter placerer de koden i deres personlige, fjerne repository og beder de ansvarlige for det officielle repository om at hentepull) deres kode ind i deres lokale repositories, hvor de gennemgår og muligvis integrerersammenslutte) den. Dette begreb er også kendt under andre navne, f.eks. merge request.

Du behøver faktisk ikke at bruge funktionen pull request i GitHub eller lignende platforme. Udviklerteams kan bruge andre kommunikationsmetoder, herunder personlige møder, telefonopkald eller e-mail, men der er stadig en række grunde til at bruge sådanne pull requests i form af forumdiskussioner. Her er nogle af dem:

• organiserede diskussioner relateret til specifikke ændringer i koden;
• som et sted at gennemgå feedback på ufuldstændigt arbejde fra både automatiserede test og kolleger;
• formalisering af kodegennemgange;
• for senere at kunne finde ud af årsagerne og overvejelserne bag en bestemt kodestump.

Normalt opretter du en pull request, når du har noget at diskutere eller ønsker feedback. For eksempel, hvis du arbejder på en funktion, der kan implementeres på flere måder, kan du oprette en ændringsanmodning, før du skriver den første kode, for at dele dine ideer og diskutere dine planer med medforfattere. Hvis arbejdet er enklere, åbnes pull requesten, når noget allerede er lavet, gemt og kan diskuteres. I nogle scenarier kan du åbne en PR alene af hensyn til kvalitetskontrol: for at køre automatiske tests eller initiere kodegennemgange. Hvad end du beslutter, så glem ikke at @nævne de personer, hvis godkendelse der kræves i din pull request.

Normalt når du opretter en PR, gør du følgende.

• Angiver hvad du foreslår at ændre og hvor.
• Skriver en beskrivelse, der forklarer formålet med ændringerne. Du kan ønske at:
  • tilføje noget vigtigt, der ikke er åbenlyst fra koden, eller noget nyttigt for at forstå konteksten, såsom relevante #bugs og commit numre;
  • @nævne alle, som du ønsker at begynde at arbejde sammen med, eller du kan @nævne dem i kommentarer senere;
  • anmode kolleger om hjælp med noget eller kontrollere noget specifikt.

Når du åbner en PR, kører de tests, der er sat op til at køre i sådanne tilfælde. I vores tilfælde vil det være det samme sæt tests, som vi kørte lokalt, men i et rigtigt projekt kan der være yderligere tests og kontroller.

Vent venligst på, at testene afsluttes. Du kan se status for testene i bunden af diskussionen i PR-grænsefladen på GitHub. Fortsæt, når testene er afsluttet.

️ Tilføj en bemærkning om vilkårligheden af CI-skridtene

Listen, der bruges i dette kursus, er vilkårlig og subjektiv, vi skal tilføje en bemærkning om dette.

️ Opgave: opret en pull request til denne bemærkning

1. auth0 master.
2. Opret en gren med navnet bugfix.
3. Tilføj tekstkommentaren til slutningen af filen ci.md.

   > **GitHub flow** bruges nogle gange som et kaldenavn for en variant af trunk-baseret udvikling  
    når koden deployeres direkte fra funktionsgrene. Denne liste er blot en fortolkning  
    som jeg bruger i mine [DevOps-kurser](http://redpill.solutions).  
    Den officielle tutorial er [her](https://guides.github.com/introduction/flow/).

4. Commit ændringerne.
5. Publicer grenen bugfix til det fjerne repository.
6. Opret en pull request med navnet Tilføjelse af en bemærkning med hovedgrenen bugfix og basisgrenenmaster.

Sørg for, at du har angivet master i din fork af repositoryet som "base branch", jeg vil ikke besvare ændringsanmodninger til repositoryet med kursusmaterialer.

Sådan skal dit repository se ud.

Kommandoer

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

Godkend pull request "Tilføjelse af en bemærkning"

️ Opgave

1. Opret en pull request.
2. Klik på "Merge pull request".
3. Klik på "Bekræft sammenlægning".
4. Klik på "Slet gren", vi har ikke brug for den længere.

Dette er diagrammet over commits efter sammenlægningen.

️ Fortsæt med at arbejde og tilføje tests

Samarbejde om pull request fører ofte til behov for yderligere arbejde. Dette er typisk resultatet af kodegennemgang eller diskussion, men i vores kursus vil vi simulere dette ved at tilføje nye elementer til vores liste over CI-trinene.

Når man arbejder med kontinuerlig integration, anvendes der typisk en vis testdækning. Kravene til testdækning varierer og er normalt i et dokument med titlen "forfattervejledning" (contribution guidelines). Vi gør det enkelt og tilføjer en test for hver linje i vores tjekliste.

Når du udfører opgaver, skal du først prøve at committe testene. Hvis du har installeret pre-commit hook korrekt tidligere, vil den netop tilføjede test blive kørt, mislykkes, og der bliver ikke committet noget. Vær opmærksom: dette fortæller os, at vores tests faktisk tjekker noget. Interessant nok, hvis vi ville være startet med koden før testene, kunne det at bestå testen betyde både, at koden fungerede som forventet, eller at testen faktisk ikke tjekkede noget. Desuden, hvis vi ikke havde skrevet testene i første omgang, kunne vi helt glemme dem, da der ikke ville være noget der mindede os om dem.

Test-drevet udvikling (TDD)

TDD anbefaler at skrive tests før koden. Den sædvanlige arbejdsproces ved hjælp af TDD ser sådan ud.

1. Tilføj testen.
2. Kør alle tests og sørg for, at den nye test ikke består.
3. Skriv koden.
4. Kør testsene, og sørg for, at alle tests består.
5. Refaktorer koden.
6. Gentag.

Da resultaterne fra tests, der ikke er bestået, normalt vises i rødt, mens beståede tests vises i grønt, kaldes cyklussen også "rød-grøn-refaktorisering" (red-green-refactor).

️ Opgave

Prøv først at committe testsene og lad dem fejle, så tilføj og commit teksten af CI-trinene. Du vil se, at testsene består ("grønne").
Derefter publicer den nye kode til det fjernlager, og se hvordan testsene udføres i GitHub-grænsefladen i bunden af pull request diskussionen, og opdater PR-status.

1. auth0 feature.

2. Tilføj disse tests til ci.test.js efter den sidste kald it (...);.

   it('5. Merge/rebase commits fra master. Få tests til at bestå på sammenfletsresultatet.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Udrul fra funktionsgrenen til produktion.', () => {
     expect(/.*Deploy.*tos+produktion.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. Hvis alt er godt i produktionen i en periode, fusioner ændringerne til master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Prøv at committe testsene. Hvis pre-commit hooken er sat, fejler committen.
4. Tilføj derefter denne tekst til ci.md.

   5. Merge/rebase commits fra master. Få tests til at bestå på sammenfletsresultatet.  
   6. Udrul fra funktionsgrenen med en snigende fejl til produktion. 
   7. Hvis alt er godt i produktionen i en periode, fusioner ændringerne til master. 

5. Foretag og commit ændringerne lokalt.
6. Publicer ændringerne til grenen feature.

Nu skal det ligne noget i denne stil

Kommandoer

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

Sammenfletningskonflikt

Gå til pull requesten Steps review.

Selvom vi ikke har gjort noget forkert, og testsene for vores kode er bestået, kan vi stadig ikke fusionere grenen. feature og master. Det skyldes, at en anden gren bugfix blev fusioneret med master mens vi arbejdede på denne PR.
Dette skaber en situation, hvor den fjerne gren master har en nyere version, end den vi baserede grenen på. feature. Derfor kan vi ikke blot spole HEAD master til slutningen af grenen. feature. I denne situation skal vi enten lave en fusion (merge) eller anvende commits feature ovenpå (rebase). master. GitHub kan faktisk udføre automatisk sammenfletning, hvis der ikke er nogen konflikter. Desværre har vi i vores situation begge grene konkurrerende ændringer i filen ci.md. Denne situation er kendt som en sammenfletningskonflikt (merge conflict), og vi skal løse den manuelt.

Sammenflet eller rebase

Sammenflet

• Opretter en ekstra sammenfletningskommit (merge commit) og bevarer arbejds historien.
  • Beholder de oprindelige commits fra grenene med de oprindelige tidsstempler og forfattere.
  • Beholder SHA for commits og referencer til dem i diskussioner om ændringsanmodninger.
• Kræver en engangsløsning af konflikter.
• Gør historien ikke-lineær.
  • Historien kan være svær at læse pga. det store antal grene (minder om et IDE-kabel).
  • Komplikerer automatisk fejlfinding, for eksempel gør git bisect mindre nyttig - det vil kun finde sammenfletningskommitten.

Rebase

• Genskaber commits fra den nuværende gren oven på basen en ad gangen.
  • Der dannes nye commits med nye SHA, hvilket betyder, at commits på GitHub er relateret til de oprindelige pull requests, men ikke de tilhørende kommentarer.
  • Commits kan blive rekombineret og ændret undervejs, eller endda kombineret til én.
• Det kan være nødvendigt at løse flere konflikter.
• Tillader at opretholde en lineær historie.
  • Historien kan være lettere at læse, så længe den ikke er for lang uden rimelige grunde.
  • Automatisk fejlfinding og fejlsøgning er lidt lettere: gør det muligt git bisect, og kan gøre automatiske tilbageslag mere klare og forudsigelige.
• Kræver offentliggørelse af grenen med flyttede commits med flaget --force når det bruges med ændringsanmodninger.

Typisk bliver teams enige om at bruge den samme strategi, når de skal sammenflette ændringer. Det kan være en "ren" sammenfletning eller "ren" anvendelse af commits oven på, eller noget imellem, som at udføre anvendelse af commits oven på i interaktiv tilstand (git rebase -i) lokalt for grene, der ikke er offentliggjort i et fælles repository, men sammenfletning (merge) for "offentlige" grene.

Her vil vi bruge sammenfletning.

️ Opgave

1. Sørg for, at koden i den lokale gren master er opdateret fra det fjerne repository.
2. auth0 feature.
3. Initier sammenfletning med grenen master. Der vil blive rapporteret om en sammenfletningskonflikt vedrørende konkurrerende ændringer i ci.md.
4. Løs konflikten, så vores CI-trinliste og bemærkningen herom forbliver i teksten.
5. Publicer merge-committet til den fjerntliggende gren. feature.
6. Tjek status for pull request'en i GitHub's brugergrænseflade, og vent på, at samlingen bliver løst.

Kommandoer

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

Godt arbejde!

Du er færdig med listen, og nu skal du godkende pull request'en i master.

️ Opgave: Godkend pull request "Steps review"

1. Åbn pull request'en.
2. Klik på "Merge pull request".
3. Klik på "Bekræft sammenlægning".
4. Klik på "Slet gren", da vi ikke længere har brug for den.

Dette er dit repository i øjeblikket.

Fejl i produktionen.

Man siger, at "testning kan bruges til at vise tilstedeværelsen af fejl, men aldrig for at vise deres fravær". Selvom vi havde tests, og de ikke viste os nogen fejl, er en snedig fejl sneglet sig ind i produktionen.

I et sådant scenarie skal vi tage os af:

• hvad der er implementeret i produktionen;
• koden i grenen master med fejlen, som udviklerne kan begynde at arbejde med.

Skal vi rulle tilbage eller rette i næste version?

"At rulle tilbage" (rolling back) er at udrulle en kendt fungerende tidligere version i produktionsmiljøet og at annullere (revert) commits, der indeholder fejlen. "At rette i næste version" (fixing forward) er at tilføje en rettelse i master og udrulle en ny version så hurtigt som muligt. Da API'er og databaseskemaer ændrer sig, når koden implementeres i produktionsmiljøet, er tilbageløb langt mere kompliceret og risikabelt end at rette i næste version, i tilfælde af kontinuerlig levering og god testdækning.

Da tilbageløb ikke indebærer nogen risiko i vores tilfælde, vil vi gå denne vej, da det gør det muligt for os

• at rette fejlen i produktionen så hurtigt som muligt;
• at gøre koden i master straks klar til at starte nyt arbejde.

️ Opgave

1. auth0 master lokalt.
2. Opdater lokalt repository fra det fjerntliggende repository.
3. Annuller merge-committet fra PR. Steps review i master.
4. Publicer ændringerne til det fjerntliggende repository.

Dette er historien for repository'et med det annullerede merge-commit.

Kommandoer

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

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

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

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

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

️ Selvvurdering

Sørg for, at ci.md den ikke længere indeholder teksten "sneaky bug" efter annulleringen af merge-committet.

Ret CI-trinlisten og returner den til master.

Vi har fuldstændigt annulleret merge-committet fra grenen feature. Den gode nyhed er, at vi nu ikke har nogen fejl i. masterEn dårlig nyhed er, at vores værdifulde liste over trin til kontinuerlig integration er forsvundet. Så ideelt set skal vi anvende en rettelse til committene fra feature og bringe dem tilbage til master sammen med rettelsen.

Vi kan nærme os opgaven på forskellige måder:

• annullere (revert) det commit, der annullerer sammenlægningen feature med master;
• overføre committene fra den tidligere feature.

Forskellige udviklerteams bruger forskellige tilgange i dette tilfælde, men vi vil overføre nyttige commits til en separat gren og skabe en separat pull request til denne nye gren.

️ Opgave

1. Opret en gren kaldet feature-fix og skift til den.

2. Overfør alle commits fra den tidligere gren feature til den nye gren. Løs eventuelle sammenlægningskonflikter, der opstod under overførslen.

   

3. Tilføj 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 testene lokalt for at sikre, at de ikke lykkes.
5. Fjern teksten "with a sneaky bug" fra ci.md.
6. Tilføj forandringerne fra testene og ændringerne i trinlisten til indekset og commit dem.
7. Publicer grenen til det eksterne repository.

Du skal have noget der ligner

Kommandoer

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

Opret en pull request.

Opret en pull request med titlen Fixing the feature. Sæt feature-fix som "head branch", og master som "base branch".
Vent venligst, indtil testene er færdige. Du kan se status for testene nederst i PR-diskussionen.

Sørg for, at du har angivet master i din fork af repositoryet som "base branch", jeg vil ikke besvare ændringsanmodninger til repositoryet med kursusmaterialer.

Godkend pull requesten "Fixing the feature"

Tak for rettelsen! Venligst godkend ændringerne i master fra pull requesten.

️ Opgave

1. Klik på "Merge pull request".
2. Klik på "Bekræft sammenlægning".
3. Klik på "Slet gren", da vi ikke længere har brug for den.

Dette er, hvad du skal have i øjeblikket

Tillykke!

Du har gennemført alle de handlinger, som folk normalt foretager i processen med kontinuerlig integration.

Hvis du har bemærket nogen problemer med kurset eller ved, hvordan det kan forbedres, skal du oprette en issue i repositoryet med kursusmaterialerne.Dette kursus har også en interaktiv version som bruger GitHub Learning Lab som platform.

Kilde: habr.com