Hefur þú lært Git skipanir en vilt ímynda þér hvernig samfelld samþætting (CI) virkar í raun og veru? Eða viltu kannski hámarka daglega starfsemi þína? Þetta námskeið mun veita þér hagnýta færni í samfelldri samþættingu með því að nota GitHub geymslu. Þessu námskeiði er ekki ætlað að vera töframaður sem þú getur einfaldlega smellt í gegnum, þvert á móti muntu framkvæma sömu aðgerðir og fólk raunverulega gerir í vinnunni, á sama hátt og það gerir það. Ég mun útskýra kenninguna þegar þú ferð í gegnum skrefin sem taka þátt.

Hvað gerum við?

Eftir því sem okkur líður munum við smám saman búa til lista yfir dæmigerð CI skref, sem er frábær leið til að muna þennan lista. Með öðrum orðum, við munum búa til lista yfir aðgerðir sem þróunaraðilar grípa til á meðan þeir stunda stöðuga samþættingu, gera stöðuga samþættingu. Við munum einnig nota einfalt sett af prófum til að færa CI ferli okkar nær því raunverulega.

Þessi GIF sýnir á skýringarmynd skuldbindingarnar í geymslunni þinni þegar þú ferð í gegnum námskeiðið. Eins og þú sérð er ekkert flókið hér og aðeins það nauðsynlegasta.

Þú munt fara í gegnum eftirfarandi staðlaða CI atburðarás:

• Vinna að eiginleikum;
• Notkun sjálfvirkra prófa til að tryggja gæði;
• Framkvæmd forgangsverkefnisins;
• Úrlausn átaka við sameiningu útibúa (sameina átök);
• Villa kemur upp í framleiðsluumhverfi.

Hvað munt þú læra?

Þú munt geta svarað eftirfarandi spurningum:

• Hvað er stöðug samþætting (CI)?
• Hvaða gerðir af sjálfvirkum prófum eru notaðar í CI og til að bregðast við hvaða aðgerðum er hrundið af stað?
• Hvað eru dráttarbeiðnir og hvenær er þörf á þeim?
• Hvað er Test Driven Development (TDD) og hvernig tengist það CI?
• Ætti ég að sameina eða endurbyggja breytingarnar?
• Fara til baka eða laga í næstu útgáfu?

Í fyrstu þýddi ég hluti eins og „pull requests“ alls staðar, en í kjölfarið ákvað ég að skila orðasamböndum á ensku sums staðar til að draga úr brjálæðisstigi í textanum. Ég mun stundum nota „forritari surzhik“ eins og hina dásamlegu sögn „skuldbinda“ þar sem fólk notar það í raun í vinnunni.

Hvað er samfelld samþætting?

Stöðug samþætting, eða CI, er tæknileg aðferð þar sem hver liðsmaður samþættir kóðann sinn í sameiginlega geymslu að minnsta kosti einu sinni á dag og kóðinn sem myndast verður að minnsta kosti að vera byggður án villna.

Það er ágreiningur um þetta kjörtímabil

Ágreiningsefnið er tíðni samþættingar. Sumir halda því fram að sameining kóða aðeins einu sinni á dag sé ekki nóg til að samþætta stöðugt. Dæmi er gefið um lið þar sem allir taka ferskan kóða á morgnana og samþætta hann einu sinni á kvöldin. Þó að þetta sé sanngjarnt andmæli, er almennt talið að skilgreiningin einu sinni á dag sé sæmilega hagnýt, sértæk og hentug fyrir teymi af mismunandi stærðum.

Önnur mótmæli er að C++ er ekki lengur eina tungumálið sem notað er í þróun og einfaldlega að krefjast villulausrar samsetningar sem leið til staðfestingar er veik. Sumt sett af prófum (til dæmis einingapróf sem eru framkvæmd á staðnum) verður einnig að ljúka með góðum árangri. Í augnablikinu stefnir samfélagið í átt að því að gera þetta að kröfu og í framtíðinni mun "byggja + einingapróf" líklega verða algeng venja, ef það hefur ekki gert það nú þegar.

