A keni mësuar komandat Git, por dëshironi të dini se si realizohet integrimi i vazhdueshëm (Continuous Integration, CI) në praktikë? Apo ndoshta dëshironi të optimizoni veprimet tuaja të përditshme? Ky kurs do t'ju japë aftësi praktike në integrimin e vazhdueshëm duke përdorur një depo në GitHub. Ky kurs nuk është një wizzard që mund ta kaloni thjesht me disa klikime, përkundrazi, do të kryeni të njëjtat veprime që njerëzit në të vërtetë bëjnë në punë, në të njëjtën mënyrë siç e bëjnë ata. Unë do t'ju shpjegoj teorinë ndërsa kaloni hapat përkatës.

Çfarë do të bëjmë?

Me kalimin e kohës, ne do të krijojmë gradualisht një listë të hapave standardë të CI, që është një mënyrë e shkëlqyer për ta memorizuar atë. Me fjalë të tjera, ne do të krijojmë një listë veprimesh që zhvilluesit kryejnë gjatë realizimit të integrimit të vazhdueshëm, duke realizuar integrimin e vazhdueshëm. Gjithashtu, do të përdorim një grup testesh të thjeshta për të afruar procesin tonë CI me realitetin.

Ky GIF tregon në mënyrë diagramatike commit-et në depo tuaj ndërsa përparoni në kurs. Siç e shihni, nuk ka asgjë të komplikuar dhe vetëm thelbësoren.

Do të kaloni skenarë standard për CI:

• Puna mbi një veçori;
• Përdorimi i testeve automatike për të siguruar cilësinë;
• Realizimi i një detyre prioritare;
• Zgjidhja e një konflikti në bashkim (merge conflict);
• Shfaqja e një gabimi në mjedisin e prodhimit.

Çfarë do të mësoni?

Do të jeni në gjendje të përgjigjeni në pyetje të tilla:

• Çfarë është integrimi i vazhdueshëm (CI)?
• Cilat lloje testesh automatike përdoren gjatë CI dhe në përgjigje të cilave veprime ato aktivizohen?
• Çfarë është pull request dhe kur janë të nevojshme?
• Çfarë është zhvillimi i bazuar në teste (Test Driven Development, TDD) dhe si lidhet ai me CI?
• Të realizosh bashkimin (merge) apo të aplikosh ndryshimet lart (rebase)?
• Të rihapesh apo të riparosh në versionin pasardhës?

Në fillim e përktheva gjithçka si "pull request", por më pas vendosa të kthej disa fraza në anglisht në disa vende për të ulur gradën e çmendurisë në tekst. Ndonjëherë do të përdor "sargji programuesi" si veprimin e mrekullueshëm "të commit" atje ku njerëzit në të vërtetë e përdorin atë në punë.

Çfarë është integrimi i vazhdueshëm?

Integrimi i vazhdueshëm, ose CI, është një praktikë teknike që përfshin çdo anëtar të ekipit të integronte kodin e tij në një depo të përbashkët të paktën një herë në ditë, dhe kodi rezultues duhet të kompilohet pa gabime.

Ekzistojnë disa interpretime të ndryshme për këtë term.

Objekti i mosmarrëveshjes është frekuenca e integrimit. Disa pretendojnë se integrimi i kodit një herë në ditë nuk është vërtet i mjaftueshëm dhe se integrimi duhet të jetë i vazhdueshëm. Një shembull është ekipi ku të gjithë marrin kodin e freskët në mëngjes dhe integrohen një herë në mbrëmje. Megjithëse kjo është një kundërshtim i arsyeshëm, në përgjithësi pranohet se definicioni "një herë në ditë" është mjaft praktik, specifik dhe i përshtatshëm për ekipe të ndryshme.

Një kundërshtim tjetër është se C++ nuk është më gjuha e vetme e përdorur gjatë zhvillimit, dhe kërkesa e thjeshtë për kompilim pa gabime si një mënyrë validimi është e dobët. Një grup testesh (për shembull, testet njësore, që ekzekutohen lokal) gjithashtu duhet të përfundojnë me sukses. Në këtë moment, komuniteti ka prirje që një kërkesë e tillë të bëhet e obligueshme, dhe në të ardhmen "kompilimi + testet modulet", duket se do të bëhet standard, nëse kjo nuk ka ndodhur tashmë.

Integrimi i vazhdueshëm dallohet nga dërgesa e vazhdueshme (Continuous Delivery, CD) në atë që nuk kërkon një kandidat për lëshim pas çdo cikli integrimi.

