Siz Git buyruqlarini o'rgandingizmi, lekin uzluksiz integratsiya (CI) haqiqatda qanday ishlashini tasavvur qilmoqchimisiz? Yoki kundalik faoliyatingizni optimallashtirishni xohlaysizmi? Ushbu kurs sizga GitHub ombori yordamida uzluksiz integratsiya bo'yicha amaliy ko'nikmalar beradi. Bu kurs siz shunchaki bosishingiz mumkin bo'lgan sehrgar bo'lish uchun mo'ljallanmagan; aksincha, siz odamlar ishda qiladigan harakatlarni xuddi ular bajaradigan tarzda bajarasiz. Bosqichlardan o'tayotganda men nazariyani tushuntiraman.

Nima qilamiz?

Rivojlanar ekanmiz, biz asta-sekin odatiy CI bosqichlari ro'yxatini yaratamiz, bu ro'yxatni eslab qolishning ajoyib usuli. Boshqacha qilib aytganda, biz ishlab chiquvchilar uzluksiz integratsiyani amalga oshirishda, uzluksiz integratsiyani amalga oshirishda bajaradigan harakatlar ro'yxatini yaratamiz. Shuningdek, biz CI jarayonimizni haqiqiyga yaqinlashtirish uchun oddiy testlar to'plamidan foydalanamiz.

Ushbu GIF sxematik tarzda siz kurs davomida o'tayotganingizda omboringizdagi majburiyatlarni ko'rsatadi. Ko'rib turganingizdek, bu erda hech qanday murakkab narsa yo'q va faqat eng zarur.

Siz quyidagi standart CI stsenariylaridan o'tasiz:

• Xususiyat ustida ishlash;
• Sifatni ta'minlash uchun avtomatlashtirilgan testlarni qo'llash;
• Ustivor vazifani amalga oshirish;
• Filiallarni birlashtirishda nizolarni hal qilish (birlashma mojarosi);
• Ishlab chiqarish muhitida xatolik yuz beradi.

Siz nimani o'rganasiz?

Siz quyidagi savollarga javob bera olasiz:

• Uzluksiz integratsiya (CI) nima?
• CIda qanday avtomatlashtirilgan testlar qo'llaniladi va ular qanday harakatlarga javoban ishga tushiriladi?
• Pull so'rovlari nima va ular qachon kerak?
• Sinovga asoslangan rivojlanish (TDD) nima va u CI bilan qanday bog'liq?
• O'zgarishlarni birlashtirish yoki qayta asoslash kerakmi?
• Orqaga qaytarilsinmi yoki keyingi versiyada tuzatiladimi?

Avvaliga men hamma joyda "tortishish so'rovlari" kabi narsalarni tarjima qildim, lekin natijada matndagi jinnilik darajasini kamaytirish uchun ba'zi joylarda ingliz tilidagi iboralarni qaytarishga qaror qildim. Men ba'zan "dasturchi surjik" dan odamlar uni ishda ishlatadigan ajoyib "commit" fe'li kabi ishlataman.

Uzluksiz integratsiya nima?

Doimiy integratsiya, yoki CI - bu har bir jamoa a'zosi o'z kodini kuniga kamida bir marta umumiy omborga birlashtiradigan texnik amaliyotdir va natijada olingan kod hech bo'lmaganda xatosiz tuzilishi kerak.

Ushbu atama bo'yicha kelishmovchiliklar mavjud

Qarama-qarshilik nuqtasi - integratsiya chastotasi. Ba'zilarning ta'kidlashicha, kodni kuniga bir marta birlashtirish doimiy ravishda integratsiya qilish uchun etarli emas. Har bir kishi ertalab yangi kod olib, kechqurun bir marta birlashtiradigan jamoaga misol keltirilgan. Bu asosli e'tiroz bo'lsa-da, odatda kuniga bir martalik ta'rif oqilona amaliy, o'ziga xos va turli o'lchamdagi jamoalar uchun mos keladi, deb ishoniladi.

Yana bir e'tiroz shundaki, C++ endi ishlab chiqishda qo'llaniladigan yagona til emas va tekshirish usuli sifatida xatosiz yig'ishni talab qilish zaifdir. Ba'zi testlar to'plami (masalan, mahalliy darajada bajarilgan birlik testlari) ham muvaffaqiyatli yakunlanishi kerak. Ayni paytda hamjamiyat buni talab qilish tomon harakat qilmoqda va kelajakda "qurilish + birlik testlari" odatiy amaliyotga aylanadi, agar u hali bo'lmasa.

Doimiy integratsiya farq qiladi uzluksiz yetkazib berish (Continuous Delivery, CD), chunki u har bir integratsiya siklidan keyin reliz nomzodini talab qilmaydi.

