Ar išmokote „Git“ komandas, bet norite įsivaizduoti, kaip nuolatinis integravimas (CI) veikia realybėje? O gal norite optimizuoti savo kasdienę veiklą? Šis kursas suteiks praktinių nuolatinio integravimo naudojant GitHub saugyklą įgūdžių. Šis kursas nėra skirtas vedliui, kurį galite tiesiog spustelėti; priešingai, atliksite tuos pačius veiksmus, kuriuos žmonės iš tikrųjų atlieka darbe, taip pat, kaip jie tai daro. Aš paaiškinsiu teoriją, kai atliksite susijusius veiksmus.

Ką mes darome?

Tobulėdami palaipsniui sudarysime tipiškų CI veiksmų sąrašą, kuris yra puikus būdas prisiminti šį sąrašą. Kitaip tariant, sudarysime sąrašą veiksmų, kurių kūrėjai atlieka nuolat integruodami, nuolat integruodami. Taip pat naudosime paprastą testų rinkinį, kad priartintume CI procesą prie tikrojo.

Šiame GIF schematiškai pavaizduoti įsipareigojimai jūsų saugykloje, kai tęsiate kursą. Kaip matote, čia nėra nieko sudėtingo ir tik būtiniausi.

Atliksite šiuos standartinius CI scenarijus:

• Darbas su funkcija;
• Automatizuotų testų taikymas kokybei užtikrinti;
• Prioritetinės užduoties įgyvendinimas;
• Konfliktų sprendimas sujungiant filialus (jungimo konfliktas);
• Gamybos aplinkoje įvyksta klaida.

ko išmoksi?

Galėsite atsakyti į šiuos klausimus:

• Kas yra nuolatinė integracija (CI)?
• Kokių tipų automatiniai testai naudojami CI ir kokie veiksmai suaktyvinami?
• Kas yra ištraukimo užklausos ir kada jų reikia?
• Kas yra bandomoji plėtra (TDD) ir kaip ji susijusi su CI?
• Ar turėčiau sujungti ar iš naujo nustatyti pakeitimus?
• Atšaukti ar pataisyti kitoje versijoje?

Iš pradžių visur verčiau tokius dalykus kaip „pull requests“, bet dėl ​​to nusprendžiau kai kur grąžinti frazes anglų kalba, kad sumažinčiau teksto beprotybės laipsnį. Kartais vartosiu „programuotojo surzhik“ kaip nuostabų veiksmažodį „įsipareigoti“, kai žmonės jį iš tikrųjų naudoja darbe.

Kas yra nuolatinė integracija?

Nuolatinė integracija, arba CI, yra techninė praktika, kai kiekvienas komandos narys integruoja savo kodą į bendrą saugyklą bent kartą per dieną, o gautas kodas turi būti sukurtas bent be klaidų.

Dėl šio termino kyla nesutarimų

Ginčo objektas yra integracijos dažnumas. Kai kurie teigia, kad kodo sujungimo tik kartą per dieną nepakanka, kad būtų galima nuolat integruotis. Pateikiamas pavyzdys, kai visi ryte paima naują kodą ir vieną kartą vakare integruoja. Nors tai yra pagrįstas prieštaravimas, paprastai manoma, kad kartą per dieną apibrėžimas yra pakankamai praktiškas, konkretus ir tinkamas įvairaus dydžio komandoms.

Kitas prieštaravimas yra tas, kad C++ nebėra vienintelė kalba, naudojama kuriant, ir tiesiog reikalauti be klaidų surinkimo kaip patvirtinimo būdo yra silpnas. Kai kurie testų rinkiniai (pavyzdžiui, vietiniai vienetų testai) taip pat turi būti sėkmingai užbaigti. Šiuo metu bendruomenė siekia, kad tai taptų reikalavimu, o ateityje „build + unit testai“ tikriausiai taps įprasta praktika, jei dar to nepadarė.

Nuolatinė integracija skiriasi nuo nuolatinis pristatymas (Nuolatinis pristatymas, kompaktinis diskas), nes po kiekvieno integravimo ciklo nereikia išleisti kandidato.

Veiksmų, kuriuos naudosime viso kurso metu, sąrašas