Lista e hapave që do të përdorim gjatë kursit.

1. Merrni kodin e fundit. Krijoni një degë nga master. Filloni të punoni.
2. Krijoni komitete në degën tuaj të re. Kompiloni dhe testoni lokalmente. E kaluat? Kaloni në hapin tjetër. Dështuat? Rregulloni gabimet ose testet dhe provoni përsëri.
3. Dërgoni në depo tuaj të largët ose në degën e largët.
4. Krijoni një kërkesë për të tërhequr. Diskutoni ndryshimet, shtoni më shumë komitete ndërsa vazhdon debati. Bëni që testet të kalojnë në degën e karakteristikave.
5. Bashkoni / ribashkoni komitetet nga master. Bëni që testet të kalojnë në rezultatin e bashkimit.
6. Zhvilloni nga dega e karakteristikave në prodhim.
7. Nëse gjithçka është mirë në prodhim për një periudhë të caktuar kohe, bashkoni ndryshimet në master.

️ Përgatitja

Sigurohuni që të keni softuerin e nevojshëm.

Për të përfunduar këtë kurs, ju nevojitet Node.js dhe klienti Git..

Mund të përdorni çdo klient Git, por unë do të jap komanda vetëm për komandën e rreshtit.

Sigurohuni që keni instaluar klientin Git që mbështet komandën e rreshtit.

Nëse nuk keni instaluar ende klientin Git që mbështet komandën e rreshtit, mund të gjeni udhëzime për instalimin. këtu.

Përgatitni depozitin.

Ju nevojitet të krijoni një kopje personale (fork) të një depo të modelit me kodin për kursin në GitHub. Le të bisedojmë për ta quajtur këtë kopje personale depo të kursit..

E bëtë? Nëse nuk keni ndryshuar cilësimet e parazgjedhura, depoja juaj e kursit me siguri quhet continuous-integration-team-scenarios-students, ndodhet në llogarinë tuaj në GitHub, dhe URL-ja duket kështu

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

Unë do ta quaj këtë adresë thjesht <URL репозитория>.

Këndet si <тут> do të thotë se duhet ta zëvendësoni këtë shprehje me vlerën përkatëse.

Sigurohuni që GitHub actions janë aktivizuar për këtë depo kursi. Nëse ato nuk janë aktivizuar, ju lutem aktivizoni duke klikuar në butonin e madh në mes të faqes, të cilin mund ta vizitoni duke klikuar në Actions në ndërfaqen e GitHub.

Nuk do të jeni në gjendje të përfundoni kursin duke ndjekur udhëzimet e mia nëse GitHub Actions nuk janë aktivizuar.

Ju gjithmonë mund të përdorni aftësinë e GitHub për të shfaqur Markdown për të parë gjendjen aktuale të listës që ne po krijojmë, këtu

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

Për përgjigjet

Megjithëse mënyra më e mirë për të përfunduar këtë kurs është të bëni gjithçka me duar, mund të keni vështirësi.

Nëse ndiheni se nuk e kuptoni se çfarë duhet të bëni dhe nuk mund të vazhdoni, mund të hidhni një sy në degën solution, e cila ndodhet në depozitin tuaj fillestar.
Ju lutem mos kryeni ndonjë bashkim solution në master gjatë kursit. Mund të përdorni këtë degë për të kuptuar se çfarë duhet të bëni, ose për të krahasuar kodin tuaj me atë origjinal, duke shfrytëzuar të gjitha mundësitë që na ofron Git. Nëse jeni plotësisht të humbur, mund ta zëvendësoni plotësisht degën tuaj master me degën solution dhe pastaj të rivendosni direktorinë tuaj të punës në atë hap të kursit që ju nevojitet.

Përdorni këtë vetëm nëse e keni vërtet të nevojshme

Kommity (commit) kodin tuaj

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

Këto komanda

• rishpërndajnë master në master-backup;
• rishpërndajnë solution në master;
• këndojnë (checkout) në një degë të re master dhe riparojnë përmbajtjen e direktorisë së punës;
• krijojnë një degë "solution" nga "master" (e cila më parë ishte "solution") në rast se do t'ju nevojitet në të ardhmen dega "solution".

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

Pas këtyre hapave, mund të përdorni git log master për të zbuluar se cili commit ju nevojitet.
Mund të rivendosni direktorinë tuaj të punës në këtë commit kështu:

git reset --hard