Kurs davomida biz foydalanadigan qadamlar ro'yxati

1. Eng so'nggi kodni torting. dan filial yarating master. Ishlashni boshlang.
2. Yangi filialingizda majburiyatlar yarating. Mahalliy ravishda yarating va sinab ko'ring. O'tishmi? Keyingi bosqichga o'ting. Muvaffaqiyatsizmi? Xatolar yoki testlarni tuzatib, qaytadan urinib ko'ring.
3. Masofaviy omboringizga yoki masofaviy filialingizga suring.
4. Olib tashlash so'rovini yarating. O'zgarishlarni muhokama qiling, muhokama davom etar ekan, qo'shimcha majburiyatlarni qo'shing. Sinovlarni xususiyat bo'limida o'tkazing.
5. Magistrdan majburiyatlarni birlashtirish/qayta tiklash. Sinovlarni birlashma natijasiga ko'ra o'tkazing.
6. Xususiyat bo'limidan ishlab chiqarishga o'tkazing.
7. Agar ma'lum vaqt davomida ishlab chiqarishda hamma narsa yaxshi bo'lsa, o'zgarishlarni masterga birlashtiring.

️ Tayyorgarlik

To'g'ri dasturiy ta'minotga ega ekanligingizga ishonch hosil qiling

Ushbu kursni o'tash uchun sizga kerak bo'ladi Node.js и Git mijozi.

Siz har qanday Git mijozidan foydalanishingiz mumkin, lekin men faqat buyruq qatori uchun buyruqlar beraman.

Buyruqlar qatorini qo'llab-quvvatlaydigan Git mijozi o'rnatilganligiga ishonch hosil qiling

Agar sizda hali buyruq qatorini qo'llab-quvvatlaydigan Git mijozi bo'lmasa, o'rnatish ko'rsatmalarini topishingiz mumkin shu yerda.

Repozitoriyni tayyorlang

Shaxsiy nusxasini yaratishingiz kerak (vilka) Kurs uchun kod bilan shablon ombori GitHub-da. Keling, ushbu shaxsiy nusxani chaqirishga rozi bo'laylik kurs ombori.

Bajarildimi? Agar siz standart sozlamalarni o'zgartirmagan bo'lsangiz, sizning kurs omboringiz chaqirilishi mumkin continuous-integration-team-scenarios-students, u GitHub hisob qaydnomangizda joylashgan va URL manzili shunday ko'rinadi

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

Men shunchaki ushbu manzilga qo'ng'iroq qilaman <URL репозитория>.

Burchakli qavslar kabi <тут> bunday ifodani tegishli qiymat bilan almashtirishingiz kerakligini bildiradi.

Bunga ishonch hosil qiling GitHub harakatlari ushbu kurs ombori uchun kiritilgan. Agar ular yoqilmagan bo'lsa, iltimos, sahifaning o'rtasida joylashgan katta tugmani bosish orqali ularni yoqing, unga GitHub interfeysidagi Amallar tugmasini bosish orqali kirishingiz mumkin.

Agar GitHub Actions yoqilmagan bo'lsa, siz mening ko'rsatmalarimga amal qilgan holda kursni yakunlay olmaysiz.

Biz tuzayotgan roʻyxatning hozirgi holatini shu yerda koʻrish uchun GitHub-ning Markdown-ni koʻrsatish qobiliyatidan har doim foydalanishingiz mumkin.

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

Javoblar haqida

Ushbu kursni yakunlashning eng yaxshi usuli buni o'zingiz qilishingiz bo'lsa-da, sizda ba'zi qiyinchiliklar bo'lishi mumkin.

Agar nima qilish kerakligini tushunmayotganingizni his qilsangiz va davom eta olmasangiz, mavzuni ko'rib chiqishingiz mumkin solution, bu sizning boshlang'ich omboringizda.
Iltimos, birlashmang solution в master kurs davomida. Git bizga bergan barcha imkoniyatlardan foydalanib, nima qilish kerakligini aniqlash yoki oʻz kodingizni muallifniki bilan solishtirish uchun ushbu filialdan foydalanishingiz mumkin. Agar siz butunlay yo'qolgan bo'lsangiz, filialingizni butunlay almashtirishingiz mumkin master filialda solution va keyin ishchi katalogingizni kerakli kurs bosqichiga qaytaring.

Buni faqat sizga kerak bo'lganda foydalaning

Kodingizni kiriting

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

Bu buyruqlar

• qayta nomlash master в master-backup;
• qayta nomlash solution в master;
• yangi filialga to'lash master va ishchi katalogning mazmunini qayta yozish;
• Kelajakda sizga “yechim” filiali kerak bo‘lsa, “master” (ilgari “yechim” bo‘lgan) “yechim” filialini yarating.

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