Stöðug samþætting frábrugðið stöðuga afhendingu (Stöðug afhending, geisladiskur) að því leyti að það þarf ekki útgáfuframbjóðanda eftir hverja samþættingarlotu.

Listi yfir skref sem við munum nota á námskeiðinu

1. Dragðu inn nýjasta kóðann. Búðu til útibú frá master. Byrjaðu að vinna.
2. Búðu til skuldbindingar fyrir nýja útibúið þitt. Byggja og prófa á staðnum. Pass? Farðu í næsta skref. Misheppnast? Lagfærðu villur eða próf og reyndu aftur.
3. Ýttu á ytri geymsluna þína eða ytri útibú.
4. Búðu til dráttarbeiðni. Ræddu breytingarnar, bættu við fleiri skuldbindingum eftir því sem umræðan heldur áfram. Láttu próf standast á eiginleikagreininni.
5. Sameina/endurbasa skuldbindingar frá meistara. Láttu próf standast sameiningarniðurstöðuna.
6. Dreifðu frá eiginleikagreininni til framleiðslu.
7. Ef allt er gott í framleiðslu í einhvern tíma skaltu sameina breytingar í master.

️ Undirbúningur

Gakktu úr skugga um að þú sért með réttan hugbúnað

Til að taka þetta námskeið þarftu Node.js и Git viðskiptavinur.

Þú getur notað hvaða Git viðskiptavin sem er, en ég mun aðeins veita skipanir fyrir skipanalínuna.

Gakktu úr skugga um að þú hafir Git viðskiptavin uppsettan sem styður skipanalínuna

Ef þú ert ekki enn með Git biðlara sem styður skipanalínuna geturðu fundið uppsetningarleiðbeiningar hér.

Undirbúðu geymsluna

Þú þarft að búa til persónulegt eintak (gaffli) sniðmátsgeymsla með kóða fyrir námskeiðið á GitHub. Við skulum samþykkja að kalla þetta persónulega eintak námskeiðageymslu.

Búið? Ef þú hefur ekki breytt sjálfgefnum stillingum er líklegast að námskeiðsgeymslan þín sé kölluð continuous-integration-team-scenarios-students, það er staðsett á GitHub reikningnum þínum og slóðin lítur svona út

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

Ég mun einfaldlega hringja í þetta heimilisfang <URL репозитория>.

Horn sviga eins og <тут> þýðir að þú verður að skipta út slíkri tjáningu fyrir viðeigandi gildi.

Gakktu úr skugga um það GitHub aðgerðir innifalinn fyrir þessa námskeiðsgeymslu. Ef þeir eru ekki virkir, vinsamlegast virkjaðu þá með því að smella á stóra hnappinn á miðri síðunni, sem þú kemst að með því að smella á Actions í GitHub viðmótinu.

Þú munt ekki geta lokið námskeiðinu eftir leiðbeiningunum mínum ef GitHub Actions eru ekki virkjaðar.

Þú getur alltaf notað getu GitHub til að gera Markdown til að sjá núverandi stöðu listans sem við erum að semja hér

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

Um svörin

Þó að besta leiðin til að klára þetta námskeið sé að gera það sjálfur, gætir þú átt í erfiðleikum.

Ef þér finnst þú ekki skilja hvað þú átt að gera og getur ekki haldið áfram, geturðu skoðað þráðinn solution, sem er í upphafsgeymslunni þinni.
Vinsamlegast ekki sameinast solution в master á námskeiðinu. Þú getur notað þessa grein til að finna út hvað á að gera, eða til að bera saman kóðann þinn við höfundinn, með því að nota alla möguleikana sem Git gefur okkur. Ef þú ert alveg týndur geturðu alveg skipt um útibúið þitt master á grein solution og endurstilltu síðan vinnuskrána þína á námskeiðsþrepið sem þú þarft.

Notaðu þetta bara ef þú þarft á því að halda

Sendu kóðann þinn

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

Þessar skipanir

• endurnefna master в master-backup;
• endurnefna solution в master;
• útskráning í nýtt útibú master og endurskrifa innihald vinnuskrárinnar;
• Búðu til "lausn" útibú frá "master" (sem áður var "lausn") ef þú þarft "lausn" útibú í framtíðinni.

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

