A i keni mësuar komandat Git por dëshironi të imagjinoni se si funksionon integrimi i vazhdueshëm (CI) në realitet? Apo ndoshta dëshironi të optimizoni aktivitetet tuaja të përditshme? Ky kurs do t'ju japë aftësi praktike në integrimin e vazhdueshëm duke përdorur një depo GitHub. Ky kurs nuk synon të jetë një magjistar që ju thjesht mund të klikoni; përkundrazi, ju do të kryeni të njëjtat veprime që njerëzit bëjnë në të vërtetë në punë, në të njëjtën mënyrë që ata e bëjnë atë. Unë do ta shpjegoj teorinë ndërsa kaloni nëpër hapat e përfshirë.

Çfarë bëjmë ne?

Ndërsa përparojmë, gradualisht do të krijojmë një listë të hapave tipikë CI, e cila është një mënyrë e shkëlqyer për të kujtuar këtë listë. Me fjalë të tjera, ne do të krijojmë një listë veprimesh që zhvilluesit ndërmarrin ndërsa bëjnë integrim të vazhdueshëm, duke bërë integrim të vazhdueshëm. Ne do të përdorim gjithashtu një grup të thjeshtë testesh për ta afruar procesin tonë CI me atë real.

Ky GIF tregon në mënyrë skematike detyrimet në depon tuaj ndërsa përparoni nëpër kurs. Siç mund ta shihni, nuk ka asgjë të komplikuar këtu dhe vetëm më e nevojshme.

Ju do të kaloni nëpër skenarët e mëposhtëm standard CI:

• Punoni në një veçori;
• Aplikimi i testeve të automatizuara për të siguruar cilësi;
• Zbatimi i detyrës prioritare;
• Zgjidhja e konflikteve gjatë bashkimit të degëve (bashkimi i konfliktit);
• Ndodh një gabim në një mjedis prodhimi.

Çfarë do të mësoni?

Ju do të jeni në gjendje t'u përgjigjeni pyetjeve të mëposhtme:

• Çfarë është integrimi i vazhdueshëm (CI)?
• Cilat lloje të testeve të automatizuara përdoren në CI dhe në përgjigje të çfarë veprimesh shkaktohen ato?
• Cilat janë kërkesat për tërheqje dhe kur nevojiten?
• Çfarë është Zhvillimi i Drejtuar nga Testi (TDD) dhe si lidhet ai me CI?
• A duhet t'i bashkoj apo ribazoj ndryshimet?
• Të rikthehet apo të rregullohet në versionin tjetër?

Në fillim përkthej kudo gjëra të tilla si "kërkesat për tërheqje", por si rezultat vendosa të ktheja frazat në anglisht në disa vende për të ulur shkallën e çmendurisë në tekst. Unë ndonjëherë do të përdor "programues surzhik" si folja e mrekullueshme "angazhohem" ku njerëzit 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ë një depo të përbashkët të paktën një herë në ditë, dhe kodi që rezulton duhet të paktën të ndërtohet pa gabime.

Ka mosmarrëveshje për këtë term

Pika e mosmarrëveshjes është shpeshtësia e integrimit. Disa argumentojnë se bashkimi i kodit vetëm një herë në ditë nuk është i mjaftueshëm për t'u integruar në të vërtetë vazhdimisht. Jepet një shembull i një ekipi ku të gjithë marrin kodin e ri në mëngjes dhe e integrojnë atë një herë në mbrëmje. Ndërsa ky është një kundërshtim i arsyeshëm, përgjithësisht besohet se përkufizimi një herë në ditë është mjaft praktik, specifik dhe i përshtatshëm për ekipe të madhësive të ndryshme.

Një tjetër kundërshtim është se C++ nuk është më gjuha e vetme e përdorur në zhvillim, dhe thjesht kërkesa për montim pa gabime si një mënyrë vërtetimi është e dobët. Disa grupe testesh (për shembull, testet e njësive të ekzekutuara në nivel lokal) gjithashtu duhet të përfundojnë me sukses. Për momentin, komuniteti po ecën drejt bërjes së kësaj kërkese, dhe në të ardhmen "ndërtimi + testet e njësive" ndoshta do të bëhet praktikë e zakonshme, nëse nuk është bërë tashmë.

