Keni studiuar komandat Git, por dëshironi të kuptoni se si ndodh integrimi i vazhdueshëm (Continuous Integration, CI) në realitet? Ose ndoshta dëshironi të optimizoni veprimet tuaja të përditshme? Ky kurs do t'ju japë aftësi praktike të integrimit të vazhdueshëm duke përdorur një depo në GitHub. Kursi nuk është menduar si një vizard që mund ta klikohet thjesht; përkundrazi, do të bëni ato veprime që njerëzit vërtet bëjnë në punë, në të njëjtën mënyrë që ata i bëjnë ato. Unë do të shpjegoj teorinë ndërsa kaloni hapat përkatës.

Çfarë do të bëjmë?

Gjatë avancimit, ne do të krijojmë gradualisht një listë hapash tipikë të CI, e cila është një mënyrë e shkëlqyer për ta mbajtur mend këtë listë. Në fjalë të tjera, ne do të krijojmë një listë veprimesh që zhvilluesit bëjnë ndërsa kryejnë integrimin e vazhdueshëm. Po ashtu, ne do të përdorim një grup të thjeshtë testesh për ta afruar procesin tonë të CI me realitetin.

Ky GIF tregon në mënyrë skematike komitetet në depo tuaj ndërsa avanconi 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ë karakteristikë;
• Përdorimi i testeve automatike për të siguruar cilësinë;
• Realizimi i një detyre me prioritet;
• Zgjidhja e një konflikti në bashkim (merge conflict);
• Shfaqja e një gabimi në ambientin e prodhimit.

Çfarë do të mësoni?

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

• Çfarë është integrimi i vazhdueshëm (CI)?
• Cilat janë llojet e testeve automatike që përdoren gjatë CI, dhe si aktivohet çdo veprim?
• Çfarë është kërkesa për të tërhequr (pull request) dhe kur janë të nevojshme?
• Çfarë është zhvillimi përmes testeve (Test Driven Development, TDD) dhe si lidhet ai me CI?
• Të kryesh bashkimin (merge) apo të aplikosh ndryshimet sipër (rebase)?
• Të kthehesh pas apo të rregullosh në versionin e ardhshëm?

Fillimisht, unë përkthenj gjëra si "pull request", por përfundimisht vendosa të rikthej frazat në anglisht në disa vende për të ulur gradin e çmendurisë në tekst. Ndonjëherë do të përdor "gjuha e zhvilluesve" siç është gjuha e mrekullueshme "komit" aty ku njerëzit vërtet e përdorin atë në punë.

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

Integrimi i vazhdueshëm, ose CI, është një praktikë teknike në të cilën çdo anëtar i ekipit integron kodin e tij në depo të përbashkët të paktën një herë në ditë, me kusht që kodi përfundimtar të ndodhet të paktën pa gabime.

Ka kërkesa të ndryshme për këtë term

Subjekti i diskutimit është frekuenca e integrimit. Disa pretendojnë se të bashkosh kodin vetëm një herë në ditë nuk është në të vërtetë integrim i vazhdueshëm. Një shembull është një ekip ku të gjithë marrin kodin e freskët në mëngjes dhe integrohen një herë në mbrëmje. Megjithatë, ndërsa është një kundërshtim i arsyeshëm, ende besohet se definicioni "një herë në ditë" është mjaft praktik, konkret, dhe përshtatet për ekipe të ndryshme në madhësi.

Një tjetër kundërshtim është se C++ nuk është ende gjuha e vetme që përdoret në zhvillim, dhe kërkesa e thjeshtë për ndërtim pa gabime, si një mënyrë vlefshmërie, është e dobët. Një grup i caktuar testesh (për shembull, teste njësish (unit) që kryhen në nivel lokal) gjithashtu duhet të përfundojë me sukses. Në këtë moment, komuniteti prirë të mbështesë që ky kërkesë të bëhet e detyrueshme, dhe në të ardhmen, "ndërtimi + testet njësish", duket se do të bëhet standard, nëse kjo nuk ka ndodhur tashmë.