Ushbu bosqichlardan so'ng siz foydalanishingiz mumkin git log master Sizga qaysi majburiyat kerakligini aniqlash uchun.
Ishchi katalogingizni ushbu majburiyatga quyidagicha tiklashingiz mumkin:

git reset --hard <the SHA you need>

Agar siz natijadan mamnun bo'lsangiz, ma'lum bir nuqtada siz o'zingizning omboringiz versiyasini masofaviy omborga nashr qilishingiz kerak bo'ladi. Buni amalga oshirayotganda masofaviy filialni aniq belgilashni unutmang.

git push --force origin master

E'tibor bering, biz foydalanamiz git push --force. Siz buni tez-tez qilishni xohlashingiz dargumon, lekin bizda bitta ombor foydalanuvchisi bilan juda aniq stsenariy bor, u qo'shimcha ravishda nima qilayotganini tushunadi.

Ishni boshlash

Keling, CI bosqichlari ro'yxatini tuzishni boshlaylik. Odatda siz bu qadamni kodning eng soʻnggi versiyasini masofaviy ombordan tekshirishdan boshlaysiz, lekin bizda hali mahalliy ombor yoʻq, shuning oʻrniga biz uni masofaviy repozitoriydan klonlaymiz.

️ Vazifa: mahalliy omborni yangilang, filial yarating master, ishlashni boshlang

1. Kurs omborini klonlash <URL репозитория>.
2. Yugur npm install kurslar ombori katalogida; Testlarni o'tkazish uchun foydalanadigan Jestni o'rnatish uchun bizga kerak.
3. Filial yarating va unga nom bering feature. Ushbu mavzuga o'tish.

4. Test kodini qo'shing ci.test.js Mendan buni qilishni so'ragan sharhlar orasida.

   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. Faylga dastlabki 4 qadam bilan matn qo'shing 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.  

   Buyruqlar

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

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

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

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

Yangi filialda majburiyatlarni yarating, mahalliy sifatida quring va sinab ko'ring

Qabul qilishdan oldin testlarni o'rnatamiz va keyin kodni topshiramiz.

Sinovlar avtomatik ravishda ishga tushirilganda odatiy stsenariylar

• Mahalliy:
  • Doimiy ravishda yoki tegishli kod o'zgarishlariga javoban;
  • Saqlash bo'yicha (tarjima qilingan yoki JIT-kompilyatsiya qilingan tillar uchun);
  • Yig'ish paytida (kompilyatsiya zarur bo'lganda);
  • Qabul qilinganda;
  • Umumiy omborga nashr qilishda.

• Qurilish serverida yoki qurish muhitida:
  • Kod shaxsiy filialga/omborga nashr etilganda.
  • Ushbu mavzudagi kod sinovdan o'tkazilmoqda.
  • Birlashishning potentsial natijasi sinovdan o'tkaziladi (odatda master).
  • Uzluksiz integratsiya bosqichi/uzluksiz yetkazib berish quvuri sifatida

Odatda, test to'plami qanchalik tez ishlasa, siz uni qanchalik tez-tez ishlatishingiz mumkin. Oddiy bosqich taqsimoti shunday ko'rinishi mumkin.

• Tez birlik sinovlari - qurish paytida, CI quvur liniyasida
• Sekin birlik sinovlari, tezkor komponentlar va integratsiya testlari - bajarilganda, CI quvurida
• Sekin komponent va integratsiya testlari - CI quvurida
• Xavfsizlik sinovlari, yuk sinovlari va boshqa ko'p vaqt talab qiladigan yoki qimmat sinovlar - CI/CD quvurlarida, lekin faqat qurilishning ma'lum rejimlarida/bosqichlarida/quvurlarida, masalan, reliz nomzodini tayyorlashda yoki qo'lda ishlashda.

️ Topshiriq

Men buyruq yordamida testlarni qo'lda bajarishni tavsiya qilaman npm test. Shundan so'ng, testlarimizni bajarish uchun git kancasini qo'shamiz. Bitta jihat bor: Git ilgaklari omborning bir qismi hisoblanmaydi va shuning uchun boshqa kurs materiallari bilan birga GitHub’dan klonlash mumkin emas. Kancani o'rnatish uchun siz yugurishingiz kerak install_hook.sh yoki faylni nusxalash repo/hooks/pre-commit mahalliy katalogga .git/hooks/.
Qachonki, siz sinovlar o'tkazilayotganini ko'rasiz va ular ro'yxatda ba'zi kalit so'zlar mavjudligini tekshiradi.