1. Įtraukite naujausią kodą. Sukurkite filialą iš master. Pradėti dirbti.
2. Sukurkite įsipareigojimus naujoje šakoje. Kurkite ir išbandykite vietoje. Pereiti? Eikite į kitą veiksmą. Nepavyko? Ištaisykite klaidas arba patikrinkite ir bandykite dar kartą.
3. Perkelkite į savo nuotolinę saugyklą arba nuotolinį filialą.
4. Sukurkite ištraukimo užklausą. Aptarkite pakeitimus, pridėkite daugiau įsipareigojimų, kai diskusija tęsiasi. Tegul testai perduodami funkcijų šakai.
5. Sujungti / iš naujo nustatyti įsipareigojimus iš pagrindinio kompiuterio. Tegul testai perduoda sujungimo rezultatą.
6. Diegti nuo funkcijų šakos iki gamybos.
7. Jei gamyboje kurį laiką viskas gerai, sujunkite pakeitimus į pagrindinį.

️ Pasiruošimas

Įsitikinkite, kad turite tinkamą programinę įrangą

Norėdami lankyti šį kursą, jums reikės Node.js и Priimk klientą.

Galite naudoti bet kurį „Git“ klientą, bet aš pateiksiu tik komandų eilutės komandas.

Įsitikinkite, kad įdiegėte „Git“ klientą, palaikantį komandų eilutę

Jei dar neturite „Git“ kliento, palaikančio komandinę eilutę, galite rasti diegimo instrukcijas čia.

Paruoškite saugyklą

Jums reikės sukurti asmeninę kopiją (šakutę) šablonų saugykla su kurso kodu „GitHub“. Sutikime šią asmeninę kopiją kursų saugykla.

Padaryta? Jei nepakeitėte numatytųjų nustatymų, greičiausiai bus iškviesta kursų saugykla continuous-integration-team-scenarios-students, jis yra jūsų „GitHub“ paskyroje, o URL atrodo taip

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

Aš tiesiog paskambinsiu šiuo adresu <URL репозитория>.

Kampiniai skliaustai kaip <тут> reikš, kad turite pakeisti tokią išraišką atitinkama reikšme.

Įsitikinti, kad „GitHub“ veiksmai įtraukta į šią kursų saugyklą. Jei jie neįjungti, įgalinkite juos spustelėdami didelį puslapio viduryje esantį mygtuką, kurį galite pasiekti „GitHub“ sąsajoje spustelėję Veiksmai.

Negalėsite baigti kurso vadovaudamiesi mano instrukcijomis, jei „GitHub“ veiksmai nebus įjungti.

Visada galite naudoti „GitHub“ galimybę pateikti „Markdown“, kad pamatytumėte dabartinę sąrašo, kurį čia sudarome, būseną

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

Apie atsakymus

Nors geriausias būdas užbaigti šį kursą yra tai padaryti patiems, gali kilti tam tikrų sunkumų.

Jei manote, kad nesuprantate, ką daryti, ir negalite tęsti, galite pažvelgti į temą solution, kuri yra jūsų pradžios saugykloje.
Prašome nesujungti solution в master kurso metu. Galite naudoti šią šaką, kad išsiaiškintumėte, ką daryti, arba palygintumėte savo kodą su autoriaus kodu, naudodami visas „Git“ mums suteiktas galimybes. Jei visiškai pasiklydote, galite visiškai pakeisti savo šaką master ant šakos solution tada iš naujo nustatykite darbo katalogą į reikiamą kurso veiksmą.

Naudokite tai tik tada, kai jums to tikrai reikia

Įveskite savo kodą

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

Šios komandos

• pervadinti master в master-backup;
• pervadinti solution в master;
• atsiskaitymas į naują filialą master ir perrašyti darbo katalogo turinį;
• Sukurkite „sprendimo“ atšaką iš „master“ (kas anksčiau buvo „sprendimas“), jei ateityje jums prireiktų „sprendimo“ šakos.

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

Atlikę šiuos veiksmus galite naudoti git log master kad išsiaiškintumėte, kokio įsipareigojimo jums reikia.
Galite iš naujo nustatyti savo darbo katalogą į šį įsipareigojimą taip:

git reset --hard <the SHA you need>

Jei esate patenkinti rezultatu, tam tikru momentu turėsite paskelbti savo saugyklos versiją nuotolinėje saugykloje. Nepamirškite aiškiai nurodyti nuotolinės šakos, kai tai darote.

git push --force origin master

Atkreipkite dėmesį, kad mes naudojame git push --force. Mažai tikėtina, kad norėsite tai daryti labai dažnai, bet mes turime labai konkretų scenarijų su vienu saugyklos vartotoju, kuris, be to, supranta, ką daro.

Pradeda dirbti

Pradėkime sudaryti savo CI veiksmų sąrašą. Paprastai šį veiksmą pradėtumėte iš nuotolinės saugyklos patikrinę naujausią kodo versiją, tačiau dar neturime vietinės saugyklos, todėl klonuojame ją iš nuotolinės.

️ Užduotis: atnaujinkite vietinę saugyklą, sukurkite filialą iš master, pradėti dirbti

1. Klonuoti kurso saugyklą iš <URL репозитория>.
2. Bėk npm install kursų saugyklos kataloge; Mums jo reikia norint įdiegti „Jest“, kurią naudojame testams vykdyti.
3. Sukurkite filialą ir pavadinkite jį feature. Perjungti į šią temą.

4. Pridėkite testo kodą prie ci.test.js tarp komentarų, prašančių tai padaryti.

   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. Į failą įtraukite tekstą atlikdami pirmuosius 4 veiksmus 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.  

   Komandos

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

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

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

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

Sukurkite įsipareigojimus naujoje šakoje, kurkite ir išbandykite vietoje

Mes nustatysime bandymus, kad jie būtų vykdomi prieš įsipareigodami, o tada patvirtinsime kodą.

Įprasti scenarijai, kai testai vykdomi automatiškai

• Lokaliai:
  • Nuolat arba reaguojant į atitinkamus kodo pakeitimus;
  • Apie taupymą (vertėtoms ar JIT kompiliuotoms kalboms);
  • Surinkimo metu (kai reikia kompiliuoti);
  • Įsipareigojimas;
  • Kai publikuojama bendrinamame saugykloje.

• Sukūrimo serveryje arba kūrimo aplinkoje:
  • Kai kodas paskelbiamas asmeniniame filiale / saugykloje.
  • Šios gijos kodas yra bandomas.
  • Galimas susijungimo rezultatas tikrinamas (dažniausiai su master).
  • Kaip nuolatinis integravimo etapas / nepertraukiamo tiekimo vamzdynas

Paprastai kuo greičiau veikia bandymų rinkinys, tuo dažniau galite sau leisti jį paleisti. Įprastas scenos pasiskirstymas gali atrodyti taip.

• Greiti vienetų bandymai – kūrimo metu, CI vamzdyne
• Lėti vienetų bandymai, greiti komponentų ir integravimo testai – įpareigojant, vyksta CI
• Lėti komponentų ir integravimo testai – vyksta CI
• Saugumo testavimas, apkrovos testavimas ir kiti daug laiko reikalaujantys ar brangūs testai – CI/CD konvejeriuose, bet tik tam tikrais kūrimo režimais/etapais/konvejeriais, pavyzdžiui, ruošiant leidimo kandidatą arba paleidžiant rankiniu būdu.

️Užduotis

Siūlau pirmiausia atlikti testus rankiniu būdu naudojant komandą npm test. Po to pridėkime git kabliuką, kad galėtume atlikti įsipareigojimo testus. Yra vienas trūkumas: „Git“ kabliukai nėra laikomi saugyklos dalimi, todėl jų negalima klonuoti iš „GitHub“ kartu su likusia kurso medžiaga. Norėdami įdiegti kabliuką, turite paleisti install_hook.sh arba nukopijuokite failą repo/hooks/pre-commit į vietinį katalogą .git/hooks/.
Kai įsipareigojate, pamatysite, kad vykdomi testai ir jie patikrina, ar sąraše yra tam tikrų raktinių žodžių.

