Megtanulta a Git parancsokat, de szeretné elképzelni, hogyan működik a folyamatos integráció (CI) a valóságban? Vagy esetleg szeretné optimalizálni napi tevékenységeit? Ez a kurzus gyakorlati készségeket ad a folyamatos integrációhoz a GitHub adattár használatával. Ennek a kurzusnak nem célja egy varázsló, amelyen egyszerűen átkattinthat, hanem éppen ellenkezőleg, ugyanazokat a műveleteket hajtja végre, amelyeket az emberek ténylegesen a munkahelyükön, ugyanúgy, ahogyan ők teszik. Elmagyarázom az elméletet, miközben végigmegy az érintett lépéseken.

Mit csináljunk?

Ahogy haladunk előre, fokozatosan elkészítjük a tipikus CI-lépések listáját, ami nagyszerű módja annak, hogy megjegyezzük ezt a listát. Más szóval, listát fogunk készíteni azokról a tevékenységekről, amelyeket a fejlesztők a folyamatos integráció és a folyamatos integráció során hajtanak végre. Egy egyszerű tesztkészletet is használunk, hogy a CI folyamatunkat közelebb hozzuk a valódihoz.

Ez a GIF sematikusan mutatja a tárolójában lévő véglegesítéseket, ahogy halad a tanfolyamon. Mint látható, itt nincs semmi bonyolult, és csak a legszükségesebb.

A következő szabványos CI-forgatókönyveken kell keresztülmennie:

• Dolgozzon egy funkción;
• Automatizált tesztek alkalmazása a minőség biztosítása érdekében;
• A kiemelt feladat megvalósítása;
• Konfliktusmegoldás fiókok összevonásakor (összevonási konfliktus);
• Hiba történik éles környezetben.

mit fogsz tanulni?

Az alábbi kérdésekre tud majd válaszolni:

• Mi az a folyamatos integráció (CI)?
• Milyen típusú automatizált teszteket használnak a CI-ben, és milyen műveletekre reagálnak?
• Mik azok a lehívási kérések és mikor van rájuk szükség?
• Mi az a tesztvezérelt fejlesztés (TDD), és hogyan kapcsolódik a CI-hez?
• Egyesítsem vagy módosítsam a változtatásokat?
• Visszaállítja vagy javítja a következő verzióban?

Eleinte mindenhol lefordítottam az olyan dolgokat, mint a „pull requests”, de ennek eredményeként úgy döntöttem, hogy egyes helyeken angol nyelvű kifejezéseket adok vissza, hogy csökkentsem a szöveg őrültségét. Időnként a „programozó surzhik”-ot fogom használni, mint a csodálatos „commit” igét, ahol az emberek ténylegesen használják a munkájuk során.

Mi a folyamatos integráció?

Folyamatos integráció, vagy CI, egy olyan technikai gyakorlat, amelyben minden csapattag naponta legalább egyszer integrálja a kódját egy közös tárolóba, és a kapott kódot legalább hibamentesen kell megépíteni.

Ezzel a kifejezéssel kapcsolatban nézeteltérések vannak

A vita pontja az integráció gyakorisága. Egyesek azzal érvelnek, hogy a kód napi egyszeri összevonása nem elegendő a folyamatos integrációhoz. Példa erre egy csapat, ahol mindenki reggel friss kódot vesz, és este egyszer integrálja. Bár ez ésszerű kifogás, általánosan elfogadott, hogy a napi egyszeri meghatározás ésszerűen praktikus, specifikus és alkalmas különböző méretű csapatok számára.

Egy másik kifogás az, hogy már nem a C++ az egyetlen nyelv, amelyet a fejlesztés során használnak, és egyszerűen hibamentes összeállítást igényelni, mint érvényesítési módot, gyenge. Egyes tesztkészleteknek (például a helyben végrehajtott egységteszteknek) szintén sikeresen be kell fejeződniük. Jelenleg a közösség halad afelé, hogy ezt kötelezővé tegyék, és a jövőben valószínűleg bevett gyakorlattá válnak a "build + unit tesztek", ha eddig nem.

