Git əmrlərini öyrənmisiniz, lakin davamlı inteqrasiyanın (CI) reallıqda necə işlədiyini təsəvvür etmək istəyirsiniz? Və ya bəlkə gündəlik fəaliyyətlərinizi optimallaşdırmaq istəyirsiniz? Bu kurs sizə GitHub repozitoriyasından istifadə edərək davamlı inteqrasiyada praktiki bacarıqlar verəcəkdir. Bu kurs sadəcə klikləyəcəyiniz bir sehrbaz olmaq üçün nəzərdə tutulmayıb; əksinə, insanların işdə etdikləri hərəkətləri eyni şəkildə yerinə yetirəcəksiniz. Nəzəriyyəni sizə aid olan addımlardan keçərkən izah edəcəyəm.

Biz nə edirik?

İrəlilədikcə, biz tədricən tipik CI addımlarının siyahısını yaradacağıq ki, bu da bu siyahını yadda saxlamaq üçün əla bir yoldur. Başqa sözlə, biz inkişaf etdiricilərin davamlı inteqrasiya edərkən, davamlı inteqrasiya edərkən gördüyü hərəkətlərin siyahısını yaradacağıq. Biz həmçinin CI prosesimizi real prosesə yaxınlaşdırmaq üçün sadə testlər dəstindən istifadə edəcəyik.

Bu GIF kursda irəlilədikcə deponuzdakı öhdəlikləri sxematik şəkildə göstərir. Gördüyünüz kimi, burada mürəkkəb bir şey yoxdur və yalnız ən zəruridir.

Aşağıdakı standart CI ssenarilərindən keçəcəksiniz:

• Bir xüsusiyyət üzərində işləmək;
• Keyfiyyəti təmin etmək üçün avtomatlaşdırılmış testlərin tətbiqi;
• Prioritet vəzifənin həyata keçirilməsi;
• Filialları birləşdirərkən münaqişənin həlli (birləşmə münaqişəsi);
• İstehsal mühitində xəta baş verir.

Nə öyrənəcəksən?

Aşağıdakı suallara cavab verə biləcəksiniz:

• Davamlı inteqrasiya (CI) nədir?
• CI-də hansı növ avtomatlaşdırılmış testlərdən istifadə olunur və onlar hansı hərəkətlərə cavab olaraq işə salınır?
• Çəkmə sorğuları nədir və nə vaxt lazımdır?
• Test Əsaslı İnkişaf (TDD) nədir və onun CI ilə necə əlaqəsi var?
• Dəyişiklikləri birləşdirməli və ya yenidən əsaslandırmalıyam?
• Geri qaytarılsın və ya növbəti versiyada düzəldilsin?

Əvvəlcə hər yerdə “çəkmə sorğuları” kimi şeyləri tərcümə etdim, amma nəticədə mətndəki çılğınlıq dərəcəsini azaltmaq üçün bəzi yerlərdə ingiliscə ifadələri qaytarmaq qərarına gəldim. Mən bəzən “proqramçı surzhik” sözündən insanların əslində işdə istifadə etdiyi gözəl “commit” feli kimi istifadə edəcəyəm.

Davamlı inteqrasiya nədir?

Davamlı İnteqrasiya, və ya CI, hər bir komanda üzvünün öz kodunu gündə ən azı bir dəfə ümumi depoya inteqrasiya etdiyi texniki təcrübədir və nəticədə yaranan kod ən azı səhvsiz qurulmalıdır.

Bu terminlə bağlı fikir ayrılıqları var

Mübahisə nöqtəsi inteqrasiyanın tezliyidir. Bəziləri iddia edir ki, kodun gündə bir dəfə birləşdirilməsi həqiqətən davamlı inteqrasiya üçün kifayət deyil. Hər kəsin səhər təzə kodu götürdüyü və axşam bir dəfə inteqrasiya etdiyi bir komanda nümunəsi verilmişdir. Bu ağlabatan etiraz olsa da, ümumiyyətlə gündə bir dəfə olan tərifin kifayət qədər praktik, spesifik və müxtəlif ölçülü komandalar üçün uyğun olduğuna inanılır.

Digər bir etiraz ondan ibarətdir ki, C++ artıq inkişafda istifadə olunan yeganə dil deyil və doğrulama yolu kimi sadəcə səhvsiz montaj tələb etmək zəifdir. Bəzi testlər dəsti (məsələn, yerli olaraq həyata keçirilən vahid testləri) də uğurla tamamlanmalıdır. Hal-hazırda, icma bunu bir tələb etmək istiqamətində hərəkət edir və gələcəkdə "qurma + vahid testləri" çox güman ki, adi bir təcrübəyə çevriləcək, əgər hələ də yoxdur.

