Het jy Git-opdragte geleer, maar wil jy jou voorstel hoe deurlopende integrasie (CI) in werklikheid werk? Of wil jy dalk jou daaglikse aktiwiteite optimaliseer? Hierdie kursus sal jou praktiese vaardighede gee in deurlopende integrasie met behulp van 'n GitHub-bewaarplek. Hierdie kursus is nie bedoel om 'n towenaar te wees waardeur jy eenvoudig kan klik nie; inteendeel, jy sal dieselfde aksies uitvoer wat mense werklik by die werk doen, op dieselfde manier as wat hulle dit doen. Ek sal die teorie verduidelik soos jy deur die betrokke stappe gaan.

Wat maak ons?

Soos ons vorder, sal ons geleidelik 'n lys van tipiese CI-stappe skep, wat 'n goeie manier is om hierdie lys te onthou. Met ander woorde, ons sal 'n lys van aksies skep wat ontwikkelaars neem terwyl hulle deurlopende integrasie doen, deurlopende integrasie doen. Ons sal ook 'n eenvoudige stel toetse gebruik om ons CI-proses nader aan die regte een te bring.

Hierdie GIF wys skematies die commits in jou bewaarplek soos jy deur die kursus vorder. Soos u kan sien, is hier niks ingewikkeld nie en slegs die nodigste.

Jy sal deur die volgende standaard CI scenario's gaan:

• Werk aan 'n kenmerk;
• Toepassing van geoutomatiseerde toetse om kwaliteit te verseker;
• Implementering van die prioriteitstaak;
• Konflikoplossing by samesmelting van takke (samesmeltingskonflik);
• 'n Fout kom voor in 'n produksie-omgewing.

Wat sal jy leer?

Jy sal die volgende vrae kan beantwoord:

• Wat is deurlopende integrasie (CI)?
• Watter tipe outomatiese toetse word in CI gebruik, en in reaksie op watter aksies word dit geaktiveer?
• Wat is trekversoeke en wanneer word dit benodig?
• Wat is toetsgedrewe ontwikkeling (TDD) en hoe hou dit verband met GI?
• Moet ek die veranderinge saamvoeg of herbaseer?
• Rol terug of maak reg in die volgende weergawe?

Ek het eers goed soos “pull requests” oral vertaal, maar as gevolg daarvan het ek besluit om op sommige plekke frases in Engels terug te gee om die mate van waansin in die teks te verminder. Ek sal soms "programmeerder surzhik" gebruik soos die wonderlike werkwoord "commit" waar mense dit eintlik by die werk gebruik.

Wat is deurlopende integrasie?

Deurlopende integrasie, of CI, is 'n tegniese praktyk waarin elke spanlid hul kode ten minste een keer per dag in 'n gemeenskaplike bewaarplek integreer, en die gevolglike kode moet ten minste sonder foute gebou word.

Daar is meningsverskille oor hierdie term

Die twispunt is die frekwensie van integrasie. Sommige argumenteer dat die samesmelting van kode net een keer per dag nie genoeg is om werklik deurlopend te integreer nie. 'n Voorbeeld word gegee van 'n span waar almal vars kode in die oggend neem en dit een keer saans integreer. Alhoewel dit 'n redelike beswaar is, word daar algemeen geglo dat die eenmalige definisie redelik prakties, spesifiek en geskik is vir spanne van verskillende groottes.

Nog 'n beswaar is dat C++ nie meer die enigste taal is wat in ontwikkeling gebruik word nie, en om bloot foutvrye samestelling as 'n manier van validering te vereis, is swak. Sommige stel toetse (byvoorbeeld eenheidstoetse wat plaaslik uitgevoer word) moet ook suksesvol voltooi. Op die oomblik beweeg die gemeenskap om dit 'n vereiste te maak, en in die toekoms sal "bou + eenheid toetse" waarskynlik algemene praktyk word, as dit nog nie het nie.