1. Buyruqni ishga tushirish orqali testlarni qo'lda bajaring npm test kursingiz ombori papkasida. Sinovlar tugallanganligini tekshiring.
2. Yugurish orqali topshiriq kancasini (oldindan topshirilgan kanca) o'rnating install_hook.sh.
3. O'zgartirishlaringizni mahalliy omboringizga kiriting.
4. Qabul qilishdan oldin testlar o'tkazilganligiga ishonch hosil qiling.

Ushbu amallarni bajarganingizdan so'ng sizning omboringiz shunday ko'rinishi kerak.

Buyruqlar

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

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

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

Kodni masofaviy omborga yoki masofaviy filialga nashr qiling

Mahalliy ravishda ishlashni tugatgandan so'ng, ishlab chiquvchilar odatda o'zlarining kodlarini ommaga ochiq qiladilar, shunda u oxir-oqibat jamoatchilik bilan birlashtirilishi mumkin. GitHub bilan bunga, odatda, ishni omborning shaxsiy nusxasiga (shaxsiy vilka) yoki shaxsiy filialga nashr qilish orqali erishiladi.

• Vilkalar yordamida ishlab chiquvchi masofaviy umumiy omborni klonlaydi va uning shaxsiy masofaviy nusxasini yaratadi, shuningdek, vilkalar deb ham ataladi. Keyin u ushbu shaxsiy omborni mahalliy bilan ishlash uchun klonlaydi. Ish tugagach va majburiyatlar bajarilganda, u ularni o'zining vilkalariga suradi, u erda ular boshqalar uchun mavjud va umumiy omborga birlashtirilishi mumkin. Ushbu yondashuv odatda GitHub'dagi ochiq kodli loyihalarda qo'llaniladi. U mening ilg'or kursimda ham qo'llaniladi [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Yana bir yondashuv faqat bitta masofaviy ombordan foydalanish va faqat filialni hisoblashdir master umumiy ombor "himoyalangan". Ushbu stsenariyda, individual ishlab chiquvchilar o'z kodlarini masofaviy omborning filiallarida nashr etadilar, shunda boshqalar ushbu kodni ko'rishlari mumkin, agar hamma narsa tartibda bo'lsa, uni birlashtiring. master umumiy ombor.

Ushbu maxsus kursda biz filiallardan foydalanadigan ish oqimidan foydalanamiz.

Keling, kodimizni nashr qilaylik.

️ Topshiriq

• O'zgarishlarni ishlaydigan filialingiz bilan bir xil nomdagi uzoq filialga e'lon qiling

Buyruqlar

git push --set-upstream origin feature

Olib tashlash so'rovini yarating

Sarlavha bilan tortib olish so'rovini yarating Qadamlarni ko'rib chiqish. O'rnatish feature "bosh filiali" kabi va master "tayanch filiali" kabi.

O'rnatganingizga ishonch hosil qiling master ichida omborni bog'lang "Asosiy filial" sifatida men kurs materiallari omboriga o'zgartirish kiritish bo'yicha so'rovlarga javob bermayman.

GitHub lingo-da "tayanch filiali" sizning ishingizga asoslanadigan filialdir va "bosh filial" taklif qilingan o'zgarishlarni o'z ichiga olgan filialdir.

O'zgarishlarni muhokama qiling, muhokama davom etar ekan, yangi majburiyatlarni qo'shing

Pull so'rovi (PR)

Pull so'rovi (PR) kodni muhokama qilish va hujjatlashtirish, shuningdek, kodni tekshirish usulidir. Pull so'rovlari umumiy kodga individual o'zgarishlarni birlashtirishning umumiy usuli bilan nomlanadi. Odatda, odam loyihaning uzoqdagi rasmiy omborini klonlaydi va mahalliy kod ustida ishlaydi. Shundan so'ng, u kodni o'zining shaxsiy masofaviy omboriga joylashtiradi va rasmiy omborga mas'ul bo'lganlardan olishni so'raydi(Torting) uning kodini o'zlarining mahalliy omborlariga joylashtiradilar, u erda ular ko'rib chiqadilar va ehtimol integratsiyalashadilar (yushmoq) uning. Bu tushuncha boshqa nomlar bilan ham tanilgan, masalan, birlashtirish so'rovi.

Siz GitHub yoki shunga o'xshash platformalarning tortishish so'rovi xususiyatidan foydalanishingiz shart emas. Rivojlanish guruhlari boshqa aloqa usullaridan, jumladan, yuzma-yuz muloqot, ovozli qo'ng'iroqlar yoki elektron pochtadan foydalanishlari mumkin, ammo forum uslubidagi tortishish so'rovlaridan foydalanish uchun hali ham bir qator sabablar mavjud. Mana ulardan ba'zilari:

• maxsus kod o'zgarishlari bilan bog'liq munozaralarni tashkil etish;
• avtotestchilar va tengdoshlar tomonidan bajarilayotgan ishlar haqida fikr-mulohazalarni ko'rish uchun joy sifatida;
• kodlarni ko'rib chiqishni rasmiylashtirish;
• Shunday qilib, keyinchalik u yoki bu kod qismining sabablari va mulohazalarini bilib olishingiz mumkin.

Odatda siz biror narsani muhokama qilishingiz yoki fikr-mulohaza olishingiz kerak bo'lganda tortishish so'rovini yaratasiz. Misol uchun, agar siz bir nechta usulda amalga oshirilishi mumkin bo'lgan xususiyat ustida ishlayotgan bo'lsangiz, g'oyalaringizni baham ko'rish va rejalaringizni hamkorlaringiz bilan muhokama qilish uchun kodning birinchi qatorini yozishdan oldin tortishish so'rovini yaratishingiz mumkin. Agar ish oddiyroq bo'lsa, biror narsa allaqachon qilingan, bajarilgan va muhokama qilinishi mumkin bo'lganida, tortish so'rovi ochiladi. Ba'zi stsenariylarda siz PRni faqat sifat nazorati sabablari uchun ochishingiz mumkin: avtomatlashtirilgan testlarni o'tkazish yoki kodni ko'rib chiqishni boshlash. Nimaga qaror qilsangiz ham, so'rovingizda ma'qullanmoqchi bo'lgan odamlarni @zikr qilishni unutmang.

Odatda, PR yaratishda siz quyidagilarni bajarasiz.

• Nimani va qaerda o'zgartirishni taklif qilayotganingizni ko'rsating.
• O'zgarishlarning maqsadini tushuntirib tavsif yozing. Siz xohlashingiz mumkin:
  • koddan aniq bo'lmagan muhim narsalarni yoki kontekstni tushunish uchun foydali narsalarni qo'shing, masalan, tegishli #bugs va commit raqamlari;
  • Ishlashni boshlamoqchi bo'lgan har bir kishini @mention yoki keyinroq izohlarda @mention qilish mumkin;
  • hamkasblaringizdan biror narsada yordam berishlarini yoki aniq bir narsani tekshirishlarini so'rang.

PRni ochganingizdan so'ng, bunday hollarda ishlash uchun tuzilgan testlar bajariladi. Bizning holatda, bu biz mahalliy darajada o'tkazgan bir xil testlar to'plami bo'ladi, ammo haqiqiy loyihada qo'shimcha testlar va tekshiruvlar bo'lishi mumkin.

Iltimos, testlar tugashini kuting. GitHub interfeysidagi PR muhokamasining pastki qismida testlar holatini ko'rishingiz mumkin. Sinovlar tugagach, davom eting.

️ CI bosqichlari roʻyxatining tasodifiyligi haqida eslatma qoʻshing

Ushbu kursda foydalanilgan ro'yxat o'zboshimchalik va sub'ektivdir, biz bu haqda eslatma qo'shishimiz kerak.

️ Vazifa: ushbu sharh uchun tortishish so'rovini yarating

1. Filialga o'tish master.
2. nomli filial yarating bugfix.
3. Fayl oxiriga eslatma matnini qo'shing 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. O'zgarishlarni qabul qiling.
5. Mavzuni nashr eting bugfix masofaviy omborga.
6. nomli tortish so'rovini yarating Izoh qo'shish bosh novdasi bilan bugfix va asosiy filialmaster.

O'rnatganingizga ishonch hosil qiling master ichida omborni bog'lang "Asosiy filial" sifatida men kurs materiallari omboriga o'zgartirish kiritish bo'yicha so'rovlarga javob bermayman.

Sizning omboringiz shunday ko'rinishi kerak.

Buyruqlar

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

"Izoh qo'shish" so'rovini tasdiqlash

️ Topshiriq

1. Olib tashlash so'rovini yarating.
2. "Birlashtirish so'rovini birlashtirish" tugmasini bosing.
3. "Birlashtirishni tasdiqlash" tugmasini bosing.
4. "Filialni o'chirish" tugmasini bosing, bizga endi kerak emas.

Bu birlashishdan keyingi majburiyatlar diagrammasi.

️ Ishlashda va testlarni qo'shishda davom eting

Pull so'rovi bo'yicha hamkorlik ko'pincha qo'shimcha ishlarga olib keladi. Bu odatda kodni ko'rib chiqish yoki muhokama qilish natijasidir, lekin kursimizda biz buni CI bosqichlari ro'yxatiga yangi elementlarni qo'shish orqali modellashtiramiz.

