Naučili ste sa príkazy Git, ale chcete si predstaviť, ako nepretržitá integrácia (CI) funguje v skutočnosti? Alebo možno chcete optimalizovať svoje každodenné aktivity? Tento kurz vám poskytne praktické zručnosti v nepretržitej integrácii pomocou úložiska GitHub. Tento kurz nie je zamýšľaný ako čarodejník, cez ktorého sa môžete jednoducho preklikať, naopak, budete vykonávať tie isté činnosti, ktoré ľudia skutočne robia v práci, rovnakým spôsobom, akým to robia. Vysvetlím teóriu, keď prejdete jednotlivými krokmi.

Čo urobíme?

Ako postupujeme, postupne vytvoríme zoznam typických krokov CI, čo je skvelý spôsob, ako si tento zoznam zapamätať. Inými slovami, vytvoríme zoznam činností, ktoré vývojári robia pri nepretržitej integrácii, pri nepretržitej integrácii. Použijeme tiež jednoduchý súbor testov, aby sme náš proces CI priblížili skutočnému.

Tento GIF schematicky zobrazuje odovzdania vo vašom úložisku, ako postupujete kurzom. Ako vidíte, nie je tu nič zložité a len to najnutnejšie.

Prejdete nasledujúcimi štandardnými scenármi CI:

• Práca na funkcii;
• Aplikácia automatizovaných testov na zabezpečenie kvality;
• Implementácia prioritnej úlohy;
• Riešenie konfliktov pri zlučovaní pobočiek (konflikt zlučovania);
• V produkčnom prostredí sa vyskytne chyba.

čo sa naučíš?

Budete vedieť odpovedať na nasledujúce otázky:

• Čo je kontinuálna integrácia (CI)?
• Aké typy automatických testov sa používajú v CI a v reakcii na aké akcie sa spúšťajú?
• Čo sú požiadavky na stiahnutie a kedy sú potrebné?
• Čo je testom riadený vývoj (TDD) a ako súvisí s CI?
• Mám zlúčiť alebo prehodnotiť zmeny?
• Vrátiť späť alebo opraviť v ďalšej verzii?

Najprv som všade prekladal veci ako „pull request“, no v dôsledku toho som sa rozhodol na niektorých miestach vrátiť frázy v angličtine, aby som znížil mieru šialenstva v texte. Niekedy použijem „programátorský surzhik“ ako úžasné sloveso „zaviazať sa“, kde ho ľudia skutočne používajú v práci.

Čo je to nepretržitá integrácia?

Nepretržitá integrácia, alebo CI, je technická prax, pri ktorej každý člen tímu aspoň raz denne integruje svoj kód do spoločného úložiska a výsledný kód musí byť aspoň zostavený bez chýb.

O tomto termíne panujú nezhody

Sporným bodom je frekvencia integrácie. Niektorí tvrdia, že zlúčenie kódu iba raz za deň nestačí na to, aby sa integroval nepretržite. Uvádza sa príklad tímu, v ktorom si každý ráno vezme nový kód a raz večer ho integruje. Aj keď je to opodstatnená námietka, všeobecne sa verí, že definícia raz za deň je primerane praktická, špecifická a vhodná pre tímy rôznych veľkostí.

Ďalšou námietkou je, že C++ už nie je jediným jazykom používaným pri vývoji a jednoducho požadovať bezchybné zostavenie ako spôsob overenia je slabé. Niektoré sady testov (napríklad jednotkové testy vykonávané lokálne) musia byť tiež úspešne dokončené. Momentálne komunita smeruje k tomu, aby sa to stalo požiadavkou a v budúcnosti sa „build + unit testy“ pravdepodobne stanú bežnou praxou, ak sa tak ešte nestalo.

Nepretržitá integrácia iné ako nepretržité dodávanie (Continuous Delivery, CD) v tom, že nevyžaduje kandidáta na vydanie po každom integračnom cykle.

Zoznam krokov, ktoré budeme v priebehu kurzu používať