Deurlopende integrasie verskil van deurlopende toevoer (Deurlopende aflewering, CD) deurdat dit nie 'n vrystellingskandidaat na elke integrasiesiklus benodig nie.

Lys van stappe wat ons deur die kursus sal gebruik

1. Trek die nuutste kode in. Skep 'n tak van master. Begin werk.
2. Skep commits op jou nuwe tak. Bou en toets plaaslik. Slaag? Gaan na die volgende stap. Misluk? Maak foute of toetse reg en probeer weer.
3. Druk na jou afgeleë bewaarplek of afgeleë tak.
4. Skep 'n trekversoek. Bespreek die veranderinge, voeg meer commits by soos bespreking voortgaan. Laat toetse op die kenmerktak slaag.
5. Merge/rebase commits from master. Laat toetse slaag op die samesmeltingsresultaat.
6. Ontplooi vanaf die kenmerktak na produksie.
7. As alles goed is in produksie vir 'n tydperk van tyd, voeg veranderinge saam om te bemeester.

️ Voorbereiding

Maak seker jy het die regte sagteware

Om hierdie kursus te neem sal jy nodig hê Node.js и Git kliënt.

U kan enige Git-kliënt gebruik, maar ek sal slegs opdragte vir die opdragreël verskaf.

Maak seker dat jy 'n Git-kliënt geïnstalleer het wat die opdragreël ondersteun

As jy nog nie 'n Git-kliënt het wat die opdragreël ondersteun nie, kan jy installasie-instruksies vind hier.

Berei die bewaarplek voor

Jy sal 'n persoonlike kopie (vurk) moet skep sjabloonbewaarplek met kode vir die kursus op GitHub. Kom ons stem in om hierdie persoonlike kopie te noem kursusbewaarplek.

Klaar? As jy nie die verstekinstellings verander het nie, word jou kursusbewaarplek heel waarskynlik genoem continuous-integration-team-scenarios-students, is dit in jou GitHub-rekening geleë en die URL lyk so

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

Ek sal eenvoudig hierdie adres bel <URL репозитория>.

Hoekhakies soos <тут> sal beteken dat jy so 'n uitdrukking met die toepaslike waarde moet vervang.

Maak seker dat GitHub-aksies ingesluit vir hierdie kursusbewaarplek. As hulle nie geaktiveer is nie, aktiveer hulle asseblief deur op die groot knoppie in die middel van die bladsy te klik, wat jy kan bereik deur op Actions in die GitHub-koppelvlak te klik.

Jy sal nie die kursus kan voltooi volgens my instruksies as GitHub Actions nie geaktiveer is nie.

Jy kan altyd GitHub se vermoë gebruik om Markdown weer te gee om die huidige stand van die lys wat ons hier saamstel te sien

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

Oor die antwoorde

Alhoewel die beste manier om hierdie kursus te voltooi is om dit self te doen, kan jy 'n paar probleme ondervind.

As jy voel dat jy nie verstaan ​​wat om te doen nie en nie kan voortgaan nie, kan jy in die draad kyk solution, wat in jou beginbewaarplek is.
Moet asseblief nie saamsmelt nie solution в master tydens die kursus. Jy kan hierdie tak gebruik om uit te vind wat om te doen, of om jou kode met die skrywer s'n te vergelyk, deur al die vermoëns te gebruik wat Git ons gee. As jy heeltemal verlore is, kan jy jou tak heeltemal vervang master op 'n tak solution en stel dan jou werkgids terug na die kursusstap wat jy nodig het.

Gebruik dit net as jy dit regtig nodig het

Verbind jou kode

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

Hierdie opdragte

• hernoem master в master-backup;
• hernoem solution в master;
• betaal na 'n nuwe tak master en die inhoud van die werkgids te herskryf;
• Skep 'n "oplossing"-tak van "meester" (wat voorheen "oplossing" was) ingeval jy 'n "oplossing"-tak in die toekoms benodig.

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