Folyamatos integráció eltér a folyamatos szállítás (Continuous Delivery, CD), mivel nem igényel kiadásjelöltet minden egyes integrációs ciklus után.

Azon lépések listája, amelyeket a tanfolyam során használunk

1. Húzza be a legújabb kódot. Hozzon létre egy ágat innen master. Kezdj dolgozni.
2. Hozzon létre kötelezettségvállalásokat az új ágon. Építsen és teszteljen helyben. Passz? Lépjen a következő lépésre. Sikertelen? Javítsa ki a hibákat vagy teszteket, és próbálja újra.
3. Nyomjon a távoli adattárra vagy távoli ágra.
4. Hozzon létre egy lehívási kérelmet. Beszélje meg a változtatásokat, és adjon hozzá további véglegesítéseket, ahogy a vita folytatódik. Tegye át a teszteket a szolgáltatási ágon.
5. Egyesítés/újrabázis véglegesítés a mestertől. A tesztek továbbadják az egyesítés eredményét.
6. Telepítés a szolgáltatási ágtól a termelésig.
7. Ha egy ideig minden rendben van a gyártásban, egyesítse a változtatásokat a masterhez.

️ Felkészülés

Győződjön meg arról, hogy a megfelelő szoftverrel rendelkezik

A tanfolyam elvégzéséhez szüksége lesz node.js и Git kliens.

Bármilyen Git klienst használhat, de csak a parancssorhoz adok parancsokat.

Győződjön meg arról, hogy telepítve van egy Git-kliens, amely támogatja a parancssort

Ha még nem rendelkezik olyan Git-klienssel, amely támogatja a parancssort, megtalálja a telepítési utasításokat itt.

Készítse elő az adattárat

Létre kell hoznia egy személyes másolatot (villát) sablon tárház a kurzus kódjával a GitHubon. Egyezzünk meg abban, hogy ezt a személyes példányt nevezzük tanfolyam tárháza.

Kész? Ha nem változtatta meg az alapértelmezett beállításokat, akkor a rendszer valószínűleg meghívja a kurzustárat continuous-integration-team-scenarios-students, az Ön GitHub-fiókjában található, és az URL így néz ki

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

Egyszerűen felhívom ezt a címet <URL репозитория>.

Szög zárójelek, mint <тут> azt jelenti, hogy egy ilyen kifejezést a megfelelő értékre kell cserélnie.

Győződjön meg arról, hogy GitHub-műveletek tartalmazza ehhez a kurzustárhoz. Ha nincsenek engedélyezve, kérjük, engedélyezze őket az oldal közepén található nagy gombra kattintva, amelyet a GitHub felületén a Műveletek gombra kattintva érhet el.

Ha a GitHub-műveletek nincsenek engedélyezve, nem tudja befejezni a tanfolyamot az utasításaim szerint.

Bármikor használhatja a GitHub képességét a Markdown megjelenítésére, hogy megtekinthesse az általunk összeállított lista aktuális állapotát

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

A válaszokról

Bár a tanfolyam elvégzésének legjobb módja, ha saját kezűleg végezzük el, nehézségei adódhatnak.

Ha úgy érzed, hogy nem érted, mit csinálj, és nem tudod folytatni, akkor belenézhetsz a szálba solution, amely a kezdő tárolóban található.
Kérem, ne egyesítse solution в master a tanfolyam alatt. Ezt az ágat használhatja arra, hogy kitalálja, mit kell tennie, vagy összehasonlíthatja kódját a szerző kódjával, kihasználva a Git által biztosított összes lehetőséget. Ha teljesen elveszett, teljesen kicserélheti az ágát master egy ágon solution majd állítsa vissza a munkakönyvtárat a kívánt kurzuslépésre.

Csak akkor használja, ha valóban szüksége van rá

Végezze el a kódot

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

Ezeket a parancsokat

• átnevezni master в master-backup;
• átnevezni solution в master;
• pénztár egy új fiókba master és írja át a munkakönyvtár tartalmát;
• Hozzon létre egy "megoldás" ágat a "master"-ből (ami korábban "megoldás" volt) arra az esetre, ha a jövőben szüksége lenne egy "megoldás" ágra.

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