Integrimi i vazhdueshëm ndryshon nga dorëzim i vazhdueshëm (Dorëzimi i vazhdueshëm, CD) në atë që nuk kërkon një kandidat për lirim pas çdo cikli integrimi.

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

1. Tërhiq kodin më të fundit. Krijo një degë nga master. Fillo të punosh.
2. Krijoni angazhime në degën tuaj të re. Ndërtoni dhe provoni në vend. Kaloni? Shkoni në hapin tjetër. Dështoni? Rregulloni gabimet ose testet dhe provoni përsëri.
3. Shtyjeni në depon tuaj të largët ose në degën në distancë.
4. Krijo një kërkesë tërheqjeje. Diskutoni ndryshimet, shtoni më shumë angazhime ndërsa diskutimi vazhdon. Bëj që testet të kalojnë në degën e veçorive.
5. Merge/rebase commits nga master. Bëni që testet të kalojnë në rezultatin e bashkimit.
6. Shpërndani nga dega e veçorive në prodhim.
7. Nëse çdo gjë është mirë në prodhim për një periudhë kohore, bashkoni ndryshimet për të zotëruar.

️ Përgatitja

Sigurohuni që keni softuerin e duhur

Për të ndjekur këtë kurs do t'ju duhet Node.js и Klient Git.

Ju mund të përdorni çdo klient Git, por unë do të jap vetëm komanda për linjën e komandës.

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

Nëse nuk keni ende një klient Git që mbështet linjën e komandës, mund të gjeni udhëzimet e instalimit këtu.

Përgatitni depon

Ju do të duhet të krijoni një kopje personale (pirun) depo e shablloneve me kod për kursin në GitHub. Le të biem dakord ta quajmë këtë kopje personale depo e kursit.

U krye? Nëse nuk i keni ndryshuar cilësimet e paracaktuara, ka shumë të ngjarë që të thirret depoja e kursit continuous-integration-team-scenarios-students, ndodhet në llogarinë tuaj GitHub dhe URL-ja duket kështu

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

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

Kllapat këndore si <тут> do të thotë që ju duhet ta zëvendësoni një shprehje të tillë me vlerën e duhur.

Sigurohu Veprimet e GitHub të përfshira për këtë depo kursi. Nëse ato nuk janë të aktivizuara, ju lutemi aktivizoni ato duke klikuar butonin e madh në mes të faqes, tek i cili mund të arrini duke klikuar Veprimet në ndërfaqen GitHub.

Nuk do të mund ta përfundoni kursin duke ndjekur udhëzimet e mia nëse Veprimet e GitHub nuk janë të aktivizuara.

Mund të përdorësh gjithmonë aftësinë e GitHub për të dhënë Markdown për të parë gjendjen aktuale të listës që po krijojmë këtu

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

Rreth përgjigjeve

Ndërsa mënyra më e mirë për të përfunduar këtë kurs është ta bëni vetë, mund të keni disa vështirësi.

Nëse mendoni se nuk kuptoni se çfarë të bëni dhe nuk mund të vazhdoni, mund të shikoni fillin solution, e cila është në depon tuaj fillestare.
Ju lutemi mos u bashkoni solution в master gjatë kursit. Ju mund ta 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 aftësitë që na jep Git. Nëse jeni plotësisht i humbur, mund ta zëvendësoni plotësisht degën tuaj master në një degë solution dhe më pas rivendosni direktorinë tuaj të punës në hapin e kursit që ju nevojitet.

Përdoreni këtë vetëm nëse ju nevojitet vërtet

Angazhoni kodin tuaj

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

Këto komanda

