Vai esat iemācījies Git komandas, bet vēlaties iedomāties, kā nepārtrauktā integrācija (CI) darbojas patiesībā? Vai varbūt vēlaties optimizēt savas ikdienas aktivitātes? Šis kurss sniegs jums praktiskas iemaņas nepārtrauktā integrācijā, izmantojot GitHub repozitoriju. Šis kurss nav paredzēts kā vednis, uz kura var vienkārši noklikšķināt; gluži pretēji, jūs veiksit tās pašas darbības, ko cilvēki faktiski dara darbā, tādā pašā veidā, kā viņi to dara. Es izskaidrošu teoriju, veicot visas iesaistītās darbības.

Ko mēs darām?

Attīstoties, mēs pakāpeniski izveidosim tipisku CI darbību sarakstu, kas ir lielisks veids, kā atcerēties šo sarakstu. Citiem vārdiem sakot, mēs izveidosim sarakstu ar darbībām, kuras izstrādātāji veic, veicot nepārtrauktu integrāciju, veicot nepārtrauktu integrāciju. Mēs izmantosim arī vienkāršu testu komplektu, lai tuvinātu mūsu CI procesu reālajam procesam.

Šis GIF shematiski parāda saistības jūsu repozitorijā, virzoties uz kursu. Kā redzat, šeit nav nekā sarežģīta un tikai pats nepieciešamākais.

Jums tiks veikti šādi standarta CI scenāriji:

• Darbs pie funkcijas;
• Automatizētu testu pielietošana kvalitātes nodrošināšanai;
• Prioritārā uzdevuma īstenošana;
• Konfliktu risināšana, apvienojot filiāles (apvienošanas konflikts);
• Ražošanas vidē rodas kļūda.

Ko tu iemācīsies?

Jūs varēsiet atbildēt uz šādiem jautājumiem:

• Kas ir nepārtraukta integrācija (CI)?
• Kāda veida automatizētās pārbaudes tiek izmantotas CI, un, reaģējot uz kādām darbībām tie tiek aktivizēti?
• Kas ir izvilkšanas pieprasījumi un kad tie ir nepieciešami?
• Kas ir Test Driven Development (TDD) un kā tā ir saistīta ar CI?
• Vai man vajadzētu apvienot vai mainīt izmaiņas?
• Atsaukt atpakaļ vai labot nākamajā versijā?

Sākumā es visur tulkoju tādas lietas kā “pull requests”, bet rezultātā nolēmu atsevišķās vietās atgriezt frāzes angļu valodā, lai samazinātu neprāta pakāpi tekstā. Es dažreiz izmantošu “programmētājs surzhik”, piemēram, brīnišķīgo darbības vārdu “apņemties”, kur cilvēki to izmanto darbā.

Kas ir nepārtraukta integrācija?

Nepārtraukta integrācija, vai CI, ir tehniska prakse, kurā katrs komandas dalībnieks integrē savu kodu kopējā repozitorijā vismaz reizi dienā, un iegūtais kods ir vismaz jāveido bez kļūdām.

Par šo terminu pastāv domstarpības

Strīda punkts ir integrācijas biežums. Daži apgalvo, ka koda apvienošana tikai vienu reizi dienā nav pietiekama, lai faktiski integrētos nepārtraukti. Tiek sniegts piemērs komandai, kurā visi no rīta paņem jaunu kodu un vienu reizi vakarā integrē. Lai gan tas ir pamatots iebildums, parasti tiek uzskatīts, ka definīcija “reizi dienā” ir pietiekami praktiska, specifiska un piemērota dažāda lieluma komandām.

Vēl viens iebildums ir tāds, ka C++ vairs nav vienīgā valoda, ko izmanto izstrādē, un vienkārši prasība bez kļūdām montāža kā validācijas veids ir vāja. Dažiem testu komplektiem (piemēram, lokāli izpildītiem vienību testiem) arī jābūt veiksmīgi pabeigtiem. Šobrīd kopiena virzās uz to, lai to padarītu par prasību, un nākotnē "būvēt + vienību testi", iespējams, kļūs par ierastu praksi, ja tā vēl nav izdarīta.

Nepārtraukta integrācija atšķiras no nepārtraukta piegāde (Nepārtraukta piegāde, CD), jo tai nav nepieciešams izlaišanas kandidāts pēc katra integrācijas cikla.