1. Paleiskite testus rankiniu būdu paleisdami komandą npm test kurso saugyklos aplanke. Patikrinkite, ar bandymai buvo baigti.
2. Bėgdami nustatykite įvykdymo kabliuką (prieš įvykdymo kabliuką). install_hook.sh.
3. Įveskite pakeitimus vietinėje saugykloje.
4. Prieš įsipareigodami įsitikinkite, kad testai yra atlikti.

Atlikus šiuos veiksmus, jūsų saugykla turėtų atrodyti taip.

Komandos

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

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

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

Paskelbkite kodą nuotolinėje saugykloje arba nuotolinėje šakoje

Baigę dirbti vietoje, kūrėjai paprastai padaro savo kodą viešai prieinamą, kad galiausiai jį būtų galima integruoti su visuomene. Naudojant „GitHub“, tai paprastai pasiekiama publikuojant kūrinį asmeninėje saugyklos kopijoje (asmeninėje šakutėje) arba asmeniniame filiale.

• Naudodamas šakutes, kūrėjas klonuoja nuotolinę bendrinamą saugyklą, sukurdamas asmeninę nuotolinę jos kopiją, dar vadinamą šakute. Tada ji klonuoja šią asmeninę saugyklą, kad su ja galėtų dirbti vietoje. Kai darbas baigtas ir įsipareigojimai padaryti, jis įstumia juos į savo šakutę, kur jie yra prieinami kitiems ir gali būti integruoti į bendrą saugyklą. Šis metodas dažniausiai naudojamas atvirojo kodo projektuose „GitHub“. Jis taip pat naudojamas mano išplėstiniame kurse [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Kitas būdas yra naudoti tik vieną nuotolinę saugyklą ir skaičiuoti tik šaką master bendra saugykla „apsaugota“. Pagal šį scenarijų pavieniai kūrėjai paskelbia savo kodą nuotolinės saugyklos filialuose, kad kiti galėtų pažiūrėti šį kodą, jei viskas tvarkoje, sujungti jį su master bendra saugykla.

Šiame konkrečiame kurse naudosime darbo eigą, kurioje naudojami filialai.

Paskelbkime savo kodą.

️Užduotis

• Paskelbkite pakeitimus nuotoliniame filiale tuo pačiu pavadinimu kaip ir jūsų darbo filialas

Komandos

git push --set-upstream origin feature

Sukurkite ištraukimo užklausą

Sukurkite ištraukimo užklausą su pavadinimu Žingsnių peržiūra... Diegti feature kaip „galvos šaka“ ir master kaip "bazinė šaka".

Įsitikinkite, kad įdiegėte master jo šakutė saugyklą Kaip „bazinė šaka“, aš neatsakysiu į prašymus pakeisti kurso medžiagos saugyklą.

„GitHub“ kalboje „bazinė šaka“ yra šaka, kuria remiatės savo darbe, o „pagrindinė šaka“ yra šaka, kurioje yra siūlomi pakeitimai.

Aptarkite pakeitimus, pridėkite naujų įsipareigojimų, kai diskusija tęsiasi

Ištraukti užklausą (PR)

Ištraukti užklausą (PR) yra būdas aptarti ir dokumentuoti kodą, taip pat atlikti kodo peržiūrą. Ištraukimo užklausos pavadintos pagal bendrą atskirų pakeitimų integravimo į bendrą kodą būdą. Paprastai asmuo klonuoja projekto nuotolinę oficialią saugyklą ir dirba su kodu vietoje. Po to jis įdeda kodą į savo asmeninę nuotolinę saugyklą ir paprašo už oficialią saugyklą atsakingų asmenų pasiimti (traukti) jo kodą į savo vietines saugyklas, kur jie peržiūri ir galbūt integruoja (susijungti) jo. Ši sąvoka taip pat žinoma kitais pavadinimais, pvz. sujungimo prašymas.

Iš tikrųjų jums nereikia naudoti „GitHub“ ar panašių platformų ištraukimo užklausos funkcijos. Kūrimo komandos gali naudoti kitus bendravimo būdus, įskaitant bendravimą akis į akį, balso skambučius ar el. paštą, tačiau vis dar yra keletas priežasčių naudoti forumo stiliaus ištraukimo užklausas. Štai keletas iš jų:

• organizuotos diskusijos, susijusios su konkrečiais kodo pakeitimais;
• kaip vieta, kur galima peržiūrėti atsiliepimus apie nebaigtą darbą tiek iš automatinių testuotojų, tiek iš kolegų;
• kodų peržiūrų įforminimas;
• kad vėliau galėtumėte sužinoti priežastis ir svarstymus, slypinčius už šio ar kito kodo.

Paprastai sukuriate ištraukimo užklausą, kai reikia ką nors aptarti arba gauti atsiliepimų. Pavyzdžiui, jei dirbate su funkcija, kurią būtų galima įdiegti daugiau nei vienu būdu, prieš rašydami pirmąją kodo eilutę galite sukurti ištraukimo užklausą, kad galėtumėte pasidalinti idėjomis ir aptarti planus su bendradarbiais. Jei darbas paprastesnis, ištraukimo užklausa atidaroma tada, kai kažkas jau padaryta, įsipareigojama ir gali būti aptarta. Kai kuriais atvejais PR galite atidaryti tik dėl kokybės kontrolės priežasčių: atlikti automatinius testus arba inicijuoti kodo peržiūras. Kad ir ką nuspręstumėte, nepamirškite @paminėti žmonių, kurių patvirtinimo norite gauti savo užklausoje.

Paprastai kurdami PR atliekate šiuos veiksmus.

• Nurodykite, ką ir kur siūlote keisti.
• Parašykite aprašymą, paaiškinantį pakeitimų tikslą. Galbūt norėsite:
  • pridėkite ką nors svarbaus, kas nėra akivaizdu iš kodo, arba ką nors naudingo norint suprasti kontekstą, pvz., atitinkamus #klaidų ir įsipareigojimų skaičius;
  • @paminėkite visus, su kuriais norite pradėti dirbti, arba galite @paminėti juos komentaruose vėliau;
  • paprašykite kolegų padėti kuo nors arba patikrinti ką nors konkretaus.

Kai atidarote PR, atliekami testai, sukonfigūruoti tokiais atvejais. Mūsų atveju tai bus tas pats testų rinkinys, kurį atlikome vietoje, tačiau realiame projekte gali būti papildomų bandymų ir patikrų.

Palaukite, kol bandymai bus baigti. Testų būseną galite pamatyti „GitHub“ sąsajos PR diskusijos apačioje. Tęskite, kai bandymai bus baigti.

️ Pridėkite pastabą apie CI veiksmų sąrašo atsitiktinumą

Šiame kurse naudojamas sąrašas yra savavališkas ir subjektyvus, todėl turėtume pridėti pastabą apie tai.

️ Užduotis: sukurkite šio komentaro ištraukimo užklausą

1. Perjungti į filialą master.
2. Sukurkite filialą pavadinimu bugfix.
3. Pridėkite pastabos tekstą failo pabaigoje 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. Įsipareigokite atlikti pakeitimus.
5. Paskelbkite temą bugfix į nuotolinę saugyklą.
6. Sukurkite ištraukimo užklausą pavadinimu Pridedamas pastaba su galvos šaka bugfix ir bazinė šakamaster.

Įsitikinkite, kad įdiegėte master jo šakutė saugyklą Kaip „bazinė šaka“, aš neatsakysiu į prašymus pakeisti kurso medžiagos saugyklą.

Taip turėtų atrodyti jūsų saugykla.

Komandos

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

Patvirtinti ištraukimo užklausą „Pridėti pastabą“

️Užduotis

1. Sukurkite ištraukimo užklausą.
2. Spustelėkite „Sujungti ištraukimo užklausą“.
3. Spustelėkite „Patvirtinti sujungimą“.
4. Spustelėkite „Ištrinti šaką“, mums jos nebereikia.

Tai yra įsipareigojimų po sujungimo diagrama.

️ Dirbkite toliau ir pridėkite testus

Bendradarbiavimas pagal traukimo užklausą dažnai sukelia papildomo darbo. Paprastai tai yra kodo peržiūros arba diskusijos rezultatas, tačiau savo kurse mes tai modeliuosime įtraukdami naujų elementų į CI veiksmų sąrašą.

Nuolatinis integravimas paprastai apima tam tikrą bandymo aprėptį. Bandymų aprėpties reikalavimai skiriasi ir paprastai pateikiami dokumente, vadinamame „įnašo gairėmis“. Mes stengsimės tai padaryti paprastai ir į savo kontrolinį sąrašą įtrauksime kiekvienos eilutės testą.

Vykdydami užduotis, pirmiausia pabandykite atlikti testus. Jei įdiegėte teisingai pre-commit kabliukas anksčiau, naujai pridėtas testas bus paleistas, nepavyks ir nieko nebus. Atminkite, kad taip mes žinome, kad mūsų bandymai iš tikrųjų kažką išbando. Įdomu tai, kad jei mes pradėtume nuo kodo prieš bandymus, testų išlaikymas gali reikšti, kad kodas veikė taip, kaip tikėtasi, arba kad testai iš tikrųjų nieko nebandė. Be to, jei nebūtume rašę testų iš pradžių, galbūt būtume juos visai pamiršę, nes niekas mums to nebūtų priminęs.

Bandymu pagrįsta plėtra (TDD)

TDD rekomenduoja prieš kodą rašyti testus. Įprasta darbo eiga naudojant TDD atrodo taip.

1. Pridėkite testą.
2. Atlikite visus testus ir įsitikinkite, kad naujas testas nepavyko.
3. Parašykite kodą.
4. Atlikite testus, įsitikinkite, kad visi testai yra sėkmingi.
5. Pertvarkykite savo kodą.
6. Pakartokite.

Kadangi nesėkmingų testų rezultatai dažniausiai rodomi raudonai, o išlaikyti – žalia spalva, ciklas taip pat žinomas kaip raudonai žalios spalvos refaktorius.

️Užduotis

Pirmiausia pabandykite atlikti testus ir leisti jiems nepavykti, tada pridėkite ir patvirtinkite patį CI veiksmų sąrašo tekstą. Pamatysite, kad testai praeina ("žalia").
Tada paskelbkite naują kodą nuotolinėje saugykloje ir stebėkite, kaip bandymai vykdomi „GitHub“ sąsajoje diskusijos ištraukimo užklausos apačioje ir PR būsenos atnaujinimas.

1. Perjungti į filialą feature.

2. Pridėkite šiuos testus prie ci.test.js po paskutinio skambučio 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. Pabandykite atlikti testus. Jeigu pre-commit kabliukas įdiegtas, bandymas atlikti nepavyks.
4. Tada pridėkite šį tekstą prie 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. Atlikite ir atlikite pakeitimus vietoje.
6. Paskelbkite pakeitimus filiale feature.

Dabar turėtumėte turėti kažką panašaus

Komandos

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

Sujungti konfliktą

Eikite į „Keisti užklausą“. Žingsnių peržiūra.

Nors mes nepadarėme nieko blogo ir mūsų kodo testai buvo sėkmingi, vis tiek negalime sujungti šakos feature и master. Taip yra dėl to, kad kita gija bugfix buvo sujungtas su master kol dirbome su šiuo viešuoju ryšiu.
Tai sukuria situaciją, kai nuotolinis filialas master turi naujesnę versiją nei ta, kuria rėmėme filialą feature. Dėl to negalime tiesiog atsukti HEAD master iki sriegio galo feature. Esant tokiai situacijai, turime arba sujungti, arba taikyti įsipareigojimus feature rebase master. „GitHub“ iš tikrųjų gali atlikti automatinį sujungimą, jei nėra konfliktų. Deja, mūsų situacijoje abiejuose filialuose yra konkuruojančių failo pakeitimų ci.md. Ši situacija vadinama sujungimo konfliktu, todėl turime ją išspręsti rankiniu būdu.

Sujungti arba iš naujo nustatyti

eiti

• Sukuria papildomą sujungimo įsipareigojimą ir išsaugo darbo istoriją.
  • Išsaugo originalius filialų įsipareigojimus su originaliomis laiko žymomis ir autoriais.
  • Išsaugo įsipareigojimų SHA ir susieja su jais diskusijose dėl pakeitimų užklausų.
• Reikia vienkartinio konflikto sprendimo.
• Padaro istoriją nelinijišką.
  • Istoriją gali būti sunku perskaityti dėl daugybės šakų (primena IDE kabelį).
  • Apsunkina automatinį derinimą, pvz. git bisect mažiau naudinga – jis ras tik sujungimo įsipareigojimą.

Pakartoti

• Vieną po kito atkuria įsipareigojimus iš dabartinės šakos ant pagrindinės šakos.
  • Sugeneruojami nauji įsipareigojimai su naujais SHA, todėl „GitHub“ įsipareigojimai atitinka pradines ištraukimo užklausas, bet ne atitinkamus komentarus.
  • Įsipareigojimai gali būti perjungti ir modifikuoti proceso metu arba net sujungti į vieną.
• Gali tekti išspręsti kelis konfliktus.
• Leidžia išlaikyti linijinę istoriją.
  • Istoriją gali būti lengviau skaityti, jei ji nėra per ilga be jokios pagrįstos priežasties.
  • Automatinis derinimas ir trikčių šalinimas yra šiek tiek lengvesnis: tai įmanoma git bisect, automatinis atšaukimas gali būti aiškesnis ir labiau nuspėjamas.
• Reikia paskelbti filialą su perkeltais įsipareigojimais su vėliavėle --force kai naudojamas su traukimo užklausomis.

Paprastai komandos sutinka visada naudoti tą pačią strategiją, kai reikia sujungti pakeitimus. Tai gali būti „grynas“ sujungimas arba „grynas“ įsipareigojimas viršuje, arba kažkas tarp jų, pavyzdžiui, interaktyvus įsipareigojimas viršuje (git rebase -i) vietoje filialams, kurie nepaskelbti viešojoje saugykloje, bet sujungiami „viešiesiems“ filialams.

Čia mes naudosime sujungimą.

️Užduotis

1. Įsitikinkite, kad kodas yra vietiniame filiale master atnaujinta iš nuotolinės saugyklos.
2. Perjungti į filialą feature.
3. Pradėkite sujungimą su filialu master. Sujungimo konfliktas dėl konkuruojančių pakeitimų ci.md.
4. Išspręskite konfliktą, kad tekste liktų ir mūsų CI veiksmų sąrašas, ir pastaba apie tai.
5. Paskelbkite sujungimo įsipareigojimą nuotoliniame filiale feature.
6. Patikrinkite ištraukimo užklausos būseną „GitHub“ vartotojo sąsajoje ir palaukite, kol sujungimas bus išspręstas.

Komandos

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

Puikus darbas!

Baigėte sudaryti sąrašą ir dabar turite patvirtinti įtraukimo užklausą master.

️ Užduotis: Patvirtinti ištraukimo užklausą „Žingsnių peržiūra“

1. Atidarykite ištraukimo užklausą.
2. Spustelėkite „Sujungti ištraukimo užklausą“.
3. Spustelėkite „Patvirtinti sujungimą“.
4. Spustelėkite „Ištrinti filialą“, nes mums jo nebereikia.

Šiuo metu tai yra jūsų saugykla

Produkto klaida

Sakoma, kad „testavimas gali būti naudojamas norint parodyti klaidų buvimą, bet niekada neparodyti jų nebuvimo“. Nors atlikome testus ir jie neparodė jokių klaidų, gamyboje įsivėlė klastinga klaida.

Esant tokiam scenarijui, turime pasirūpinti:

• kas yra naudojama gamyboje;
• kodas gijoje master su klaida, nuo kurios kūrėjai gali pradėti naują darbą.

Ar turėčiau atšaukti ar pataisyti ją kitoje versijoje?

Atšaukimas – tai žinomos geros ankstesnės versijos diegimas gamybinėje versijoje ir įsipareigojimų, kuriuose yra klaida, grąžinimas. „Pataisymas į priekį“ yra pataisymo pridėjimas prie master ir kuo greičiau įdiegti naują versiją. Kadangi API ir duomenų bazių schemos keičiasi, kai kodas yra diegiamas gamyboje, o nuolatinis pristatymas ir geras bandymų aprėptis, paprastai grąžinti atgal yra daug sudėtingiau ir rizikingiau nei taisyti kitoje versijoje.

Kadangi riedėjimas atgal mūsų atveju nekelia jokios rizikos, eisime šiuo keliu, nes tai leidžia

• kuo greičiau ištaisykite gaminio klaidą;
• įvesti kodą master iš karto tinkamas naujo darbo pradžiai.

️Užduotis

1. Perjungti į filialą master lokaliai.
2. Atnaujinkite vietinę saugyklą iš nuotolinės saugyklos.
3. Grąžinti PR sujungimo įsipareigojimą Žingsnių peržiūra в master.
4. Paskelbti pakeitimus nuotolinėje saugykloje.

Tai saugyklos, kurios sujungimo įsipareigojimas atšauktas, istorija

Komandos

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

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

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

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

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

️ Savęs patikrinimas

Įsitikinti, kad ci.md atšaukus sujungimo įsipareigojimą, nebėra teksto „netikėta klaida“.

Pataisykite CI veiksmų sąrašą ir grąžinkite jį pagrindiniam kompiuteriui

Mes visiškai atšaukėme filialo sujungimo įsipareigojimą. feature. Geros naujienos yra tai, kad dabar neturime klaidų master. Bloga žinia ta, kad mūsų brangus nuolatinės integracijos veiksmų sąrašas taip pat dingo. Taigi, idealiu atveju, pataisymą turime pritaikyti įsipareigojimams nuo feature ir grąžinti juos master kartu su pataisymu.

Mes galime spręsti problemą įvairiais būdais:

• grąžinti įsipareigojimą, kuris anuliuoja sujungimą feature с master;
• perkelti įsipareigoja iš buvusio feature.

Šiuo atveju skirtingos kūrimo komandos taiko skirtingus metodus, tačiau naudingus įsipareigojimus perkelsime į atskirą šaką ir sukursime atskirą šios naujos šakos atsisiuntimo užklausą.

️Užduotis

1. Sukurkite giją pavadinimu feature-fix ir pereiti prie jo.

2. Perkelti visus įsipareigojimus iš buvusios šakos feature į naują giją. Išspręskite sujungimo konfliktus, įvykusius perkėlimo metu.

   

3. Pridėkite regresijos testą ci.test.js:

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

4. Vykdykite bandymus vietoje, kad įsitikintumėte, jog jie nepasiduoda.
5. Pašalinkite tekstą „su slapta klaida“. ci.md.
6. Pridėkite bandomuosius pakeitimus ir žingsnių sąrašo pakeitimus į indeksą ir patvirtinkite juos.
7. Paskelbkite filialą nuotolinėje saugykloje.

Turėtumėte baigti kažką panašaus į šį:

Komandos

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

Sukurkite ištraukimo užklausą.

Sukurkite ištraukimo užklausą su pavadinimu Funkcijos taisymas... Diegti feature-fix kaip „galvos šaka“ ir master kaip "bazinė šaka".
Palaukite, kol bus baigti bandymai. Testų būseną galite pamatyti PR diskusijos apačioje.

Įsitikinkite, kad įdiegėte master jo šakutė saugyklą Kaip „bazinė šaka“, aš neatsakysiu į prašymus pakeisti kurso medžiagos saugyklą.

Patvirtinti ištraukimo užklausą „Funkcijos taisymas“

Ačiū už pataisymą! Patvirtinkite pakeitimus master iš traukimo prašymo.

️Užduotis

1. Spustelėkite „Sujungti ištraukimo užklausą“.
2. Spustelėkite „Patvirtinti sujungimą“.
3. Spustelėkite „Ištrinti filialą“, nes mums jo nebereikia.

Štai ką šiuo metu turėtumėte turėti.

Sveikiname!

Atlikote visus veiksmus, kuriuos žmonės paprastai atlieka nuolat integruodami.

Jei pastebite kokių nors kurso problemų arba žinote, kaip jį patobulinti, sukurkite problemą saugyklos su kurso medžiaga. Šis kursas taip pat turi interaktyvi versija naudojant GitHub Learning Lab kaip platformą.

Šaltinis: www.habr.com