Uzluksiz integratsiya odatda ba'zi sinovlarni qamrab oladi. Test qamrovi talablari har xil va odatda "hissa qo'shish bo'yicha ko'rsatmalar" deb nomlangan hujjatda topiladi. Biz buni soddalashtiramiz va nazorat ro'yxatimizdagi har bir qator uchun test qo'shamiz.

Topshiriqlarni bajarayotganda, avval testlarni topshirishga harakat qiling. Agar siz to'g'ri o'rnatgan bo'lsangiz pre-commit Ilgari qo'shilsa, yangi qo'shilgan test ishga tushadi, muvaffaqiyatsiz bo'ladi va hech narsa bajarilmaydi. E'tibor bering, bizning testlarimiz aslida nimanidir sinab ko'rayotganini shu tarzda bilamiz. Qizig'i shundaki, agar biz testlardan oldin kod bilan boshlagan bo'lsak, testlardan o'tish kodning kutilganidek ishlaganligini yoki testlar aslida hech narsani sinab ko'rmaganligini anglatishi mumkin. Bundan tashqari, agar biz testlarni boshida yozmaganimizda, biz ular haqida umuman unutgan bo'lishimiz mumkin edi, chunki hech narsa bizga buni eslatmasdi.

Sinovga asoslangan rivojlanish (TDD)

TDD koddan oldin test yozishni tavsiya qiladi. TDD yordamida odatiy ish jarayoni shunday ko'rinadi.

1. Sinov qo'shing.
2. Barcha testlarni bajaring va yangi sinov muvaffaqiyatsizligiga ishonch hosil qiling.
3. Kodni yozing.
4. Sinovlarni o'tkazing, barcha testlar o'tganligiga ishonch hosil qiling.
5. Kodingizni qayta ko'rib chiqing.
6. Takrorlang.

Muvaffaqiyatsiz bo'lgan testlar natijalari odatda qizil rangda, o'tganlari esa yashil rangda ko'rsatilganligi sababli, tsikl qizil-yashil-refaktor sifatida ham tanilgan.

️ Topshiriq

Birinchidan, testlarni topshirishga harakat qiling va ularning muvaffaqiyatsiz bo'lishiga yo'l qo'ying, so'ngra CI qadamlar ro'yxati matnini o'zi qo'shing va kiriting. Sinovlar o'tayotganini ko'rasiz ("yashil").
Keyin yangi kodni masofaviy omborga e'lon qiling va tortishish so'rovi muhokamasi va PR holatini yangilashning pastki qismida GitHub interfeysida o'tkaziladigan testlarni tomosha qiling.

1. Filialga o'tish feature.

2. Ushbu testlarni qo'shing ci.test.js oxirgi qo'ng'iroqdan keyin 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. Sinovlarni topshirishga harakat qiling. Agar pre-commit kanca o'rnatilgan bo'lsa, majburiyatga urinish muvaffaqiyatsiz bo'ladi.
4. Keyin ushbu matnni qo'shing 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. Mahalliy o'zgarishlarni amalga oshiring va kiriting.
6. Filialdagi o'zgarishlarni e'lon qiling feature.

Endi sizda shunga o'xshash narsa bo'lishi kerak

Buyruqlar

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

Mojarolarni birlashtirish

O'zgartirish so'roviga o'ting Qadamlarni ko'rib chiqish.

Hech qanday xato qilmagan bo'lsak ham va kodimiz sinovlari o'tgan bo'lsa ham, biz hali ham filialni birlashtira olmaymiz. feature и master. Buning sababi, boshqa mavzu bugfix bilan birlashtirildi master biz ushbu PR ustida ishlayotganimizda.
Bu uzoq filiali vaziyatni yaratadi master biz filialni asos qilib olganimizdan yangiroq versiyasiga ega feature. Shu sababli biz HEAD-ni shunchaki orqaga o'tkaza olmaymiz master ipning oxirigacha feature. Bunday vaziyatda biz majburiyatlarni birlashtirishimiz yoki qo'llashimiz kerak feature qayta tiklash master. Agar ziddiyat bo'lmasa, GitHub aslida avtomatik birlashmalarni amalga oshirishi mumkin. Afsuski, bizning vaziyatimizda ikkala filialda ham faylda raqobatbardosh o'zgarishlar mavjud ci.md. Bu holat birlashish mojarosi sifatida tanilgan va biz uni qo'lda hal qilishimiz kerak.

Birlashtirish yoki qayta asoslash

borib

• Qo'shimcha birlashtirish majburiyatini yaratadi va ish tarixini saqlaydi.
  • Filiallarning asl majburiyatlarini asl vaqt belgilari va mualliflari bilan saqlaydi.
  • O'zgartirish so'rovini muhokama qilishda majburiyatlarning SHA va ularga havolalarni saqlaydi.