To darbību saraksts, kuras izmantosim visa kursa laikā

1. Ievelciet jaunāko kodu. Izveidojiet filiāli no master. Sāk strādāt.
2. Izveidojiet saistības savā jaunajā filiālē. Veidojiet un pārbaudiet lokāli. Iziet? Pārejiet uz nākamo darbību. Izgāzies? Izlabojiet kļūdas vai pārbaudes un mēģiniet vēlreiz.
3. Pārsūtiet uz savu attālo repozitoriju vai attālo filiāli.
4. Izveidojiet izvilkšanas pieprasījumu. Apspriediet izmaiņas, pievienojiet vairāk saistību, kamēr diskusija turpinās. Nodrošiniet, lai pārbaudes tiktu nodotas funkciju zaram.
5. Apvienot/pārbāzt saistības no galvenā. Nodrošiniet, lai pārbaudes nodotu apvienošanas rezultātu.
6. Izvietot no līdzekļu nozares uz ražošanu.
7. Ja kādu laiku ražošanā viss ir kārtībā, apvienojiet izmaiņas ar galveno.

️ Sagatavošana

Pārliecinieties, vai jums ir piemērota programmatūra

Lai apmeklētu šo kursu, jums būs nepieciešams Node.js и Apmeklējiet klientu.

Varat izmantot jebkuru Git klientu, bet es sniegšu komandas tikai komandrindai.

Pārliecinieties, vai ir instalēts Git klients, kas atbalsta komandrindu

Ja jums vēl nav Git klienta, kas atbalsta komandrindu, varat atrast instalēšanas instrukcijas šeit.

Sagatavojiet repozitoriju

Jums būs jāizveido personiskā kopija (dakša) veidņu repozitorijs ar kursa kodu vietnē GitHub. Vienosimies saukt šo personisko kopiju kursu krātuve.

Gatavs? Ja neesat mainījis noklusējuma iestatījumus, visticamāk, tiks izsaukta jūsu kursu krātuve continuous-integration-team-scenarios-students, tas atrodas jūsu GitHub kontā, un URL izskatās šādi

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

Es vienkārši piezvanīšu uz šo adresi <URL репозитория>.

Leņķa kronšteini, piemēram <тут> nozīmē, ka jums ir jāaizstāj šāda izteiksme ar atbilstošu vērtību.

Pārliecinies ka GitHub darbības iekļauts šajā kursu krātuvē. Ja tie nav iespējoti, lūdzu, iespējojiet tos, lapas vidū noklikšķinot uz lielās pogas, kuru varat atvērt, GitHub saskarnē noklikšķinot uz Darbības.

Ja GitHub darbības nav iespējotas, jūs nevarēsit pabeigt kursu, izpildot manus norādījumus.

Jūs vienmēr varat izmantot GitHub spēju renderēt Markdown, lai redzētu pašreizējo saraksta stāvokli, ko mēs šeit veidojam.

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

Par atbildēm

Lai gan labākais veids, kā pabeigt šo kursu, ir to izdarīt pats, jums var rasties dažas grūtības.

Ja jūtat, ka nesaprotat, ko darīt, un nevarat turpināt, varat ieskatīties pavedienā solution, kas atrodas jūsu sākuma repozitorijā.
Lūdzu, neapvienojiet solution в master kursa laikā. Varat izmantot šo atzaru, lai noskaidrotu, ko darīt, vai salīdzinātu savu kodu ar autora kodu, izmantojot visas Git sniegtās iespējas. Ja esat pilnībā pazudis, varat pilnībā nomainīt savu filiāli master uz zara solution un pēc tam atiestatiet darba direktoriju uz nepieciešamo kursa darbību.

Izmantojiet to tikai tad, ja jums tas patiešām ir nepieciešams

Piestipriniet savu kodu

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

Šīs komandas

• pārdēvēt master в master-backup;
• pārdēvēt solution в master;
• izrakstīšanās uz jaunu filiāli master un pārrakstīt darba direktorijas saturu;
• Izveidojiet "risinājuma" atzaru no "master" (kas agrāk bija "risinājums"), ja jums nākotnē būs nepieciešams "risinājuma" zars.

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

