Har du lært Git-kommandoer, men ønsker at forstå, hvordan Continuous Integration (CI) fungerer i virkeligheden? Eller måske vil du optimere dine daglige aktiviteter? Dette kursus vil give dig praktiske færdigheder i kontinuerlig integration ved hjælp af et GitHub-lager. Dette kursus er ikke ment som en guide, som du bare kan klikke på, tværtimod vil du gøre de samme ting, som folk rent faktisk gør på arbejdet, på samme måde som de gør det. Jeg vil forklare teorien, mens du gennemgår de relevante trin.

Hvad gør vi?

Efterhånden som vi går, vil vi gradvist opbygge en liste over typiske CI-trin, hvilket er en god måde at huske denne liste på. Med andre ord vil vi oprette en liste over aktiviteter, som udviklere udfører, når de implementerer kontinuerlig integration, implementerer kontinuerlig integration. Vi vil også bruge en simpel testpakke til at bringe vores CI-proces tættere på den ægte vare.

Denne GIF viser skematisk commits i dit repository, mens du skrider frem gennem kurset. Som du kan se, er der ikke noget kompliceret og kun det mest nødvendige.

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

• Arbejd på en funktion;
• Anvendelse af autotest til kvalitetssikring;
• Gennemførelse af den prioriterede opgave;
• Konfliktløsning ved sammenlægning af filialer (fusionskonflikt);
• Forekomsten af ​​en fejl i et produktionsmiljø.

Hvad vil du lære?

Du vil være i stand til at besvare spørgsmål som:

• Hvad er kontinuerlig integration (CI)?
• Hvilke typer autotest bruges i CI, og som svar på hvilke handlinger kører de?
• Hvad er en pull-anmodning, og hvornår er de nødvendige?
• Hvad er Test Driven Development (TDD), og hvordan hænger det sammen med CI?
• Vil du flette eller anvende ændringer på toppen (rebase)?
• Rollback eller reparation i næste version?

Først oversatte jeg ting som "pull request" overalt, men som et resultat besluttede jeg at returnere sætninger på engelsk nogle steder for at reducere graden af ​​sindssyge i teksten. Jeg vil lejlighedsvis bruge en "programmering surzhik" som det smarte verbum "forpligte", hvor folk rent faktisk bruger det på arbejdet.

Hvad er kontinuerlig integration?

Kontinuerlig integration, eller CI, er en teknisk praksis, hvor hvert teammedlem integrerer deres kode i et fælles lager mindst én gang om dagen, og den resulterende kode skal mindst bygge uden fejl.

Der er kontroverser om dette udtryk.

Stridspunktet er frekvensen af ​​integration. Nogle hævder, at fletning af kode en gang om dagen ikke er nok til faktisk at integrere kontinuerligt. Et eksempel er et hold, hvor alle tager en frisk kode om morgenen og integrerer en gang om aftenen. Selvom dette er en rimelig indvending, menes det generelt, at definitionen af ​​"en gang om dagen" er ret praktisk, specifik og velegnet til hold af forskellig størrelse.

En anden indvending er, at C++ ikke har været det eneste sprog, der er brugt i udviklingen i lang tid, og blot at kræve montering uden fejl som en valideringsmetode er ret svag. Et sæt tests (f.eks. enhedstests, der køres lokalt) skal også lykkes. I øjeblikket trækker samfundet hen imod at gøre et sådant krav obligatorisk, og i fremtiden vil "build + unit tests" formentlig blive almindeligt, hvis det ikke allerede har gjort det.

Kontinuerlig integration anderledes end kontinuerlig forsyning (Continuous Delivery, CD), idet det ikke kræver en udgivelseskandidat efter hver integrationscyklus.

Liste over trin, som vi vil bruge gennem hele forløbet

1. Indtast den seneste kode. Opret en filial fra master. Begynd at arbejde.
2. Opret commits på din nye filial. Byg og test lokalt. Passere? Gå til næste trin. svigte? Ret fejl eller test, og prøv igen.
3. Skub til dit fjernlager eller fjernafdeling.
4. Opret en pull-anmodning. Diskuter ændringerne, tilføj flere commits, efterhånden som diskussionen fortsætter. Få test til at bestå på featuregrenen.
5. Merge/rebase commits fra master. Få testene til at bestå sammenfletningsresultatet.
6. Implementer fra funktionsgrenen til produktion.
7. Hvis alt er godt i produktionen i en periode, skal du flette ændringer til master.