Integrimi i vazhdueshëm dallon nga dorëzimi i vazhdueshëm (Continuous Delivery, CD) sepse 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 më të fundit. Krijoni një degë nga master. Filloni të punoni.
2. Krijoni komitete në degën tuaj të re. Ndërtoni dhe testoni në lokal. Kaloni? Shkoni në hapin tjetër. Dështoni? Rregulloni gabimet ose testet dhe provoni përsëri.
3. Shtyni në depo tuaj të largët ose në degën tuaj të largët.
4. Krijoni një kërkesë për të tërhequr. Diskutoni ndryshimet, shtoni më shumë komitete ndërsa diskutimi vazhdon. Bëni që testet të kalojnë në degën e karakteristikës.
5. Bashkoni/rebase komitetet nga master. Bëni që testet të kalojnë në rezultatin e bashkimit.
6. Shpërndani nga dega e karakteristikës në prodhim.
7. Nëse gjithçka është mirë në prodhim për një periudhë kohe, bashkoni ndryshimet me master.

️ Përgatitja

Sigurohuni që keni software të nevojshëm

Për ta kaluar këtë kurs, do t'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 linjës.

Sigurohuni që keni instaluar një klient Git që mbështet komandën e linjës

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

Përgatitni depo

Ju nevojitet të krijoni një kopje personale (fork) të depo-së-shtjellë me kodin për kursin në GitHub. Le të marrim vesh ta quajmë këtë kopje personale depo e kursit.

E bëtë? Nëse nuk keni ndryshuar cilësimet e paracaktuara, depoja juaj e kursit ndoshta quhet skenarët-e-ekipit-të-integrimit-të-vazhdushëm-studentët, ndodhet në llogarinë tuaj në GitHub, dhe URL-ja duket kështu

https://github.com//skenarët-e-ekipit-të-integrimit-të-vazhdushëm-studentët

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

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

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

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

Mund të përdorni gjithmonë aftësinë e GitHub për të shfaqur Markdown për të parë gjendjen aktuale të listës që po e shkruajmë, këtu

https://github.com//skenarët-e-ekipit-të-integrimit-të-vazhdushëm-studentët/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 dorë, mund të hasni disa vështirësi.

Nëse ndiheni se nuk e kuptoni se çfarë duhet të bëni dhe nuk mund të vazhdoni, mund të shqyrtoni degën solution, e cila është në repozitorin tuaj të fillimit.
Ju lutem, mos bëni bashkimin solution në master gjatë kursit. Mund të përdorni këtë degë për të kuptuar se çfarë të bëni, ose për të krahasuar kodin tuaj me atë të autorit, duke përdorur të gjitha mundësitë që na ofron Git. Nëse jeni plotësisht të humbur, mund ta zëvendësoni krejtësisht degën tuaj master me degën solution dhe pastaj të rivendosni direktorin tuaj të punës në hapin e kursit që ju nevojitet.

Përdorni këtë vetëm nëse ju nevojitet me të vërtetë.

Bëni commit për kodin tuaj

git add .
git commit -m "Backup i punës sime"

Këto komanda

• ridemonstrojnë master në master-backup;
• ridemonstrojnë solution në master;
• kalojnë (checkout) në një degë të re master dhe shkruajnë përmbajtjen e direktorisë së punës;
• krijojnë degën "solution" nga "master" (e cila më parë ishte "solution") në rast se ju nevojitet në të ardhmen degë "solution".

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

Pas këtyre veprimeve mund të përdorni git log master për të bërë të qartë se cilin commit ju duhet.
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ë çast ju nevojitet të publikoni versionet tuaja të repozitorit në një repozitor të largët (remote). Mos harroni të specifikoni qartë degën e largët kur ta bëni këtë.

git push --force origin master

Ju lutem, vini re se përdorim git push --force.Padyshim që nuk do të dëshironi ta bëni këtë shpesh, por kemi një skenar shumë specifik me një përdorues të repozitorit, i cili gjithashtu, e kupton atë që po bën.

Po fillojmë të punojmë

Të fillojmë të përgatisim listën tonë të hapave CI. Normalisht supozoni këtë hap me nxjerrjen e versionit më të fundit të kodit nga repozitori i largët, por ne ende nuk kemi një repozitor lokal, kështu që në vend të kësaj e klonojmë nga repozitori i largët.

️ Detyra: përditësoni repozitorin lokal, krijoni një degë nga master, filloni punën