• Bir martalik nizolarni hal qilishni talab qiladi.
• Hikoyani chiziqli bo'lmagan holga keltiradi.
  • Hikoyani ko'p sonli filiallar (IDE kabelini eslatadi) tufayli o'qish qiyin bo'lishi mumkin.
  • Avtomatik nosozliklarni tuzatishni qiyinlashtiradi, masalan. git bisect kamroq foydali - u faqat birlashma majburiyatini topadi.

Qayta tiklash

• Tayanch novdaning tepasida joylashgan joriy shoxchadan topshiriqlarni birin-ketin takrorlaydi.
  • Yangi SHAlar bilan yangi majburiyatlar hosil bo'ladi, bu esa GitHub'dagi majburiyatlarning asl tortishish so'rovlariga mos kelishiga olib keladi, lekin tegishli izohlarga emas.
  • Majburiyatlar jarayonda qayta birlashtirilishi va o'zgartirilishi yoki hatto bittasiga birlashtirilishi mumkin.
• Bir nechta nizolarni hal qilish kerak bo'lishi mumkin.
• Chiziqli hikoyani saqlashga imkon beradi.
  • Hikoya hech qanday sababsiz juda uzoq bo'lmasa, o'qish osonroq bo'lishi mumkin.
  • Avtomatik disk raskadrovka va nosozliklarni bartaraf etish biroz osonroq: buni amalga oshiradi git bisect, avtomatik orqaga qaytarishni aniqroq va bashorat qilish mumkin.
• Bayroq bilan ko'chirilgan majburiyatlari bo'lgan filialni nashr qilishni talab qiladi --force tortish so'rovlari bilan foydalanilganda.

Odatda, jamoalar o'zgarishlarni birlashtirish kerak bo'lganda har doim bir xil strategiyadan foydalanishga rozi bo'lishadi. Bu "sof" birlashma yoki tepada "sof" majburiyat yoki ularning orasidagi narsa bo'lishi mumkin, masalan, interaktiv ravishda yuqorida majburiyatni bajarish(git rebase -i) jamoat omborida e'lon qilinmagan filiallar uchun mahalliy, lekin "ommaviy" filiallar uchun birlashtiriladi.

Bu erda biz birlashtirishdan foydalanamiz.

️ Topshiriq

1. Kod mahalliy filialda ekanligiga ishonch hosil qiling master masofaviy ombordan yangilangan.
2. Filialga o'tish feature.
3. Filial bilan birlashishni boshlang master. ga raqobatdosh o'zgarishlar tufayli birlashma mojarosi ci.md.
4. Mojaroni shunday hal qilingki, bizning CI qadamlarimiz ro'yxati ham, u haqidagi eslatma ham matnda qolsin.
5. Masofaviy filialga birlashtirish majburiyatini e'lon qiling feature.
6. GitHub UI-da tortish so'rovining holatini tekshiring va birlashma hal bo'lguncha kuting.

Buyruqlar

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

Yaxshi bajarilgan ish!

Siz ro'yxatni tayyorladingiz va endi siz jalb qilish so'rovini tasdiqlashingiz kerak master.

️ Vazifa: "Qadamlarni ko'rib chiqish" so'rovini tasdiqlash

1. O'chirish so'rovini oching.
2. "Birlashtirish so'rovini birlashtirish" tugmasini bosing.
3. "Birlashtirishni tasdiqlash" tugmasini bosing.
4. "Filialni o'chirish" tugmasini bosing, chunki bizga endi kerak emas.

Ayni paytda bu sizning omboringiz

Mahsulot xatosi

Aytishlaricha, "sinov xatolar mavjudligini ko'rsatish uchun ishlatilishi mumkin, ammo ularning yo'qligini hech qachon ko'rsatmaslik". Garchi bizda sinovlar bo'lsa va ular bizga hech qanday xato ko'rsatmasa ham, ishlab chiqarishga makkor xato kirib keldi.

Bunday stsenariyda biz quyidagilarga e'tibor berishimiz kerak:

• ishlab chiqarishda nima qo'llaniladi;
• mavzudagi kod master xato bilan, ishlab chiquvchilar yangi ishni boshlashlari mumkin.

Orqaga qaytarishim kerakmi yoki keyingi versiyada tuzatishim kerakmi?

Orqaga qaytarish - bu ishlab chiqarishga ma'lum bo'lgan oldingi versiyani qo'llash va xatoni o'z ichiga olgan majburiyatlarni qaytarish jarayoni. "Oldinga tuzatish" - tuzatishning qo'shilishi master va yangi versiyani imkon qadar tezroq o'rnatish. API va ma'lumotlar bazasi sxemalari kod ishlab chiqarishga o'rnatilishi bilan uzluksiz yetkazib berish va yaxshi sinov qamrovi bilan o'zgarganligi sababli, orqaga qaytarish odatda keyingi versiyada tuzatishdan ko'ra ancha qiyin va xavfliroqdir.