Davamlı İnteqrasiya fərqlənir fasiləsiz çatdırılma (Davamlı Çatdırılma, CD), çünki hər inteqrasiya dövründən sonra buraxılış namizədi tələb olunmur.

Kurs boyu istifadə edəcəyimiz addımların siyahısı

1. Ən son kodu daxil edin. -dən filial yaradın master. İşə başlamaq.
2. Yeni filialınızda öhdəliklər yaradın. Yerli olaraq qurun və sınaqdan keçirin. Keçmək? Növbəti addıma keçin. Uğursuz? Səhvləri və ya testləri düzəldin və yenidən cəhd edin.
3. Uzaq deponuza və ya uzaq filialınıza itələyin.
4. Çəkmə sorğusu yaradın. Dəyişiklikləri müzakirə edin, müzakirə davam etdikcə daha çox öhdəliklər əlavə edin. Testləri xüsusiyyət bölməsində keçin.
5. Ustadan öhdəlikləri birləşdirin/yenidən əsaslandırın. Testlərin birləşmə nəticəsində keçməsini təmin edin.
6. Xüsusiyyət bölməsindən istehsala qədər yerləşdirin.
7. Bir müddət istehsalda hər şey yaxşı olarsa, dəyişiklikləri master üçün birləşdirin.

️ Hazırlıq

Düzgün proqram təminatına malik olduğunuzdan əmin olun

Bu kursu keçmək üçün sizə lazım olacaq Node.js и Git müştəri.

İstənilən Git müştərisindən istifadə edə bilərsiniz, lakin mən yalnız komanda xətti üçün əmrlər verəcəyəm.

Komanda xəttini dəstəkləyən bir Git müştəri quraşdırdığınızdan əmin olun

Hələ komanda xəttini dəstəkləyən Git müştəriniz yoxdursa, quraşdırma təlimatlarını tapa bilərsiniz burada.

Anbarı hazırlayın

Siz şəxsi nüsxə yaratmalısınız (çəngəl) Kurs kodu ilə şablon deposu GitHub-da. Gəlin bu şəxsi nüsxə adlandırmağa razılaşaq kurs anbarı.

Bitdi? Defolt parametrləri dəyişməmisinizsə, çox güman ki, kurs anbarınız çağırılır continuous-integration-team-scenarios-students, GitHub hesabınızda yerləşir və URL belə görünür

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

Sadəcə bu ünvana zəng edəcəyəm <URL репозитория>.

Bucaq mötərizələri kimi <тут> belə bir ifadəni müvafiq dəyərlə əvəz etməli olduğunuz anlamına gələcək.

Buna əmin olun GitHub hərəkətləri bu kurs anbarı üçün daxil edilmişdir. Əgər onlar aktiv deyilsə, lütfən, GitHub interfeysində Fəaliyyətlər düyməsini klikləməklə əldə edə biləcəyiniz səhifənin ortasındakı böyük düyməni klikləməklə onları aktivləşdirin.

GitHub Fəaliyyətləri aktiv deyilsə, siz mənim göstərişlərimə əməl etməklə kursu tamamlaya bilməyəcəksiniz.

Burada tərtib etdiyimiz siyahının cari vəziyyətini görmək üçün GitHub-ın Markdown-u göstərmək qabiliyyətindən hər zaman istifadə edə bilərsiniz.

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

Cavablar haqqında

Bu kursu tamamlamağın ən yaxşı yolu bunu özünüz etmək olsa da, bəzi çətinlikləriniz ola bilər.

Nə edəcəyinizi başa düşmədiyinizi və davam edə bilməyəcəyinizi hiss edirsinizsə, mövzuya baxa bilərsiniz solution, başlanğıc deponuzda olan.
Xahiş edirəm birləşməyin solution в master kurs zamanı. Siz Git-in bizə verdiyi bütün imkanlardan istifadə edərək nə edəcəyinizi anlamaq və ya kodunuzu müəllifinki ilə müqayisə etmək üçün bu filialdan istifadə edə bilərsiniz. Əgər siz tamamilə itmişsinizsə, filialınızı tamamilə əvəz edə bilərsiniz master bir filialda solution və sonra iş kataloqunuzu sizə lazım olan kurs mərhələsinə sıfırlayın.

Bunu yalnız həqiqətən ehtiyacınız olduqda istifadə edin

Kodunuzu təhvil verin

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

Bu əmrlər