1. Vytiahnite najnovší kód. Vytvorte vetvu z master. Začať pracovať.
2. Vytvorte commity na svojej novej pobočke. Vytvárajte a testujte lokálne. prejsť? Prejdite na ďalší krok. zlyhať? Opravte chyby alebo testy a skúste to znova.
3. Push do vášho vzdialeného úložiska alebo vzdialenej pobočky.
4. Vytvorte požiadavku na stiahnutie. Diskutujte o zmenách a pri pokračovaní diskusie pridajte ďalšie odovzdania. Nechajte testy prejsť na vetve funkcií.
5. Zlúčiť/znovu založiť odovzdania z hlavného. Nechajte testy odovzdať výsledok zlúčenia.
6. Nasadenie od vetvy funkcií až po produkciu.
7. Ak je vo výrobe po určitú dobu všetko v poriadku, zlúčte zmeny do predlohy.

️ Príprava

Uistite sa, že máte správny softvér

Na absolvovanie tohto kurzu budete potrebovať Node.js и Klient Git.

Môžete použiť ľubovoľného klienta Git, ale ja poskytnem iba príkazy pre príkazový riadok.

Uistite sa, že máte nainštalovaného klienta Git, ktorý podporuje príkazový riadok

Ak ešte nemáte klienta Git, ktorý podporuje príkazový riadok, nájdete pokyny na inštaláciu tu.

Pripravte úložisko

Budete si musieť vytvoriť osobnú kópiu (fork) úložisko šablón s kódom pre kurz na GitHub. Dohodnime sa, že túto osobnú kópiu nazveme úložisko kurzov.

Hotový? Ak ste nezmenili predvolené nastavenia, s najväčšou pravdepodobnosťou sa volá váš archív kurzu continuous-integration-team-scenarios-students, nachádza sa vo vašom účte GitHub a adresa URL vyzerá takto

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

Jednoducho zavolám na túto adresu <URL репозитория>.

Uhlové zátvorky ako <тут> bude znamenať, že musíte nahradiť takýto výraz príslušnou hodnotou.

Uistite sa, že Akcie GitHubu zahrnuté pre tento archív kurzov. Ak nie sú povolené, povoľte ich kliknutím na veľké tlačidlo v strede stránky, na ktoré sa dostanete kliknutím na Akcie v rozhraní GitHub.

Ak nie sú povolené akcie GitHub, nebudete môcť dokončiť kurz podľa mojich pokynov.

Vždy môžete použiť schopnosť GitHubu vykresliť Markdown, aby ste videli aktuálny stav zoznamu, ktorý tu vytvárame

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

O odpovediach

Aj keď najlepší spôsob, ako tento kurz absolvovať, je urobiť si ho sami, môžete mať určité ťažkosti.

Ak máte pocit, že nerozumiete, čo máte robiť, a nemôžete pokračovať, môžete sa pozrieť do vlákna solution, ktorý je vo vašom štartovacom úložisku.
Prosím nezlučujte solution в master počas kurzu. Pomocou tejto vetvy môžete zistiť, čo robiť, alebo porovnať svoj kód s kódom autora s využitím všetkých možností, ktoré nám Git poskytuje. Ak ste úplne stratení, môžete svoju ratolesť úplne nahradiť master na konári solution a potom obnovte svoj pracovný adresár na krok kurzu, ktorý potrebujete.

Použite to len vtedy, ak to naozaj potrebujete

Odovzdajte svoj kód

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

Tieto príkazy

• premenovať master в master-backup;
• premenovať solution в master;
• pokladňa do novej pobočky master a prepíšte obsah pracovného adresára;
• Vytvorte vetvu "riešenie" z "master" (čo bývalo "riešenie") pre prípad, že by ste v budúcnosti potrebovali vetvu "riešenie".

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

Po týchto krokoch môžete použiť git log master aby ste zistili, ktorý záväzok potrebujete.
Svoj pracovný adresár môžete resetovať na tento príkaz takto:

git reset --hard <the SHA you need>

Ak ste s výsledkom spokojní, v určitom bode budete musieť zverejniť svoju verziu úložiska do vzdialeného úložiska. Keď to urobíte, nezabudnite explicitne špecifikovať vzdialenú pobočku.

git push --force origin master

Upozorňujeme, že používame git push --force. Je nepravdepodobné, že to budete chcieť robiť veľmi často, ale máme tu veľmi špecifický scenár s jedným používateľom úložiska, ktorý navyše rozumie tomu, čo robí.

Začiatok práce

Začnime zostavovať náš zoznam krokov CI. Normálne by ste tento krok začali skontrolovaním najnovšej verzie kódu zo vzdialeného úložiska, ale zatiaľ nemáme lokálne úložisko, takže ho namiesto toho naklonujeme zo vzdialeného úložiska.

️ Úloha: aktualizovať lokálne úložisko, vytvoriť pobočku z master, začať pracovať

1. Naklonujte úložisko kurzov z <URL репозитория>.
2. beh npm install v adresári úložiska kurzov; Potrebujeme ho na inštaláciu Jestu, ktorý používame na spustenie testov.
3. Vytvorte pobočku a pomenujte ju feature. Prejdite na toto vlákno.

4. Pridajte testovací kód do ci.test.js medzi komentármi, ktoré ma žiadajú, aby som to urobil.

   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. Do súboru pridajte text s prvými 4 krokmi 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.  

   príkazy

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

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

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

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

Vytvorte odovzdania na novej vetve, zostavte a otestujte lokálne

Nastavíme testy tak, aby sa spustili pred potvrdením, a potom potvrdíme kód.

Typické scenáre, keď sa testy spúšťajú automaticky

• Lokálne:
  • Priebežne alebo v reakcii na príslušné zmeny kódu;
  • Pri ukladaní (pre prekladané jazyky alebo jazyky kompilované JIT);
  • Počas montáže (keď je potrebná kompilácia);
  • Pri záväzku;
  • Pri publikovaní do zdieľaného úložiska.

• Na zostavovacom serveri alebo v zostavovacom prostredí:
  • Keď je kód zverejnený na osobnej pobočke/úložisku.
  • Kód v tomto vlákne sa testuje.
  • Testuje sa potenciálny výsledok fúzie (zvyčajne s master).
  • Ako kontinuálna integračná etapa/kontinuálna dodávka

Zvyčajne čím rýchlejšie beží testovací balík, tým častejšie si ho môžete dovoliť spúšťať. Typická distribúcia fáz môže vyzerať takto.

• Rýchle jednotkové testy - počas výstavby, v CI potrubí
• Pomalé testy jednotiek, rýchle testy komponentov a integrácie - pri odovzdaní, v potrubí CI
• Pomalé testy komponentov a integrácie - v CI pipeline
• Bezpečnostné testovanie, záťažové testovanie a iné časovo náročné alebo drahé testy – v CI/CD kanáloch, ale iba v určitých režimoch/fázach/priebehoch zostavenia, napríklad pri príprave kandidáta na vydanie alebo pri manuálnom spustení.

️Úloha

Odporúčam najskôr spustiť testy manuálne pomocou príkazu npm test. Potom pridajte git hook na spustenie našich testov pri odovzdaní. Má to jeden háčik: Git hooks sa nepovažujú za súčasť úložiska, a preto ich nemožno klonovať z GitHubu spolu so zvyškom materiálov kurzu. Ak chcete nainštalovať hák, musíte ho spustiť install_hook.sh alebo skopírujte súbor repo/hooks/pre-commit do lokálneho adresára .git/hooks/.
Keď vykonáte potvrdenie, uvidíte, že sa spustia testy a skontrolujú, či sa v zozname nachádzajú určité kľúčové slová.