1. Klononi repozitorin e kursit nga <URL репозитория>.
2. Perfshi npm install në katalogun e repozitorit të kursit; na nevojitet për të instaluar Jest, që 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. nxirni kodin më të fundit', () => {
     expect(/.*pull.*/ig.test(fileContents)).toBe(true);
   });
   
   it('2. shtoni commit', () => {
     expect(/.*commit.*/ig.test(fileContents)).toBe(true);
   });
   
   it('3. shtypni 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ë tërheqje dhe vazhdoni të punoni', () => {
     expect(/.*pulls+request.*/ig.test(fileContents)).toBe(true);
   });

5. Shtoni tekstin me 4 hapet e para në skedën ci.md.

   1. Shtyni kodin më të fundit. Krijoni një degë nga `master`. Filloni punën.    
   2. Krijoni commit në degën tuaj të re. Nxehni dhe testoni lokal.  
   Kaloni? Shkoni te hapi tjetër. Dështoni? Rregulloni gabimet ose testet dhe provoni përsëri.  
   3. Shtypni në repozitorin tuaj të largët ose degën e largët.  
   4. Krijoni një kërkesë tërheqje. Diskutoni ndryshimet, shtoni më shumë commits  
   dhe diskursi vazhdon. Bëni që testet të kalojnë në degën e veçorive.  

   Ekipet

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

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

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

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

Krijoni commits në degën e re, ndërtoni dhe testoni lokal.

Po përgatitemi të konfigurojmë testet që të ekzekutohen para commit-it, dhe pastaj të bëjmë commit për kodin.

Skenerë tipikë, kur testet ekzekutohen automatikisht

• Lokalisht:
  • Në mënyrë të vazhdueshme ose në përgjigje të ndryshimeve përkatëse të kodit;
  • Kur ruhet (për gjuhët interpretuese ose JIT-kompilim);
  • Kur ndërtohet (kur është e nevojshme kompilimi);
  • Kur bëhet commit;
  • Kur publikohet në një repozitor të përbashkët.

• Në serverin e ndërtimit (build server) ose në mjedisin e ndërtimit:
  • Kur kodi publikohet në një degë / repozitor personal.
  • Kodi testohet në këtë degë.
  • Rezultati potencial i bashkimit testohet (zakonisht me master).
  • Si një fazë e integrimit të vazhdueshëm / procesit të ofrimit të vazhdueshëm

Si zakonisht, sa më shpejt të ekzekutohen testet, aq më shpesh mund të lejoni që ato të drejtohen. Një shpërndarje tipe në faza mund të duket kështu.

• Testet modulare të shpejta — gjatë ndërtimit, në procesin CI
• Testet modulare të ngadalta, testet komponentë të shpejta dhe testet integruese — gjatë angazhimit, në procesin CI
• Testet komponentë dhe integruese të ngadalta — në procesin CI
• Testimi i sigurisë, testet e ngarkesës dhe teste të tjera të gjata ose të kushtueshme — në proceset CI/CD, por vetëm në disa mënyra/faza/procesesh ndërtimi, për shembull, gjatë përgatitjes së kandidatit për lëshim ose kur fillohet manualisht.

️ Detyra

Sugjeroj të fillojmë duke ekzekutuar testet manualisht, duke përdorur komandën npm test. Më pas, le të shtojmë hook git për të drejtuar testet tona gjatë angazhimit. Ka një pengesë: Git hooks nuk janë pjesë e depozitës dhe prandaj nuk mund të klonohen nga GitHub së bashku me materialet e tjera të kursit. Për të instaluar hook, ju duhet të ekzekutoni install_hook.sh ose të kopjoni skedarin repo/hooks/pre-commit në direktorinë lokale .git/hooks/.
Kur angazhoheni do të shihni që testet ekzekutohen dhe kontrollojnë nëse fjalët e caktuara janë të pranishme në listë.

1. Ekzekutoni testet manualisht, duke përdorur komandën npm test në direktorinë e depozitës së kursit tuaj. Sigurohuni që testet të kenë përfunduar.
2. Vendosni hook për angazhimin (pre-commit hook), duke ekzekutuar install_hook.sh.
3. Angazhoni ndryshimet në depozitën tuaj lokale.
4. Sigurohuni që testet të ekzekutohen para angazhimit.

Depozita juaj duhet të duket kështu pas këtyre veprimeve.

Ekipet

# Установите 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ë depozitën e largët ose në degën e largët

Pas përfundimit të punës lokale, zhvilluesit zakonisht e bëjnë kodin e tyre publik për ta integruar në të ardhmen me të përbashkëtin. Me ndihmën e GitHub, kjo zakonisht arrihet duke publikuar punën ose në një kopje personale të depozitës (personal fork, fork), ose në një degë personale.