Ezen lépések után használhatja git log master hogy rájöjjön, melyik kötelezettségvállalásra van szüksége.
A munkakönyvtárat a következőképpen állíthatja vissza erre a véglegesítésre:

git reset --hard <the SHA you need>

Ha elégedett az eredménnyel, egy bizonyos ponton közzé kell tennie a lerakat verzióját egy távoli tárolóban. Ne felejtse el kifejezetten megadni a távoli ágat, amikor ezt teszi.

git push --force origin master

Felhívjuk figyelmét, hogy használjuk git push --force. Nem valószínű, hogy ezt nagyon gyakran szeretné megtenni, de van egy nagyon konkrét forgatókönyvünk egy adattár-felhasználóval, aki ráadásul érti is, hogy mit csinál.

Munkakezdés

Kezdjük összeállítani a CI lépések listáját. Általában ezt a lépést úgy kell kezdenie, hogy megnézi a kód legújabb verzióját a távoli tárolóból, de még nincs helyi tárolónk, ezért inkább a távoli tárolóból klónozzuk.

️ Feladat: frissítse a helyi adattárat, hozzon létre egy ágat master, kezdj dolgozni

1. A kurzustár klónozása innen <URL репозитория>.
2. Fuss npm install a kurzustár könyvtárában; Szükségünk van rá a Jest telepítéséhez, amelyet tesztek futtatásához használunk.
3. Hozzon létre egy ágat, és nevezze el feature. Váltás erre a szálra.

4. Adjon hozzá tesztkódot ci.test.js az erre kérő megjegyzések között.

   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. Adjon hozzá szöveget az első 4 lépéssel a fájlhoz 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.  

   parancsok

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

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

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

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

Hozzon létre véglegesítéseket egy új ágon, építse fel és tesztelje helyileg

Beállítjuk a teszteket, hogy lefussanak a véglegesítés előtt, majd véglegesítjük a kódot.

Tipikus forgatókönyvek, amikor a tesztek automatikusan futnak

• Helyileg:
  • Folyamatosan vagy a megfelelő kódmódosításokra reagálva;
  • Mentésről (tolmácsolt vagy JIT által összeállított nyelveknél);
  • Összeszerelés során (amikor összeállítás szükséges);
  • Elköteleződéskor;
  • Megosztott tárhelyen történő közzétételkor.

• A build szerveren vagy build környezetben:
  • Amikor a kódot közzéteszik egy személyes fiókban/tárhelyen.
  • A szálban található kód tesztelése folyamatban van.
  • Az egyesülés lehetséges eredményét tesztelik (általában a master).
  • Folyamatos integrációs szakaszként/folyamatos szállítási csővezetékként

Általában minél gyorsabban fut egy tesztcsomag, annál gyakrabban engedheti meg magának. Egy tipikus színpadi eloszlás így nézhet ki.

• Gyors egységtesztek – építés közben, CI folyamatban
• Lassú egységtesztek, gyors komponens- és integrációs tesztek – véglegesítéskor, a CI folyamatban
• Lassú komponens- és integrációs tesztek – a CI folyamatban
• Biztonsági tesztelés, terhelési tesztelés és egyéb időigényes vagy költséges tesztek - CI/CD-folyamatokban, de csak a build bizonyos üzemmódjaiban/szakaszaiban/folyamataiban, például kiadásjelölt előkészítésekor vagy manuális futtatáskor.

️ Feladat

Azt javaslom, hogy először manuálisan futtassa le a teszteket a paranccsal npm test. Ezt követően adjunk hozzá egy git hook-ot, hogy lefuttassuk a teszteket a commit-on. Van egy bökkenő: a Git hook nem számítanak a repository részének, ezért nem klónozhatók a GitHubról a többi tananyaggal együtt. A horog telepítéséhez futnia kell install_hook.sh vagy másolja a fájlt repo/hooks/pre-commit a helyi címtárba .git/hooks/.
Amikor elkötelezi magát, látni fogja, hogy tesztek futnak, és ellenőrzik, hogy bizonyos kulcsszavak jelen vannak-e a listában.