Pēc šīm darbībām varat izmantot git log master lai noskaidrotu, kura apņemšanās jums ir nepieciešama.
Jūs varat atiestatīt savu darba direktoriju uz šo saistību šādi:

git reset --hard <the SHA you need>

Ja esat apmierināts ar rezultātu, kādā brīdī jums būs jāpublicē sava repozitorija versija attālajā repozitorijā. To darot, neaizmirstiet skaidri norādīt attālo filiāli.

git push --force origin master

Lūdzu, ņemiet vērā, ka mēs izmantojam git push --force. Maz ticams, ka jūs to vēlēsities darīt ļoti bieži, taču mums ir ļoti konkrēts scenārijs ar vienu repozitorija lietotāju, kurš turklāt saprot, ko viņš dara.

Darba sākšana

Sāksim veidot savu CI darbību sarakstu. Parasti jūs sāktu šo darbību, pārbaudot jaunāko koda versiju no attālās krātuves, taču mums vēl nav vietējās krātuves, tāpēc mēs to klonējam no attālās krātuves.

️ Uzdevums: atjaunināt vietējo repozitoriju, izveidot filiāli no master, sāk strādāt

1. Klonēt kursa repozitoriju no <URL репозитория>.
2. Skrien npm install kursu repozitorija direktorijā; Mums tas ir nepieciešams, lai instalētu Jest, ko izmantojam testu veikšanai.
3. Izveidojiet filiāli un nosauciet to feature. Pārslēdzieties uz šo pavedienu.

4. Pievienojiet testa kodu ci.test.js starp komentāriem, kuros man tas tiek lūgts.

   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. Pievienojiet failam tekstu ar pirmajām 4 darbībām 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.  

   Komandas

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

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

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

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

Izveidojiet saistības jaunā filiālē, izveidojiet un pārbaudiet lokāli

Mēs iestatīsim testus, lai tie tiktu izpildīti pirms apņemšanās, un pēc tam ieviesīsim kodu.

Tipiski scenāriji, kad testi tiek izpildīti automātiski

• Lokāli:
  • Nepārtraukti vai reaģējot uz atbilstošām koda izmaiņām;
  • Par saglabāšanu (tulkotajām vai JIT apkopotajām valodām);
  • Montāžas laikā (kad nepieciešama kompilācija);
  • Par apņemšanos;
  • Publicējot koplietotā repozitorijā.

• Būvēšanas serverī vai būvēšanas vidē:
  • Kad kods tiek publicēts personīgajā filiālē/repozitorijā.
  • Kods šajā pavedienā tiek pārbaudīts.
  • Apvienošanās potenciālais rezultāts tiek pārbaudīts (parasti ar master).
  • Kā nepārtrauktas integrācijas posms/nepārtrauktas piegādes cauruļvads

Parasti, jo ātrāk testa komplekts darbojas, jo biežāk varat atļauties to palaist. Tipisks posma sadalījums varētu izskatīties šādi.

• Ātrās vienību pārbaudes - būvniecības laikā, CI cauruļvadā
• Lēnās vienību pārbaudes, ātrās komponentu un integrācijas pārbaudes — izpildes laikā, CI konveijerā
• Lēni komponentu un integrācijas testi - CI konveijerā
• Drošības testēšana, slodzes pārbaude un citi laikietilpīgi vai dārgi testi - CI/CD konveijeros, bet tikai atsevišķos būvēšanas režīmos/posmos/konveijeros, piemēram, sagatavojot izlaiduma kandidātu vai palaižot manuāli.

️Uzdevums

Es iesaku vispirms manuāli palaist testus, izmantojot komandu npm test. Pēc tam pievienosim git hook, lai palaistu mūsu commit pārbaudes. Ir viena problēma: Git āķi netiek uzskatīti par daļu no repozitorija, un tāpēc tos nevar klonēt no GitHub kopā ar pārējiem kursa materiāliem. Lai instalētu āķi, jums jāskrien install_hook.sh vai kopējiet failu repo/hooks/pre-commit uz vietējo direktoriju .git/hooks/.
Veicot apņemšanos, jūs redzēsit, ka tiek veikti testi un tie pārbauda, ​​vai sarakstā ir noteikti atslēgvārdi.