• Kur përdoren fork, zhvilluesi klonon depozitën e largët të përbashkët, duke krijuar një kopje personale të saj të largët, e njohur gjithashtu si fork. Më pas, ai klonon këtë depo të personalizuar për të punuar me të lokal. Kur puna të jetë përfunduar dhe komitet të jenë krijuar, ai i vendos në forkun e tij, ku ato janë të disponueshme 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. Ai gjithashtu përdoret në kursin tim të avancuar [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Një qasje tjetër është të përdorim vetëm një depo të largët dhe të konsiderojmë vetëm degën master të depozitës së përbashkët "të mbrojtur". Në këtë skenar, zhvilluesit e veçantë publikojnë kodin e tyre në degët e depozitës së largët, kështu që të tjerët mund ta shohin këtë kod, dhe nëse gjithçka shkon mirë, ta integrojnë me master depozitën e përbashkët.

Në këtë kurs të veçante do të përdorim një proces pune që përdor degë.

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

Ekipet

git push --set-upstream origin feature

Krijoni pull request

Krijoni pull request me emrin Steps review. Vendosni feature si "head branch" dhe master si "base branch".

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

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

Diskutoni ndryshimet, shtoni komitete të reja ndërkohë që 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ë kontroll të kodit (code review). Pull request janë emërtuar sipas një mënyre të zakonshme për të integruar ndryshime të veçanta në kodin e përbashkët. Zakonisht, një person klonon depozitën e largët zyrtare të projektit dhe punon në kodin lokal. Më pas, ai e vendos kodin në depozitën e tij personale të largët dhe kërkon nga ata që janë përgjegjës për depozitën zyrtare të marrinpull) kodin e tij në depozitat e tyre lokale, ku e kontrollojnë dhe ndoshta e integrojnëbashkë). Ky koncept është i njohur edhe me emra të tjerë, siç është merge request.

Në të vërtetë nuk është e nevojshme të përdorni funksionin pull request të GitHub ose platformave të ngjashme. Grupi i zhvilluesve mund të përdorë mjete të tjera kommunikimi, duke përfshirë biseda personale, thirrje telefonike ose email, por gjithsesi ka disa arsye për të përdorur pull requests të tilla në stilin e diskutimeve në forum. Ja disa prej tyre:

• diskutime të organizuara që lidhen me ndryshime të caktuara në kod;
• si një vend për të parë komente për punën e papërfunduar si nga testet automatike, ashtu edhe nga kolegët;
• formalizimi i rishikimeve të kodit;
• në mënyrë që më vonë të mund të kuptoni arsyet dhe motivet e pr خلف parave të caktuara të kodit.

Zakonisht krijoni një pull request kur keni nevojë të diskutoni diçka ose të merrni feedback. Për shembull, nëse po punoni në një funksion që mund të implementohet në disa mënyra, mund të krijoni një kërkesë për ndryshim para se të shkruani rreshtin e parë të kodit, për të ndarë idetë tuaja dhe për të diskutuar planet me bashkëautorin. Nëse puna është më e thjeshtë, pull request hapet kur diçka tashmë është bërë, e regjistruar dhe mund të diskutohet. Në disa skenarë, mund të hapni PR vetëm për arsye cilësie: për të ekzekutuar teste automatike ose për të iniciuar një kontroll të kodit. Çfarëdo që të vendosni, mos harroni të @përmendni njerëzit, aprovimi i të cilëve është i nevojshëm në pull request-in tuaj.

Zakonisht, kur krijoni një PR, bëni të siguiente.

• Specifikoni se çfarë po propozon dhe ku.
• Shkruani një përshkrim që shpjegon qëllimin e ndryshimeve. Mundi të dëshironi:
  • të shtoni diçka të rëndësishme që s'është e dukshme nga kodi, ose diçka të dobishme për të kuptuar kontekstin, si #bug të relevante dhe numra commitesh;
  • @përmendni të gjithë ata me të cilët dëshironi të filloni të punoni së bashku, ose mund të @përmendni ata në komentet më vonë;
  • të kërkoni që kolegët të ndihmojnë me diçka ose të kontrollojnë diçka specifike.

Pasi të hapni PR, ekzekutohen testet e konfigurura për t'u ekzekutuar në raste të tilla. Në rastin tonë, kjo do të jetë e njëjta grup testesh që kemi ekzekutuar lokal, por në një projekt real mund të ketë teste dhe verifikime shtesë.

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