Nëse jeni të kënaqur me rezultatin, në një moment do t'ju nevojitet të publikoni versionin tuaj të depozitës në një depozitë të largët. Mos harroni të tregoni qartë degën e largët kur ta bëni këtë.

git push --force origin master

Ju lutem vini re se ne po përdorim git push --force. Është e vështirë të dëshironi ta bëni këtë shpesh, por kemi një skenar mjaft specifik me një përdorues të depozitës që gjithashtu kupton se çfarë po bën.

Të fillojmë të punojmë

Le të fillojmë të hartojmë listën tonë të hapave CI. Në përgjithësi, ju e filloni këtë hap me tërheqjen e versionit më të fundit të kodit nga depoja e largët, por ne ende nuk kemi depo lokale, kështu që në vend të kësaj e klonojmë nga e largëta.

️ Detyra: përditësoni depozitën lokale, krijoni një degë nga master, filloni të punoni

1. Klononi depozitën e kursit nga <URL репозитория>.
2. Startoni npm install në katalogun e depozitës së kursit; na nevojitet për të instaluar Jest, që po e përdorim për të ekzekutuar testet.
3. Krijoni një degë dhe emërojeni feature. Kaloni në këtë degë.

4. Shtoni kodin e testit në ci.test.js ndërmjet komenteve që kërkojnë ta bëni këtë.

   it('1. tërheq kodin më të fundit', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. shtoni komitetet', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. shtyni në degën e largët me të njëjtin emër', () => {
     expect(/.*push.*/ig.test(fileContents)).toBe(true);
   });
   
   it('4. krijoni një kërkesë për tërheqje dhe vazhdoni të punoni', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. Shtoni tekstin me 4 hapat e para në skedarin ci.md.

   1. Tërhiqni kodin më të fundit. Krijoni një degë nga `master`. Filloni të punoni.    
   2. Krijoni komitete në degën tuaj të re. Ndërtoni dhe testoni lokalisht.  
   Kaloni? Shkoni te hapi tjetër. Dështoni? Rregulloni gabimet ose testet dhe provoni përsëri.  
   3. Shtyni në depozitën tuaj të largët ose degën e largët.  
   4. Krijoni një kërkesë për tërheqje. Diskutoni ndryshimet, shtoni më shumë komitete  
   ndërsa vazhdon diskutimi. Bëni që testet të kalojnë në degën e veçantisë.  

   Komandat

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

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

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

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

Krijoni komitete në degen e re, bëni ndërtimin dhe testimin lokal.

Ne do të konfigurojmë testet që të ekzekutohen para komitimit dhe pastaj do të komitojmë kodin.

Skenarët tipikë kur testet ekzekutohen automatikisht

• Lokal:
  • Përherë ose si përgjigje ndaj ndryshimeve përkatëse në kod;
  • Kur ruhet (për gjuhë interpretuese ose JIT-kompilator);
  • Kur bëhet ndërtimi (kur kërkohet kompaktimi);
  • Kur bëhet komitimi;
  • Kur publikohet në depo të përbashkët.

• Në serverin e ndërtimit (build server) ose në mjedisin e ndërtimit:
  • Kur kodi publikohet në një degë / depo personale.
  • Kodi testuar në këtë degë.
  • Rezultati potencial i bashkimit (zakonisht me master).
  • Si një hap i integrimit të vazhdueshëm / pipeline të shpërndarjes së vazhdueshme

Një rregull i zakonshëm është që sa më shpejt të ekzekutohet një grup testesh, aq më shpesh mund ta lejoni veten që ta lançoni atë. Një shpërndarje tipike për fazat mund të duket kështu.

• Testet modulare të shpejta — gjatë ndërtimit, në pipeline-in CI
• Testet modulare të ngadalta, testet e shpejta komponent dhe testet integruese — gjatë commit-it, në pipeline-in CI
• Testet komponent dhe integruese të ngadalta — në pipeline-in CI
• Testimi i sigurisë, testet e ngarkesës dhe testet e tjera të gjata ose të kushtueshme — në pipeline-in CI/CD, por vetëm në disa modë/faza/pipeline ndërtimi, për shembull, gjatë përgatitjes së kandidatit për rrelease ose gjatë ekzekutimit manual.

️ Detyra

Unë propozoj që fillimisht të ekzekutoni testet manualisht duke përdorur komandën npm test. Pas kësaj, le të shtojmë një git hook për të ekzekutuar testet tona gjatë commit-it. Ka një problem: Git hooks nuk konsiderohen si pjesë e repozitorit dhe prandaj nuk mund të klonohen nga GitHub së bashku me materialet e tjera të kursit. Për të instaluar hook-un, ju duhet të ekzekutoni install_hook.sh ose të kopjoni skedarin repo/hooks/pre-commit në direktorinë lokale .git/hooks/.
Gjatë commit-it do të shihni se testet ekzekutohen dhe ato kontrollojnë nëse disa fjalë kyçe janë të pranishme në listë.

1. Ekzekutoni testet manualisht duke ekzekutuar komandën npm test në dosjen e repozitorit të kursit tuaj. Sigurohuni që testet të kenë përfunduar.
2. Vendosni hook në commit (pre-commit hook) duke ekzekutuar install_hook.sh.
3. Kryeni commit-in e ndryshimeve në repozitorin lokal.
4. Sigurohuni që testet ekzekutohen para commit-it.

Repozitori juaj duhet të duket kështu pas ekzekutimit të këtyre veprimeve.

Komandat

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

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

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

Publikoni kodin në repozitorin e largët ose në degën e largët

Pas përfundimit të punës lokal, zhvilluesit zakonisht e bëjnë kodin e tyre publik për t'u integruar më në fund me të përbashkëtin. Me GitHub, kjo arrihet zakonisht duke publikuar punën ose në një kopje personale të repozitorit (personal fork) ose në një degë private.

• Duke përdor forks, zhvilluesi klonon depozitën e largët të përbashkët, duke krijuar një kopje të saj të largët personale, e njohur gjithashtu si fork. Më pas ai klonon këtë depozitë personale për të punuar me të lokal. Kur puna përfundon dhe commit-et janë krijuar, ai i vendos ato në fork-un e tij, ku ato janë të aksesueshme për të tjerët dhe mund të integrohen në depozitën e përbashkët. Ky qasje zakonisht përdoret në projektet me burim të hapur në GitHub. Përdoret gjithashtu në kursin tim të avancuar [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Një qasje tjetër është të përdoret vetëm një depozitë e vetëm dhe të besohet vetëm dega master e depozitës së përbashkët si "dega e sigurt". Në këtë skenar, zhvilluesit individualë publikojnë kodin e tyre në degët e depozitës së largët, që të tjerët mund ta shohin këtë kod, nëse gjithçka është në rregull, ta bashkojnë me master depozitën e përbashkët.

Në këtë kurs të veçantë ne do të përdorim një proces punimi që përdor degët.

Le të publikojmë kodin tonë.

️ Detyra

• Publikoni ndryshimet në një degë të largët me të njëjtin emër si dega juaj e punës

Komandat

git push --set-upstream origin feature

Krijoni një pull request

Krijoni një pull request me titullin Hapat e rishikimit. Caktoni feature si "head branch" dhe master si "base branch".

Sigurohuni që keni caktuar master në fork-un e depozitës si "base branch", unë nuk do të përgjigjem për kërkesat për ndryshime në depozitën me materialet e kursit.

Në gjuhën e përditshme GitHub "base branch" është dega mbi të cilën themeloni punën tuaj, ndërsa "head branch" është dega që përmban ndryshimet e propozuara.

Diskutoni ndryshimet, shtoni commit-e të reja ndërsa vazhdoni diskutimin

Pull request (PR)

Pull request (PR) është një mënyrë për të diskutuar dhe dokumentuar kodin, si dhe për të kryer një rishikim të kodit. Pull request janë emërtuar në nder të një metode të zakonshme për të integruar ndryshime të veçanta në kodin e përbashkët. Zakonisht, një person klonon depozitën zyrtare të largët të projektit dhe punon mbi kodin lokal. Më pas ai vendos kodin në depozitën e tij të largët personale dhe kërkon nga përgjegjësit e depozitës zyrtare që ta marrin (pull) kodin e tij në dep më të largëta lokale, ku ata rishikojnë dhe ndoshta integrojnë (merge) atë. Ky koncept është i njohur edhe me emra të tjerë, si p.sh., merge request.

Në të vërtetë, nuk është e nevojshme të përdorni funksionin e pull request në GitHub ose në platforma të ngjashme. Ekipet e zhvilluesve mund të përdorin mënyra të tjera komunikimi, duke përfshirë biseda personale, telefonata ose email, por megjithatë ka disa arsye për të përdorur këto pull request në stilin e diskutimeve në forume. Ja disa prej tyre:

• diskutime të organizuara lidhur me ndryshime specifike në kod;
• si një vend për të parë rishikimet e punës së papërfunduar si nga testet automatike ashtu edhe nga kolegët;
• formalizimi i kontrollit të kodit;
• për të vërtetuar më vonë arsyet dhe konsideratat pas një fragmenti të caktuar të kodit.

Në përgjithësi, krijoni pull request kur keni nevojë për të diskutuar diçka ose për të marrë përseritje. Për shembull, nëse jeni duke punuar në një funksion që mund të jetë implementuar në disa mënyra, mund të krijoni një kërkesë për ndryshime edhe para se të shkruani linjën e parë të kodit, për të ndarë idetë tuaja dhe për të biseduar planet tuaja me bashkautorët. Nëse puna është më e thjeshtë, pull request hapet kur diçka tashmë është bërë, e dokumentuar dhe mund të diskutohet. Në disa skenarë, mund të hapni një PR vetëm për arsye të kontrollit të cilësisë: për të nisur testet automatike ose për të iniciuar kontrollin e kodit. Çfarëdo që të vendosni, mos harroni të përmendni @njerëzit, miratimi i të cilëve është i nevojshëm në pull request-in tuaj.

Zakonisht, kur krijoni një PR bëni sa vijon.

• Tregoni se çfarë po sugjeroni të ndryshoni dhe ku.
• Shkruani një përshkrim që shpjegon qëllimin e ndryshimeve. Mund të dëshironi:
  • të shtoni diçka të rëndësishme që nuk është e qartë nga kodi, ose diçka të dobishme për të kuptuar kontekstin, siç janë #bug-et përkatëse dhe numrat e komiteteve;
  • @përmendni të gjithë ata me të cilët dëshironi të filloni të punoni së bashku, ose mund t'i përmendni ata më vonë në komente;
  • të kërkoni ndihmën e kolegëve për diçka ose për të kontrolluar diçka specifike.

Pas hapjes së PR, testet e cilat janë të rregulluara për t'u ekzekutuar në raste të tilla kryhen. Në rastin tonë, do të jetë e njëjta gamë testesh që kemi ekzekutuar lokal, por në një projekt real mund të ketë teste dhe kontrollime të tjera.

Ju lutem prisni derisa të përfundojnë testet. Mund ta shihni statusin e testeve në fund të diskutimit PR në ndërfaqen e GitHub. Vazhdoni kur testet të jenë përfunduar.

️ Shtoni një nëntitull për arbitraritetin e listës së hapave të CI

Lista e përdorur në këtë kurs është arbitrare dhe subjektive, duhet të shtojmë një shënim për këtë.

️ Detyra: krijimi i një pull request për këtë koment

1. Kaloni në degën master.
2. Krijoni një degë me emrin bugfix.
3. Shtoni tekstin e shënimit në fund të skedës ci.md.

   > **GitHub flow** ndonjëherë përdoret si një emër i përkoshëm për një lloj zhvillimi të bazuar në trung  
   kur kodi publikohhet direkt nga degët e veçanta. Kjo listë është thjesht një interpretim  
   që unë përdor në [kurset e mia DevOps](http://redpill.solutions).  
   Tutoriali zyrtar është [këtu](https://guides.github.com/introduction/flow/).

4. Bërni commit ndryshimeve.
5. Publikoni degën bugfix në repozitorin e largët.
6. Krijoni një pull request me emrin Shtimi i një vërejtjeje me degën kryesore bugfix dhe degën bazëmaster.

Sigurohuni që keni caktuar master në fork-un e depozitës si "base branch", unë nuk do të përgjigjem për kërkesat për ndryshime në depozitën me materialet e kursit.

Këtu është si duhet të duket repozitori juaj.

Komandat

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

Pranojeni pull request-in "Shtimi i një vërejtjeje"

️ Detyra

1. Krijoni pull request.
2. Klikoni "Bashko pull request".
3. Klikoni "Konfirmoni bashkimin".
4. Klikoni "Fshini degën", nuk na nevojitet më.

Kjo është një diagramë e komiteteve pas bashkimit.

️ Vazhdoni punën dhe shtoni teste

Bashkëpunimi mbi pull request shpesh sjell nevojën për punë të mëtejshme. Zakonisht është rezultat i kontrollit të kodit ose diskutimit, por në kursin tonë do të simulonim këtë duke shtuar elemente të reja në listën tonë të hapave të CI.

Në integrimin e vazhdueshëm zakonisht aplikohet një mbulim testues. Kërkesat për mbulimin e testeve ndryshojnë dhe zakonisht ndodhen në një dokument me një emër si "udhezimi për autorë" (contribution guidelines). Ne do të veprojmë thjesht dhe do të shtojmë një test për çdo rresht në listën tonë të kontrollit.

Në kryerjen e detyrave, filloni duke u përpjekur të bëni commit teste. Nëse e keni vendosur siç duhet pre-commit hook më parë, testi i sapo shtuar do të ekzekutohet, nuk do të kalojë, dhe asgjë nuk do të bëhet commit. Kthejini vëmendjen: kështu do të mësojmë se testet tona vërtet kontrollojnë diçka. E çuditshme, po qartë se nëse do të fillonim me kodin para testeve, kalimi i testeve mund të do të thoshte se kodi punon siç pritej, ose se testet në të vërtetë nuk kontrollojnë asgjë. Për më tepër, nëse nuk do të kishim shkruar testet fillimisht, mund të ishim plotësisht të harresuar për to, pasi asgjë nuk do të na kujtonte atë.

Zhvillimi përmes testimit (TDD)

TDD sugjeron të shkruani teste para kodit. Procesi i zakonshëm i punës duke përdorur TDD duket kështu.

1. Shtoni testin.
2. Ekzekutoni të gjitha testet dhe kontrolloni që testi i ri nuk kalon me sukses.
3. Shkruani kodin.
4. Ekzekutoni testet, sigurohuni që të gjitha testet kalojnë me sukses.
5. Kryeni refaktorimin e kodit.
6. Përsëritni.

Pasi rezultatet e testeve, të cilat nuk kalohen me sukses, zakonisht shfaqen me të kuqe, dhe ato që kalohen me sukses me të gjelbërt, cikli gjithashtu njihet si "i kuq-i gjelbër-refaktorizim" (red-green-refactor).

️ Detyra

Së pari, përpiquni të bëni një commit me testet dhe t'i lini ato të dështojnë, pastaj shtoni dhe bëni commit tekstin e listës së hapave CI. Do të shihni që testet kalojnë ("të gjelbra").
Pastaj publikoni kodin e ri në repositorin e largët dhe shikoni si ekzekutohen testet në ndërfaqen GitHub në fund të diskutimit të kërkesës për të bërë ndryshime dhe statusi i PR përditësohet.

1. Kaloni në degën feature.

2. Shtoni këto teste në ci.test.js pas thirrjes së fundit it (...);.

   it('5. Bashkoni/rebase commit-et nga master. Bëni që testet të kalojnë në rezultatin e bashkimit.', () => {
     expect(/.*bashkoni.*commit-et.*testet+s+kalojnë.*\/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Publikoni nga dega e veçorive në prodhim.', () => {
     expect(/.*Publikoni.*në+prodhim.*\/ig.test(fileContents)).toBe(true);
   });
   
   it('7. Nëse gjithçka shkon mirë në prodhim për një periudhë të caktuar, bashkoni ndryshimet në master.', () => {
     expect(/.*bashkoni.*në+master.*\/ig.test(fileContents)).toBe(true);
   });

3. Përpiquni të bëni commit me testet. Nëse pre-commit hook-u është instaluar, përpjekja për të bërë commit do të dështojë.
4. Më pas shtoni këtë tekst në ci.md.

   5. Bashkoni/rebase commit-et nga master. Bëni që testet të kalojnë në rezultatin e bashkimit.  
   6. Publikoni nga dega e veçorive me një defekt të fshehur në prodhim.
   7. Nëse gjithçka shkon mirë në prodhim për një periudhë të caktuar, bashkoni ndryshimet në master. 

5. Bëni dhe bëni commit ndryshimet lokalë.
6. Publikoni ndryshimet në degën feature.

Tani duhet të keni diçka të tillë

Komandat

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

Konflikti i bashkimit

Shkoni te kërkesa për të bërë ndryshime Hapat e rishikimit.

Pavarësisht se ne nuk bëmë asgjë të keqe, dhe testet për kodin tonë kaluan me sukses, ne ende nuk mund të kryejmë bashkimin e degës feature dhe master. Kjo është për shkak se një degë tjetër bugfix u bashkua me master ndërsa ne punonim në këtë PR.
Kjo krijon një situatë ku dega e largët master ka një version më të ri, sesa ajo mbi të cilën ne ndërtuam degën tonë. feature. Për shkak të kësaj, ne nuk mund të thjesht rrotullojmë HEAD master deri në fund të degës feature. Në këtë situatë, na nevojitet ose të kryejmë bashkimin (merge), ose të aplikojmë commit-et feature sipër (rebase) master. GitHub në të vërtetë mund të kryejë bashkimin automatik nëse nuk ka konflikte. Megjithatë, në situatën tonë të dy degët kanë ndryshime konkurruese në skedarin ci.md. Kjo situatë njihet si konflikt bashkimi (merge conflict), dhe duhet ta zgjidhim atë manualisht.

Merge ose rebase

Merge

• Krijon një komit të shtuar bashkimi (merge commit) dhe ruan historinë e punës.
  • Ruani komitet origjinal të degëve me shenjat e origjinës dhe autorët.
  • Ruani SHA-të e komiteteve dhe lidhjet e tyre në diskutimet e kërkesave për ndryshime.
• Kërkon një zgjidhje për konfliktet një herë.
• E bën historinë jo lineare.
  • Historia mund të jetë e vështirë për t'u lexuar për shkak të numrit të madh të degëve (ngjason me një kabllo IDE).
  • E komplikon diagnostikimin automatik, për shembull, bën git bisect më pak të dobishëm - ai do të gjejë vetëm komitin e bashkimit.

Rebase

• Riprodhon komitet nga dega aktuale mbi bazën njëri pas tjetrit.
  • Formohen komitete të reja me SHA të reja, duke bërë që komitet në GitHub të lidhen me kërkesat origjinale për ndryshime, por jo me komentet përkatëse.
  • Komitetet mund të ribashkohen dhe të ndryshohen gjatë procesit ose madje të kombinohen në një.
• Mund të kërkohet zgjidhja e shumë konflikteve.
• Lejon ruajtjen e një historie lineare.
  • Historia mund të jetë më e lehtë për t'u lexuar, përveç nëse nuk është tepër e gjatë pa arsye të arsyeshme.
  • Diagnostikimi dhe zgjidhja e problemeve automatikisht janë pak më të lehta: e bën të mundur git bisect, mund të bëjë rrotullime automatike më të qarta dhe të parashikueshme.
• Kërkon publikim të degës me komitet e transferuara me flagun --force kur përdoret me kërkesat për ndryshime.

Në përgjithësi, ekipet bien dakord të përdorin gjithmonë të njëjtën strategji kur u nevojitet të bashkojnë ndryshimet. Kjo mund të jetë një bashkim "të pastër" ose "të pastër" duke vendosur komitetet në sipërfaqe ose diçka ndërmjet, për shembull, duke kryer vendosjen e komiteteve në mënyrë interaktive (git rebase -i) lokal për degët, që nuk janë botuar në një depo të përbashkët, por bashkimi (merge) për degët "publike".

Këtu do të përdorim bashkimin.

️ Detyra

1. Sigurohuni që kodi në degën lokale master të jetë i përditësuar nga repozitori i largët.
2. Kaloni në degën feature.
3. Inicioni bashkimin me degën master. Do të raportoheni për një konflikt bashkimi të lidhur me ndryshime konkurruese në ci.md.
4. Zgjidhni konfliktin në mënyrë që në tekst të mbetet si lista jonë e hapave CI, ashtu edhe vërejtja për të.
5. Publikoni komitin e bashkimit në degën e largët. feature.
6. Kontrolloni statusin e kërkesës për tërheqje në ndërfaqen e përdoruesit GitHub, prisni derisa bashkimi të jetë zgjidhur.

Komandat

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

Punë e shkëlqyer!

Keni përfunduar punën me listën, dhe tani duhet të miratoni kërkesën për tërheqje në master.

️ Detyra: Miratoni kërkesën për tërheqje "Rishikimi i hapave".

1. Hapni kërkesën për tërheqje.
2. Klikoni "Bashko pull request".
3. Klikoni "Konfirmoni bashkimin".
4. Klikoni "Fshi degën", pasi nuk na nevojitet më.

Ky është depoja juaj në këtë moment.

Gabim në prodhim.

Thonë se "testimi mund të përdoret për të treguar prezencën e gabimeve, por kurrë për të treguar mungesën e tyre". Megjithëse kishim teste, dhe ato nuk na treguan ndonjë gabim, një gabim subversiv arriti të hyjë në prodhim.

Në një skenar të tillë, duhet të kujdesemi për:

• atë që është deployuar në prodhim;
• kodin në degën master me gabim, nga i cili zhvilluesit mund të fillojnë punë të re.

Të rikthejmë apo të rregullojmë në versionin e ardhshëm?

"Rikthimi" (rolling back) është deployment i një versioni më të hershëm, të njohur si i saktë, në ambientin e prodhimit dhe të anuloj (revert) komitet që përmbajnë gabimin. "Rregullimi në versionin e ardhshëm" (fixing forward) është shtimi i një rregullimi në master dhe deploymenti i një versioni të ri sa më shpejt të jetë e mundur. Ndërsa API dhe skemat e bazës së të dhënave ndryshojnë me vendosjen e kodit në mjedisin prodhues, me dorëzimin e vazhdueshëm dhe një mbulesë të mirë testimi, rikthimi zakonisht është shumë më i komplikuar dhe më i rrezikshëm se rregullimi në versionin e ardhshëm.

Duke qenë se rikthimi nuk paraqet asnjë rrezik në rastin tonë, do të shkojmë në këtë rrugë, sepse na lejon të

• rregullojmë gabimin në prodhim sa më shpejt të jetë e mundur;
• bëjmë kodin në master menjëherë të gatshëm për të filluar punë të re.

️ Detyra

1. Kaloni në degën master lokalisht.
2. Përditësoni depozitat lokale nga depozita e largët.
3. Anuloni komitin e bashkimit të PR. Hapat e rishikimit në master.
4. Publikoni ndryshimet në depozita e largët.

Ky është historia e depozitës me komitin e bashkimit të anuluar.

Komandat

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

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

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

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

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

️ Vetëkontroll.

Sigurohuni që ci.md nuk përmban më tekstin "sneaky bug" pas anulimit të komitit të bashkimit.

Rregulloni listën e hapave CI dhe kthejeni në master.

Ne e anulonim plotësisht komitin e bashkimit të degës feature. Lajmi i mirë është se tani nuk kemi gabim në masterLajmi i keq është se lista jonë e çmuar e hapave të integrimit të vazhdueshëm ka humbur. Pra, në mënyrë ideale, na nevojitet të zbatojmë një rregullim në komitetet nga feature dhe t'i kthejmë ato në master së bashku me rregullimin.

Ne mund të qasemi në këtë detyrë në mënyra të ndryshme:

• të kthejmë (revert) komitetin, i cili kthen mërgimin feature me master;
• të transferojmë komitetet nga ish feature.

Ekipet e ndryshme të zhvilluesve në këtë rast përdorin qasje të ndryshme, ne do të transferojmë komitetet e dobishme në një degë të veçantë dhe do të krijojmë një pull request të veçantë për këtë degë të re.

️ Detyra

1. Krijoni një degë me emrin feature-fix dhe kaloni në të.

2. Transferoni të gjitha komitetet nga dega e mëparshme feature në degën e re. Zgjidhni konfliktet e mërgimit që janë shfaqur gjatë transferimit.

   

3. Shtoni një test regresioni në ci.test.js:

   it('nuk përmban gabimin e fshehur', () => {
   expect( /.*sneakys+bug.* /gi.test(fileContents)).toBe(false);
   });

4. Mundohuni të ekzekutoni testet lokalish, për të siguruar që ato të mos përfundojnë me sukses.
5. Fshini tekstin " me një gabim të fshehur" në ci.md.
6. Shtoni në indeks ndryshimet e testeve dhe ndryshimet në listën e hapave dhe kryeni ato.
7. Publikoni degën në repositorin e largët.

Si rezultat, duhet të keni diçka që duket si

Komandat

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

Krijoni pull request.

Krijoni një pull request me titullin Rregullimi i veçorisë. Caktoni feature-fix si "dega kryesore", dhe master si "base branch".
Ju lutemi prisni derisa testet të përfundojnë. Mund ta shihni statusin e testeve në fund të diskutimit të PR-së.

Sigurohuni që keni caktuar master në fork-un e depozitës si "base branch", unë nuk do të përgjigjem për kërkesat për ndryshime në depozitën me materialet e kursit.

Miratoni pull request-in "Rregullimi i veçorisë"

Faleminderit për rregullimin! Ju lutem miratoni ndryshimet në master nga pull request.

️ Detyra

1. Klikoni "Bashko pull request".
2. Klikoni "Konfirmoni bashkimin".
3. Klikoni "Fshi degën", pasi nuk na nevojitet më.

Kjo është ajo që duhet të keni deri tani

Gratulacija!

Ju keni kryer të gjitha veprimet që njerëzit zakonisht bëjnë gjatë procesit të integrimit të vazhdueshëm.

Nëse vëreni ndonjë problem me kursin ose dini si ta përmirësoni, krijoni një çështje në repositorin e materialeve të kursit. Ky kurs gjithashtu ka një version interaktiv duke përdorur GitHub Learning Lab si platformë.

Burimi: habr.com