Eftir þessi skref geturðu notað git log master til að finna út hvaða skuldbindingu þú þarft.
Þú getur endurstillt vinnuskrána þína á þessa skuldbindingu svona:

git reset --hard <the SHA you need>

Ef þú ert ánægður með niðurstöðuna þarftu á einhverjum tímapunkti að birta útgáfuna þína af geymslunni á ytri geymslu. Ekki gleyma að tilgreina fjarútibúið sérstaklega þegar þú gerir þetta.

git push --force origin master

Vinsamlegast athugaðu að við notum git push --force. Það er ólíklegt að þú viljir gera þetta mjög oft, en við höfum mjög sérstaka atburðarás hér með einn geymslunotanda sem að auki skilur hvað hann er að gera.

Að byrja að vinna

Við skulum byrja að setja saman lista okkar yfir CI skref. Venjulega byrjarðu þetta skref með því að skoða nýjustu útgáfuna af kóðanum frá ytri geymslunni, en við erum ekki með staðbundna geymslu ennþá, svo við klónum hana úr ytri geymslunni í staðinn.

️ Verkefni: uppfærðu staðbundna geymsluna, búðu til útibú frá master, Byrjaðu að vinna

1. Klóna námskeiðsgeymsluna úr <URL репозитория>.
2. Hlaupa npm install í kennsluskránni; Við þurfum það til að setja upp Jest, sem við notum til að keyra próf.
3. Búðu til útibú og gefðu henni nafn feature. Skiptu yfir á þennan þráð.

4. Bættu prófkóða við ci.test.js á milli athugasemda þar sem ég er beðin um að gera þetta.

   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. Bættu texta við skrána með fyrstu 4 skrefunum 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.  

   Lið

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

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

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

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

Búðu til skuldbindingar um nýtt útibú, byggðu og prófaðu á staðnum

Við ætlum að setja upp prófin til að keyra áður en við skuldbindum okkur, og skuldbindum síðan kóðann.

Dæmigerðar aðstæður þegar próf keyra sjálfkrafa

• Staðbundið:
  • Stöðugt eða til að bregðast við viðeigandi kóðabreytingum;
  • Við vistun (fyrir túlkuð eða JIT-samsett tungumál);
  • Við samsetningu (þegar þörf er á samantekt);
  • Á skuldbindingu;
  • Þegar birt er í sameiginlegri geymslu.

• Á byggingarþjóninum eða byggingarumhverfinu:
  • Þegar kóði er birtur í persónulegu útibúi/geymsla.
  • Verið er að prófa kóðann í þessum þræði.
  • Möguleg niðurstaða samrunans er prófuð (venjulega með master).
  • Sem samfellt samþættingarstig/samfelld afhendingarleiðslu

Venjulega, því hraðar sem prófunarsvíta keyrir, því oftar hefur þú efni á að keyra það. Dæmigerð stigadreifing gæti litið svona út.

• Hratt einingapróf - meðan á smíði stendur, í CI leiðslum
• Hæg einingapróf, hröð íhluta- og samþættingarpróf - á skuldbindingu, í CI leiðslum
• Hæg íhluta- og samþættingarpróf - í CI leiðslum
• Öryggisprófanir, álagsprófanir og aðrar tímafrekar eða dýrar prófanir - í CI/CD leiðslum, en aðeins í ákveðnum stillingum/áföngum/leiðslum smíðinnar, til dæmis þegar útgáfuframbjóðandi er útbúinn eða þegar keyrt er handvirkt.

️Verkefni

Ég legg til að keyra prófin handvirkt fyrst með því að nota skipunina npm test. Eftir það skulum við bæta við git krók til að keyra prófin okkar á commit. Það er einn galli: Git krókar eru ekki taldir hluti af geymslunni og því er ekki hægt að klóna þær úr GitHub ásamt restinni af námskeiðsefninu. Til að setja upp krók þarftu að keyra install_hook.sh eða afritaðu skrána repo/hooks/pre-commit í staðbundna skrá .git/hooks/.
Þegar þú skuldbindur þig muntu sjá að próf eru keyrð og þau athuga hvort ákveðin leitarorð séu til staðar á listanum.