Na hierdie stappe kan jy gebruik git log master om uit te vind watter commit jy nodig het.
Jy kan jou werkgids so na hierdie commit terugstel:

git reset --hard <the SHA you need>

As jy tevrede is met die resultaat, sal jy op 'n stadium jou weergawe van die bewaarplek na 'n afgeleë bewaarplek moet publiseer. Moenie vergeet om die afgeleë tak uitdruklik te spesifiseer wanneer jy dit doen nie.

git push --force origin master

Neem asseblief kennis dat ons gebruik git push --force. Dit is onwaarskynlik dat jy dit baie gereeld sal wil doen, maar ons het 'n baie spesifieke scenario hier met een bewaarplekgebruiker wat boonop verstaan ​​wat hy doen.

Begin werk

Kom ons begin ons lys van CI-stappe saamstel. Normaalweg sal jy hierdie stap begin deur die nuutste weergawe van die kode van die afgeleë bewaarplek na te gaan, maar ons het nog nie 'n plaaslike bewaarplek nie, so ons kloon dit eerder vanaf die afgeleë een.

️ Taak: werk die plaaslike bewaarplek op, skep 'n tak van master, begin werk

1. Kloon die kursusbewaarplek vanaf <URL репозитория>.
2. Hardloop npm install in die kursusbewaarplekgids; Ons het dit nodig om Jest te installeer, wat ons gebruik om toetse uit te voer.
3. Skep 'n tak en noem dit feature. Skakel oor na hierdie draad.

4. Voeg toetskode by ci.test.js tussen kommentaar wat my vra om dit te doen.

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

5. Voeg teks met die eerste 4 stappe by die lêer 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 как описано выше

Skep commits op 'n nuwe tak, bou en toets plaaslik

Ons gaan die toetse opstel om uit te voer voordat ons pleeg, en dan die kode pleeg.

Tipiese scenario's wanneer toetse outomaties loop

• Plaaslik:
  • Deurlopend of in reaksie op toepaslike kodeveranderings;
  • Op besparing (vir geïnterpreteerde of JIT-saamgestelde tale);
  • Tydens samestelling (wanneer samestelling vereis word);
  • Op commit;
  • Wanneer u na 'n gedeelde bewaarplek publiseer.

• Op die boubediener of bou-omgewing:
  • Wanneer kode na 'n persoonlike tak/bewaarplek gepubliseer word.
  • Die kode in hierdie draad word getoets.
  • Die potensiële resultaat van die samesmelting word getoets (gewoonlik met master).
  • As 'n deurlopende integrasiestadium/deurlopende afleweringspyplyn

Tipies, hoe vinniger 'n toetsreeks loop, hoe meer dikwels kan jy bekostig om dit te laat loop. 'n Tipiese verhoogverspreiding kan so lyk.

• Vinnige eenheidstoetse - tydens bou, in CI-pyplyn
• Stadige eenheidstoetse, vinnige komponent- en integrasietoetse - op commit, in die CI-pyplyn
• Stadige komponent- en integrasietoetse - in die CI-pyplyn
• Sekuriteitstoetsing, lastoetsing en ander tydrowende of duur toetse - in CI/CD-pyplyne, maar slegs in sekere modusse/stadiums/pyplyne van die bou, byvoorbeeld wanneer 'n vrystellingskandidaat voorberei word of wanneer met die hand uitgevoer word.

️ Taak

Ek stel voor om die toetse eers handmatig uit te voer deur die opdrag te gebruik npm test. Laat ons daarna 'n git-hook byvoeg om ons toetse op commit uit te voer. Daar is een vangplek: Git-hake word nie as deel van die bewaarplek beskou nie en kan dus nie vanaf GitHub saam met die res van die kursusmateriaal gekloon word nie. Om haak te installeer, moet jy hardloop install_hook.sh of kopieer die lêer repo/hooks/pre-commit na die plaaslike gids .git/hooks/.
Wanneer jy jou verbind, sal jy sien dat toetse uitgevoer word en hulle kyk of sekere sleutelwoorde in die lys voorkom.