1. Palaidiet testus manuāli, izpildot komandu npm test kursa repozitorija mapē. Pārbaudiet, vai testi ir pabeigti.
2. Iestatiet apņemšanās āķi (pirmsapstiprināšanas āķi), skrienot install_hook.sh.
3. Veiciet izmaiņas vietējā repozitorijā.
4. Pirms apņemšanās pārliecinieties, vai ir veikti testi.

Pēc šo darbību veikšanas jūsu krātuvei vajadzētu izskatīties šādi.

Komandas

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

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

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

Publicējiet kodu attālā repozitorijā vai attālā filiālē

Kad izstrādātāji ir pabeiguši darbu lokāli, izstrādātāji parasti dara savu kodu publiski pieejamu, lai to galu galā varētu integrēt publiski. Izmantojot GitHub, tas parasti tiek panākts, publicējot darbu vai nu personīgā repozitorija kopijā (personīgā dakša), vai personīgajā filiālē.

• Izmantojot dakšas, izstrādātājs klonē attālo koplietojamo repozitoriju, izveidojot tā personisku attālo kopiju, kas pazīstama arī kā dakša. Pēc tam tas klonē šo personīgo repozitoriju, lai strādātu ar to lokāli. Kad darbs ir pabeigts un saistības ir izdarītas, viņš tās iespiež savā dakšā, kur tās ir pieejamas citiem un var tikt integrētas kopējā repozitorijā. Šo pieeju parasti izmanto atvērtā pirmkoda projektos vietnē GitHub. To izmanto arī manā padziļinātajā kursā [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Vēl viena pieeja ir izmantot tikai vienu attālo repozitoriju un skaitīt tikai filiāli master koplietotais repozitorijs "aizsargāts". Šajā scenārijā atsevišķi izstrādātāji publicē savu kodu attālās repozitorija filiālēs, lai citi varētu apskatīt šo kodu, ja viss ir kārtībā, apvienot to ar master koplietotā repozitorija.

Šajā konkrētajā kursā mēs izmantosim darbplūsmu, kurā tiek izmantotas filiāles.

Publicēsim savu kodu.

️Uzdevums

• Publicējiet izmaiņas attālā filiālē ar tādu pašu nosaukumu kā jūsu darba filiālei

Komandas

git push --set-upstream origin feature

Izveidojiet izvilkšanas pieprasījumu

Izveidojiet izvilkšanas pieprasījumu ar nosaukumu Soļu apskats... Uzstādīt feature kā "galvas zars" un master piemēram, "bāzes filiāle".

Pārliecinieties, vai esat instalējis master viņa dakša repozitorijs Es kā "bāzes filiāle" neatbildēšu uz pieprasījumu veikt izmaiņas kursa materiālu krātuvē.

GitHub lingo “bāzes atzars” ir filiāle, uz kuras pamata tiek veikts darbs, un “galvenais atzars” ir filiāle, kurā ietvertas ierosinātās izmaiņas.

Apspriediet izmaiņas, pievienojiet jaunas saistības, kamēr diskusija turpinās

Izvilkšanas pieprasījums (PR)

Izvilkšanas pieprasījums (PR) ir veids, kā apspriest un dokumentēt kodu, kā arī veikt koda pārskatīšanu. Izvilkšanas pieprasījumi ir nosaukti pēc vispārējā veida, kā integrēt atsevišķas izmaiņas kopējā kodā. Parasti persona klonē projekta attālo oficiālo repozitoriju un strādā pie koda lokāli. Pēc tam viņš ievieto kodu savā personīgajā attālajā repozitorijā un lūdz personām, kas ir atbildīgas par oficiālo repozitoriju, paņemt (vilkt) tā kodu savos lokālajos krātuvēs, kur viņi pārskata un, iespējams, integrē (apvienot) viņa. Šis jēdziens ir pazīstams arī ar citiem nosaukumiem, piemēram, sapludināšanas pieprasījums.

Jums faktiski nav jāizmanto GitHub vai līdzīgu platformu vilkšanas pieprasījuma funkcija. Izstrādes komandas var izmantot citas saziņas metodes, tostarp klātienes saziņu, balss zvanus vai e-pastu, taču joprojām ir vairāki iemesli, lai izmantotu foruma stila piesaistes pieprasījumus. Šeit ir daži no tiem:

• organizētas diskusijas saistībā ar konkrētām koda izmaiņām;
• kā vieta, kur skatīt atsauksmes par nepabeigtajiem darbiem gan no autotestētājiem, gan no vienaudžiem;
• kodu pārskatīšanas formalizēšana;
• lai vēlāk jūs varētu uzzināt iemeslus un apsvērumus, kas ir aiz šī vai cita koda daļas.

Parasti izvilkšanas pieprasījumu veidojat, kad nepieciešams kaut ko apspriest vai saņemt atsauksmes. Piemēram, ja strādājat pie funkcijas, ko varētu ieviest vairāk nekā vienā veidā, pirms pirmās koda rindiņas rakstīšanas varat izveidot izvilkšanas pieprasījumu, lai dalītos ar savām idejām un apspriestu savus plānus ar līdzstrādniekiem. Ja darbs ir vienkāršāks, izvilkšanas pieprasījums tiek atvērts, kad kaut kas jau ir izdarīts, izdarīts un to var apspriest. Dažos gadījumos varat atvērt PR tikai kvalitātes kontroles nolūkos: lai palaistu automatizētus testus vai sāktu koda pārskatīšanu. Neatkarīgi no tā, ko izlemjat, neaizmirstiet @pieminēt cilvēkus, kuru apstiprinājumu vēlaties savā piesaistes pieprasījumā.

Parasti, veidojot PR, rīkojieties šādi.

• Norādiet, ko jūs piedāvājat mainīt un kur.
• Uzrakstiet aprakstu, izskaidrojot izmaiņu mērķi. Jūs varētu vēlēties:
  • pievienojiet visu svarīgu, kas nav acīmredzams no koda, vai kaut ko noderīgu konteksta izpratnei, piemēram, atbilstošus #bugs un commit numurus;
  • @pieminiet ikvienu, ar kuru vēlaties sākt strādāt, vai arī vēlāk varat @pieminēt viņus komentāros;
  • palūdziet kolēģiem kaut ko palīdzēt vai pārbaudiet kaut ko konkrētu.

Kad esat atvēris PR, tiek izpildīti testi, kas konfigurēti tā, lai tie darbotos šādos gadījumos. Mūsu gadījumā tas būs tas pats testu komplekts, ko veicām lokāli, taču reālā projektā var būt papildu testi un pārbaudes.

Lūdzu, uzgaidiet, kamēr testi ir pabeigti. Pārbaužu statusu varat redzēt GitHub saskarnes PR diskusijas apakšā. Turpiniet, kad testi ir pabeigti.

️ Pievienojiet piezīmi par CI soļu saraksta nejaušību

Šajā kursā izmantotais saraksts ir patvaļīgs un subjektīvs, par to jāpievieno piezīme.

️ Uzdevums: izveidojiet izvilkšanas pieprasījumu šim komentāram

1. Pārslēgties uz filiāli master.
2. Izveidojiet filiāli ar nosaukumu bugfix.
3. Pievienojiet piezīmes tekstu faila beigās 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. Veiciet izmaiņas.
5. Publicējiet pavedienu bugfix uz attālo repozitoriju.
6. Izveidojiet izvilkšanas pieprasījumu ar nosaukumu Pievienojot piezīmi ar galvas zaru bugfix un pamatzarsmaster.

Pārliecinieties, vai esat instalējis master viņa dakša repozitorijs Es kā "bāzes filiāle" neatbildēšu uz pieprasījumu veikt izmaiņas kursa materiālu krātuvē.

Šādi vajadzētu izskatīties jūsu krātuvei.

Komandas

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

Apstiprināt izvilkšanas pieprasījumu "Piezīmes pievienošana"

️Uzdevums

1. Izveidojiet izvilkšanas pieprasījumu.
2. Noklikšķiniet uz "Apvienot vilkšanas pieprasījumu".
3. Noklikšķiniet uz "Apstiprināt sapludināšanu".
4. Noklikšķiniet uz "Dzēst filiāli", mums tas vairs nav vajadzīgs.

Šī ir saistību diagramma pēc apvienošanas.

️ Turpiniet strādāt un pievienojiet testus

Sadarbība pievilkšanas pieprasījuma izpildē bieži vien rada papildu darbu. Parasti tas ir koda pārskatīšanas vai diskusijas rezultāts, taču mūsu kursā mēs to modelēsim, pievienojot jaunus vienumus mūsu CI darbību sarakstam.

Nepārtraukta integrācija parasti ietver zināmu testa pārklājumu. Pārbaudes pārklājuma prasības atšķiras, un parasti tās ir atrodamas dokumentā, ko sauc par "ieguldījuma vadlīnijām". Mēs saglabāsim to vienkāršu un pievienosim testu katrai mūsu kontrolsaraksta rindai.

Veicot uzdevumus, vispirms mēģiniet veikt testus. Ja instalējāt pareizi pre-commit āķis agrāk, tikko pievienotais tests tiks palaists, neizdosies un nekas netiks veikts. Ņemiet vērā, ka šādi mēs zinām, ka mūsu testi kaut ko pārbauda. Interesanti, ka, ja mēs sākām ar kodu pirms testiem, testu nokārtošana varētu nozīmēt, ka kods darbojās, kā paredzēts, vai arī testi faktiski neko nepārbauda. Turklāt, ja mēs vispirms nebūtu uzrakstījuši testus, mēs, iespējams, būtu par tiem aizmirsuši pavisam, jo ​​nekas mums to nebūtu atgādinājis.

Testa virzīta izstrāde (TDD)

TDD iesaka rakstīt testus pirms koda. Tipiska darbplūsma, izmantojot TDD, izskatās šādi.

1. Pievienojiet testu.
2. Palaidiet visus testus un pārliecinieties, ka jaunais tests neizdodas.
3. Uzrakstiet kodu.
4. Izpildiet testus, pārliecinieties, ka visi testi ir izturējuši.
5. Refaktorējiet savu kodu.
6. Atkārtojiet.

Tā kā nesekmīgo pārbaužu rezultāti parasti tiek parādīti sarkanā krāsā, bet sekmīgie rezultāti parasti tiek parādīti zaļā krāsā, cikls ir pazīstams arī kā sarkans-zaļš-refaktors.

️Uzdevums

Vispirms mēģiniet veikt testus un ļaujiet tiem neizdoties, pēc tam pievienojiet un apstipriniet pašu CI darbību saraksta tekstu. Jūs redzēsiet, ka testi iztur ("zaļi").
Pēc tam publicējiet jauno kodu attālajā repozitorijā un skatieties testus, kas tiek veikti GitHub saskarnē, kas atrodas lejupielādes pieprasījuma diskusijas un PR statusa atjauninājuma apakšdaļā.

1. Pārslēgties uz filiāli feature.

2. Pievienojiet šos testus ci.test.js pēc pēdējā zvana 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. Mēģiniet veikt testus. Ja pre-commit āķis ir uzstādīts, izpildes mēģinājums neizdosies.
4. Pēc tam pievienojiet šo tekstu 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. Veiciet un veiciet izmaiņas lokāli.
6. Publicējiet izmaiņas filiālē feature.

Tagad jums vajadzētu iegūt kaut ko līdzīgu šim

Komandas

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

Apvienot konfliktu

Dodieties uz izmaiņu pieprasījumu Soļu apskats.

Lai gan mēs neko nedarījām nepareizi un mūsu koda testi izturēja, mēs joprojām nevaram apvienot filiāli feature и master. Tas ir tāpēc, ka otrs pavediens bugfix tika apvienots ar master kamēr mēs strādājām pie šī PR.
Tas rada situāciju, kad attālā filiāle master ir jaunāka versija nekā tā, uz kuru mēs balstījām filiāli feature. Tāpēc mēs nevaram vienkārši attīt HEAD master līdz vītnes galam feature. Šādā situācijā mums ir jāapvieno vai jāpiemēro saistības feature rebase master. GitHub faktiski var veikt automātisku sapludināšanu, ja nav konfliktu. Diemžēl mūsu situācijā abās filiālēs ir konkurējošas izmaiņas failā ci.md. Šī situācija ir pazīstama kā sapludināšanas konflikts, un mums tas ir jāatrisina manuāli.

Apvienot vai pārbāzt

Apvienot

• Izveido papildu sapludināšanas apņemšanos un saglabā darba vēsturi.
  • Saglabā sākotnējās filiāļu saistības ar to oriģinālajiem laikspiedoliem un autoriem.
  • Saglabā saistību SHA un saites uz tām izmaiņu pieprasījumu diskusijās.
• Nepieciešama vienreizēja konflikta atrisināšana.
• Padara stāstu nelineāru.
  • Stāsts var būt grūti lasāms lielā zaru skaita dēļ (atgādina IDE kabeli).
  • Apgrūtina automātisko atkļūdošanu, piem. git bisect mazāk noderīgs — tas atradīs tikai sapludināšanas apņemšanos.

Atkārtot

• Atkārto darbības no pašreizējā zara virsū bāzes zaram vienu pēc otras.
  • Tiek ģenerētas jaunas saistības ar jauniem SHA, kā rezultātā GitHub izpildes atbilst sākotnējiem izvilkšanas pieprasījumiem, bet ne atbilstošajiem komentāriem.
  • Saistības procesā var apvienot un modificēt vai pat apvienot vienā.
• Var būt nepieciešams atrisināt vairākus konfliktus.
• Ļauj saglabāt lineāru stāstu.
  • Stāstu var būt vieglāk lasīt, ja tas nav pārāk garš bez saprātīga iemesla.
  • Automātiskā atkļūdošana un problēmu novēršana ir nedaudz vienkāršāka: padara to iespējamu git bisect, var padarīt automātisko atcelšanu skaidrāku un paredzamāku.
• Nepieciešama filiāles publicēšana ar migrētām saistībām ar karogu --force ja to izmanto ar vilkšanas pieprasījumiem.

Parasti komandas vienojas vienmēr izmantot vienu un to pašu stratēģiju, kad tām ir nepieciešams apvienot izmaiņas. Tā varētu būt “tīra” sapludināšana vai “tīra” apņemšanās augšpusē, vai kaut kas pa vidu, piemēram, interaktīva darbības veikšana augšpusē (git rebase -i) lokāli filiālēm, kas nav publicētas publiskajā repozitorijā, bet apvienotas "publiskajām" filiālēm.

Šeit mēs izmantosim sapludināšanu.

️Uzdevums

1. Pārliecinieties, vai kods atrodas vietējā filiālē master atjaunināts no attālās krātuves.
2. Pārslēgties uz filiāli feature.
3. Sāciet sapludināšanu ar filiāli master. Apvienošanas konflikts konkurējošo izmaiņu dēļ ci.md.
4. Atrisiniet konfliktu, lai tekstā paliktu gan mūsu CI darbību saraksts, gan piezīme par to.
5. Publicējiet sapludināšanas saistības attālā filiālē feature.
6. Pārbaudiet izvilkšanas pieprasījuma statusu GitHub lietotāja saskarnē un pagaidiet, līdz sapludināšana ir atrisināta.

Komandas

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

Lielisks darbs!

Jūs esat pabeidzis ar sarakstu, un tagad jums ir jāapstiprina ievilkšanas pieprasījums master.

️ Uzdevums: Apstipriniet izvilkšanas pieprasījumu "Soļu pārskatīšana"

1. Atveriet izvilkšanas pieprasījumu.
2. Noklikšķiniet uz "Apvienot vilkšanas pieprasījumu".
3. Noklikšķiniet uz "Apstiprināt sapludināšanu".
4. Noklikšķiniet uz "Dzēst filiāli", jo mums tas vairs nav vajadzīgs.

Šobrīd šī ir jūsu krātuve

Produkta kļūda

Ir teikts, ka "pārbaudi var izmantot, lai parādītu kļūdu esamību, bet nekad, lai parādītu to neesamību." Lai gan mums bija testi un tie mums neuzrādīja nekādas kļūdas, ražošanā iezagās mānīga kļūda.

Šādā gadījumā mums ir jārūpējas par:

• kas tiek izmantots ražošanā;
• kods pavedienā master ar kļūdu, no kuras izstrādātāji var sākt jaunu darbu.

Vai man vajadzētu atsaukt atpakaļ vai labot to nākamajā versijā?

Atgriešana ir process, kurā izvietojot zināmu labu iepriekšējo versiju ražošanas un atgriežot saistības, kurās ir kļūda. "Fixing forward" ir labojuma pievienošana master un pēc iespējas ātrāk izvietot jauno versiju. Tā kā API un datu bāzes shēmas mainās, kad kods tiek izvietots ražošanā, ar nepārtrauktu piegādi un labu testa pārklājumu, atgriešana parasti ir daudz grūtāka un riskantāka nekā to labošana nākamajā versijā.

Tā kā mūsu gadījumā ripināšana nav saistīta ar risku, mēs iesim šo ceļu, jo tas mums ļauj

• pēc iespējas ātrāk labojiet produkta kļūdu;
• ievadiet kodu master uzreiz piemērots jauna darba uzsākšanai.

️Uzdevums

1. Pārslēgties uz filiāli master lokāli.
2. Atjauniniet vietējo repozitoriju no attālās repozitorija.
3. Atsaukt PR sapludināšanas apņemšanos Soļu apskats в master.
4. Publicējiet izmaiņas attālajā repozitorijā.

Šī ir repozitorija vēsture, kurai ir atsaukta sapludināšanas darbība

Komandas

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

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

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

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

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

️ Pašpārbaude

Pārliecinies ka ci.md pēc sapludināšanas apņemšanās atsaukšanas vairs nesatur tekstu "sneaky bug".

Labojiet CI darbību sarakstu un atgrieziet to galvenajam

Mēs esam pilnībā atsaukuši filiāles apvienošanas saistības. feature. Labā ziņa ir tā, ka tagad mums nav kļūdu master. Sliktā ziņa ir tā, ka arī mūsu vērtīgais nepārtrauktās integrācijas darbību saraksts ir pazudis. Tātad ideālā gadījumā mums ir jāpiemēro labojums saistībām no feature un atgriezt tos master kopā ar labojumu.

Mēs varam risināt problēmu dažādos veidos:

• atsaukt saistību, kas atceļ sapludināšanu feature с master;
• pārvietot apņemas no bijušā feature.

Šajā gadījumā dažādas izstrādes komandas izmanto dažādas pieejas, taču mēs pārvietosim noderīgās saistības uz atsevišķu filiāli un izveidosim atsevišķu izvilkšanas pieprasījumu šai jaunajai filiālei.

️Uzdevums

1. Izveidojiet pavedienu ar nosaukumu feature-fix un pārslēdzieties uz to.

2. Migrēt visas saistības no iepriekšējās filiāles feature uz jaunu pavedienu. Atrisiniet sapludināšanas konfliktus, kas radās migrācijas laikā.

   

3. Pievienojiet regresijas testu ci.test.js:

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

4. Izpildiet testus lokāli, lai pārliecinātos, ka tie neizdodas.
5. Noņemiet tekstu "ar viltīgu kļūdu". ci.md.
6. Pievienojiet indeksam testa izmaiņas un soļu saraksta izmaiņas un veiciet tās.
7. Publicējiet filiāli attālā repozitorijā.

Jums vajadzētu beigties ar kaut ko līdzīgu šim:

Komandas

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

Izveidojiet izvilkšanas pieprasījumu.

Izveidojiet izvilkšanas pieprasījumu ar nosaukumu Funkcijas labošana... Uzstādīt feature-fix kā "galvas zars" un master piemēram, "bāzes filiāle".
Lūdzu, uzgaidiet, kamēr testi ir pabeigti. Pārbaužu statusu varat redzēt PR diskusijas apakšā.

Pārliecinieties, vai esat instalējis master viņa dakša repozitorijs Es kā "bāzes filiāle" neatbildēšu uz pieprasījumu veikt izmaiņas kursa materiālu krātuvē.

Apstiprināt izvilkšanas pieprasījumu "Funkcijas labošana"

Paldies par labojumu! Lūdzu, apstipriniet izmaiņas master no izvilkšanas pieprasījuma.

️Uzdevums

1. Noklikšķiniet uz "Apvienot vilkšanas pieprasījumu".
2. Noklikšķiniet uz "Apstiprināt sapludināšanu".
3. Noklikšķiniet uz "Dzēst filiāli", jo mums tas vairs nav vajadzīgs.

Tas ir tas, kam jums šobrīd vajadzētu būt.

Apsveicam!

Jūs esat pabeidzis visas darbības, ko cilvēki parasti veic nepārtrauktas integrācijas laikā.

Ja pamanāt kādas problēmas ar kursu vai zināt, kā to uzlabot, lūdzu, izveidojiet problēmu krātuves ar kursa materiāliem. Šim kursam ir arī interaktīvā versija izmantojot GitHub Learning Lab kā platformu.

Avots: www.habr.com