️ Forberedelse

Sørg for, at du har den rigtige software

For at tage dette kursus skal du node.js и Git klient.

Du kan bruge enhver Git-klient, men jeg vil kun vise kommandoer for kommandolinjen.

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

Hvis du ikke allerede har en kommandolinje Git-klient installeret, kan du finde installationsinstruktioner her. her.

Forbered depotet

Du skal oprette en personlig kopi (gaffel) repository-skabelon med koden til kurset på GitHub. Lad os blive enige om at kalde denne personlige kopi kursusopbevaring.

Færdig? Hvis du ikke har ændret standardindstillingerne, er dit kursuslager højst sandsynligt navngivet continuous-integration-team-scenarios-students, den er på din GitHub-konto, og URL'en ser sådan ud

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

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

vinkelbeslag som <тут> vil betyde, at du skal erstatte et sådant udtryk med den passende værdi.

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

Du vil ikke være i stand til at gennemføre kurset ved at følge mine instruktioner, medmindre GitHub Actions er aktiveret.

Du kan altid bruge GitHubs evne til at vise Markdown for at se den aktuelle tilstand af den liste, vi er ved at lave, her

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

Om svar

Selvom den bedste måde at gennemføre dette kursus på er at gøre det selv, kan du finde det svært at gennemføre.

Hvis du føler, at du ikke forstår, hvad du skal gøre, og ikke kan fortsætte, kan du kigge ind i tråden solution, som er i dit startlager.
Venligst ikke flette solution в master under forløbet. 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, som Git giver os. Hvis du er helt tabt, kan du helt erstatte din filial master på en gren solution og nulstil derefter din arbejdsmappe til det kursustrin, du ønsker.

Brug kun dette, hvis du virkelig har brug for det.

Indgiv din kode

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

Disse kommandoer

• omdøbe master в master-backup;
• omdøbe solution в master;
• skifte (checkout) til en ny filial master og overskriv indholdet af arbejdsbiblioteket;
• opret en "løsning"-gren fra "master" (som plejede at være "løsning"), hvis du har brug for en "løsning"-gren i fremtiden.

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

Efter disse trin 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 på denne måde:

git reset --hard <the SHA you need>

Hvis du er tilfreds med resultatet, skal du på et tidspunkt udgive din version af depotet til et fjernlager (fjern). Glem ikke eksplicit at angive fjerngrenen, når du gør dette.

git push --force origin master

Bemærk venligst, at vi bruger git push --force. Du ønsker nok ikke at gøre dette så tit, men vi har et meget specifikt scenarie her med en bruger af depotet, som derudover forstår, hvad han laver.

Begynder at arbejde

Lad os begynde at kompilere vores liste over CI-trin. Du starter normalt dette trin ved at trække den seneste kode fra et fjernlager, men vi har ikke et lokalt depot endnu, så vi kloner det fra et fjernlager i stedet.

️ Opgave: Opdater lokalt lager, opret en filial fra master, begynde at arbejde

1. Klon kursuslageret fra <URL репозитория>.
2. Start npm install i kursusbiblioteket; vi har brug for det til at installere Jest, som vi bruger til at køre test.
3. Opret en gren og navngiv den feature. Skift til denne tråd.

4. Tilføj testkode til ci.test.js mellem kommentarer, der beder dig om 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. Tilføj tekst med de første 4 trin til 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.  

   Команды

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

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

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

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

Opret commits på en ny filial, byg og test lokalt

Vi vil konfigurere testene til at køre før commit, og derefter commit koden.

Typiske scenarier, når test kører automatisk

• Lokalt:
  • Løbende eller som reaktion på passende kodeændringer;
  • Ved gem (for fortolkede eller JIT-kompilerede sprog);
  • On build (når kompilering er påkrævet);
  • På forpligtelse;
  • Når du udgiver til et delt lager.

• På build-serveren eller build-miljøet:
  • Når koden udgives til en personlig filial/depot.
  • Koden i denne tråd er ved at blive testet.
  • Et potentielt fletteresultat testes (normalt med master).
  • Som et kontinuerligt integrationstrin/kontinuerlig leveringspipeline

Generelt gælder det, at jo hurtigere en testpakke kører, jo oftere har du råd til at køre den. En typisk iscenesættelse kan se sådan ud.