1. Keyrðu prófin handvirkt með því að keyra skipunina npm test í námskeiðageymslumöppunni þinni. Staðfestu að prófunum hafi verið lokið.
2. Settu commit krók (pre-commit krók) með því að hlaupa install_hook.sh.
3. Sendu breytingarnar þínar á staðbundna geymsluna þína.
4. Gakktu úr skugga um að prófanir séu keyrðar áður en þú skuldbindur þig.

Geymslan þín ætti að líta svona út eftir að hafa fylgt þessum skrefum.

Lið

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

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

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

Birtu kóða á fjarlægri geymslu eða ytri útibú

Þegar þeir eru búnir að vinna á staðnum, gera verktaki venjulega kóðann sinn aðgengilegan almenningi svo hann geti að lokum verið samþættur almenningi. Með GitHub er þessu venjulega náð með því að birta verkið annað hvort í persónulegu afriti af geymslunni (persónulega gaffli) eða persónulegu útibúi.

• Með gafflum klónar verktaki fjarlæga sameiginlega geymslu og býr til persónulegt fjarafrit af henni, einnig þekkt sem gaffal. Það klónar síðan þessa persónulegu geymslu til að vinna með á staðnum. Þegar verkinu er lokið og skuldbindingarnar eru gerðar, ýtir hann þeim í gaffalinn sinn, þar sem þeir eru aðgengilegir öðrum og hægt er að samþætta þær í sameiginlega geymsluna. Þessi aðferð er almennt notuð í opnum uppspretta verkefnum á GitHub. Það er líka notað í framhaldsnámskeiðinu mínu [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Önnur aðferð er að nota aðeins eina fjargeymslu og aðeins telja útibúið master sameiginleg geymsla „varin“. Í þessari atburðarás birta einstakir forritarar kóðann sinn í útibú fjarlægrar geymslu svo aðrir geti skoðað þennan kóða, ef allt er í lagi, sameinað hann við master sameiginleg geymsla.

Í þessu tiltekna námskeiði munum við nota verkflæði sem notar útibú.

Við skulum birta kóðann okkar.

️Verkefni

• Birtu breytingar á ytri útibúi með sama nafni og starfandi útibú

Lið

git push --set-upstream origin feature

Búðu til dráttarbeiðni

Búðu til dráttarbeiðni með titli Skref endurskoðun... Setja upp feature eins og "höfuðgrein" og master eins og "grunngrein".

Gakktu úr skugga um að þú hafir sett upp master í hans gaffla geymslunni Sem „grunnútibú“ mun ég ekki svara beiðnum um breytingar á námsgagnageymslunni.

Í GitHub tungumál er "grunngreinin" útibúið sem þú byggir vinnuna þína á og "höfuðgreinin" er útibúið sem inniheldur fyrirhugaðar breytingar.

Ræddu breytingarnar, bættu við nýjum skuldbindingum þegar umræðan heldur áfram

Dragabeiðni (PR)

Dragabeiðni (PR) er leið til að ræða og skjalfesta kóða, ásamt endurskoðun á reglum. Pull beiðnir eru nefndar eftir almennri leið til að samþætta einstakar breytingar í heildarkóðann. Venjulega klónar einstaklingur ytri opinbera geymslu verkefnisins og vinnur að kóðanum á staðnum. Eftir þetta setur hann kóðann í persónulegu fjargeymsluna sína og biður þá sem bera ábyrgð á opinberu geymslunni að sækja(draga) kóðann þess í staðbundnar geymslur sínar, þar sem þeir skoða og hugsanlega samþætta(sameinast) hans. Þetta hugtak er einnig þekkt undir öðrum nöfnum, td. beiðni um sameiningu.

Þú þarft í raun ekki að nota pull request eiginleika GitHub eða svipaðra kerfa. Þróunarteymi geta notað aðrar samskiptaaðferðir, þar á meðal augliti til auglitis samskipti, símtöl eða tölvupóst, en það eru samt ýmsar ástæður fyrir því að nota spjallbeiðnir. Hér eru nokkrar þeirra:

• skipulagðar umræður sem tengjast sérstökum kóðabreytingum;
• sem staður til að skoða endurgjöf um verk í vinnslu frá bæði sjálfvirkum prófurum og jafnöldrum;
• formfesting umsagna um kóða;
• svo að síðar getið þið komist að ástæðum og forsendum á bak við þennan eða hinn kóðann.

Venjulega býrðu til dráttarbeiðni þegar þú þarft að ræða eitthvað eða fá endurgjöf. Til dæmis, ef þú ert að vinna að eiginleikum sem hægt væri að útfæra á fleiri en einn hátt, geturðu búið til beiðni áður en þú skrifar fyrstu línu kóðans til að deila hugmyndum þínum og ræða áætlanir þínar við samstarfsaðila þína. Ef vinnan er einfaldari er opnað fyrir dráttarbeiðni þegar eitthvað hefur þegar verið gert, skuldbundið og hægt er að ræða það. Í sumum tilfellum gætirðu viljað opna PR eingöngu af gæðaeftirlitsástæðum: til að keyra sjálfvirk próf eða hefja endurskoðun kóða. Hvað sem þú ákveður, ekki gleyma að @nefna fólkið sem þú vilt hafa samþykki fyrir í beiðni þinni um að draga.

Venjulega, þegar þú býrð til PR, gerirðu eftirfarandi.

• Tilgreindu hverju þú hyggst breyta og hvar.
• Skrifaðu lýsingu sem útskýrir tilgang breytinganna. Þú gætir viljað:
  • bæta við einhverju mikilvægu sem er ekki augljóst af kóðanum, eða einhverju gagnlegu til að skilja samhengið, eins og viðeigandi #bugs og skuldbindingarnúmer;
  • @nefni alla sem þú vilt byrja að vinna með, eða þú getur @nefni þá í athugasemdum síðar;
  • biðja samstarfsfólk um að hjálpa við eitthvað eða athuga eitthvað ákveðið.

Þegar þú hefur opnað PR eru prófin sem eru stillt til að keyra í slíkum tilvikum framkvæmd. Í okkar tilviki mun þetta vera sama sett af prófum og við keyrðum á staðnum, en í alvöru verkefni geta verið fleiri prófanir og athuganir.

Vinsamlegast bíddu á meðan prófunum er lokið. Þú getur séð stöðu prófanna neðst í PR umræðunni í GitHub viðmótinu. Haltu áfram þegar prófunum er lokið.

️ Bættu við athugasemd um handahófi lista yfir CI skref

Listinn sem notaður er í þessu námskeiði er handahófskenndur og huglægur, við ættum að bæta við athugasemd um þetta.

️ Verkefni: Búðu til dráttarbeiðni fyrir þessa athugasemd

1. Skiptu yfir í útibú master.
2. Búðu til útibú sem heitir bugfix.
3. Bættu athugasemdatexta við lok skráarinnar 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. Skuldbinda breytingarnar.
5. Birta þráðinn bugfix í fjargeymslu.
6. Búðu til dráttarbeiðni sem heitir Bætir við athugasemd með höfuðgrein bugfix og grunngreininmaster.

Gakktu úr skugga um að þú hafir sett upp master í hans gaffla geymslunni Sem „grunnútibú“ mun ég ekki svara beiðnum um breytingar á námsgagnageymslunni.

Svona ætti geymslan þín að líta út.

Lið

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

Samþykkja dráttarbeiðni „Bætir við athugasemd“

️Verkefni

1. Búðu til dráttarbeiðni.
2. Smelltu á „Sameina dráttarbeiðni“.
3. Smelltu á „Staðfesta sameiningu“.
4. Smelltu á „Eyða útibú“, við þurfum það ekki lengur.

Þetta er skýringarmynd af skuldbindingum eftir sameiningu.

️ Haltu áfram að vinna og bæta við prófum

Samvinna við dráttarbeiðni leiðir oft til viðbótarvinnu. Þetta er venjulega afleiðing af endurskoðun kóða eða umræðu, en á námskeiðinu okkar ætlum við að móta þetta með því að bæta nýjum hlutum við listann okkar yfir CI skref.

Stöðug samþætting felur venjulega í sér nokkra prófun. Prófþekjukröfur eru mismunandi og eru venjulega að finna í skjali sem kallast eitthvað eins og "framlagsleiðbeiningar". Við munum hafa það einfalt og bæta við prófi fyrir hverja línu á gátlistanum okkar.

Þegar þú keyrir verkefni skaltu reyna að framkvæma prófin fyrst. Ef þú hefur sett upp rétt pre-commit krók fyrr, nýlega bætt við prófið verður keyrt, mun mistakast og ekkert verður skuldbundið. Athugaðu að þetta er hvernig við vitum að prófin okkar eru í raun að prófa eitthvað. Athyglisvert er að ef við byrjuðum á kóðanum fyrir prófin gæti það að standast prófin annað hvort þýtt að kóðinn virkaði eins og búist var við eða að prófin væru í raun ekki að prófa neitt. Auk þess, ef við hefðum ekki skrifað prófin í fyrsta lagi, hefðum við kannski gleymt þeim alveg, þar sem ekkert hefði minnt okkur á það.

Prófdrifin þróun (TDD)

TDD mælir með því að skrifa próf fyrir kóða. Dæmigerð vinnuflæði með TDD lítur svona út.

1. Bættu við prófi.
2. Keyrðu öll próf og tryggðu að nýja prófið mistókst.
3. Skrifaðu kóðann.
4. Keyrðu prófin, vertu viss um að öll próf standist.
5. Endurstilltu kóðann þinn.
6. Endurtaktu.

Vegna þess að niðurstöður prófa sem falla eru venjulega sýndar með rauðu, og þær sem hafa staðist eru venjulega sýndar með grænu, er hringrásin einnig þekkt sem rauð-græn-refactor.

️Verkefni

Reyndu fyrst að framkvæma prófin og láta þau mistakast, bættu síðan við og framkvæmdu texta CI skrefalistans sjálfs. Þú munt sjá að prófin standast ("græn").
Birtu síðan nýja kóðann á fjargeymsluna og horfðu á prófin keyra í GitHub viðmótinu neðst í umræðunni um dráttarbeiðni og PR stöðuuppfærslu.

1. Skiptu yfir í útibú feature.

2. Bættu þessum prófum við ci.test.js eftir síðasta símtal 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. Prófaðu að framkvæma prófin. Ef pre-commit krókurinn er settur upp mun commit tilraunin mistakast.
4. Bættu svo þessum texta við 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. Gerðu og framkvæmdu breytingar á staðnum.
6. Settu inn breytingar á útibúinu feature.

Þú ættir nú að hafa eitthvað svona

Lið

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

Sameina átök

Farðu í Breytingarbeiðni Skref endurskoðun.

Jafnvel þó að við höfum ekki gert neitt rangt og prófin fyrir kóðann okkar staðist, getum við samt ekki sameinað útibúið feature и master. Það er vegna þess að hinn þráðurinn bugfix var sameinað master á meðan við vorum að vinna í þessu PR.
Þetta skapar aðstæður þar sem afskekkt útibú master er með nýrri útgáfu en þá sem við byggðum útibúið á feature. Vegna þessa getum við ekki bara spólað HEAD til baka master til enda þráðarins feature. Í þessari stöðu þurfum við annað hvort að sameina eða beita skuldbindingum feature endurbæta master. GitHub getur í raun framkvæmt sjálfvirkar sameiningar ef engin árekstrar eru. Því miður, í okkar aðstæðum, eru báðar greinar með samkeppnisbreytingar í skránni ci.md. Þetta ástand er þekkt sem samrunaátök og við þurfum að leysa það handvirkt.

Sameina eða endurbyggja

Sameina

• Býr til viðbótar samrunaskuldbindingu og vistar vinnuferilinn.
  • Varðveitir upprunalegu skuldbindingar útibúa með upprunalegum tímastimplum og höfundum.
  • Vistar SHA af skuldbindingum og tenglum á þær í umræðum um breytingarbeiðnir.
• Krefst einu sinni lausn ágreinings.
• Gerir söguna ólínulega.
  • Sagan getur verið erfið aflestrar vegna mikils fjölda útibúa (minnir á IDE snúru).
  • Gerir sjálfvirka villuleit erfiðari, t.d. git bisect minna gagnlegt - það mun aðeins finna samruna skuldbindinguna.

Endurbyrgð

• Endurspilar skuldbindingar frá núverandi grein ofan á grunngreininni hver á eftir annarri.
  • Nýjar skuldbindingar með nýjum SHA eru búnar til, sem veldur því að skuldbindingarnar í GitHub passa við upprunalegu dráttarbeiðnirnar, en ekki samsvarandi athugasemdir.
  • Hægt er að sameina skuldbindingar aftur og breyta í ferlinu, eða jafnvel sameina í eina.
• Það gæti þurft að leysa mörg árekstra.
• Gerir þér kleift að viðhalda línulegri sögu.
  • Sagan getur verið auðveldari aflestrar svo framarlega sem hún er ekki of löng án skynsamlegrar ástæðu.
  • Sjálfvirk kembiforrit og bilanaleit er aðeins auðveldara: gerir það mögulegt git bisect, getur gert sjálfvirkar afturköllun skýrari og fyrirsjáanlegri.
• Krefst útgáfu útibús með fluttar skuldbindingar með fána --force þegar það er notað með dragbeiðnum.

Venjulega eru lið sammála um að nota alltaf sömu stefnu þegar þau þurfa að sameina breytingar. Þetta gæti verið „hrein“ sameining eða „hrein“ commit ofan á, eða eitthvað þar á milli, eins og að gera commit ofan á gagnvirkt(git rebase -i) staðbundið fyrir útibú sem ekki eru birt í opinberu geymslunni, en sameinast fyrir „opinber“ útibú.

Hér munum við nota sameiningu.

️Verkefni

1. Gakktu úr skugga um að kóðinn sé í útibúi á staðnum master uppfært úr fjarlægri geymslu.
2. Skiptu yfir í útibú feature.
3. Hefja sameiningu við útibú master. Samrunaátök vegna samkeppnisbreytinga á ci.md.
4. Leysaðu ágreininginn þannig að bæði listi okkar yfir CI skref og athugasemd um það haldist í textanum.
5. Birta samrunaskuldbindingu fyrir ytra útibú feature.
6. Athugaðu stöðu togbeiðnarinnar í GitHub notendaviðmótinu og bíddu þar til sameiningin er leyst.

Lið

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

Frábært starf!

Þú ert búinn með listann og nú þarftu að samþykkja inndráttarbeiðnina master.

️ Verkefni: Samþykkja dráttarbeiðni „Skref endurskoðun“

1. Opnaðu dráttarbeiðni.
2. Smelltu á „Sameina dráttarbeiðni“.
3. Smelltu á „Staðfesta sameiningu“.
4. Smelltu á „Eyða grein“ þar sem við þurfum það ekki lengur.

Þetta er geymslan þín í augnablikinu

Vöruvilla

Það er sagt að "prófun er hægt að nota til að sýna tilvist villna, en aldrei til að sýna fjarveru þeirra." Jafnvel þó að við hefðum prófað og þær sýndu okkur engar villur, læddist lævís galla í framleiðslu.

Í atburðarás sem þessari verðum við að gæta að:

• hvað er notað í framleiðslu;
• kóða í þræðinum master með villu, sem verktaki getur hafið nýtt verk frá.

Ætti ég að snúa til baka eða laga það í næstu útgáfu?

Afturköllun er ferlið við að dreifa þekktri, góðri fyrri útgáfu í framleiðslu og afturkalla skuldbindingar sem innihalda villuna. "Fixing forward" er viðbót við lagfæringu við master og innleiða nýju útgáfuna eins fljótt og auðið er. Vegna þess að API og gagnagrunnsskemu breytast eftir því sem kóða er dreift til framleiðslu, með stöðugri afhendingu og góðri prufuþekju, er afturköllun venjulega mun erfiðari og áhættusamari en að laga það í næstu útgáfu.

Þar sem það fylgir engin áhætta í okkar tilfelli að rúlla til baka, þá munum við fara þessa leið, því það gerir okkur kleift

• laga villuna á vörunni eins fljótt og auðið er;
• gera kóða inn master strax hentugur til að hefja nýtt starf.

️Verkefni

1. Skiptu yfir í útibú master á staðnum.
2. Uppfærðu staðbundna geymsluna úr ytri geymslunni.
3. Afturkalla PR samruna skuldbindinguna Skref endurskoðun в master.
4. Birta breytingar á fjarlægri geymslu.

Þetta er saga geymslu með sameiningu skuldbindingu afturkölluð

Lið

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

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

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

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

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

️ Sjálfspróf

Gakktu úr skugga um það ci.md inniheldur ekki lengur textann "sneaky bug" eftir að samrunaframkvæmd hefur verið afturkallað.

Lagaðu listann yfir CI skref og skilaðu honum til masters

Við höfum algjörlega snúið við samrunaskuldbindingu útibúsins. feature. Góðu fréttirnar eru þær að nú er engin villa í okkur master. Slæmu fréttirnar eru þær að dýrmætur listi okkar yfir samfellda samþættingarskref er líka horfinn. Svo, helst, þurfum við að beita lagfæringunni á skuldbindingarnar frá feature og skila þeim til master ásamt lagfæringunni.

Við getum nálgast vandamálið á mismunandi vegu:

• afturkalla skuldbindingu sem afturkallar samruna feature с master;
• færa skuldbindur sig frá fyrrv feature.

Mismunandi þróunarteymi nota mismunandi aðferðir í þessu tilfelli, en við munum færa gagnlegar skuldbindingar yfir í sérstaka útibú og búa til sérstaka dráttarbeiðni fyrir þessa nýju útibú.

️Verkefni

1. Búðu til þráð sem heitir feature-fix og skiptu yfir í það.

2. Flyttu allar skuldbindingar frá fyrrum útibúi feature á nýjan þráð. Leysa samrunaárekstra sem áttu sér stað við flutninginn.

   

3. Bættu aðhvarfsprófi við ci.test.js:

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

4. Keyrðu prófin á staðnum til að ganga úr skugga um að þau falli ekki.
5. Fjarlægðu textann „með lúmskum galla“ inn ci.md.
6. Bættu prófbreytingum og skrefalistabreytingum við vísitöluna og framkvæmdu þær.
7. Birtu útibúið á fjarlægri geymslu.

Þú ættir að enda með eitthvað svipað þessu:

Lið

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

Búðu til dráttarbeiðni.

Búðu til dráttarbeiðni með titli Að laga eiginleikann... Setja upp feature-fix eins og "höfuðgrein" og master eins og "grunngrein".
Vinsamlegast bíddu á meðan prófunum lýkur. Hægt er að sjá stöðuna á prófunum neðst í PR-umræðunni.

Gakktu úr skugga um að þú hafir sett upp master í hans gaffla geymslunni Sem „grunnútibú“ mun ég ekki svara beiðnum um breytingar á námsgagnageymslunni.

Samþykkja dráttarbeiðni „Að laga eiginleikann“

Takk fyrir leiðréttinguna! Vinsamlegast samþykktu breytingar á master frá draga beiðni.

️Verkefni

1. Smelltu á „Sameina dráttarbeiðni“.
2. Smelltu á „Staðfesta sameiningu“.
3. Smelltu á „Eyða grein“ þar sem við þurfum það ekki lengur.

Þetta er það sem þú ættir að hafa í augnablikinu.

Til hamingju!

Þú hefur lokið öllum skrefum sem fólk tekur venjulega við samfellda samþættingu.

Ef þú tekur eftir einhverjum vandamálum með námskeiðið eða veist hvernig á að bæta það, vinsamlegast búðu til mál inn geymslur með námskeiðsgögnum. Þetta námskeið hefur einnig gagnvirk útgáfa með því að nota GitHub Learning Lab sem vettvang.

Heimild: www.habr.com