• riemërto master в master-backup;
• riemërto solution в master;
• arka në një degë të re master dhe rishkruaj përmbajtjen e drejtorisë së punës;
• Krijoni një degë "zgjidhje" nga "master" (që dikur ishte "zgjidhje") në rast se keni nevojë për një degë "zgjidhje" në të ardhmen.

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ë kuptuar se cili angazhim ju nevojitet.
Ju mund të rivendosni direktorinë tuaj të punës në këtë komitet si kjo:

git reset --hard <the SHA you need>

Nëse jeni të kënaqur me rezultatin, në një moment do t'ju duhet të publikoni versionin tuaj të depove në një depo të largët. Mos harroni të specifikoni në mënyrë eksplicite degën në distancë kur e bëni këtë.

git push --force origin master

Ju lutemi vini re se ne përdorim git push --force. Nuk ka gjasa që ju të dëshironi ta bëni këtë shumë shpesh, por ne kemi një skenar shumë specifik këtu me një përdorues të depove, i cili, përveç kësaj, e kupton se çfarë po bën.

Fillimi i punës

Le të fillojmë të përpilojmë listën tonë të hapave CI. Normalisht, ju do ta filloni këtë hap duke kontrolluar versionin më të fundit të kodit nga depoja në distancë, por ne nuk kemi ende një depo lokale, kështu që ne e klonojmë atë nga distanca.

️ Detyrë: përditësoni depon lokale, krijoni një degë nga master, Fillo të punosh

1. Klononi depon e kursit nga <URL репозитория>.
2. run npm install në drejtorinë e depove të lëndëve; Na duhet për të instaluar Jest, të cilin e përdorim për të kryer teste.
3. Krijo një degë dhe emërtoje atë feature. Kalo në këtë temë.

4. Shtoni kodin e provës në ci.test.js mes komenteve që më kërkojnë ta bëj këtë.

   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. Shtoni tekst me 4 hapat e parë në skedar 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.  

   komandat

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

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

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

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

Krijoni angazhime në një degë të re, ndërtoni dhe testoni në nivel lokal

Ne do të vendosim testet për t'u ekzekutuar përpara se të kryejmë, dhe më pas do të kryejmë kodin.

Skenarët tipikë kur testet ekzekutohen automatikisht

• Në nivel lokal:
  • Vazhdimisht ose në përgjigje të ndryshimeve të duhura të kodit;
  • Mbi ruajtjen (për gjuhët e interpretuara ose të përpiluara nga JIT);
  • Gjatë montimit (kur kërkohet përpilimi);
  • Në kryerje;
  • Kur publikoni në një depo të përbashkët.

• Në serverin e ndërtimit ose mjedisin e ndërtimit:
  • Kur kodi publikohet në një degë/depo personale.
  • Kodi në këtë temë është duke u testuar.
  • Rezultati i mundshëm i bashkimit testohet (zakonisht me master).
  • Si një fazë e integrimit të vazhdueshëm / tubacion i vazhdueshëm i ofrimit

Në mënyrë tipike, sa më shpejt të funksionojë një grup testimi, aq më shpesh mund të përballoni ta ekzekutoni atë. Një shpërndarje tipike e skenës mund të duket kështu.

• Teste të shpejta të njësisë - gjatë ndërtimit, në tubacionin CI
• Testet e ngadalta të njësisë, testet e shpejta të komponentëve dhe integrimit - në kryerje, në tubacionin CI
• Testet e ngadalta të komponentëve dhe integrimit - në tubacionin CI
• Testimi i sigurisë, testimi i ngarkesës dhe teste të tjera që konsumojnë kohë ose të shtrenjta - në tubacionet CI/CD, por vetëm në mënyra/faza/ tubacione të caktuara të ndërtimit, për shembull, kur përgatitni një kandidat për lëshim ose kur ekzekutoni manualisht.

️Detyrë

Unë sugjeroj të ekzekutoni testet manualisht së pari duke përdorur komandën npm test. Pas kësaj, le të shtojmë një goditje git për të ekzekutuar testet tona në commit. Ka një kapje: Githooks nuk konsiderohen pjesë e depove dhe për këtë arsye nuk mund të klonohen nga GitHub së bashku me pjesën tjetër të materialeve të kursit. Për të instaluar grep ju duhet të kandidoni install_hook.sh ose kopjoni skedarin repo/hooks/pre-commit në drejtorinë lokale .git/hooks/.
Kur të angazhoheni, do të shihni që testet janë ekzekutuar dhe ata kontrollojnë nëse disa fjalë kyçe janë të pranishme në listë.