• adını dəyişin master в master-backup;
• adını dəyişin solution в master;
• yeni filiala müraciət edin master və işçi kataloqunun məzmununu yenidən yazmaq;
• Gələcəkdə "həll" filialına ehtiyacınız olarsa, "master"dən (əvvəllər "həll" idi) "həll" filialı yaradın.

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

Bu addımlardan sonra istifadə edə bilərsiniz git log master hansı öhdəliyə ehtiyacınız olduğunu anlamaq üçün.
İş kataloqunuzu bu öhdəliyə belə sıfırlaya bilərsiniz:

git reset --hard <the SHA you need>

Nəticədən razısınızsa, nə vaxtsa siz anbar versiyasını uzaq depoda dərc etməli olacaqsınız. Bunu edərkən uzaq filialı açıq şəkildə göstərməyi unutmayın.

git push --force origin master

Qeyd edək ki, istifadə edirik git push --force. Çox güman ki, bunu tez-tez etmək istəyəcəksiniz, lakin bizim burada, əlavə olaraq, nə etdiyini başa düşən bir depo istifadəçisi ilə çox xüsusi bir ssenarimiz var.

İşə başlamaq

Gəlin CI addımlarının siyahısını tərtib etməyə başlayaq. Normalda siz bu addımı kodun ən son versiyasını uzaq depodan yoxlamaqla başlayardınız, lakin bizim hələ yerli depomuz yoxdur, ona görə də biz onu uzaqdan klonlayırıq.

️ Tapşırıq: yerli deponu yeniləyin, buradan filial yaradın master, işə başlamaq

1. Kurs deposunu klonlayın <URL репозитория>.
2. Çalışın npm install kurs anbar kataloqunda; Testlər aparmaq üçün istifadə etdiyimiz Jest-i quraşdırmaq üçün bizə lazımdır.
3. Filial yaradın və adını verin feature. Bu mövzuya keçin.

4. Test kodu əlavə edin ci.test.js Məndən bunu etməyi xahiş edən şərhlər arasında.

   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. Fayla ilk 4 addımı olan mətn əlavə edin 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.  

   Komanda

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

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

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

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

Yeni filialda öhdəliklər yaradın, yerli olaraq qurun və sınaqdan keçirin

Təhlükəsizliyə başlamazdan əvvəl testləri təyin edəcəyik və sonra kodu yerinə yetirəcəyik.

Testlər avtomatik işə salındıqda tipik ssenarilər

• Yerli:
  • Davamlı olaraq və ya müvafiq kod dəyişikliklərinə cavab olaraq;
  • Saxlama haqqında (tərcümə edilmiş və ya JIT tərəfindən tərtib edilmiş dillər üçün);
  • Montaj zamanı (kompilyasiya tələb olunduqda);
  • Öhdəlik haqqında;
  • Paylaşılan anbarda dərc edərkən.

• Quraşdırma serverində və ya qurma mühitində:
  • Kod şəxsi filialda/repozitoriyada dərc edildikdə.
  • Bu mövzudakı kod sınaqdan keçirilir.
  • Birləşmənin potensial nəticəsi sınaqdan keçirilir (adətən master).
  • Davamlı inteqrasiya mərhələsi/davamlı çatdırılma boru kəməri kimi

Tipik olaraq, test paketi nə qədər tez işləsə, bir o qədər tez-tez onu işə sala bilərsiniz. Tipik bir mərhələ paylanması bu kimi görünə bilər.

• Sürətli vahid sınaqları - tikinti zamanı, CI boru kəmərində
• Yavaş bölmə testləri, sürətli komponent və inteqrasiya testləri - yerinə yetirildikdə, CI boru kəmərində
• Yavaş komponent və inteqrasiya testləri - CI boru kəmərində
• Təhlükəsizlik testi, yük testi və digər vaxt aparan və ya bahalı sınaqlar - CI/CD boru kəmərlərində, lakin yalnız quruluşun müəyyən rejimlərində/mərhələlərində/boru kəmərlərində, məsələn, buraxılış namizədi hazırlayarkən və ya əl ilə işləyərkən.

️Tapşırıq

Testləri əvvəlcə əmrdən istifadə edərək əl ilə keçirməyi təklif edirəm npm test. Bundan sonra testlərimizi yerinə yetirmək üçün git hook əlavə edək. Bir məqam var: Git qarmaqları repozitoriyanın bir hissəsi hesab edilmir və buna görə də kurs materiallarının qalan hissəsi ilə birlikdə GitHub-dan klonlana bilməz. Çəngəl quraşdırmaq üçün qaçmaq lazımdır install_hook.sh və ya faylı kopyalayın repo/hooks/pre-commit yerli kataloqa .git/hooks/.
Etdiyiniz zaman testlərin keçirildiyini və siyahıda müəyyən açar sözlərin olub-olmadığını yoxlayacağını görəcəksiniz.