️ Shtoni një shënim për subjektivitetin e listës së hapave CI

Lista e përdorur në këtë kurs është subjektive dhe ne duhet të shtojmë një shënim rreth kësaj.

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

1. Kaloni në degën master.
2. Krijoni një degë me emrin i versioneve bugfix. Kjo bëhet me ndihmën e.
3. Shtoni tekstin e shënimit në fund të skedarit ci.md.

   > **GitHub flow** nganjëherë përdoret si emër për një version të zhvillimit bazuar në degën kryesore  
   kur kodi është dërguar direkt nga degët e funksionalitetit. Kjo listë është vetëm një interpretim  
    që unë përdor në [kurset e mia DevOps](http://redpill.solutions).  
   Mënyra zyrtare është [këtu](https://guides.github.com/introduction/flow/).

4. Regjistroni ndryshimet.
5. Publikoni degën i versioneve bugfix. Kjo bëhet me ndihmën e në depozitat e largëta.
6. Krijoni një pull request me emrin Shtimi i një shënimi me degën kryesore i versioneve bugfix. Kjo bëhet me ndihmën e dhe degën bazëmaster.

Sigurohuni që keni vendosur master në forkun e depozitës si "base branch", 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 depozita juaj.

Ekipet

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

Miratoni pull request-in "Shtimi i një shënimi"

️ Detyra

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

Kjo është diagrami i komiteteve pas bashkimit.

️ Vazhdoni të punoni dhe shtoni teste

Puna në përbashkët mbi pull request shpesh kërkon punë shtesë. Kjo është zakonisht rezultat i kontrollit të kodit ose diskutimeve, por në kursin tonë ne do të simulojmë këtë, duke shtuar elemente të reja në listën tonë të hapave CI.

Me integrimin e vazhdueshëm, zakonisht zbatohen disa teste. Kërkesat për mbulimin e testeve ndryshojnë dhe zakonisht ndodhen në një dokument të quajtur si "udhezimet për autorë" (contribution guidelines). Ne do të veprojmë në mënyrë të thjeshtë dhe do të shtojmë një test për çdo rresht në listën tonë kontrolluese.

Duke kryer detyra, filloni duke u përpjekur të regjistroni teste. Nëse keni vendosur mbi pre-commit hook më parë, testi i sapo shtuar do të ekzekutohet, nuk do të përfundojë me sukses, dhe nuk do të regjistrohet asgjë. Kuptoni: kështu do të mësojmë që testet tona vërtet kontrollojnë diçka. E çuditshme, nëse do të kishim filluar me kodin përpara testeve, kalimi i testeve mund të do të thoshte ose që kodi funksionon si pritej, ose që testet në të vërtetë nuk kontrollojnë asgjë. Për më tepër, nëse nuk do të kishim shkruar teste fillimisht, mund të ishim haruar për to, sepse asgjë nuk do të na kujtonte.

Zhvillimi përmes testeve (TDD)

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

1. Shtoni një test.
2. Ekzekutoni të gjitha testet dhe sigurohuni që testi i ri nuk kalon me sukses.
3. Shkruani kodin.
4. Ekzekutoni testet, sigurohuni që të gjitha testet kalojnë me sukses.
5. Rifaktoni kodin.
6. Përfaqësoni.

Duke qenë se rezultatet e testeve që nuk kalohen zakonisht shfaqen në të kuqe, dhe ato që kalojnë me sukses në të verde, cikli gjithashtu njihet si "i kuq-i gjelbër-rifaktorim" (red-green-refactor).

️ Detyra

Filloni duke u përpjekur të regjistroni teste dhe t'i lejoni ato të përfundojnë në mënyrë të pasuksesshme, pastaj shtoni dhe regjistroni veten tekstin e listës së hapave CI. Do të shihni që testet kalojnë ("të gjelbra").
Më pas publikoni kodin e ri në depo të largët dhe shihni se si ekzekutohen testet në ndërfaqen e GitHub-it 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/ri-bashkoni commit-et nga master. Bëni që testet të kalojnë në rezultatin e bashkimit.', () => {
     expect(/.*bashkoni.*commit-et.*testet*kalojnë.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Publikoni nga dega e ve feature 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 me master.', () => {
     expect(/.*bashkoni.*me*master.*/ig.test(fileContents)).toBe(true);
   });

3. Provoni të bëni commit teste. Nëse pre-commit hook-u është vendosur, përpjekja për të bërë commit do të përfundojë me një gabim.
4. Më pas shtoni këtë tekst në ci.md.

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

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

Tani duhet të keni diçka si kjo

Ekipet

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

Edhe pse nuk bëmë asgjë të keqe dhe testet për kodin tonë kaluan me sukses, ende nuk mund të bëjmë bashkimin e degës feature dhe master. Kjo ndodh sepse një degë tjetër i versioneve bugfix. Kjo bëhet me ndihmën e u bashkua me master ndërsa ne po punonim mbi këtë PR.
Kjo krijon një situatë ku dega e largët master ka një version më të ri se ai mbi të cilin ne e bazuam degën feature. Për këtë arsye, nuk mund të kthejmë thjesht HEAD master në fund të degës feature. Në këtë situatë, na nevojitet të bëjmë ose një bashkim (merge) ose aplikim të commit-eve feature mbi (rebase) master. GitHub në të vërtetë mund të realizojë bashkim automatik nëse nuk ka konflikte. Fatkeqësisht, në situatën tonë, të dy deget kanë ndryshime konkurruese në skedarin ci.md. Kjo situatë njihet si konflikt bashkimi (merge conflict) dhe na nevojitet ta zgjidhim në mënyrë manuale.

Merge ose rebase

Merge

• Krijon një commit bashkimi (merge commit) të shtuar dhe ruan historinë e punës.
  • Ruani commit-et origjinale të degëve me kohët dhe autorët origjinalë.
  • Ruani SHA e commit-eve dhe lidhjet e tyre në diskutimet e kërkesave për të bërë ndryshime.
• Kërkon zgjidhjen e konflikteve një herë.
• E bën historinë jolineare.
  • Historia mund të jetë e vështirë për të lexuar për shkak të numrit të madh të degëve (ngjason me kabllon e IDE).
  • E komplikon debugimin automatiku, për shembull, e bën git bisect më pak të dobishëm — ai do të gjejë vetëm commit-in e bashkimit.

Rebase

• Riprodhon commit-et nga dega aktuale mbi bazën një nga një.
  • Formohen commit të reja me SHA të reja, duke rezultuar në që commit-et në GitHub lidhen me kërkesat origjinale për të bërë ndryshime, por jo me komentet përkatëse.
  • Commit-et mund të rikonfigurohen dhe të ndryshohen gjatë procesit ose madje të bashkohen në një.
• Mund të nevojitet të zgjidhni disa konflikte.
• Lejon të ruhet një histori lineare.
  • Historia mund të jetë më e lehtë për t'u lexuar, përveç nëse ajo nuk është shumë e gjatë pa arsyeshmëri.
  • Debugimi automatik dhe gjetja e gabimeve janë pak më të lehta: e bën më të mundur git bisect, mund të bëjë rikthime automatikë më të qarta dhe parashikueshme.
• Kërkon publikimin e degës me commit-et e transferuara me flamurin --force kur përdoret me kërkesat për të bërë ndryshime.

Në përgjithësi, ekipet bien dakord gjithmonë të përdorin të njëjtën strategji kur u nevojitet të bashkojnë ndryshime. Kjo mund të jetë "bashkimi" i pastër ose "aplikimi" i pastër i commit-eve ose diçka ndërmjet, siç është realizimi i aplikimit të commit-eve mbi mënyrën interaktive (git rebase -i) lokalish për degët që nuk janë publikuar në 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ë përditësuar nga depoja e largët.
2. Kaloni në degën feature.
3. Nisni bashkimin me degën master. Do të raportohet për një konflikt bashkimi, i lidhur me ndryshimet konkurruese në ci.md.
4. Zgjidhni konfliktin, në mënyrë që të mbetet në tekst lista jonë e hapave CI dhe një vërejtje për të.
5. Publikoni commit-in e bashkimit në degën e largët feature.
6. Kontrolloni statusin e kërkesës për të bërë ndryshime në ndërfaqen e GitHub-it, prisni derisa të zgjidhet bashkimi.

Ekipet

# Убедитесь, что код в локальное ветке `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ë aprooni kërkesën për të bërë ndryshime në master.

️ Detyra: Aprovo kërkesën për të bërë ndryshime "Rishikimi i hapave"

1. Hyni në kërkesën për të bërë ndryshime.
2. Klikoni "Bashko pull request".
3. Klikoni "Konfirmoni bashkimin".
4. Shkoni te "Fshi degën", pasi nuk e kemi më nevojë.

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

Gabim në prodhim

Thonë se "testimi mund të përdoret për të treguar praninë e gabimeve, por kurrë për të treguar mungesën e tyre". Edhe pse kishim teste dhe ato nuk na treguan asnjë gabim, një gabim i dëmshëm kaloi në prodhim.

Në një skenar të tillë, na nevojitet të kujdesemi për:

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

Bëri rekursiv apo ta korrigjojmë në versionin e ardhshëm?

"Rikthimi" (rolling back) është implementimi i një versioni të hershëm të rregullt në ambientin prodhues dhe anulimi (revert) i komiteve që përmbajnë një gabim. "Korrigjimi në versionin e ardhshëm" (fixing forward) është shtimi i një rregullimi në master dhe implementimin e një versioni të ri sa më shpejt të jetë e mundur. Duke qenë se API dhe skemat e bazave të dhënave ndryshojnë me implementimin e kodit në ambientin prodhues, me shpërndarje të vazhdueshme dhe mbulimin e mirë me teste, rikthimi, zakonisht, është shumë më i komplikuar dhe i rrezikshëm sesa korrigjimi në versionin e ardhshëm.

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

• korrigjojmë gabimin në prodhim sa më shpejt të jetë e mundur;
• të bëjmë kodin në master papritmas të gatshëm për fillimin e punës së re.

️ Detyra

1. Kaloni në degën master lokalisht.
2. Përditësoni repozitorin lokal nga repozitori i largët.
3. Anuloni komitin e bashkimit të PR Steps review në master.
4. Publikoni ndryshimet në repozitorin e largët.

Kjo është historia e repozitorit me komitin e bashkimit të anuluar

Ekipet

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

Korrigjoni listën e hapave CI dhe riktheni atë në master

Ne e anulua plotësisht komitin e bashkimit të degës feature. Lajmi i mirë është se tani nuk kemi gabim në master. Lajmi i keq është se ka humbur edhe lista jonë e çmuar e hapave të integrimit të vazhdueshëm. Pra, në mënyrë ideale, na nevojitet të aplikojmë rregullimin në komitetet nga feature dhe t'i rikthejmë në master bashkë me rregullimin.

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

• anuloni (revert) komitin, që anulon bashkimin feature me master;
• shkoni komitetet nga degët e mëparshme feature.

Grupet e ndryshme të zhvilluesve përdorin qasje të ndryshme në këtë rast, ne do të transferojmë komitetet e dobishme në një degë të veçantë dhe do të krijojmë një kërkesë 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 bashkimit që kanë ndodhur 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. Kjeni testet lokal, për të siguruar që ato nuk përfundojnë me sukses.
5. Fshini tekstin " with a sneaky bug" në ci.md.
6. Shtoni në indeks ndryshimet e testeve dhe ndryshimet në listën e hapave dhe komitoni ato.
7. Publikoni degën në repozitorinë e largët.

Duhet të keni diçka të ngjashme me

Ekipet

# Создайте ветку под названием 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 pull request me emrin Korrigjimi i karakteristikës. Vendosni feature-fix si "head branch", dhe master si "base branch".
Ju lutemi prisni derisa testet të përfundojnë. Mund të shihni statusin e testeve në fund të diskutimit të PR.

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

Miratoni kërkesën për bashkim "Korrigjimi i karakteristikës"

Faleminderit për korrigjimin! Ju lutemi miratoni ndryshimet në master nga kërkesa për bashkim.

️ Detyra

1. Klikoni "Bashko pull request".
2. Klikoni "Konfirmoni bashkimin".
3. Shkoni te "Fshi degën", pasi nuk e kemi më nevojë.

Kjo është ajo që duhet të keni në këtë moment

Përgëzoj!

Keni realizuar të gjitha veprimet që njerëzit zakonisht bëjnë në procesin e integrimit të vazhdueshëm.

Nëse keni vënë re ndonjë problem me kursin ose dini si ta përmirësoni, krijoni një issue në repozitari me materialet e kursit. Ky kurs gjithashtu ka një version interaktiv duke përdorur GitHub Learning Lab si një platformë.

Burimi: habr.com