1. Kryeni testet manualisht duke ekzekutuar komandën npm test në dosjen tuaj të depove të kursit. Verifikoni që testet të kenë përfunduar.
2. Vendosni një grep për të kryer (pre-commit hook) duke vrapuar install_hook.sh.
3. Kryeni ndryshimet tuaja në depon tuaj lokale.
4. Sigurohuni që testet janë kryer përpara se të kryeni.

Depoja juaj duhet të duket kështu pasi të keni ndjekur këto hapa.

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ë një depo të largët ose në një degë të largët

Pasi të kenë mbaruar së punuari në nivel lokal, zhvilluesit zakonisht e bëjnë kodin e tyre të disponueshëm publikisht në mënyrë që ai përfundimisht të mund të integrohet me publikun. Me GitHub, kjo zakonisht arrihet duke publikuar punën ose në një kopje personale të depove (pirun personal) ose në një degë personale.

• Me forks, një zhvillues klonon një depo të përbashkët të largët, duke krijuar një kopje personale të saj në distancë, e njohur gjithashtu si pirun. Më pas klonon këtë depo personale për të punuar në nivel lokal. Kur puna përfundon dhe angazhimet janë bërë, ai i shtyn ato në pirunin e tij, ku ato janë të disponueshme për të tjerët dhe mund të integrohen në depon e përbashkët. Kjo qasje përdoret zakonisht 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ërdorni vetëm një depo të largët dhe të numëroni vetëm degën master depo e përbashkët "e mbrojtur". Në këtë skenar, zhvilluesit individualë publikojnë kodin e tyre në degët e një depoje të largët në mënyrë që të tjerët të mund ta shikojnë këtë kod, nëse gjithçka është në rregull, bashkoje atë me master depo e përbashkët.

Në këtë kurs të veçantë, ne do të përdorim një rrjedhë pune që përdor degë.

Le të publikojmë kodin tonë.

️Detyrë

• 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

Krijo një kërkesë për tërheqje

Krijo një kërkesë tërheqjeje me një titull Rishikimi i hapave... Instaloni feature si "dega e kokës" dhe master si "dega bazë".

Sigurohuni që të keni instaluar master në të tijin fork depo Si "degë bazë", nuk do t'i përgjigjem kërkesave për ndryshime në depon e materialeve të kursit.

Në gjuhën GitHub, "dega bazë" është dega mbi të cilën bazoni punën tuaj, dhe "dega e kokës" është dega që përmban ndryshimet e propozuara.

Diskutoni ndryshimet, shtoni angazhime të reja ndërsa diskutimi vazhdon

Kërkesa për tërheqje (PR)

Kërkesa për tërheqje (PR) është një mënyrë për të diskutuar dhe dokumentuar kodin, si dhe për të kryer rishikimin e kodit. Kërkesat për tërheqje emërtohen sipas mënyrës së përgjithshme të integrimit të ndryshimeve individuale në kodin e përgjithshëm. Në mënyrë tipike, një person klonon depon zyrtare të projektit në distancë dhe punon në kodin lokal. Pas kësaj, ai vendos kodin në depon e tij personale në distancë dhe u kërkon atyre që janë përgjegjës për depon zyrtare të marrin (tërheq) kodin e tij në depot e tyre lokale, ku ata shqyrtojnë dhe mundësisht integrojnë(shkrihet) e tij. Ky koncept njihet edhe me emra të tjerë, p.sh. kërkesë për bashkim.

Në fakt nuk duhet të përdorni veçorinë e kërkesës për tërheqje të GitHub ose platformave të ngjashme. Ekipet e zhvillimit mund të përdorin metoda të tjera komunikimi, duke përfshirë komunikimin ballë për ballë, thirrjet zanore ose emailin, por ka ende një sërë arsyesh për të përdorur kërkesat për tërheqje të stilit të forumit. Ja disa prej tyre:

• organizoi diskutime në lidhje me ndryshimet specifike të kodit;
• si një vend për të parë reagimet mbi punën në vazhdim si nga autotestuesit ashtu edhe nga kolegët;
• zyrtarizimi i rishikimeve të kodit;
• në mënyrë që më vonë të mund të zbuloni arsyet dhe konsideratat pas kësaj apo asaj pjese të kodit.

Në mënyrë tipike ju krijoni një kërkesë tërheqjeje kur keni nevojë të diskutoni diçka ose të merrni komente. Për shembull, nëse jeni duke punuar në një veçori që mund të zbatohet në më shumë se një mënyrë, mund të krijoni një kërkesë tërheqëse përpara se të shkruani rreshtin e parë të kodit për të ndarë idetë tuaja dhe për të diskutuar planet tuaja me bashkëpunëtorët tuaj. Nëse puna është më e thjeshtë, një kërkesë për tërheqje hapet kur diçka tashmë është bërë, kryer dhe mund të diskutohet. Në disa skenarë, mund të dëshironi të hapni një PR vetëm për arsye të kontrollit të cilësisë: për të kryer teste të automatizuara ose për të filluar rishikimet e kodit. Çfarëdo që të vendosni, mos harroni të @përmendni njerëzit miratimin e të cilëve dëshironi në kërkesën tuaj për tërheqje.

Në mënyrë tipike, kur krijoni një PR, bëni sa më poshtë.

• Tregoni se çfarë propozoni të ndryshoni dhe ku.
• Shkruani një përshkrim duke shpjeguar qëllimin e ndryshimeve. Ju mund të dëshironi:
  • shtoni çdo gjë të rëndësishme që nuk është e dukshme nga kodi, ose diçka të dobishme për të kuptuar kontekstin, të tilla si #bugs përkatëse dhe numrat e kryerjes;
  • @përmendni këdo me të cilin dëshironi të filloni të punoni, ose mund t'i @përmendni në komente më vonë;
  • kërkoni nga kolegët të ndihmojnë me diçka ose të kontrollojnë diçka specifike.

Pasi të hapni PR, testet e konfiguruara për të ekzekutuar në raste të tilla ekzekutohen. Në rastin tonë, ky do të jetë i njëjti grup testesh që kemi kryer në nivel lokal, por në një projekt real mund të ketë teste dhe kontrolle shtesë.

Ju lutemi prisni derisa të përfundojnë testet. Ju mund të shihni statusin e testeve në fund të diskutimit PR në ndërfaqen GitHub. Vazhdoni kur të përfundojnë testet.

️ Shtoni një shënim në lidhje me rastësinë e listës së hapave CI

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

️ Detyrë: krijoni një kërkesë tërheqëse për këtë koment

1. Kalo në degë master.
2. Krijo një degë me emrin bugfix.
3. Shtoni tekstin e shënimit në fund të skedarit 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. Kryeni ndryshimet.
5. Publikoni temën bugfix në një depo të largët.
6. Krijo një kërkesë tërheqjeje me emrin Duke shtuar një vërejtje me një degë kokë bugfix dhe dega bazëmaster.

Sigurohuni që të keni instaluar master në të tijin fork depo Si "degë bazë", nuk do t'i përgjigjem kërkesave për ndryshime në depon e materialeve të kursit.

Kështu duhet të duket depoja 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 как описано выше

Mirato kërkesën për tërheqje "Shtimi i një vërejtjeje"

️Detyrë

1. Krijo një kërkesë tërheqjeje.
2. Klikoni "Kërkesa për të tërhequr bashkimin".
3. Klikoni "Konfirmo bashkimin".
4. Klikoni "Fshi degën", nuk na nevojitet më.

Ky është një diagram i kryerjeve pas një bashkimi.

️ Vazhdo të punosh dhe të shtosh teste