1. Futtassa a teszteket manuálisan a parancs futtatásával npm test a kurzustár mappájában. Ellenőrizze, hogy a tesztek befejeződtek-e.
2. Állítson be egy commit hook-ot (pre-commit hook) futással install_hook.sh.
3. Végezze el a változtatásokat a helyi adattárban.
4. Győződjön meg arról, hogy a tesztek lefutottak az elköteleződés előtt.

Az alábbi lépések végrehajtása után a tárhelynek így kell kinéznie.

parancsok

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

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

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

Kód közzététele távoli lerakatban vagy távoli ágban

Miután végeztek a helyi munkával, a fejlesztők általában nyilvánosan elérhetővé teszik kódjukat, hogy végül integrálható legyen a nyilvánossággal. A GitHub esetében ez általában úgy érhető el, hogy a munkát a tár személyes másolatán (személyes elágazás) vagy egy személyes fiókban közzéteszik.

• A fork segítségével a fejlesztő klónoz egy távoli megosztott adattárat, és létrehoz egy személyes távoli másolatot, más néven fork-ot. Ezután klónozza ezt a személyes adattárat, hogy helyileg dolgozzon vele. Amikor a munka elkészült és a commitok megtörténtek, azokat a villájába tolja, ahol mások számára elérhetőek és integrálhatók a közös adattárba. Ezt a megközelítést gyakran használják nyílt forráskódú projektekben a GitHubon. A haladó kurzusomban is használom [Csapatmunka és CI Gittel] (http://devops.redpill.solutions/).
• Egy másik megközelítés az, hogy csak egy távoli tárolót használunk, és csak az ágat számoljuk master megosztott adattár "védett". Ebben a forgatókönyvben az egyes fejlesztők közzéteszik a kódjukat egy távoli adattár ágaiban, hogy mások megnézhessék ezt a kódot, ha minden rendben van, egyesítsék master megosztott adattár.

Ebben a kurzusban olyan munkafolyamatot fogunk használni, amely ágakat használ.

Tegyük közzé a kódunkat.

️ Feladat

• A módosítások közzététele egy távoli ágban, amelynek neve megegyezik a dolgozó ágával

parancsok

git push --set-upstream origin feature

Hozzon létre egy lehívási kérelmet

Hozzon létre egy lehívási kérelmet címmel Lépések áttekintése... Telepítés feature mint a „fejág” és master mint az "alapág".

Győződjön meg arról, hogy telepítette master az övében elágazik a tárház "Alap ágként" nem válaszolok a tananyagtár módosítására irányuló kérésekre.

A GitHub nyelvben az "alap ág" az az ág, amelyre a munkája alapszik, a "fej ág" pedig a javasolt változtatásokat tartalmazó ág.

Beszélje meg a változtatásokat, és adjon hozzá új véglegesítéseket, ahogy a vita folytatódik

Lehívási kérelem (PR)

Lehívási kérelem (PR) egy módja annak, hogy megvitassák és dokumentálják a kódot, valamint lefolytassák a kód felülvizsgálatát. A lehívási kérelmek elnevezése az egyes változtatások általános kódba történő integrálásának általános módja után kapta a nevét. Általában egy személy klónozza a projekt távoli hivatalos tárolóját, és helyileg dolgozik a kódon. Ezt követően elhelyezi a kódot a személyes távoli tárolójába, és megkéri a hivatalos adattárért felelősöket, hogy vegyék fel (húzza) kódját a helyi tárolóikba, ahol áttekintik és esetleg integrálják (összeolvad) övé. Ez a fogalom más néven is ismert, pl. összevonási kérelem.

Valójában nem kell használnia a GitHub vagy hasonló platformok lekérési funkcióját. A fejlesztőcsapatok használhatnak más kommunikációs módszereket is, beleértve a személyes kommunikációt, a hanghívásokat vagy az e-mailt, de továbbra is számos oka van a fórumszerű lehívási kérések használatának. Itt van néhány közülük:

• konkrét kódmódosításokkal kapcsolatos megbeszéléseket;
• mint egy hely, ahol megtekintheti a folyamatban lévő munkákra vonatkozó visszajelzéseket mind az automatikus tesztelőktől, mind a többiektől;
• kód felülvizsgálatok formalizálása;
• hogy a későbbiekben megtudhasd az adott kódrészlet mögött meghúzódó okokat és szempontokat.

Általában akkor hoz létre lehívási kérelmet, amikor meg kell beszélnie valamit, vagy visszajelzést kell kapnia. Ha például egy olyan funkción dolgozik, amelyet többféleképpen is meg lehet valósítani, akkor a kód első sorának megírása előtt létrehozhat egy lehívási kérelmet, hogy megosszák az ötleteit, és megvitassák a terveit munkatársaival. Ha a munka egyszerűbb, akkor a lehívási kérelem akkor nyílik meg, amikor valami már megtörtént, elkötelezte magát, és meg lehet beszélni. Bizonyos esetekben előfordulhat, hogy csak minőség-ellenőrzési okokból kíván PR-t megnyitni: automatizált tesztek futtatásához vagy kódellenőrzések kezdeményezéséhez. Bárhogyan is dönt, ne felejtse el @említeni azokat az embereket, akiknek jóváhagyását szeretné kérni.

A PR létrehozásakor általában a következőket kell tennie.

• Jelölje meg, hogy mit és hol javasol változtatni.
• Írjon leírást a változtatások céljáról! Érdemes lehet:
  • adjon hozzá bármi fontosat, ami nem nyilvánvaló a kódból, vagy valami hasznosat a kontextus megértéséhez, például releváns #bugs és commit számokat;
  • @említs meg bárkit, akivel szeretnél együtt dolgozni, vagy később @említsd meg a megjegyzésekben;
  • kérje meg kollégáit, hogy segítsenek valamiben, vagy ellenőrizzen valami konkrétat.

A PR megnyitása után az ilyen esetekben futtatásra konfigurált tesztek végrehajtásra kerülnek. A mi esetünkben ez ugyanaz a tesztkészlet, amelyet helyben futtattunk, de egy valós projektben további tesztek és ellenőrzések lehetnek.

Kérjük, várja meg, amíg a tesztek befejeződnek. A tesztek állapotát a PR-vita alján láthatod a GitHub felületén. A tesztek befejeztével folytassa.

️ Megjegyzés hozzáadása a CI lépések listájának véletlenszerűségéhez

A kurzusban használt lista önkényes és szubjektív, erről érdemes megjegyzést fűznünk.

️ Feladat: hozzon létre egy lehívási kérelmet ehhez a megjegyzéshez

1. Váltás ágra master.
2. Hozzon létre egy elnevezésű ágat bugfix.
3. Jegyzetszöveg hozzáadása a fájl végéhez 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. Végezze el a változtatásokat.
5. Tedd közzé a szálat bugfix távoli tárolóba.
6. Hozzon létre egy lehívási kérelmet, melynek neve Megjegyzés hozzáadása fejággal bugfix és az alapágatmaster.

Győződjön meg arról, hogy telepítette master az övében elágazik a tárház "Alap ágként" nem válaszolok a tananyagtár módosítására irányuló kérésekre.

Így kell kinéznie a tárhelyének.

parancsok

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

"Megjegyzés hozzáadása" lekérési kérelem jóváhagyása

️ Feladat

1. Hozzon létre egy lehívási kérelmet.
2. Kattintson a "Kérés egyesítése" gombra.
3. Kattintson az "Egyesítés megerősítése" gombra.
4. Kattintson az "Ág törlése" gombra, már nincs rá szükségünk.

Ez az összevonás utáni véglegesítések diagramja.

️ Folytassa a munkát és adjon hozzá teszteket

A lehívási kérelemben való együttműködés gyakran többletmunkát eredményez. Ez általában egy kódellenőrzés vagy megbeszélés eredménye, de tanfolyamunk során ezt úgy fogjuk modellezni, hogy új elemeket adunk hozzá a CI lépések listájához.

A folyamatos integráció általában bizonyos tesztlefedettséget jelent. A tesztek lefedettségére vonatkozó követelmények eltérőek, és általában a „hozzájárulási irányelvek” nevű dokumentumban találhatók. Leegyszerűsítjük, és az ellenőrzőlistánk minden sorához hozzáadunk egy tesztet.

Feladatok futtatásakor először próbálja meg végrehajtani a teszteket. Ha megfelelően telepítette pre-commit hook korábban, az újonnan hozzáadott teszt lefut, sikertelen lesz, és semmi sem kerül végrehajtásra. Vegye figyelembe, hogy így tudjuk, hogy tesztjeink valójában tesztelnek valamit. Érdekes módon, ha a tesztek előtt kezdjük a kóddal, a tesztek sikeres teljesítése azt jelentheti, hogy a kód az elvárásoknak megfelelően működött, vagy azt, hogy a tesztek valójában nem teszteltek semmit. Ráadásul, ha nem írtuk volna meg először a teszteket, lehet, hogy teljesen megfeledkeztünk volna róluk, hiszen semmi sem emlékeztetett volna rá.

Tesztvezérelt fejlesztés (TDD)

A TDD azt javasolja, hogy a kód előtt teszteket írjon. A TDD-t használó tipikus munkafolyamat így néz ki.

1. Adjon hozzá egy tesztet.
2. Futtasson le minden tesztet, és győződjön meg arról, hogy az új teszt sikertelen.
3. Írd be a kódot.
4. Futtassa le a teszteket, és győződjön meg arról, hogy minden teszt sikeres volt.
5. Refaktorálja a kódot.
6. Ismétlés.

Mivel a sikertelen tesztek eredményei általában pirossal, a sikeresek pedig zölddel jelennek meg, a ciklust piros-zöld-refaktornak is nevezik.

️ Feladat

Először próbálja meg végrehajtani a teszteket, és hagyja, hogy meghiúsuljanak, majd adja hozzá és véglegesítse magát a CI lépéslista szövegét. Látni fogja, hogy a tesztek sikeresek ("zöld").
Ezután tegye közzé az új kódot a távoli tárolóban, és nézze meg a teszteket a GitHub felületen a lekérési kérés megbeszélésének és a PR állapotfrissítésének alján.

1. Váltás ágra feature.

2. Adja hozzá ezeket a teszteket ci.test.js az utolsó hívás után 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óbálja meg elvégezni a teszteket. Ha pre-commit hook telepítve van, a véglegesítési kísérlet sikertelen lesz.
4. Ezután adja hozzá ezt a szöveget 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. Helyben hajtsa végre és hajtsa végre a változtatásokat.
6. Módosítások közzététele az ágban feature.

Most valami ilyesmit kellene kapnod

parancsok

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

Konfliktus összevonása

Lépjen a Módosítási kérelemhez Lépések áttekintése.

Annak ellenére, hogy nem csináltunk semmi rosszat, és a kódunk tesztjei sikeresek voltak, mégsem tudjuk összevonni az ágat feature и master. Ez azért van, mert a másik szál bugfix -vel egyesült master miközben ezen a PR-n dolgoztunk.
Ez olyan helyzetet teremt, amikor a távoli ág master van egy újabb verziója, mint amelyre az ágat alapoztuk feature. Emiatt nem tudjuk csak úgy visszatekerni a HEAD-et master a szál végére feature. Ebben a helyzetben vagy egyesítenünk kell, vagy commitokat kell alkalmaznunk feature rebase master. A GitHub valóban képes automatikus egyesítést végrehajtani, ha nincsenek ütközések. Sajnos a mi helyzetünkben mindkét ágnak versengő változásai vannak a fájlban ci.md. Ezt a helyzetet összevonási ütközésnek nevezik, és manuálisan kell megoldanunk.

Egyesítés vagy alapozás

megy

• További egyesítési véglegesítést hoz létre, és elmenti a munkaelőzményeket.
  • Megőrzi az ágak eredeti véglegesítését az eredeti időbélyegekkel és szerzőkkel.
  • Elmenti a véglegesítések SHA-ját, és hivatkozásokat hoz rájuk a változtatási kérelmek megbeszélései során.
• Egyszeri konfliktuskezelést igényel.
• Nem lineárissá teszi a történetet.
  • A sztori nehezen olvasható a sok ág miatt (IDE-kábelre emlékeztet).
  • Megnehezíti az automatikus hibakeresést, pl. git bisect kevésbé hasznos – csak az egyesítő véglegesítést fogja megtalálni.

rebase

• Egymás után játssza le a véglegesítéseket az aktuális ágról az alapág tetejére.
  • Új véglegesítések jönnek létre új SHA-kkal, így a GitHub véglegesítései megegyeznek az eredeti lekérési kérelmekkel, de nem a megfelelő megjegyzésekkel.
  • A véglegesítések újra kombinálhatók és módosíthatók a folyamat során, vagy akár egyesíthetők is.
• Több konfliktus megoldására is szükség lehet.
• Lehetővé teszi egy lineáris történet fenntartását.
  • A történet könnyebben olvasható, ha nem túl hosszú ésszerű ok nélkül.
  • Az automatikus hibakeresés és hibaelhárítás egy kicsit könnyebb: lehetővé teszi git bisect, egyértelműbbé és kiszámíthatóbbá teheti az automatikus visszaállításokat.
• Áttelepített véglegesítésekkel rendelkező ág közzététele szükséges jelzővel --force amikor lehívási kérésekkel használják.

A csapatok általában megegyeznek abban, hogy mindig ugyanazt a stratégiát használják, amikor a változtatásokat össze kell vonniuk. Ez lehet egy "tiszta" összevonás vagy egy "tiszta" véglegesítés a tetején, vagy valami a kettő között, például egy véglegesítés a tetején interaktívan(git rebase -i).

Itt az egyesítést fogjuk használni.

️ Feladat

1. Győződjön meg arról, hogy a kód egy helyi fiókban van master távoli tárolóból frissítve.
2. Váltás ágra feature.
3. Egyesítés kezdeményezése egy ággal master. Egyesítési ütközés a következő versengő módosításai miatt ci.md.
4. Oldja fel az ütközést úgy, hogy a CI-lépések listája és egy megjegyzés is a szövegben maradjon.
5. Tegyen közzé egy összevonási kötelezettséget egy távoli ágon feature.
6. Ellenőrizze a lekérési kérés állapotát a GitHub felhasználói felületén, és várja meg, amíg az egyesítés megtörténik.

parancsok

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

Nagyszerű munka!

Elkészült a listával, és most jóvá kell hagynia a lehívási kérelmet master.

️ Feladat: "Lépések áttekintése" lekérési kérelem jóváhagyása

1. Nyisson meg egy lehívási kérelmet.
2. Kattintson a "Kérés egyesítése" gombra.
3. Kattintson az "Egyesítés megerősítése" gombra.
4. Kattintson az "Ág törlése" gombra, mert már nincs rá szükségünk.

Jelenleg ez a tárhelyed

Termék hiba

Azt mondják, hogy „a tesztelést fel lehet használni a hibák meglétének kimutatására, de soha nem a hiányuk kimutatására”. Annak ellenére, hogy voltak tesztjeink, és nem mutattak ki hibát, egy alattomos hiba csúszott be a gyártásba.

Ilyen forgatókönyv esetén ügyelnünk kell a következőkre:

• mit alkalmaznak a termelésben;
• kód a szálban master hibával, amitől a fejlesztők új munkát kezdhetnek.

Vissza kell állítani vagy javítani kell a következő verzióban?

A visszagörgetés egy ismert jó korábbi verzió üzembe helyezése az éles környezetben, és a hibát tartalmazó véglegesítések visszaállítása. A "Fixing forward" egy javítás hozzáadása a master és az új verzió mielőbbi üzembe helyezése. Mivel az API-k és az adatbázissémák a kód éles üzembe helyezésekor változnak, folyamatos kézbesítés és jó tesztlefedettség mellett, a visszagörgetés általában sokkal nehezebb és kockázatosabb, mint a következő verzióban történő javítás.

Mivel esetünkben a visszagurulás nem jár kockázattal, így ezen az úton járunk, mert ez megengedi

• a lehető leghamarabb javítsa ki a hibát a terméken;
• beírni a kódot master azonnal alkalmas új munka megkezdésére.

️ Feladat

1. Váltás ágra master helyileg.
2. Frissítse a helyi lerakat a távoli lerakatból.
3. A PR-összevonási véglegesítés visszavonása Lépések áttekintése в master.
4. A módosítások közzététele távoli tárolóban.

Ez egy olyan adattár története, amelynek egyesítési véglegesítése vissza lett állítva

parancsok

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

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

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

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

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

️ Önteszt

Győződjön meg arról, hogy ci.md már nem tartalmazza a "sneaky bug" szöveget az összevonási véglegesítés visszaállítása után.

Javítsa ki a CI lépések listáját, és térjen vissza a masterhez

Teljesen visszavontuk az ág összevonási kötelezettségvállalását. feature. A jó hír az, hogy most nincs hiba master. A rossz hír az, hogy a folyamatos integrációs lépések értékes listája is eltűnt. Ideális esetben tehát alkalmaznunk kell a javítást a from commitokra feature és visszaküldi őket master a javítással együtt.

A problémát többféleképpen közelíthetjük meg:

• az összevonást visszavonó véglegesítés visszaállítása feature с master;
• lépés elköveti az előbbitől feature.

A különböző fejlesztőcsapatok ebben az esetben eltérő megközelítést alkalmaznak, de a hasznos kötelezettségvállalásokat egy külön ágba helyezzük át, és külön lekérést hozunk létre ehhez az új ághoz.

️ Feladat

1. Hozzon létre egy szálat feature-fix és váltson rá.

2. Az összes kötelezettség áttelepítése a korábbi ágból feature egy új szálra. Oldja meg az áttelepítés során felmerült összevonási ütközéseket.

   

3. Adjon hozzá egy regressziós tesztet ci.test.js:

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

4. Futtassa le a teszteket helyben, hogy megbizonyosodjon arról, hogy nem sikerül.
5. Távolítsa el az „aljas hibával” szöveget ci.md.
6. Adjon hozzá tesztmódosításokat és lépéslista-módosításokat az indexhez, és hagyja jóvá azokat.
7. Tegye közzé az ágat egy távoli tárolóban.

Valami ehhez hasonlóra kellene a végén:

parancsok

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

Hozzon létre egy lehívási kérelmet.

Hozzon létre egy lehívási kérelmet címmel A funkció javítása... Telepítés feature-fix mint a „fejág” és master mint az "alapág".
Kérjük, várja meg, amíg a tesztek befejeződnek. A tesztek állapotát a PR-beszélgetés alján tekintheti meg.

Győződjön meg arról, hogy telepítette master az övében elágazik a tárház "Alap ágként" nem válaszolok a tananyagtár módosítására irányuló kérésekre.

„A szolgáltatás javítása” lekérési kérelem jóváhagyása

Köszönöm a helyesbítést! Kérjük, hagyja jóvá a módosításokat master húzási kérésből.

️ Feladat

1. Kattintson a "Kérés egyesítése" gombra.
2. Kattintson az "Egyesítés megerősítése" gombra.
3. Kattintson az "Ág törlése" gombra, mert már nincs rá szükségünk.

Jelenleg ez kell.

Gratulálunk!

Elvégezte az összes olyan lépést, amelyet az emberek a folyamatos integráció során általában megtesznek.

Ha bármilyen problémát észlel a kurzussal kapcsolatban, vagy tudja, hogyan javíthatja azt, kérjük, hozzon létre egy problémát tárak tananyagokkal. Ennek a tanfolyamnak is van interaktív változat a GitHub Learning Lab platformként való használata.

Forrás: will.com