1. Spustite testy manuálne spustením príkazu npm test v priečinku archívu vášho kurzu. Skontrolujte, či boli testy dokončené.
2. Spustením nastavte háčik odovzdania (hák pred potvrdením). install_hook.sh.
3. Odovzdajte svoje zmeny do miestneho úložiska.
4. Pred potvrdením sa uistite, že sú spustené testy.

Po vykonaní týchto krokov by malo vaše úložisko vyzerať takto.

príkazy

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

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

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

Publikovanie kódu do vzdialeného úložiska alebo vzdialenej pobočky

Keď vývojári skončia prácu na mieste, zvyčajne sprístupnia svoj kód verejnosti, aby ho mohli nakoniec integrovať s verejnosťou. S GitHub sa to zvyčajne dosahuje zverejnením diela buď v osobnej kópii úložiska (osobná vidlica) alebo v osobnej pobočke.

• Pomocou forkov vývojár naklonuje vzdialené zdieľané úložisko a vytvorí jeho osobnú vzdialenú kópiu, tiež známu ako fork. Potom naklonuje toto osobné úložisko, aby s ním mohlo pracovať lokálne. Keď je práca dokončená a sú vykonané príkazy, vloží ich do svojej vidlice, kde sú k dispozícii ostatným a môžu byť integrované do spoločného úložiska. Tento prístup sa bežne používa v open source projektoch na GitHub. Používa sa aj v mojom pokročilom kurze [Tímová práca a CI s Git] (http://devops.redpill.solutions/).
• Ďalším prístupom je použitie iba jedného vzdialeného úložiska a započítanie iba vetvy master zdieľané úložisko „chránené“. V tomto scenári jednotliví vývojári zverejňujú svoj kód do pobočiek vzdialeného úložiska, aby si ostatní mohli tento kód pozrieť, ak je všetko v poriadku, zlúčiť ho s master zdieľané úložisko.

V tomto konkrétnom kurze budeme používať pracovný postup, ktorý využíva pobočky.

Zverejnime náš kód.

️Úloha

• Zverejnite zmeny vo vzdialenej vetve s rovnakým názvom, ako má vaša pracovná vetva

príkazy

git push --set-upstream origin feature

Vytvorte požiadavku na stiahnutie

Vytvorte požiadavku na stiahnutie s názvom Kontrola krokov... Inštalácia feature ako "hlavná vetva" a master ako „základná vetva“.

Uistite sa, že ste nainštalovali master v jeho rozvetviť úložisko Ako „základná pobočka“ nebudem reagovať na žiadosti o zmeny v úložisku materiálov kurzu.

V jazyku GitHub je „základná vetva“ vetva, na ktorej zakladáte svoju prácu, a „hlavná vetva“ je vetva obsahujúca navrhované zmeny.

Diskutujte o zmenách, pridávajte nové odovzdania, ako diskusia pokračuje

Vytiahnuť žiadosť (PR)

Vytiahnuť žiadosť (PR) je spôsob, ako diskutovať a dokumentovať kódex, ako aj vykonávať jeho preskúmanie. Pull requesty sú pomenované podľa všeobecného spôsobu integrácie jednotlivých zmien do celkového kódu. Osoba zvyčajne klonuje vzdialené oficiálne úložisko projektu a pracuje na kóde lokálne. Potom umiestni kód do svojho osobného vzdialeného úložiska a požiada osoby zodpovedné za oficiálne úložisko, aby si ho vyzdvihli (SEM) jeho kód do svojich lokálnych úložísk, kde kontrolujú a prípadne integrujú (spojiť) jeho. Tento pojem je známy aj pod inými názvami, napr. žiadosť o zlúčenie.

V skutočnosti nemusíte používať funkciu pull request GitHub alebo podobných platforiem. Vývojové tímy môžu používať iné spôsoby komunikácie vrátane osobnej komunikácie, hlasových hovorov alebo e-mailov, ale stále existuje množstvo dôvodov, prečo používať žiadosti o stiahnutie v štýle fóra. Tu sú niektoré z nich:

• organizované diskusie týkajúce sa konkrétnych zmien v kóde;
• ako miesto na zobrazenie spätnej väzby o rozpracovanej práci od autotesterov aj kolegov;
• formalizácia preskúmania kódu;
• aby ste neskôr mohli zistiť dôvody a úvahy za tým či oným kódom.

Požiadavku na stiahnutie zvyčajne vytvoríte, keď potrebujete niečo prediskutovať alebo získať spätnú väzbu. Ak napríklad pracujete na funkcii, ktorá by sa dala implementovať viacerými spôsobmi, môžete pred napísaním prvého riadku kódu vytvoriť požiadavku na stiahnutie, aby ste sa podelili o svoje nápady a prediskutovali svoje plány so svojimi spolupracovníkmi. Ak je práca jednoduchšia, požiadavka na stiahnutie sa otvorí, keď sa už niečo urobilo, zaviazalo a možno o tom diskutovať. V niektorých scenároch možno budete chcieť otvoriť PR iba z dôvodov kontroly kvality: spustiť automatické testy alebo spustiť kontrolu kódu. Nech sa už rozhodnete akokoľvek, nezabudnite vo svojej žiadosti o stiahnutie @uviesť ľudí, ktorých schválenie chcete.

Pri vytváraní PR zvyčajne robíte nasledovné.

• Uveďte, čo a kde navrhujete zmeniť.
• Napíšte popis vysvetľujúci účel zmien. Možno budete chcieť:
  • pridajte čokoľvek dôležité, čo nie je zrejmé z kódu, alebo niečo užitočné na pochopenie kontextu, ako napríklad relevantné #chyby a čísla odovzdania;
  • @spomínajte kohokoľvek, s kým chcete začať spolupracovať, alebo sa o nich môžete @spomínať v komentároch neskôr;
  • požiadajte kolegov, aby s niečím pomohli alebo si niečo konkrétne overili.

Po otvorení PR sa vykonajú testy nakonfigurované na spustenie v takýchto prípadoch. V našom prípade to bude rovnaký súbor testov, ktoré sme spustili lokálne, ale v skutočnom projekte môžu existovať dodatočné testy a kontroly.

Počkajte, kým sa testy dokončia. Stav testov si môžete pozrieť v spodnej časti PR diskusie v rozhraní GitHubu. Po dokončení testov pokračujte.

️ Pridajte poznámku o náhodnosti zoznamu krokov CI

Zoznam použitý v tomto kurze je ľubovoľný a subjektívny, k tomu by sme mali pridať poznámku.

️ Úloha: vytvorte požiadavku na stiahnutie tohto komentára

1. Prepnúť na pobočku master.
2. Vytvorte vetvu s názvom bugfix.
3. Pridajte text poznámky na koniec súboru 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. Potvrdiť zmeny.
5. Zverejnite vlákno bugfix do vzdialeného úložiska.
6. Vytvorte požiadavku na stiahnutie s názvom Pridanie poznámky s hlavovou vetvou bugfix a základná vetvamaster.

Uistite sa, že ste nainštalovali master v jeho rozvetviť úložisko Ako „základná pobočka“ nebudem reagovať na žiadosti o zmeny v úložisku materiálov kurzu.

Takto by malo vyzerať vaše úložisko.

príkazy

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

Schválenie žiadosti o stiahnutie „Pridanie poznámky“

️Úloha

1. Vytvorte požiadavku na stiahnutie.
2. Kliknite na "Zlúčiť žiadosť o stiahnutie".
3. Kliknite na „Potvrdiť zlúčenie“.
4. Kliknite na „Odstrániť vetvu“, už ju nepotrebujeme.

Toto je schéma odovzdania po zlúčení.

️ Pokračujte v práci a pridávaní testov

Spolupráca na žiadosti o stiahnutie často vedie k ďalšej práci. Zvyčajne je to výsledok kontroly kódu alebo diskusie, ale v našom kurze to budeme modelovať pridaním nových položiek do nášho zoznamu krokov CI.

Nepretržitá integrácia zvyčajne zahŕňa určité testovacie pokrytie. Požiadavky na pokrytie testov sa líšia a zvyčajne sa nachádzajú v dokumente, ktorý sa nazýva niečo ako „usmernenia pre príspevky“. Urobíme to jednoducho a pridáme test pre každý riadok v našom kontrolnom zozname.

Pri zadávaní úloh skúste najskôr odovzdať testy. Ak ste nainštalovali správne pre-commit háčik skôr, novo pridaný test sa spustí, zlyhá a nič sa nezaviaže. Všimnite si, že takto vieme, že naše testy skutočne niečo testujú. Zaujímavé je, že ak by sme s kódom začali pred testami, úspešné absolvovanie testov by mohlo znamenať, že kód fungoval podľa očakávania, alebo že testy v skutočnosti nič netestovali. Navyše, ak by sme v prvom rade nepísali testy, možno by sme na ne úplne zabudli, keďže by nám to nič nepripomínalo.

Testom riadený vývoj (TDD)

TDD odporúča písať testy pred kódom. Typický pracovný postup využívajúci TDD vyzerá takto.

1. Pridajte test.
2. Spustite všetky testy a uistite sa, že nový test zlyhá.
3. Napíšte kód.
4. Spustite testy a uistite sa, že všetky testy prebehli úspešne.
5. Refaktorujte svoj kód.
6. Opakujte.

Pretože výsledky testov, ktoré zlyhali, sú zvyčajne zobrazené červenou farbou a tie, ktoré vyhoveli, sú zvyčajne zobrazené zelenou farbou, cyklus je tiež známy ako červeno-zelený faktor.

️Úloha

Najprv sa pokúste potvrdiť testy a nechať ich zlyhať, potom pridajte a potvrďte text samotného zoznamu krokov CI. Uvidíte, že testy sú úspešné ("zelené").
Potom publikujte nový kód do vzdialeného úložiska a sledujte testy spustené v rozhraní GitHub v spodnej časti diskusie o žiadosti o stiahnutie a aktualizácii stavu PR.

1. Prepnúť na pobočku feature.

2. Pridajte tieto testy do ci.test.js po poslednom hovore 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. Skúste absolvovať testy. Ak pre-commit hák je nainštalovaný, pokus o potvrdenie zlyhá.
4. Potom pridajte tento text do 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. Vykonajte a potvrďte zmeny lokálne.
6. Odošlite zmeny do pobočky feature.

Teraz by ste mali mať niečo takéto

príkazy

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

Zlúčiť konflikt

Prejdite na Žiadosť o zmenu Kontrola krokov.

Aj keď sme neurobili nič zlé a testy pre náš kód prešli, stále nemôžeme vetvu zlúčiť feature и master. Je to kvôli tomu druhému vláknu bugfix bol zlúčený s master keď sme pracovali na tomto PR.
Vzniká tak situácia, kedy vzdialená pobočka master má novšiu verziu ako tá, na ktorej sme založili pobočku feature. Z tohto dôvodu nemôžeme len pretočiť HEAD master do konca vlákna feature. V tejto situácii musíme buď zlúčiť, alebo použiť commity feature rebase master. GitHub môže skutočne vykonávať automatické zlúčenia, ak neexistujú žiadne konflikty. Bohužiaľ, v našej situácii majú obe pobočky konkurenčné zmeny v súbore ci.md. Táto situácia je známa ako konflikt zlučovania a musíme ju vyriešiť manuálne.

Zlúčiť alebo znova založiť

ísť

• Vytvorí dodatočné odovzdanie zlúčenia a uloží históriu práce.
  • Zachováva pôvodné commity pobočiek s ich pôvodnými časovými pečiatkami a autormi.
  • Uloží SHA potvrdení a odkazov na ne v diskusiách o požiadavkách na zmenu.
• Vyžaduje jednorazové riešenie konfliktu.
• Robí príbeh nelineárnym.
  • Príbeh sa môže ťažko čítať kvôli veľkému počtu vetiev (pripomína IDE kábel).
  • Sťažuje automatické ladenie, napr. git bisect menej užitočné - nájde iba príkaz na zlúčenie.

rebase

• Prehrá potvrdenia z aktuálnej vetvy nad základnú vetvu jeden po druhom.
  • Generujú sa nové potvrdenia s novými SHA, čo spôsobí, že potvrdenia v GitHub sa zhodujú s pôvodnými požiadavkami na stiahnutie, ale nie so zodpovedajúcimi komentármi.
  • Záväzky je možné v procese prekombinovať a upraviť, alebo dokonca zlúčiť do jedného.
• Možno bude potrebné vyriešiť viacero konfliktov.
• Umožňuje vám udržiavať lineárny príbeh.
  • Príbeh sa môže čítať ľahšie, ak nie je príliš dlhý bez rozumného dôvodu.
  • Automatické ladenie a riešenie problémov je o niečo jednoduchšie: umožňuje to git bisect, môže urobiť automatické vrátenia prehľadnejšie a predvídateľnejšie.
• Vyžaduje zverejnenie vetvy s migrovanými potvrdeniami s príznakom --force pri použití s ​​požiadavkami na stiahnutie.

Tímy sa zvyčajne dohodnú, že vždy použijú rovnakú stratégiu, keď potrebujú zlúčiť zmeny. Môže to byť „čisté“ zlúčenie alebo „čisté“ odovzdanie navrchu, alebo niečo medzi tým, napríklad interaktívne vykonanie odovzdania navrchu(git rebase -i) lokálne pre pobočky nezverejnené vo verejnom úložisku, ale zlúčiť sa pre „verejné“ pobočky.

Tu použijeme zlúčenie.

️Úloha

1. Uistite sa, že kód je v miestnej pobočke master aktualizované zo vzdialeného úložiska.
2. Prepnúť na pobočku feature.
3. Iniciujte zlúčenie s pobočkou master. Konflikt pri zlúčení v dôsledku konkurenčných zmien súboru ci.md.
4. Vyriešte konflikt tak, aby v texte zostal náš zoznam krokov CI aj poznámka o ňom.
5. Zverejnite odovzdanie zlúčenia do vzdialenej vetvy feature.
6. Skontrolujte stav žiadosti o stiahnutie v používateľskom rozhraní GitHub a počkajte, kým sa zlúčenie nevyrieši.

príkazy

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

Dobrá práca!

So zoznamom ste skončili a teraz musíte schváliť žiadosť o stiahnutie master.

️ Úloha: Schváľte žiadosť o stiahnutie „Kontrola krokov“

1. Otvorte požiadavku na stiahnutie.
2. Kliknite na "Zlúčiť žiadosť o stiahnutie".
3. Kliknite na „Potvrdiť zlúčenie“.
4. Kliknite na „Odstrániť vetvu“, pretože ju už nepotrebujeme.

Toto je momentálne vaše úložisko

Chyba produktu

Hovorí sa, že „testovanie možno použiť na preukázanie prítomnosti chýb, ale nikdy nie na preukázanie ich absencie“. Aj keď sme mali testy a neukázali nám žiadne chyby, do výroby sa vkradla zákerná chyba.

V takomto scenári sa musíme postarať o:

• čo je nasadené vo výrobe;
• kód vo vlákne master s chybou, od ktorej môžu vývojári začať novú prácu.

Mám to vrátiť späť alebo to opraviť v ďalšej verzii?

Vrátenie späť je proces nasadenia známej dobrej staršej verzie do produkcie a vrátenia potvrdení, ktoré obsahujú chybu. "Oprava vpred" je pridanie opravy k master a nasadenie novej verzie čo najskôr. Keďže API a databázové schémy sa menia, keď je kód nasadený do produkcie, s nepretržitým doručovaním a dobrým testovacím pokrytím, vrátenie späť je zvyčajne oveľa zložitejšie a riskantnejšie ako oprava v ďalšej verzii.

Keďže vracanie späť v našom prípade nenesie žiadne riziko, pôjdeme touto cestou, pretože nám to umožňuje

• opraviť chybu na produkte čo najskôr;
• vložiť kód master ihneď vhodné na nástup do nového zamestnania.

️Úloha

1. Prepnúť na pobočku master lokálne.
2. Aktualizujte lokálny archív zo vzdialeného archívu.
3. Vráťte potvrdenie PR zlúčenia Kontrola krokov в master.
4. Zverejnite zmeny vo vzdialenom úložisku.

Toto je história archívu s vráteným odovzdaním zlúčenia

príkazy

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

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

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

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

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

️ Autotest

Uistite sa, že ci.md po vrátení odovzdania zlúčenia už neobsahuje text „záludná chyba“.

Opravte zoznam krokov CI a vráťte ho na hlavný

Kompletne sme zrušili príkaz na zlúčenie pobočky. feature. Dobrou správou je, že teraz nemáme žiadnu chybu master. Zlou správou je, že náš vzácny zoznam kontinuálnych integračných krokov je tiež preč. Takže v ideálnom prípade musíme použiť opravu na commity z feature a vrátiť ich do master spolu s opravou.

K problému môžeme pristupovať rôznymi spôsobmi:

• vrátiť potvrdenie, ktoré zruší zlúčenie feature с master;
• presunúť sa zaväzuje z býv feature.

Rôzne vývojové tímy používajú v tomto prípade rôzne prístupy, ale my presunieme užitočné commity do samostatnej vetvy a vytvoríme samostatnú požiadavku na stiahnutie pre túto novú vetvu.

️Úloha

1. Vytvorte vlákno s názvom feature-fix a prepnúť naň.

2. Migrujte všetky potvrdenia z bývalej pobočky feature do nového vlákna. Vyriešte konflikty pri zlučovaní, ktoré sa vyskytli počas migrácie.

   

3. Pridajte regresný test do ci.test.js:

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

4. Spustite testy lokálne, aby ste sa uistili, že nezlyhajú.
5. Odstráňte text „so záludnou chybou“. ci.md.
6. Pridajte testovacie zmeny a zmeny zoznamu krokov do indexu a potvrďte ich.
7. Zverejnite vetvu do vzdialeného úložiska.

Mali by ste skončiť s niečím podobným:

príkazy

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

Vytvorte požiadavku na stiahnutie.

Vytvorte požiadavku na stiahnutie s názvom Oprava funkcie... Inštalácia feature-fix ako "hlavná vetva" a master ako „základná vetva“.
Počkajte, kým sa testy dokončia. Stav testov si môžete pozrieť v spodnej časti PR diskusie.

Uistite sa, že ste nainštalovali master v jeho rozvetviť úložisko Ako „základná pobočka“ nebudem reagovať na žiadosti o zmeny v úložisku materiálov kurzu.

Schválenie žiadosti o stiahnutie „Oprava funkcie“

Ďakujem za opravu! Schváľte zmeny v master zo žiadosti o stiahnutie.

️Úloha

1. Kliknite na "Zlúčiť žiadosť o stiahnutie".
2. Kliknite na „Potvrdiť zlúčenie“.
3. Kliknite na „Odstrániť vetvu“, pretože ju už nepotrebujeme.

To je to, čo by ste v tejto chvíli mali mať.

Gratulujem!

Dokončili ste všetky kroky, ktoré ľudia zvyčajne vykonávajú počas nepretržitej integrácie.

Ak si všimnete nejaké problémy s kurzom alebo viete, ako ho zlepšiť, vytvorte problém v úložiská s učebnými materiálmi. Tento kurz má tiež interaktívna verzia pomocou GitHub Learning Lab ako platformy.

Zdroj: hab.com