1. Voer die toetse handmatig uit deur die opdrag uit te voer npm test in jou kursusbewaarlêergids. Verifieer dat die toetse voltooi is.
2. Stel 'n commit-haak (pre-commit-haak) deur te hardloop install_hook.sh.
3. Verbind jou veranderinge aan jou plaaslike bewaarplek.
4. Maak seker dat toetse uitgevoer word voordat dit toegepas word.

Jou bewaarplek behoort so te lyk nadat jy hierdie stappe gevolg het.

Команды

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

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

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

Publiseer kode na 'n afgeleë bewaarplek of afgeleë tak

Sodra hulle klaar is om plaaslik te werk, maak ontwikkelaars gewoonlik hul kode publiek beskikbaar sodat dit uiteindelik met die publiek geïntegreer kan word. Met GitHub word dit gewoonlik bereik deur die werk te publiseer na óf 'n persoonlike kopie van die bewaarplek (persoonlike vurk) of 'n persoonlike tak.

• Met vurke kloon 'n ontwikkelaar 'n afgeleë gedeelde bewaarplek, en skep 'n persoonlike afgeleë kopie daarvan, ook bekend as 'n vurk. Dit kloon dan hierdie persoonlike bewaarplek om plaaslik mee te werk. Wanneer die werk voltooi is en die commits gemaak is, druk hy dit in sy vurk, waar dit vir ander beskikbaar is en in die gemeenskaplike bewaarplek geïntegreer kan word. Hierdie benadering word algemeen gebruik in oopbronprojekte op GitHub. Dit word ook gebruik in my gevorderde kursus [Spanwerk en CI met Git] (http://devops.redpill.solutions/).
• Nog 'n benadering is om slegs een afgeleë bewaarplek te gebruik en slegs die tak te tel master gedeelde bewaarplek "beskerm". In hierdie scenario publiseer individuele ontwikkelaars hul kode na takke van 'n afgeleë bewaarplek sodat ander na hierdie kode kan kyk, as alles in orde is, dit saamsmelt met master gedeelde bewaarplek.

In hierdie spesifieke kursus sal ons 'n werkvloei gebruik wat takke gebruik.

Kom ons publiseer ons kode.

️ Taak

• Publiseer veranderinge aan 'n afgeleë tak met dieselfde naam as jou werkende tak

Команды

git push --set-upstream origin feature

Skep 'n trekversoek

Skep 'n trekversoek met 'n titel Stappe hersiening... Installeer feature soos "hooftak" en master soos "basistak".

Maak seker jy het geïnstalleer master in sy vurk die bewaarplek As 'n "basistak" sal ek nie reageer op versoeke vir veranderinge aan die kursusmateriaalbewaarplek nie.

In GitHub-taal is die "basistak" die tak waarop jy jou werk baseer, en die "hoofvertakking" is die tak wat die voorgestelde veranderinge bevat.

Bespreek die veranderinge, voeg nuwe commits by soos die bespreking voortgaan

Trek versoek (PR)

Trek versoek (PR) is 'n manier om kode te bespreek en te dokumenteer, asook kode-hersiening uit te voer. Trekversoeke is vernoem na die algemene manier om individuele veranderinge in die algehele kode te integreer. Tipies kloon 'n persoon die projek se afgeleë amptelike bewaarplek en werk op die kode plaaslik. Hierna plaas hy die kode in sy persoonlike afgeleë bewaarplek en vra diegene wat verantwoordelik is vir die amptelike bewaarplek om af te haal(trek) sy kode in hul plaaslike bewaarplekke, waar hulle hersien en moontlik integreer (saamsmelt) syne. Hierdie konsep is ook bekend onder ander name, bv. samesmeltingsversoek.

U hoef nie eintlik die trekversoekfunksie van GitHub of soortgelyke platforms te gebruik nie. Ontwikkelingspanne kan ander metodes van kommunikasie gebruik, insluitend van aangesig tot aangesig kommunikasie, stemoproepe of e-pos, maar daar is steeds 'n aantal redes om forumstyl-trekversoeke te gebruik. Hier is 'n paar van hulle:

• georganiseerde besprekings wat verband hou met spesifieke kodeveranderings;
• as 'n plek om terugvoer te sien oor werk wat aan die gang is van beide outotoetsers en eweknieë;
• formalisering van kode resensies;
• sodat jy later die redes en oorwegings agter hierdie of daardie stukkie kode kan uitvind.

Tipies skep jy 'n trekversoek wanneer jy iets moet bespreek of terugvoer moet kry. As jy byvoorbeeld werk aan 'n kenmerk wat op meer as een manier geïmplementeer kan word, kan jy 'n trekversoek skep voordat jy die eerste reël kode skryf om jou idees te deel en jou planne met jou medewerkers te bespreek. As die werk eenvoudiger is, word 'n trekversoek geopen wanneer iets reeds gedoen is, toegewyd is en bespreek kan word. In sommige scenario's wil jy dalk net 'n PR oopmaak om kwaliteitbeheerredes: om outomatiese toetse uit te voer of kode-oorsig te inisieer. Wat jy ook al besluit, moenie vergeet om die mense wie se goedkeuring jy wil hê in jou trekversoek te @noem nie.

Tipies, wanneer jy 'n PR skep, doen jy die volgende.

• Dui aan wat jy voorstel om te verander en waar.
• Skryf 'n beskrywing wat die doel van die veranderinge verduidelik. Jy wil dalk:
  • voeg enigiets belangrik by wat nie duidelik uit die kode is nie, of iets nuttig om die konteks te verstaan, soos relevante #bugs en commit-nommers;
  • @noem enigiemand met wie jy wil begin werk, of jy kan hulle later in die kommentaar @noem;
  • vra kollegas om te help met iets of kyk na iets spesifiek.

Sodra jy die PR oopmaak, word die toetse wat in sulke gevalle gekonfigureer is, uitgevoer. In ons geval sal dit dieselfde stel toetse wees wat ons plaaslik uitgevoer het, maar in 'n regte projek kan daar bykomende toetse en kontroles wees.

Wag asseblief terwyl die toetse voltooi is. U kan die status van die toetse onderaan die PR-bespreking in die GitHub-koppelvlak sien. Gaan voort wanneer die toetse voltooi is.

️ Voeg 'n nota by oor die willekeurigheid van die lys CI-stappe

Die lys wat in hierdie kursus gebruik word, is arbitrêr en subjektief, ons moet 'n nota hieroor byvoeg.

️ Taak: skep 'n trekversoek vir hierdie opmerking

1. Skakel oor na tak master.
2. Skep 'n tak met die naam bugfix.
3. Voeg notateks by die einde van die lêer 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. Verbind die veranderinge.
5. Publiseer die draad bugfix na 'n afgeleë bewaarplek.
6. Skep 'n trekversoek met die naam Voeg 'n opmerking by met 'n koptak bugfix en die basistakmaster.

Maak seker jy het geïnstalleer master in sy vurk die bewaarplek As 'n "basistak" sal ek nie reageer op versoeke vir veranderinge aan die kursusmateriaalbewaarplek nie.

Dit is hoe jou bewaarplek moet lyk.

Команды

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

Keur trekversoek "Voeg 'n opmerking by" goed

️ Taak

1. Skep 'n trekversoek.
2. Klik "Voeg trekversoek saam".
3. Klik "Bevestig samesmelting".
4. Klik "Delete branch", ons het dit nie meer nodig nie.

Dit is 'n diagram van commits na 'n samesmelting.

️ Hou aan werk en voeg toetse by

Samewerking aan 'n trekversoek lei dikwels tot bykomende werk. Dit is gewoonlik die resultaat van 'n kode-oorsig of bespreking, maar in ons kursus gaan ons dit modelleer deur nuwe items by ons lys CI-stappe te voeg.

Deurlopende integrasie behels tipies 'n mate van toetsdekking. Toetsdekkingvereistes verskil en word gewoonlik gevind in 'n dokument wat iets soos "bydrae riglyne" genoem word. Ons sal dit eenvoudig hou en 'n toets vir elke reël in ons kontrolelys byvoeg.

Wanneer jy opdragte uitvoer, probeer eers om die toetse af te lê. As jy korrek geïnstalleer het pre-commit haak vroeër, die nuut bygevoegde toets sal uitgevoer word, sal misluk, en niks sal gepleeg word nie. Let daarop dat dit is hoe ons weet dat ons toetse eintlik iets toets. Interessant genoeg, as ons voor die toetse met die kode begin het, kan die slaag van die toetse óf beteken dat die kode gewerk het soos verwag is, óf dat die toetse eintlik niks getoets het nie. Plus, as ons nie die toetse in die eerste plek geskryf het nie, sou ons dalk heeltemal daarvan vergeet het, aangesien niks ons daaraan sou herinner het nie.

Toetsgedrewe ontwikkeling (TDD)

TDD beveel aan om toetse voor kode te skryf. 'n Tipiese werkvloei wat TDD gebruik, lyk so.

1. Voeg 'n toets by.
2. Voer alle toetse uit en maak seker dat die nuwe toets misluk.
3. Skryf die kode.
4. Voer die toetse uit, maak seker dat alle toetse slaag.
5. Refaktoreer jou kode.
6. Herhaal.

Omdat die uitslae van toetse wat misluk gewoonlik in rooi getoon word, en dié wat geslaag het, gewoonlik in groen getoon word, staan ​​die siklus ook bekend as 'n rooi-groen-refaktor.

️ Taak

Probeer eers om die toetse uit te voer en laat hulle misluk, voeg dan die teks van die CI-staplys self by en voer dit uit. Jy sal sien dat die toetse slaag ("groen").
Publiseer dan die nuwe kode na die afgeleë bewaarplek en kyk hoe die toetse uitgevoer word in die GitHub-koppelvlak aan die onderkant van die trekversoekbespreking en die PR-statusopdatering.

1. Skakel oor na tak feature.

2. Voeg hierdie toetse by ci.test.js na die laaste oproep it (...);.

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

3. Probeer om die toetse te doen. As pre-commit haak geïnstalleer is, sal die pleegpoging misluk.
4. Voeg dan hierdie teks by 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. Maak en pleeg veranderinge plaaslik.
6. Plaas veranderinge aan die tak feature.

Jy behoort nou so iets te hê

Команды

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

Voeg konflik saam

Gaan na Veranderversoek Stappe hersiening.

Alhoewel ons niks verkeerd gedoen het nie en die toetse vir ons kode geslaag het, kan ons steeds nie die tak saamsmelt nie feature и master. Dit is omdat die ander draad bugfix is saamgevoeg met master terwyl ons aan hierdie PR gewerk het.
Dit skep 'n situasie waar die afgeleë tak master het 'n nuwer weergawe as die een waarop ons die tak gebaseer het feature. As gevolg hiervan kan ons nie net KOP terugspoel nie master tot aan die einde van die draad feature. In hierdie situasie moet ons óf saamsmelt óf commits toepas feature herbaseer master. GitHub kan eintlik outomatiese samesmeltings uitvoer as daar geen konflikte is nie. Helaas, in ons situasie het beide takke mededingende veranderinge in die lêer ci.md. Hierdie situasie staan ​​bekend as 'n samesmeltingskonflik, en ons moet dit handmatig oplos.

Voeg saam of herbaseer

Kombineer

• Skep 'n bykomende samesmelting en stoor die werkgeskiedenis.
  • Behou die oorspronklike verbintenisse van takke met hul oorspronklike tydstempels en outeurs.
  • Stoor die SHA van verbintenisse en skakels daarna in besprekingsversoeke oor verandering.
• Vereis eenmalige konflikoplossing.
• Maak die storie nie-lineêr.
  • Die storie kan moeilik wees om te lees as gevolg van die groot aantal vertakkings (herinner aan 'n IDE-kabel).
  • Maak outomatiese ontfouting moeiliker, bv. git bisect minder bruikbaar - dit sal net die samesmelting vind.

Herbegin

• Herspeel commits van die huidige tak bo-op die basistak een na die ander.
  • Nuwe commits met nuwe SHA's word gegenereer, wat veroorsaak dat die commits in GitHub ooreenstem met die oorspronklike trekversoeke, maar nie die ooreenstemmende opmerkings nie.
  • Verbintenisse kan in die proses herkombineer en gewysig word, of selfs in een saamgevoeg word.
• Veelvuldige konflikte moet dalk opgelos word.
• Laat jou toe om 'n lineêre storie te handhaaf.
  • Die storie is dalk makliker om te lees solank dit nie te lank is vir geen redelike rede nie.
  • Outomatiese ontfouting en foutsporing is 'n bietjie makliker: maak dit moontlik git bisect, kan outomatiese terugdraaie duideliker en meer voorspelbaar maak.
• Vereis die publisering van 'n tak met gemigreerde commits met 'n vlag --force wanneer dit gebruik word met trekversoeke.

Tipies stem spanne in om altyd dieselfde strategie te gebruik wanneer hulle veranderinge moet saamvoeg. Dit kan 'n "suiwer" samesmelting of 'n "suiwer" commit bo-op wees, of iets tussenin, soos om 'n commit bo-op interaktief te doen(git rebase -i) plaaslik vir takke wat nie na die publieke bewaarplek gepubliseer is nie, maar saamsmelt vir "openbare" takke.

Hier sal ons samesmelting gebruik.

️ Taak

1. Maak seker dat die kode in 'n plaaslike tak is master vanaf 'n afgeleë bewaarplek opgedateer.
2. Skakel oor na tak feature.
3. Begin 'n samesmelting met 'n tak master. N samesmelting konflik as gevolg van mededingende veranderinge aan die ci.md.
4. Los die konflik op sodat beide ons lys CI-stappe en 'n nota daaroor in die teks bly.
5. Publiseer 'n samesmeltingstoewysing na 'n afgeleë tak feature.
6. Gaan die status van die trekversoek na in die GitHub UI en wag totdat die samesmelting opgelos is.

Команды

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

Goeie werk!

Jy is klaar met die lys en nou moet jy die intrekversoek goedkeur master.

️ Taak: Keur trekversoek "Stappe hersiening" goed

1. Maak 'n trekversoek oop.
2. Klik "Voeg trekversoek saam".
3. Klik "Bevestig samesmelting".
4. Klik op "Verwyder tak" aangesien ons dit nie meer nodig het nie.

Dit is jou bewaarplek op die oomblik

Produkfout

Daar word gesê dat "toetsing gebruik kan word om die teenwoordigheid van foute te wys, maar nooit om hul afwesigheid te wys nie." Alhoewel ons toetse gehad het en hulle ons geen foute gewys het nie, het 'n verraderlike fout in produksie ingesluip.

In 'n scenario soos hierdie moet ons sorg vir:

• wat in produksie ontplooi word;
• kode in die draad master met 'n fout, waaruit ontwikkelaars nuwe werk kan begin.

Moet ek terugrol of dit regmaak in die volgende weergawe?

Terugrol is die proses om 'n bekende goeie vroeër weergawe na produksie te ontplooi en om commits wat die fout bevat, terug te keer. "Voorwaarts regmaak" is die toevoeging van 'n regstelling aan die master en die implementering van die nuwe weergawe so gou as moontlik. Omdat API's en databasisskemas verander namate kode na produksie ontplooi word, met deurlopende aflewering en goeie toetsdekking, is die terugrol gewoonlik baie moeiliker en meer riskant as om dit in die volgende weergawe reg te stel.

Aangesien terugrol in ons geval geen risiko inhou nie, sal ons hierdie roete gaan, want dit laat ons toe

• herstel die fout op die produk so gou as moontlik;
• maak kode in master onmiddellik geskik om 'n nuwe werk te begin.

️ Taak

1. Skakel oor na tak master plaaslik.
2. Dateer die plaaslike bewaarplek op vanaf die afgeleë bewaarplek.
3. Stel die PR-samesmeltingsverbintenis terug Stappe hersiening в master.
4. Publiseer veranderinge aan 'n afgeleë bewaarplek.

Dit is die geskiedenis van 'n bewaarplek met 'n samesmelting wat teruggekeer is

Команды

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

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

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

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

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

️ Selftoets

Maak seker dat ci.md bevat nie meer die teks "sneaky bug" nadat 'n samesmeltingstoewysing teruggestel is nie.

Maak die lys van CI-stappe reg en stuur dit terug na meester

Ons het die samesmeltingsverbintenis van die tak heeltemal teruggedraai. feature. Die goeie nuus is dat ons nou geen fout in het nie master. Die slegte nuus is dat ons kosbare lys van deurlopende integrasiestappe ook weg is. Dus, ideaal gesproke, moet ons die regstelling toepas op die commits vanaf feature en gee hulle terug na master saam met die regstelling.

Ons kan die probleem op verskillende maniere benader:

• 'n commit terugstel wat 'n samesmelting ongedaan maak feature с master;
• skuif pleeg van eersgenoemde feature.

Verskillende ontwikkelingspanne gebruik verskillende benaderings in hierdie geval, maar ons sal nuttige commits na 'n aparte tak skuif en 'n aparte trekversoek vir hierdie nuwe tak skep.

️ Taak

1. Skep 'n draad genaamd feature-fix en skakel daarna oor.

2. Migreer alle verpligtinge van die voormalige tak feature na 'n nuwe draad. Los samesmeltingskonflikte op wat tydens die migrasie plaasgevind het.

   

3. Voeg 'n regressietoets by ci.test.js:

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

4. Voer die toetse plaaslik uit om seker te maak dat hulle nie druip nie.
5. Verwyder die teks "met 'n skelm gogga" in ci.md.
6. Voeg toetsveranderinge en staplysveranderinge by die indeks en pleeg dit.
7. Publiseer die tak na 'n afgeleë bewaarplek.

Jy behoort met iets soortgelyks te eindig:

Команды

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

Skep 'n trekversoek.

Skep 'n trekversoek met 'n titel Regstelling van die kenmerk... Installeer feature-fix soos "hooftak" en master soos "basistak".
Wag asseblief terwyl die toetse voltooi word. U kan die status van die toetse onderaan die PR-bespreking sien.

Maak seker jy het geïnstalleer master in sy vurk die bewaarplek As 'n "basistak" sal ek nie reageer op versoeke vir veranderinge aan die kursusmateriaalbewaarplek nie.

Keur trekversoek "Repareer die kenmerk" goed

Dankie vir regstelling! Keur asseblief die veranderinge aan master van trek versoek.

️ Taak

1. Klik "Voeg trekversoek saam".
2. Klik "Bevestig samesmelting".
3. Klik op "Verwyder tak" aangesien ons dit nie meer nodig het nie.

Dit is wat jy op die oomblik moet hê.

Baie geluk!

Jy het al die stappe voltooi wat mense gewoonlik tydens deurlopende integrasie neem.

As jy enige probleme met die kursus opmerk of weet hoe om dit te verbeter, skep asseblief 'n probleem in bewaarplekke met kursusmateriaal. Hierdie kursus het ook interaktiewe weergawe gebruik GitHub Learning Lab as 'n platform.

Bron: will.com