Bashkëpunimi për një kërkesë tërheqëse shpesh rezulton në punë shtesë. Ky është zakonisht rezultat i një rishikimi ose diskutimi të kodit, por në kursin tonë ne do ta modelojmë këtë duke shtuar artikuj të rinj në listën tonë të hapave CI.

Integrimi i vazhdueshëm zakonisht përfshin disa mbulime provë. Kërkesat e mbulimit të testit ndryshojnë dhe zakonisht gjenden në një dokument të quajtur diçka si "udhëzimet e kontributit". Ne do ta mbajmë të thjeshtë dhe do të shtojmë një test për secilën rresht në listën tonë të kontrollit.

Kur kryeni detyrat, provoni fillimisht të kryeni testet. Nëse e keni instaluar saktë pre-commit fiksojeni më herët, testi i shtuar rishtazi do të ekzekutohet, do të dështojë dhe asgjë nuk do të kryhet. Vini re se kjo është mënyra se si ne e dimë se testet tona në të vërtetë po testojnë diçka. Interesante, nëse ne filluam me kodin përpara testeve, kalimi i testeve mund të nënkuptojë ose se kodi funksionoi siç pritej, ose se testet nuk po testonin asgjë. Plus, nëse nuk do t'i kishim shkruar testet në fillim, mund t'i kishim harruar fare, pasi asgjë nuk do të na e kishte kujtuar.

Zhvillimi i drejtuar nga testi (TDD)

TDD rekomandon shkrimin e testeve përpara kodit. Një rrjedhë tipike pune duke përdorur TDD duket kështu.

1. Shto një test.
2. Kryeni të gjitha testet dhe sigurohuni që testi i ri të dështojë.
3. Shkruani kodin.
4. Kryeni testet, sigurohuni që të gjitha testet të kalojnë.
5. Rifaktoroni kodin tuaj.
6. Përsëriteni.

Për shkak se rezultatet e testeve që dështojnë zakonisht tregohen me të kuqe, dhe ato që kalojnë zakonisht tregohen me jeshile, cikli njihet gjithashtu si një refaktor i kuq-jeshile.

️Detyrë

Së pari, provoni të kryeni testet dhe t'i lini të dështojnë, pastaj shtoni dhe kryeni vetë tekstin e listës së hapave CI. Do të shihni që testet po kalojnë ("jeshile").
Më pas publikoni kodin e ri në depon e largët dhe shikoni testet e ekzekutuara në ndërfaqen GitHub në fund të diskutimit të kërkesës për tërheqje dhe përditësimin e statusit PR.

1. Kalo në degë feature.

2. Shtoni këto teste në ci.test.js pas thirrjes së fundit 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. Provoni të kryeni testet. Nëse pre-commit hook është instaluar, përpjekja për kryerjen do të dështojë.
4. Pastaj shtoni këtë tekst në 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. Bëni dhe kryeni ndryshime në nivel lokal.
6. Postoni ndryshimet në degë 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

Bashkoni konfliktin

Shkoni te Kërkesa për Ndryshim Rishikimi i hapave.

Edhe pse nuk bëmë asgjë të gabuar dhe testet për kodin tonë kaluan, ne ende nuk mund ta bashkojmë degën feature и master. Kjo është për shkak të fillit tjetër bugfix u bashkua me master ndërsa ne po punonim për këtë PR.
Kjo krijon një situatë ku dega e largët master ka një version më të ri se ai në të cilin bazuam degën feature. Për shkak të kësaj, ne nuk mund ta kthejmë kokën prapa master deri në fund të fillit feature. Në këtë situatë, ne duhet ose të bashkojmë ose të aplikojmë angazhime feature ribazoj master. GitHub në fakt mund të kryejë bashkime automatike nëse nuk ka konflikte. Mjerisht, në situatën tonë, të dyja degët kanë ndryshime konkurruese në dosje ci.md. Kjo situatë njihet si një konflikt bashkimi dhe ne duhet ta zgjidhim atë manualisht.

Bashkoni ose ribazoni

Shkrihet