• Hurtige enhedstests - ved opbygning, i CI-pipeline
• Langsomme enhedstests, hurtige komponent- og integrationstests - ved commit, i CI-pipeline
• Langsomme komponent- og integrationstests - i CI-pipeline
• Sikkerhedstest, belastningstest og andre lange eller dyre tests - i CI / CD-pipelines, men kun i visse tilstande / stadier / build-pipelines, for eksempel når du forbereder en udgivelseskandidat eller når du starter manuelt.

️ Quest

Jeg foreslår at køre testene manuelt først ved hjælp af kommandoen npm test. Lad os derefter tilføje en git-hook for at køre vores test på commit. Der er en hake: Git hooks betragtes ikke som en del af repository og kan derfor ikke klones fra GitHub sammen med resten af ​​kursusindholdet. For at installere krog skal du køre install_hook.sh eller kopier filen repo/hooks/pre-commit til den lokale mappe .git/hooks/.
Når du forpligter dig, vil du se, at testene er kørt, og de tjekker, om bestemte søgeord er til stede på listen.

1. Kør testene manuelt ved at køre kommandoen npm test i din kursusopbevaringsmappe. Bekræft, at testene er blevet kørt.
2. Installer en commit hook (pre-commit hook) ved at køre install_hook.sh.
3. Overfør ændringerne til det lokale lager.
4. Sørg for, at testene køres før commit.

Dit lager skal se sådan ud efter at have gennemført disse trin.

Команды

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

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

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

Udgiv kode til et eksternt lager eller en ekstern filial

Efter at have afsluttet arbejdet lokalt, offentliggør udviklere normalt deres kode offentlig, så den til sidst kan integreres med offentligheden. Med GitHub opnås dette normalt ved at publicere værket enten til en personlig kopi af depotet (personlig gaffel, gaffel) eller til en personlig gren.