Orqaga qaytish bizning holatlarimizda hech qanday xavf tug'dirmasligi sababli, biz bu yo'ldan boramiz, chunki bu bizga imkon beradi

• mahsulotdagi xatoni imkon qadar tezroq tuzating;
• kodni kiriting master yangi ish boshlash uchun darhol mos keladi.

️ Topshiriq

1. Filialga o'tish master mahalliy darajada.
2. Masofaviy ombordan mahalliy omborni yangilang.
3. PR birlashma majburiyatini qaytaring Qadamlarni ko'rib chiqish в master.
4. O'zgarishlarni masofaviy omborga e'lon qilish.

Bu birlashtirish majburiyati qaytarilgan ombor tarixi

Buyruqlar

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

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

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

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

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

️ O'z-o'zini sinab ko'rish

Bunga ishonch hosil qiling ci.md birlashish majburiyatini qaytargandan so'ng, endi "sneaky bug" matnini o'z ichiga olmaydi.

CI bosqichlari ro'yxatini tuzating va uni masterga qaytaring

Biz filialni birlashtirish majburiyatini butunlay qaytarib oldik. feature. Yaxshi xabar shundaki, bizda endi hech qanday xato yo'q master. Yomon xabar shundaki, bizning doimiy integratsiya bosqichlarining qimmatli ro'yxati ham yo'qoldi. Shunday qilib, ideal holda, biz tuzatishni majburiyatlarga qo'llashimiz kerak feature va ularni qaytaring master tuzatish bilan birga.

Muammoga turli yo'llar bilan yondashishimiz mumkin:

• birlashishni bekor qiladigan majburiyatni qaytarish feature с master;
• avvalgisidan ko'chirish majburiyatlari feature.

Turli ishlab chiqish guruhlari bu holatda turli yondashuvlardan foydalanadilar, ammo biz foydali majburiyatlarni alohida filialga o'tkazamiz va ushbu yangi filial uchun alohida tortib olish so'rovini yaratamiz.

️ Topshiriq

1. deb nomlangan mavzuni yarating feature-fix va unga o'ting.

2. Oldingi filialdan barcha majburiyatlarni ko'chiring feature yangi mavzuga. Migratsiya paytida yuzaga kelgan birlashma nizolarini hal qiling.

   

3. ga regressiya testini qo'shing ci.test.js:

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

4. Muvaffaqiyatsiz bo'lmasligiga ishonch hosil qilish uchun testlarni mahalliy sifatida bajaring.
5. "Yashirin xato bilan" matnini olib tashlang ci.md.
6. Sinov o'zgarishlarini va qadamlar ro'yxatidagi o'zgarishlarni indeksga qo'shing va ularni bajaring.
7. Filialni masofaviy omborga nashr qiling.

Siz shunga o'xshash narsa bilan yakunlashingiz kerak:

Buyruqlar

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

Olib tashlash so'rovini yarating.

Sarlavha bilan tortib olish so'rovini yarating Xususiyatni tuzatish. O'rnatish feature-fix "bosh filiali" kabi va master "tayanch filiali" kabi.
Iltimos, testlar tugaguncha kuting. Testlar holatini PR muhokamasining pastki qismida ko'rishingiz mumkin.

O'rnatganingizga ishonch hosil qiling master ichida omborni bog'lang "Asosiy filial" sifatida men kurs materiallari omboriga o'zgartirish kiritish bo'yicha so'rovlarga javob bermayman.

"Xususiyatlar tuzatilmoqda" tortishish so'rovini tasdiqlash

Tuzatish uchun rahmat! Iltimos, quyidagi oʻzgarishlarni maʼqullang master tortish so'rovidan.

️ Topshiriq

1. "Birlashtirish so'rovini birlashtirish" tugmasini bosing.
2. "Birlashtirishni tasdiqlash" tugmasini bosing.
3. "Filialni o'chirish" tugmasini bosing, chunki bizga endi kerak emas.

Ayni paytda sizda bo'lishi kerak bo'lgan narsa shu.

Tabriklaymiz!

Siz doimiy integratsiya paytida odamlar odatda bajaradigan barcha qadamlarni bajardingiz.

Agar siz kurs bilan bog'liq muammolarga duch kelsangiz yoki uni qanday yaxshilashni bilsangiz, unda muammo yarating kurs materiallari bilan omborlar. Bu kurs ham bor interaktiv versiya platforma sifatida GitHub Learning Lab dan foydalanish.

Manba: www.habr.com