• Krijon një bashkim shtesë dhe ruan historinë e punës.
  • Ruan angazhimet origjinale të degëve me vulat kohore dhe autorët e tyre origjinalë.
  • Ruan SHA-në e angazhimeve dhe lidhjet me to në diskutimet e kërkesave për ndryshim.
• Kërkon zgjidhje një herë të konfliktit.
• E bën tregimin jolinear.
  • Historia mund të jetë e vështirë për t'u lexuar për shkak të numrit të madh të degëve (që të kujton një kabllo IDE).
  • E bën më të vështirë korrigjimin automatik, p.sh. git bisect më pak i dobishëm - do të gjejë vetëm kryerjen e bashkimit.

Rebaza

• Përsëritjet kryen nga dega aktuale në krye të degës bazë njëra pas tjetrës.
  • Krijohen angazhime të reja me SHA të reja, duke bërë që angazhimet në GitHub të përputhen me kërkesat origjinale të tërheqjes, por jo me komentet përkatëse.
  • Detyrimet mund të rikombinohen dhe modifikohen gjatë procesit, apo edhe të shkrihen në një.
• Mund të kenë nevojë të zgjidhen konflikte të shumta.
• Ju lejon të mbani një histori lineare.
  • Historia mund të jetë më e lehtë për t'u lexuar për sa kohë që nuk është shumë e gjatë pa ndonjë arsye të arsyeshme.
  • Korrigjimi automatik dhe zgjidhja e problemeve është pak më e lehtë: e bën të mundur git bisect, mund t'i bëjë rikthimet automatike më të qarta dhe më të parashikueshme.
• Kërkon publikimin e një dege me angazhime të migruara me një flamur --force kur përdoret me kërkesa për tërheqje.

Në mënyrë tipike, ekipet bien dakord të përdorin gjithmonë të njëjtën strategji kur duhet të bashkojnë ndryshimet. Kjo mund të jetë një bashkim "i pastër" ose një angazhim "i pastër" në krye, ose diçka në mes, të tilla si bërja e një commit në krye në mënyrë interaktive (git rebase -i) në nivel lokal për degët që nuk janë publikuar në depo publike, por bashkohen për degët "publike".

Këtu do të përdorim bashkimin.

️Detyrë

1. Sigurohuni që kodi të jetë në një degë lokale master përditësuar nga një depo e largët.
2. Kalo në degë feature.
3. Filloni një bashkim me një degë master. Një konflikt bashkimi për shkak të ndryshimeve konkurruese në ci.md.
4. Zgjidheni konfliktin në mënyrë që lista jonë e hapave CI dhe një shënim rreth tij të mbeten në tekst.
5. Publikoni një angazhim për bashkimin në një degë të largët feature.
6. Kontrolloni statusin e kërkesës për tërheqje në UI GitHub dhe prisni derisa bashkimi të zgjidhet.

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 mrekullueshme!

Ju keni mbaruar me listën dhe tani duhet të miratoni kërkesën për tërheqje master.

️ Detyrë: Miratoni kërkesën për tërheqje "Shqyrtimi i hapave"

1. Hapni një kërkesë për tërheqje.
2. Klikoni "Kërkesa për të tërhequr bashkimin".
3. Klikoni "Konfirmo bashkimin".
4. Klikoni "Fshi degën" pasi nuk na nevojitet më.

Ky është depoja juaj për momentin

Gabim produkti

Thuhet 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 nuk na treguan asnjë gabim, një defekt tinëzar u fut në prodhim.

Në një skenar si ky, duhet të kujdesemi për:

• çfarë përdoret në prodhim;
• kodi në thread master me një gabim, nga i cili zhvilluesit mund të fillojnë punë të reja.

A duhet ta kthej prapa apo ta rregulloj atë në versionin tjetër?