• Med gafler kloner udvikleren det eksterne delte lager og skaber en personlig fjernkopi af det, også kendt som en gaffel. Derefter kloner han dette personlige lager, så han kan arbejde med det lokalt. Når arbejdet er gjort, og commits er skabt, lægger han dem i sin gaffel, hvor de er tilgængelige for andre og kan integreres i et fælles depot. Denne tilgang er almindeligt anvendt i open source-projekter på GitHub. Det bruges også i mit avancerede kursus [Teamarbejde og CI med Git] (http://devops.redpill.solutions/).
• En anden tilgang er kun at bruge ét fjernlager og kun tælle grenen master det delte lager er "beskyttet". I dette scenarie udgiver individuelle udviklere deres kode til grenene af fjernlageret, så andre kan se denne kode, hvis alt er i orden, flettes med master delt depot.

I dette særlige kursus vil vi bruge en arbejdsgang, der bruger grene.

Lad os udgive vores kode.

️ Quest

• Send ændringer til en ekstern filial med samme navn som din arbejdsgren

Команды

git push --set-upstream origin feature

Opret en pull-anmodning

Opret en pull-anmodning med en titel Gennemgang af trin... Installere feature som "hovedgren" og master som "basisgren".

Sørg for, at du har installeret master i hans depotgaffel som en "basisgren" vil jeg ikke svare på ændringsanmodninger til kursusindholdsarkivet.

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

Diskuter ændringer, tilføj nye commits, efterhånden som diskussionen fortsætter

Træk anmodning (PR)

Træk anmodning (PR) er en måde at diskutere og dokumentere kode på, samt at gennemføre kodegennemgang. Pull-anmodninger er opkaldt efter en almindelig måde at integrere individuelle ændringer i den overordnede kode. Normalt kloner en person et eksternt officielt projektlager og arbejder på koden lokalt. Derefter placerer han koden i sit personlige fjernlager og beder de ansvarlige for det officielle lager om at hente den (Træk) sin kode til deres lokale depoter, hvor de gennemgår og muligvis integrerer(fusionere) hans. Dette koncept er også kendt under andre navne, f.eks. anmodning om sammenlægning.

Faktisk behøver du ikke bruge pull request-funktionen på GitHub eller lignende platforme. Udviklingsteams kan bruge andre kommunikationsmidler, herunder ansigt-til-ansigt kommunikation, taleopkald eller e-mail, men der er stadig en række grunde til at bruge sådanne pull-anmodninger i forumstil. Her er nogle af dem:

• organiserede diskussioner relateret til specifikke ændringer i koden;
• som et sted at se feedback om igangværende arbejde fra både autotests og peers;
• formalisering af kodekontrol;
• så du senere kan finde ud af årsagerne og overvejelserne bag dette eller hint stykke kode.

Normalt opretter du en pull-anmodning, når du skal diskutere noget eller få feedback. Hvis du for eksempel arbejder på en funktion, der kan implementeres på flere måder, kan du oprette en pull-anmodning, før den første kodelinje er skrevet for at dele dine ideer og diskutere dine planer med samarbejdspartnere. Hvis arbejdet er mere enkelt, åbnes en pull request, når noget allerede er gjort, forpligtet og kan diskuteres. I nogle scenarier vil du måske åbne en PR kun af kvalitetskontrolårsager: for at køre automatiserede tests eller starte kodegennemgange. Uanset hvad du beslutter dig for, så glem ikke at @omtale de personer, du ønsker godkendelse i din pull-anmodning.

Når du opretter en PR, gør du typisk følgende.

• Angiv, hvad du foreslår at ændre, og hvor.
• Skriv en beskrivelse, der forklarer formålet med ændringen. Du ønsker måske:
  • tilføje noget vigtigt, som ikke er tydeligt fra koden, eller noget nyttigt til at forstå konteksten, såsom relevante #bugs og commit-numre;
  • @omtale alle du vil arbejde med, eller du kan @omtale dem i kommentarerne senere;
  • bede kolleger om at hjælpe med noget eller tjekke noget specifikt.

Når du har åbnet en PR, udføres de test, der er konfigureret til at køre i sådanne tilfælde. I vores tilfælde vil dette være den samme testsuite, som vi kørte lokalt, men der kan være yderligere test og kontroller i et rigtigt projekt.

Vent venligst, mens testene er afsluttet. Du kan se status for testene i bunden af ​​PR-tråden i GitHub-grænsefladen. Fortsæt, når testene er afsluttet.

️ Tilføj en note om vilkårligheden af ​​listen over CI-trin

Listen brugt i dette kursus er vilkårlig og subjektiv, vi skal tilføje en note om dette.

️ Udfordring: Opret en pull-anmodning for denne note

1. Skift til filial master.
2. Opret en filial med navnet bugfix.
3. Tilføj notetekst til slutningen af ​​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. Forpligt ændringerne.
5. Udgiv en filial bugfix til et fjernlager.
6. Opret en pull-anmodning med navnet Tilføjelse af en bemærkning med hovedgren bugfix og basisgrenmaster.

Sørg for, at du har installeret master i hans depotgaffel som en "basisgren" vil jeg ikke svare på ændringsanmodninger til kursusindholdsarkivet.

Sådan skal dit lager se ud.

Команды

# Переключитесь на ветку 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-anmodningen "Tilføjelse af en bemærkning"

️ Quest

1. Opret en pull-anmodning.
2. Klik på "Merge pull request".
3. Klik på "Bekræft fletning".
4. Klik på "Slet filial", vi har ikke brug for det længere.

Dette er et diagram over commits efter fusionen.

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

At samarbejde om en pull-anmodning resulterer ofte i, at der bliver gjort mere arbejde. Dette er normalt resultatet af en kodegennemgang eller diskussion, men i vores kursus vil vi modellere dette ved at tilføje nye elementer til vores liste over CI-trin.

Ved kontinuerlig integration anvendes normalt en vis testdækning. Kravene til testdækning varierer og findes normalt i et dokument med en titel som "bidragsretningslinjer". Vi gør det let og tilføjer en test for hver linje i vores tjekliste.

Når du kører job, skal du først prøve at udføre testene. Hvis du har installeret korrekt pre-commit krog før, vil den nyligt tilføjede test køre, mislykkes, og intet vil blive begået. Bemærk, at det er sådan, vi ved, at vores test faktisk tester noget. Mærkeligt nok, hvis vi startede med koden før testene, kunne beståelse af testene enten betyde, at koden fungerer som forventet, eller at testene faktisk ikke tester noget. Også, hvis vi ikke havde skrevet prøverne i første omgang, kunne vi have glemt dem helt, da der ikke ville være noget, der kunne minde os om det.

Testdrevet udvikling (TDD)

TDD anbefaler at skrive test før kode. En typisk arbejdsgang ved hjælp af TDD ser sådan ud.

1. Tilføj en test.
2. Kør alle test og bekræft, at den nye test mislykkes.
3. Skriv kode.
4. Kør tests, sørg for at alle tests består.
5. Refaktorer din kode.
6. Gentage.

Fordi testresultater, der fejler, typisk vises med rødt, og test, der består, vises med grønt, er cyklussen også kendt som rød-grøn-refaktor.

️ Quest

Prøv først at udføre testene og lad dem mislykkes, og tilføj og bekræft derefter selve CI-trinlisteteksten. Du vil se, at testene består ("grøn").
Publicer derefter den nye kode til et fjernlager og se testene køre i GitHub-grænsefladen nederst i pull request-diskussionen, og PR-statussen opdateres.

1. Skift til filial feature.

2. Tilføj disse tests til ci.test.js efter sidste opkald 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. Prøv at begå testene. Hvis pre-commit krogen er sat, mislykkes forsøget.
4. Tilføj derefter denne tekst til 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. Foretag og forpligt ændringer lokalt.
6. Indsend ændringer til filial feature.

Nu skulle du have sådan noget

Команды

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

Sammenflet konflikt

Gå til ændringsanmodning Gennemgang af trin.

Selvom vi ikke gjorde noget forkert, og testene for vores kode bestod, kan vi stadig ikke slå grenen sammen feature и master. Dette er fordi den anden tråd bugfix blev slået sammen med master mens vi arbejdede på denne PR.
Dette skaber en situation, hvor den fjerne filial master har en nyere version end den vi baserede grenen på feature. På grund af dette kan vi ikke bare spole HEAD tilbage master til enden af ​​grenen feature. I denne situation skal vi enten fusionere eller anvende commits feature over(rebase) master. GitHub kan faktisk lave en automatisk fletning, hvis der ikke er konflikter. Ak, i vores situation har begge grene konkurrerende ændringer i filen ci.md. Denne situation er kendt som en fusionskonflikt, og vi er nødt til at løse den manuelt.

Flet eller rebase

Flet

• Opretter en ekstra flette-commit og gemmer arbejdshistorikken.
  • Bevarer de originale filialforpligtelser med deres originale tidsstempler og forfattere.
  • Gemmer commit SHA'erne og links til commits i ændringsanmodningsdiskussioner.
• Kræver engangskonfliktløsning.
• Gør historien ikke-lineær.
  • Historien kan være svær at læse på grund af det store antal grene (minder mig om et IDE-kabel).
  • Gør automatisk debugging sværere, for eksempel at udføre git bisect mindre nyttigt - det vil kun finde sammensmeltningen.

rebase

• Afspiller commits fra den aktuelle gren oven på basen én efter én.
  • Nye commits genereres med nye SHA'er, hvilket får GitHub commits til at matche de originale pull-anmodninger, men ikke de tilsvarende kommentarer.
  • Commits kan rekombineres og ændres i processen eller endda slås sammen til én.
• Du skal muligvis løse flere konflikter.
• Giver dig mulighed for at opretholde en lineær historie.
  • Historien kan være lettere at læse, så længe den ikke er for lang uden god grund.
  • Automatisk debugging og fejlfinding er noget nemmere: gør det muligt git bisect, kan gøre automatiske tilbagerulninger mere tydelige og forudsigelige.
• Kræver udgivelse af en filial med tilbageførte commits med et flag --force når det bruges sammen med ændringsanmodninger.

Hold er normalt enige om altid at bruge den samme strategi, når de skal flette ændringer. Dette kan være en "ren" sammenfletning eller en "ren" commit ovenpå, eller noget midt imellem, såsom at lave en commit over interaktiv tilstand(git rebase -i) lokalt for filialer, der ikke er publiceret til et delt lager, men fusioneres for "offentlige" filialer.

Her vil vi bruge merge.

️ Quest

1. Sørg for, at koden er i den lokale afdeling master opdateret fra et fjernlager.
2. Skift til filial feature.
3. Start en fletning med en gren master. En fusionskonflikt vil blive rapporteret på grund af konkurrerende ændringer i ci.md.
4. Løs konflikten, så både vores liste over CI-trin og en note om det forbliver i teksten.
5. Indsend en fletforpligtelse til en ekstern filial feature.
6. Tjek status for pull-anmodningen i GitHub-brugergrænsefladen, vent, indtil fletningen er løst.

Команды

# Убедитесь, что код в локальное ветке `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-anmodningen master.

️ Opgave: Godkend pull-anmodningen "Steps review"

1. Åbn en pull-anmodning.
2. Klik på "Merge pull request".
3. Klik på "Bekræft fletning".
4. Klik på "Slet filial", da vi ikke har brug for det længere.

Dette er dit lager i øjeblikket

Produkt fejl

De siger, at "test kan bruges til at vise tilstedeværelsen af ​​fejl, men aldrig til at vise deres fravær." På trods af at vi havde test, og de ikke viste os nogen fejl, sneg der sig en snigende fejl ind i produktionen.

I et scenarie som dette skal vi tage os af:

• der er indsat på det produktive;
• afdelingskode master med en fejl, hvorfra udviklere kan starte nyt arbejde.

Rollback eller rettelse i næste version?

"Rolling back" er handlingen med at implementere en kendt og god tidligere version til et produktionsmiljø og vende tilbage til de commits, der indeholder fejlen. "Fixing forward" er tilføjelsen af ​​en rettelse til master og implementere den nye version så hurtigt som muligt. Fordi API'er og databaseskemaer ændrer sig, efterhånden som kode implementeres til produktion, med kontinuerlig levering og god testdækning, er tilbagerulning generelt meget vanskeligere og mere risikabelt end at rette i den næste udgivelse.

Da tilbagerulning ikke indebærer nogen risiko i vores tilfælde, vil vi gå denne vej, fordi det tillader os

• ret fejlen på produktionen så hurtigt som muligt;
• lave kode ind master straks klar til at starte et nyt job.

️ Quest

1. Skift til filial master lokalt
2. Opdater det lokale lager fra fjernlageret.
3. Tilbagefør PR-fusionsforpligtelsen Gennemgang af trin в master.
4. Udgiv ændringer til et fjernlager.

Dette er historikken for depotet med fusions-commit vendt tilbage

Команды

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

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

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

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

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

️Selvtjek

Sørg for at ci.md indeholder ikke længere teksten "sneaky bug", efter at en merge commit er vendt tilbage.

Ret CI-trinliste og vend tilbage til master

Vi vendte fuldstændigt om filialfusionsforpligtelsen feature. Den gode nyhed er, at nu har vi ingen fejl master. Den dårlige nyhed er, at vores dyrebare liste over kontinuerlige integrationstrin også er væk. Så ideelt set ønsker vi at anvende rettelsen på commits fra feature og returnere dem til master sammen med rettelsen.

Vi kan gribe problemet an på forskellige måder:

• fortryd commit, som fortryder sammenfletningen feature с master;
• migrere begår fra førstnævnte feature.

Forskellige udviklingsteams tager forskellige tilgange i dette tilfælde, men vi vil flytte nyttige tilsagn til en separat gren og oprette en separat pull-anmodning for denne nye gren.

️ Quest

1. Opret en gren kaldet feature-fix og skifte til det.

2. Migrer alle commits fra den tidligere filial feature til en ny tråd. Løs flettekonflikter, der opstod under migreringen.

   

3. Tilføj en regressionstest til 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 gennemføres korrekt.
5. Slet teksten "med en lusket fejl" i ci.md.
6. Tilføj testændringer og -ændringer til listen over trin til indekset og forpligt dem.
7. Udgiv grenen til fjernlageret.

Du burde ende med noget som

Команды

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

Opret en pull-anmodning med en titel Retter funktionen... Installere feature-fix som "hovedgren", og master som "basisgren".
Vent venligst, mens testene er afsluttet. Du kan se status på testene nederst i PR-diskussionen.

Sørg for, at du har installeret master i hans depotgaffel som en "basisgren" vil jeg ikke svare på ændringsanmodninger til kursusindholdsarkivet.

Godkend pull-anmodningen "Fixing the feature"

Tak for rettelsen! Godkend venligst ændringerne i master fra en pull-anmodning.

️ Quest

1. Klik på "Merge pull request".
2. Klik på "Bekræft fletning".
3. Klik på "Slet filial", da vi ikke har brug for det længere.

Dette er hvad du skal have lige nu.

Tillykke!

Du har gennemført alle de trin, som folk typisk tager i en kontinuerlig integrationsproces.

Hvis du bemærker problemer med kurset eller ved, hvordan du kan forbedre det, bedes du oprette et problem i kursusmaterialelager. Dette kursus har også interaktiv version ved at bruge GitHub Learning Lab som platform.

Kilde: www.habr.com