1. Komandanı işlətməklə testləri əl ilə həyata keçirin npm test kurs anbar qovluğunda. Testlərin tamamlandığını yoxlayın.
2. Qaçışla icra çəngəlini (əvvəlcədən icra çəngəl) təyin edin install_hook.sh.
3. Dəyişikliklərinizi yerli deponuza köçürün.
4. Təhlil etməzdən əvvəl testlərin keçirildiyinə əmin olun.

Bu addımları yerinə yetirdikdən sonra deponuz belə görünməlidir.

Komanda

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

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

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

Kodu uzaq depoya və ya uzaq filiala dərc edin

Yerli olaraq işləməyi başa vurduqdan sonra tərtibatçılar adətən öz kodlarını ictimaiyyətə təqdim edirlər ki, nəticədə ictimaiyyətlə inteqrasiya olunsun. GitHub ilə buna adətən işi ya deponun şəxsi nüsxəsində (şəxsi çəngəl) və ya şəxsi filialda dərc etməklə nail olunur.

• Çəngəllər ilə bir tərtibatçı uzaqdan paylaşılan anbarı klonlayır və onun şəxsi uzaqdan nüsxəsini yaradır, çəngəl kimi də tanınır. Daha sonra yerli olaraq işləmək üçün bu şəxsi deponu klonlaşdırır. İş tamamlandıqda və öhdəliklər yerinə yetirildikdə, o, onları başqaları üçün əlçatan olduğu və ümumi depoya inteqrasiya oluna biləcəyi çəngəlinə itələyir. Bu yanaşma adətən GitHub-da açıq mənbə layihələrində istifadə olunur. O, mənim qabaqcıl kursumda da istifadə olunur [Komanda işi və Git ilə CI] (http://devops.redpill.solutions/).
• Başqa bir yanaşma yalnız bir uzaq depodan istifadə etmək və yalnız filialı saymaqdır master paylaşılan depo "qorunur". Bu ssenaridə ayrı-ayrı tərtibatçılar öz kodlarını uzaq deponun filiallarında dərc edirlər ki, başqaları bu koda baxa bilsinlər, əgər hər şey qaydasındadırsa, onunla birləşdirin. master paylaşılan anbar.

Bu xüsusi kursda filiallardan istifadə edən bir iş axınından istifadə edəcəyik.

Gəlin kodumuzu dərc edək.

️Tapşırıq

• Dəyişiklikləri işləyən filialınızla eyni adlı uzaq filialda dərc edin

Komanda

git push --set-upstream origin feature

Çəkmə sorğusu yaradın

Başlıq ilə çəkmə sorğusu yaradın Addımların nəzərdən keçirilməsi... Yüklemek feature kimi "baş budaq" və master "baza filialı" kimi.

Quraşdırdığınızdan əmin olun master onun içində anbarı bağlayın "Baza filialı" olaraq, kurs materialları anbarında dəyişiklik tələblərinə cavab verməyəcəyəm.

GitHub lingo-da "baza filialı" işinizi əsaslandırdığınız filialdır və "baş budaq" təklif olunan dəyişiklikləri ehtiva edən filialdır.

Dəyişiklikləri müzakirə edin, müzakirə davam etdikcə yeni öhdəliklər əlavə edin

Çəkmə sorğusu (PR)

Çəkmə sorğusu (PR) kodu müzakirə etmək və sənədləşdirmək, eləcə də kodu nəzərdən keçirmək üçün bir yoldur. Çəkmə sorğuları fərdi dəyişikliklərin ümumi koda inteqrasiyasının ümumi üsulu ilə adlandırılır. Tipik olaraq, şəxs layihənin uzaq rəsmi deposunu klonlayır və kod üzərində yerli olaraq işləyir. Bundan sonra o, kodu şəxsi uzaq deposuna yerləşdirir və rəsmi depoya cavabdeh olan şəxslərdən götürməyi xahiş edir(dartmaq) kodunu nəzərdən keçirdikləri və bəlkə də birləşdirə biləcəyi yerli repozitoriyalarına daxil edin(qatışmaq) onun. Bu anlayış başqa adlarla da tanınır, məsələn, birləşmə sorğusu.

GitHub və ya oxşar platformaların çəkmə sorğusu funksiyasından istifadə etmək məcburiyyətində deyilsiniz. İnkişaf qrupları üz-üzə ünsiyyət, səsli zənglər və ya e-poçt da daxil olmaqla digər ünsiyyət üsullarından istifadə edə bilər, lakin forum tipli çəkmə sorğularından istifadə etmək üçün hələ də bir sıra səbəblər var. Onlardan bəzilərini təqdim edirik:

• xüsusi kod dəyişiklikləri ilə bağlı müzakirələrin təşkili;
• həm avtotestçilər, həm də həmyaşıdları tərəfindən davam edən iş haqqında rəylərə baxmaq üçün bir yer kimi;
• kodun nəzərdən keçirilməsinin rəsmiləşdirilməsi;
• belə ki, sonradan bu və ya digər kod parçasının arxasında duran səbəbləri və mülahizələri öyrənə biləsiniz.

Tipik olaraq, nəyisə müzakirə etmək və ya rəy almaq lazım olanda bir çəkmə sorğusu yaradırsınız. Məsələn, birdən çox şəkildə həyata keçirilə bilən funksiya üzərində işləyirsinizsə, fikirlərinizi bölüşmək və planlarınızı əməkdaşlarınızla müzakirə etmək üçün kodun ilk sətirini yazmadan əvvəl çəkmə sorğusu yarada bilərsiniz. Əgər iş daha sadədirsə, bir şey artıq görülüb, yerinə yetirildikdə və müzakirə oluna bildikdə, çəkmə sorğusu açılır. Bəzi ssenarilərdə siz yalnız keyfiyyətə nəzarət məqsədləri üçün PR açmaq istəyə bilərsiniz: avtomatlaşdırılmış testlər keçirmək və ya kod nəzərdən keçirməyə başlamaq. Qərarınız nə olursa olsun, çəkmə sorğunuzda təsdiqini istədiyiniz insanları @qeyd etməyi unutmayın.

Tipik olaraq, PR yaratarkən aşağıdakıları edirsiniz.

• Nəyi və harada dəyişdirməyi təklif etdiyinizi göstərin.
• Dəyişikliklərin məqsədini izah edən təsviri yazın. İstəyə bilərsiniz:
  • koddan aydın olmayan vacib hər hansı bir şeyi və ya müvafiq #bugs və commit nömrələri kimi konteksti anlamaq üçün faydalı bir şey əlavə edin;
  • işləməyə başlamaq istədiyiniz hər kəsi @qeyd edin və ya daha sonra şərhlərdə @qeyd edə bilərsiniz;
  • həmkarlarınızdan bir şeydə kömək etmələrini və ya konkret bir şeyi yoxlamaqlarını xahiş edin.

PR-ı açdıqdan sonra belə hallarda işləmək üçün konfiqurasiya edilmiş testlər yerinə yetirilir. Bizim vəziyyətimizdə bu, yerli olaraq keçirdiyimiz testlər dəsti olacaq, lakin real layihədə əlavə testlər və yoxlamalar ola bilər.

Testlər tamamlanana qədər gözləyin. GitHub interfeysində PR müzakirəsinin altındakı testlərin vəziyyətini görə bilərsiniz. Testlər tamamlandıqda davam edin.

️ CI addımlarının siyahısının təsadüfi olması haqqında qeyd əlavə edin

Bu kursda istifadə olunan siyahı ixtiyari və subyektivdir, bu barədə bir qeyd əlavə etməliyik.

️ Tapşırıq: bu şərh üçün çəkmə sorğusu yaradın

1. Filiallara keçin master.
2. adlı bir filial yaradın bugfix.
3. Faylın sonuna qeyd mətni əlavə edin 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. Dəyişikliklərə əməl edin.
5. Mövzunu dərc edin bugfix uzaq depoya.
6. adlı çəkmə sorğusu yaradın Qeyd əlavə etmək baş filialı ilə bugfix və əsas filialmaster.

Quraşdırdığınızdan əmin olun master onun içində anbarı bağlayın "Baza filialı" olaraq, kurs materialları anbarında dəyişiklik tələblərinə cavab verməyəcəyəm.

Anbarınız belə görünməlidir.

Komanda

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

"Bir qeydin əlavə edilməsi" sorğusunu təsdiqləyin

️Tapşırıq

1. Çəkmə sorğusu yaradın.
2. "Çəkmə sorğusunu birləşdir" üzərinə klikləyin.
3. "Birləşməni təsdiq et" düyməsini basın.
4. "Filili sil" klikləyin, artıq bizə lazım deyil.

Bu birləşmədən sonra öhdəliklərin diaqramıdır.

️ İşləməyə və testlər əlavə etməyə davam edin

Çəkmə sorğusu üzərində əməkdaşlıq çox vaxt əlavə işlərlə nəticələnir. Bu, adətən kodun nəzərdən keçirilməsi və ya müzakirəsinin nəticəsidir, lakin kursumuzda biz bunu CI addımları siyahısına yeni elementlər əlavə etməklə modelləşdirəcəyik.

Davamlı inteqrasiya adətən bəzi test əhatəsini əhatə edir. Test əhatəsi tələbləri dəyişir və adətən "töhfə qaydaları" kimi bir sənəddə tapılır. Biz bunu sadə saxlayacağıq və yoxlama siyahımızda hər sətir üçün bir test əlavə edəcəyik.

Tapşırıqları yerinə yetirərkən əvvəlcə testləri yerinə yetirməyə çalışın. Düzgün quraşdırmısınızsa pre-commit əvvəl çəngəl, yeni əlavə edilmiş test icra olunacaq, uğursuz olacaq və heç bir şey törədilməyəcək. Qeyd edək ki, testlərimizin əslində nəyisə sınadığını belə bilirik. Maraqlıdır ki, testlərdən əvvəl kodla başlasaq, testlərdən keçmək ya kodun gözlənildiyi kimi işlədiyini, ya da testlərin əslində heç bir şeyi sınaqdan keçirmədiyini göstərə bilər. Üstəlik, ilk növbədə testləri yazmasaydıq, bəlkə də onları tamamilə unuda bilərdik, çünki heç bir şey bizə bunu xatırlatmazdı.

Test Əsaslı İnkişaf (TDD)

TDD koddan əvvəl testlər yazmağı tövsiyə edir. TDD istifadə edən tipik bir iş axını bu kimi görünür.

1. Test əlavə edin.
2. Bütün testləri yerinə yetirin və yeni testin uğursuz olduğundan əmin olun.
3. Kodu yazın.
4. Testləri həyata keçirin, bütün testlərin keçdiyinə əmin olun.
5. Kodunuzu refaktor edin.
6. Təkrarlamaq.

Uğursuz olan testlərin nəticələri adətən qırmızı, keçənlər isə yaşıl rəngdə göstərildiyi üçün dövrə qırmızı-yaşıl-refaktor kimi də tanınır.

️Tapşırıq

Əvvəlcə testləri yerinə yetirməyə və onların uğursuz olmasına icazə verməyə çalışın, sonra CI addım siyahısının mətnini əlavə edin və yerinə yetirin. Testlərin keçdiyini görəcəksiniz ("yaşıl").
Sonra yeni kodu uzaq depoda dərc edin və çəkmə sorğusu müzakirəsinin və PR statusu yeniləməsinin altındakı GitHub interfeysində həyata keçirilən testlərə baxın.

1. Filiallara keçin feature.

2. Bu testləri əlavə edin ci.test.js son zəngdən sonra 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. Testləri yerinə yetirməyə çalışın. Əgər pre-commit çəngəl quraşdırılıb, öhdəçilik cəhdi uğursuz olacaq.
4. Sonra bu mətni əlavə edin 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. Yerli olaraq dəyişikliklər edin və edin.
6. Filialda dəyişikliklər göndərin feature.

İndi belə bir şeyə sahib olmalısınız

Komanda

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

Münaqişəni birləşdirin

Dəyişiklik sorğusuna keçin Addımların nəzərdən keçirilməsi.

Səhv bir şey etməsək və kodumuz üçün testlər keçsə də, biz hələ də filialı birləşdirə bilmirik. feature и master. Çünki digər mövzu bugfix ilə birləşdirildi master biz bu PR üzərində işləyərkən.
Bu, uzaq şöbənin olduğu bir vəziyyət yaradır master filialı əsaslandırdığımız versiyadan daha yeni versiyaya malikdir feature. Buna görə biz sadəcə HEAD-i geri çevirə bilmərik master ipin sonuna qədər feature. Bu vəziyyətdə ya birləşməli, ya da öhdəlikləri tətbiq etməliyik feature rebase master. GitHub, heç bir ziddiyyət olmadıqda avtomatik birləşmələr həyata keçirə bilər. Təəssüf ki, bizim vəziyyətimizdə hər iki filialın faylda rəqabət aparan dəyişiklikləri var ci.md. Bu vəziyyət birləşmə münaqişəsi kimi tanınır və biz bunu əl ilə həll etməliyik.

Birləşdirin və ya yenidən qurun

Qatışmaq

• Əlavə birləşmə öhdəliyi yaradır və iş tarixçəsini saxlayır.
  • Filialların orijinal öhdəliklərini orijinal vaxt damğaları və müəllifləri ilə qoruyur.
  • Dəyişiklik sorğusu müzakirələrində öhdəliklərin və onlara keçidlərin SHA-nı saxlayır.
• Birdəfəlik münaqişənin həllini tələb edir.
• Hekayəni qeyri-xətti edir.
  • Budaqların çoxluğuna görə hekayəni oxumaq çətin ola bilər (IDE kabelini xatırladır).
  • Avtomatik sazlamanı çətinləşdirir, məs. git bisect daha az faydalı - o, yalnız birləşmə öhdəliyini tapacaq.

Baza

• Bir-birinin ardınca əsas budağın üstündəki cari filialdan öhdəliyi təkrarlayır.
  • Yeni SHA-larla yeni öhdəliklər yaradılır, bu da GitHub-dakı öhdəliklərin müvafiq şərhlərə deyil, orijinal çəkmə sorğularına uyğun olmasına səbəb olur.
  • Öhdəliklər prosesdə yenidən birləşdirilə və dəyişdirilə və ya hətta birinə birləşdirilə bilər.
• Çoxlu münaqişələrin həllinə ehtiyac ola bilər.
• Xətti hekayəni saxlamağa imkan verir.
  • Heç bir ağlabatan səbəb olmadan çox uzun olmadığı müddətcə hekayəni oxumaq daha asan ola bilər.
  • Avtomatik sazlama və problemlərin aradan qaldırılması bir az asandır: bunu mümkün edir git bisect, avtomatik geri dönmələri daha aydın və proqnozlaşdırıla bilən edə bilər.
• Bayraq ilə köçürülmüş öhdəlikləri olan filialın dərc edilməsini tələb edir --force çəkmə tələbləri ilə istifadə edildikdə.

Tipik olaraq, komandalar dəyişiklikləri birləşdirməyə ehtiyac olduqda həmişə eyni strategiyadan istifadə etməyə razılaşırlar. Bu, "təmiz" birləşmə və ya yuxarıda "təmiz" öhdəlik ola bilər və ya interaktiv şəkildə yuxarıda bir öhdəlik yerinə yetirmək kimi bir şey ola bilər(git rebase -i) yerli olaraq ictimai repozitoriyada dərc olunmayan filiallar üçün, lakin "ictimai" filiallar üçün birləşdirin.

Burada birləşmədən istifadə edəcəyik.

️Tapşırıq

1. Kodun yerli filialda olduğundan əmin olun master uzaq depodan yeniləndi.
2. Filiallara keçin feature.
3. Filialla birləşməyə başlayın master. Rəqabətli dəyişikliklər səbəbiylə birləşmə münaqişəsi ci.md.
4. Münaqişəni elə həll edin ki, həm CI addımlarımızın siyahısı, həm də bu barədə qeyd mətndə qalsın.
5. Uzaq filiala birləşmə öhdəliyini dərc edin feature.
6. GitHub UI-də çəkmə sorğusunun vəziyyətini yoxlayın və birləşmənin həllini gözləyin.

Komanda

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

Əla işdir!

Siyahı ilə işiniz bitdi və indi cəlbetmə sorğusunu təsdiqləməlisiniz master.

️ Tapşırıq: "Addımların nəzərdən keçirilməsi" sorğusunu təsdiqləyin

1. Çəkmə sorğusu açın.
2. "Çəkmə sorğusunu birləşdir" üzərinə klikləyin.
3. "Birləşməni təsdiq et" düyməsini basın.
4. Artıq ehtiyacımız olmadığı üçün "Filili sil" düyməsini basın.

Bu, hazırda sizin deponuzdur

Məhsul xətası

Deyirlər ki, “sınaq səhvlərin olub-olmadığını göstərmək üçün istifadə oluna bilər, lakin onların yoxluğunu heç vaxt göstərməmək üçün”. Testlərimiz olsa da və onlar bizə heç bir səhv göstərməsələr də, istehsala məkrli bir səhv daxil oldu.

Belə bir ssenaridə biz qayğı göstərməliyik:

• istehsalda nə tətbiq olunur;
• mövzuda kod master tərtibatçıların yeni işə başlaya biləcəyi bir səhv ilə.

Onu geri qaytarmalıyam, yoxsa növbəti versiyada düzəltməliyəm?

Geri qaytarma, tanınmış yaxşı əvvəlki versiyanın istehsala yerləşdirilməsi və xətanı ehtiva edən öhdəliklərin geri qaytarılması prosesidir. "İrəli düzəltmək" bir düzəlişin əlavə edilməsidir master və mümkün qədər tez yeni versiyanın yerləşdirilməsi. API-lər və verilənlər bazası sxemləri kod istehsala yerləşdirildikcə, davamlı çatdırılma və yaxşı sınaq əhatəsi ilə dəyişdiyinə görə, geri qayıtmaq onu növbəti versiyada düzəltməkdən daha çətin və risklidir.

Geriyə yuvarlanma bizim vəziyyətimizdə heç bir risk daşımadığından, biz bu yolla gedəcəyik, çünki bu, bizə imkan verir

• məhsuldakı səhvi mümkün qədər tez düzəldin;
• kodu daxil edin master dərhal yeni işə başlamaq üçün uyğundur.

️Tapşırıq

1. Filiallara keçin master yerli olaraq.
2. Uzaq depodan yerli deponu yeniləyin.
3. PR birləşmə öhdəliyini geri qaytarın Addımların nəzərdən keçirilməsi в master.
4. Dəyişiklikləri uzaq depoda dərc edin.

Bu, birləşmə öhdəliyi geri qaytarılmış deponun tarixçəsidir

Komanda

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

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

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

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

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

️ Özünü sınamaq

Buna əmin olun ci.md birləşmə öhdəliyini geri qaytardıqdan sonra artıq "gizli səhv" mətnini ehtiva etmir.

CI addımlarının siyahısını düzəldin və master-a qaytarın

Filialın birləşmə öhdəliyini tamamilə geri qaytardıq. feature. Yaxşı xəbər budur ki, indi heç bir səhvimiz yoxdur master. Pis xəbər odur ki, davamlı inteqrasiya addımlarımızın qiymətli siyahısı da itdi. Beləliklə, ideal olaraq, düzəlişi olan öhdəliklərə tətbiq etməliyik feature və onları geri qaytarın master düzəltmə ilə birlikdə.

Problemə müxtəlif yollarla yanaşa bilərik:

• birləşməni ləğv edən öhdəliyi geri qaytarın feature с master;
• hərəkət əvvəlkindən əmələ gəlir feature.

Fərqli inkişaf qrupları bu halda fərqli yanaşmalardan istifadə edir, lakin biz faydalı öhdəlikləri ayrıca filiala köçürəcəyik və bu yeni filial üçün ayrıca çəkmə sorğusu yaradacağıq.

️Tapşırıq

1. adlı bir mövzu yaradın feature-fix və ona keçin.

2. Keçmiş filialdan bütün öhdəlikləri köçürün feature yeni mövzuya. Miqrasiya zamanı yaranan birləşmə münaqişələrini həll edin.

   

3. Bir reqressiya testi əlavə edin ci.test.js:

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

4. Uğursuz olmadıqlarına əmin olmaq üçün testləri yerli olaraq həyata keçirin.
5. İçindəki "gizli səhvlə" mətnini silin ci.md.
6. İndeksə test dəyişiklikləri və addım siyahısı dəyişiklikləri əlavə edin və onları yerinə yetirin.
7. Filialı uzaq depoda dərc edin.

Buna bənzər bir şeylə başa vurmalısınız:

Komanda

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

Çəkmə sorğusu yaradın.

Başlıq ilə çəkmə sorğusu yaradın Xüsusiyyətin düzəldilməsi... Yüklemek feature-fix kimi "baş budaq" və master "baza filialı" kimi.
Testlər tamamlanana qədər gözləyin. Testlərin vəziyyətini PR müzakirəsinin altında görə bilərsiniz.

Quraşdırdığınızdan əmin olun master onun içində anbarı bağlayın "Baza filialı" olaraq, kurs materialları anbarında dəyişiklik tələblərinə cavab verməyəcəyəm.

"Xüsusiyyət düzəldilir" çəkmə sorğusunu təsdiqləyin

Düzəliş üçün təşəkkür edirik! Dəyişiklikləri təsdiqləyin master çəkmə sorğusundan.

️Tapşırıq

1. "Çəkmə sorğusunu birləşdir" üzərinə klikləyin.
2. "Birləşməni təsdiq et" düyməsini basın.
3. Artıq ehtiyacımız olmadığı üçün "Filili sil" düyməsini basın.

Bu anda sizdə olmalıdır.

Təbrik edirik!

Davamlı inteqrasiya zamanı insanların adətən atdıqları bütün addımları tamamladınız.

Kursla bağlı hər hansı problem görsəniz və ya onu necə təkmilləşdirəcəyinizi bilirsinizsə, lütfən, burada problem yaradın kurs materialları ilə depolar. Bu kurs da var interaktiv versiya GitHub Learning Lab-dan platforma kimi istifadə.

Mənbə: www.habr.com