Rikthimi është procesi i vendosjes së një versioni të mirë të mëparshëm të njohur në prodhim dhe kthimi i detyrimeve që përmbajnë gabimin. "Fixing forward" është shtimi i një rregullimi në master dhe vendosjen e versionit të ri sa më shpejt të jetë e mundur. Për shkak se API-të dhe skemat e bazës së të dhënave ndryshojnë kur kodi shpërndahet në prodhim, me shpërndarje të vazhdueshme dhe mbulim të mirë të testit, rikthimi është zakonisht shumë më i vështirë dhe më i rrezikshëm sesa rregullimi i tij në versionin tjetër.

Meqenëse kthimi mbrapa nuk mbart asnjë rrezik në rastin tonë, ne do të shkojmë në këtë rrugë, sepse na lejon

• rregulloni gabimin në produkt sa më shpejt të jetë e mundur;
• bëj kodin në master i pershtatshem menjehere per fillimin e nje pune te re.

️Detyrë

1. Kalo në degë master lokalisht.
2. Përditësoni depon lokale nga depoja e largët.
3. Riktheje angazhimin e bashkimit PR Rishikimi i hapave в master.
4. Publikoni ndryshimet në një depo të largët.

Ky është historia e një depoje me një angazhim të bashkimit të rikthyer

komandat

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

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

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

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

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

️ Vetëtestim

Sigurohu ci.md nuk përmban më tekstin "bug poshtër" pas kthimit të një bashkimi të kryer.

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

Kemi rikthyer plotësisht bashkimin e degës. feature. Lajmi i mirë është se tani nuk kemi asnjë gabim master. Lajmi i keq është se lista jonë e çmuar e hapave të vazhdueshëm të integrimit është zhdukur gjithashtu. Pra, në mënyrë ideale, ne duhet të aplikojmë rregullimin për kryerjet nga feature dhe kthejini ato në master së bashku me rregullimin.

Ne mund t'i qasemi problemit në mënyra të ndryshme:

• riktheje një kryerje që zhbë një bashkim feature с master;
• lëviz commits nga ish feature.

Ekipe të ndryshme zhvillimi përdorin qasje të ndryshme në këtë rast, por ne do të zhvendosim angazhimet e dobishme në një degë të veçantë dhe do të krijojmë një kërkesë të veçantë tërheqjeje për këtë degë të re.

️Detyrë

1. Krijo një fije të quajtur feature-fix dhe kaloni në të.

2. Migroni të gjitha detyrimet nga dega e mëparshme feature në një fill të ri. Zgjidh konfliktet e bashkimit që kanë ndodhur gjatë migrimit.

   

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

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

4. Kryeni testet në nivel lokal për t'u siguruar që ato të mos dështojnë.
5. Hiqni tekstin "me një gabim të poshtër". ci.md.
6. Shtoni ndryshimet e testit dhe ndryshimet e listës së hapave në indeks dhe kryeni ato.
7. Publikoni degën në një depo të largët.

Ju duhet të përfundoni me diçka të ngjashme me këtë:

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

Krijo një kërkesë tërheqjeje.

Krijo një kërkesë tërheqjeje me një titull Rregullimi i veçorisë... Instaloni feature-fix si "dega e kokës" dhe master si "dega bazë".
Ju lutemi prisni derisa të përfundojnë testet. Ju mund të shihni statusin e testeve në fund të diskutimit të PR.

Sigurohuni që të keni instaluar master në të tijin fork depo Si "degë bazë", nuk do t'i përgjigjem kërkesave për ndryshime në depon e materialeve të kursit.

Mirato kërkesën për tërheqje "Rregullimi i veçorisë"

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

️Detyrë

1. Klikoni "Kërkesa për të tërhequr bashkimin".
2. Klikoni "Konfirmo bashkimin".
3. Klikoni "Fshi degën" pasi nuk na nevojitet më.

Kjo është ajo që duhet të keni për momentin.

Urime!

Ju keni përfunduar të gjithë hapat që njerëzit zakonisht marrin gjatë integrimit të vazhdueshëm.

Nëse vëreni ndonjë problem me kursin ose dini se si ta përmirësoni atë, ju lutemi krijoni një problem në depo me materiale kursi. Ky kurs gjithashtu ka version interaktiv duke përdorur GitHub Learning Lab si një platformë.

Burimi: www.habr.com