Сіз Git командаларын үйрендіңіз бе, бірақ үздіксіз интеграцияның (CI) шын мәнінде қалай жұмыс істейтінін елестеткіңіз келе ме? Немесе күнделікті әрекеттеріңізді оңтайландырғыңыз келе ме? Бұл курс сізге GitHub репозиторийін пайдаланып үздіксіз интеграциялаудың практикалық дағдыларын береді. Бұл курс жай ғана басуға болатын шебер болуға арналмаған; керісінше, сіз адамдар жұмыста іс жүзінде жасайтын әрекеттерді олар жасайтын әдіспен орындайсыз. Қадамдар арқылы өтіп жатқанда мен теорияны түсіндіремін.

Біз не істейміз?

Прогресс барысында біз бірте-бірте әдеттегі CI қадамдарының тізімін жасаймыз, бұл осы тізімді есте сақтаудың тамаша тәсілі. Басқаша айтқанда, біз үздіксіз интеграцияны орындау кезінде әзірлеушілер жасайтын әрекеттер тізімін жасаймыз. Біз сондай-ақ CI процесін нақтыға жақындату үшін қарапайым сынақтар жинағын қолданамыз.

Бұл GIF курсты өту барысында репозиторийдегі тапсырмаларды схемалық түрде көрсетеді. Көріп отырғаныңыздай, мұнда күрделі ештеңе жоқ және тек ең қажет.

Сіз келесі стандартты CI сценарийлерінен өтесіз:

• Функция бойынша жұмыс істеу;
• Сапаны қамтамасыз ету үшін автоматтандырылған сынақтарды қолдану;
• Бірінші кезектегі міндетті жүзеге асыру;
• Филиалдарды біріктіру кезінде қайшылықтарды шешу (біріктіру конфликті);
• Өндірістік ортада қате орын алады.

Сіз не үйренесіз?

Сіз келесі сұрақтарға жауап бере аласыз:

• Үздіксіз интеграция (CI) дегеніміз не?
• CI-де автоматтандырылған сынақтардың қандай түрлері қолданылады және олар қандай әрекеттерге жауап ретінде іске қосылады?
• Тарту сұраулары дегеніміз не және олар қашан қажет?
• Тестке негізделген даму (TDD) дегеніміз не және оның CI-мен қандай қатысы бар?
• Өзгерістерді біріктіру керек пе немесе қайта құру керек пе?
• Артқа айналдыру немесе келесі нұсқада түзету керек пе?

Бастапқыда мен барлық жерде «pull requests» сияқты нәрселерді аудардым, бірақ нәтижесінде мәтіндегі ақылсыздықты азайту үшін кейбір жерлерде ағылшын тіліндегі сөз тіркестерін қайтаруды шештім. Мен кейде «бағдарламашы суржик» сөзін адамдар оны жұмыста қолданатын «міндет» деген тамаша етістігі сияқты қолданамын.

Үздіксіз интеграция дегеніміз не?

Үздіксіз интеграция, немесе CI - әрбір команда мүшесі өз кодын күніне кемінде бір рет ортақ репозиторийге біріктіретін техникалық тәжірибе және нәтижесінде алынған код кем дегенде қатесіз құрастырылуы керек.

Бұл терминге қатысты келіспеушіліктер бар

Даулы мәселе - интеграцияның жиілігі. Кейбіреулер үздіксіз біріктіру үшін кодты күніне бір рет біріктіру жеткіліксіз деп санайды. Әрбір адам таңертең жаңа кодты алып, кешке бір рет біріктіретін команданың мысалы келтірілген. Бұл ақылға қонымды қарсылық болғанымен, әдетте күніне бір рет болатын анықтама ақылға қонымды, нақты және әртүрлі өлшемдегі командалар үшін жарамды деп есептеледі.

Тағы бір қарсылық мынада: C++ енді әзірлеуде қолданылатын жалғыз тіл емес және тексеру әдісі ретінде қатесіз құрастыруды талап ету әлсіз. Кейбір сынақтар жинағы (мысалы, жергілікті орындалған бірлік сынақтары) да сәтті аяқталуы керек. Қазіргі уақытта қауымдастық мұны талап ету бағытында жүріп жатыр және болашақта «құрастыру + бірлік сынақтары» әлі болмаса, әдеттегі тәжірибеге айналуы мүмкін.

Үздіксіз интеграция ерекшеленеді үздіксіз жеткізу (Үздіксіз жеткізу, ықшам дискі), өйткені ол әрбір интеграция циклінен кейін шығарылым кандидатын қажет етпейді.

Курс барысында біз қолданатын қадамдар тізімі

1. Соңғы кодты тартыңыз. филиалын жасаңыз master. Жұмысты бастаңыз.
2. Жаңа филиалыңызда міндеттеме жасаңыз. Жергілікті жерде құрастырыңыз және сынаңыз. Өту? Келесі қадамға өтіңіз. Сәтсіз бе? Қателерді немесе сынақтарды түзетіп, әрекетті қайталаңыз.
3. Қашықтағы репозиторийге немесе қашықтағы филиалға басыңыз.
4. Тарту сұрауын жасаңыз. Өзгерістерді талқылаңыз, талқылау жалғасуда көбірек міндеттеме қосыңыз. Сынақтарды мүмкіндік тармағында тапсырыңыз.
5. Шеберден міндеттемелерді біріктіру/қайта негіздеу. Біріктіру нәтижесі бойынша сынақтардан өтуге мүмкіндік беріңіз.
6. Мүмкіндік тармағынан өндіріске дейін орналастырыңыз.
7. Біраз уақыт ішінде өндірісте бәрі жақсы болса, өзгертулерді шеберге біріктіріңіз.

️ Дайындық

Дұрыс бағдарламалық құрал бар екеніне көз жеткізіңіз

Бұл курсты алу үшін сізге қажет Node.js и Git клиенті.

Сіз кез келген Git клиентін пайдалана аласыз, бірақ мен тек пәрмен жолы үшін пәрмендерді беремін.

Пәрмен жолын қолдайтын Git клиенті орнатылғанына көз жеткізіңіз

Пәрмен жолын қолдайтын Git клиенті әлі болмаса, орнату нұсқауларын таба аласыз осында.

Репозиторийді дайындаңыз

Сізге жеке көшірме жасау қажет (шанышқы) курс коды бар үлгі репозиторийі GitHub сайтында. Осы жеке көшірмені атауға келістік курс репозиторийі.

Дайын ба? Әдепкі параметрлерді өзгертпеген болсаңыз, сіздің курс репозиторийіңіз шақырылады continuous-integration-team-scenarios-students, ол GitHub тіркелгіңізде орналасқан және URL мекенжайы келесідей көрінеді

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

Мен жай ғана осы мекенжайға хабарласамын <URL репозитория>.

Бұрыштық жақшалар сияқты <тут> мұндай өрнекті сәйкес мәнмен ауыстыру керек дегенді білдіреді.

Бұған көз жеткізіңіз GitHub әрекеттері осы курс репозиторийіне енгізілген. Егер олар қосылмаған болса, оларды беттің ортасындағы үлкен түймені басу арқылы қосыңыз, оған GitHub интерфейсіндегі Әрекеттер түймесін басу арқылы қол жеткізуге болады.

GitHub әрекеттері қосылмаған болса, менің нұсқауларым бойынша курсты аяқтай алмайсыз.

Мұнда біз жасап жатқан тізімнің ағымдағы күйін көру үшін GitHub-тың Markdown көрсету мүмкіндігін әрқашан пайдалана аласыз.

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

Жауаптар туралы

Бұл курсты аяқтаудың ең жақсы жолы оны өзіңіз жасау болғанымен, сізде кейбір қиындықтар болуы мүмкін.

Егер сіз не істеу керектігін түсінбей жатқаныңызды және жалғастыра алмайтыныңызды сезсеңіз, ағынды қарауға болады solution, ол сіздің бастапқы репозиторийіңізде.
Біріктірмеңіз solution в master курс барысында. Сіз бұл тармақты не істеу керектігін анықтау үшін немесе Git бізге беретін барлық мүмкіндіктерді пайдалана отырып, автордың кодымен салыстыру үшін пайдалана аласыз. Егер сіз толығымен жоғалсаңыз, филиалыңызды толығымен ауыстыра аласыз master филиалда solution содан кейін жұмыс каталогын қажетті курс қадамына қалпына келтіріңіз.

Мұны сізге шынымен қажет болған жағдайда ғана пайдаланыңыз

Кодыңызды тапсырыңыз

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

Бұл командалар

• атын өзгерту master в master-backup;
• атын өзгерту solution в master;
• жаңа филиалға төлем жасау master және жұмыс каталогының мазмұнын қайта жазу;
• Болашақта «шешім» тармағы қажет болған жағдайда «шеберден» (бұрын «шешім» болған) «шешім» тармағын жасаңыз.

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

Осы қадамдардан кейін сіз пайдалана аласыз git log master Сізге қандай міндеттеме қажет екенін анықтау үшін.
Жұмыс каталогын осы міндеттемеге келесідей қалпына келтіруге болады:

git reset --hard <the SHA you need>

Нәтижеге риза болсаңыз, белгілі бір уақытта репозиторийдің нұсқасын қашықтағы репозиторийге жариялау қажет болады. Мұны істегенде қашықтағы филиалды нақты көрсетуді ұмытпаңыз.

git push --force origin master

Біз қолданатынымызды ескеріңіз git push --force. Сіз мұны өте жиі орындағыңыз келетіні екіталай, бірақ бізде бір репозиторий пайдаланушысы бар өте нақты сценарий бар, ол қосымша оның не істеп жатқанын түсінеді.

Жұмысты бастау

CI қадамдарының тізімін құрастыруды бастайық. Әдетте бұл қадамды қашықтағы репозиторийден кодтың соңғы нұсқасын тексеру арқылы бастайсыз, бірақ бізде әлі жергілікті репозиторий жоқ, сондықтан оның орнына қашықтағы репозитарийден клондаймыз.

️ Тапсырма: жергілікті репозиторийді жаңартыңыз, бөлімше жасаңыз master, жұмысқа кірісіңіз

1. Курс репозиторийін клондау <URL репозитория>.
2. Жүгіру npm install курс репозиторийінің анықтамалығында; Бұл бізге сынақтарды орындау үшін пайдаланатын Jest орнату үшін қажет.
3. Филиал жасаңыз және оны атаңыз feature. Осы ағынға ауысыңыз.

4. Сынақ кодын қосыңыз ci.test.js мұны істеуімді сұрайтын пікірлер арасында.

   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. Файлға алғашқы 4 қадамы бар мәтінді қосыңыз 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.  

   Командалар

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

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

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

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

Жаңа филиалда міндеттемелерді жасаңыз, жергілікті түрде жасаңыз және сынаңыз

Біз орындамас бұрын сынақтарды орнатамыз, содан кейін кодты орындаймыз.

Тесттер автоматты түрде іске қосылған кездегі әдеттегі сценарийлер

• Жергілікті:
  • Үздіксіз немесе сәйкес код өзгерістеріне жауап ретінде;
  • Сақтау туралы (түсіндірілетін немесе JIT құрастырылған тілдер үшін);
  • Құрастыру кезінде (компиляция қажет болғанда);
  • Міндеттеме бойынша;
  • Ортақ репозиторийге жариялау кезінде.

• Құрастыру серверінде немесе құрастыру ортасында:
  • Код жеке филиалға/репозиторийге жарияланған кезде.
  • Бұл ағындағы код тексерілуде.
  • Біріктірудің ықтимал нәтижесі сыналады (әдетте master).
  • Үздіксіз интеграция кезеңі/үздіксіз жеткізу құбыры ретінде

Әдетте, сынақ жинағы неғұрлым жылдам жұмыс істесе, соғұрлым оны іске қосу мүмкіндігіңіз болады. Әдеттегі кезеңді бөлу келесідей болуы мүмкін.

• Жылдам қондырғы сынақтары - құрастыру кезінде, CI құбырында
• Баяу блок сынақтары, жылдам құрамдас және біріктіру сынақтары – орындау кезінде, CI құбырында
• Баяу құрамдас және интеграциялық сынақтар - CI құбырында
• Қауіпсіздік сынағы, жүктеме сынағы және басқа уақытты қажет ететін немесе қымбат сынақтар - CI/CD құбырларында, бірақ құрылыстың белгілі бір режимдерінде/кезеңдерінде/құбырларында, мысалы, шығару кандидатын дайындаған кезде немесе қолмен іске қосылғанда.

️Тапсырма

Алдымен пәрменді пайдаланып сынақтарды қолмен орындауды ұсынамын npm test. Осыдан кейін тесттерімізді орындау үшін git hook қосайық. Бір тосқауыл бар: Git ілмектері репозиторийдің бөлігі болып саналмайды, сондықтан GitHub-тан курс материалдарының қалған бөлігімен бірге клондауға болмайды. Ілмекті орнату үшін сізге жүгіру керек install_hook.sh немесе файлды көшіріңіз repo/hooks/pre-commit жергілікті каталогқа .git/hooks/.
Сіз орындаған кезде, сынақтардың орындалғанын және тізімде белгілі бір кілт сөздердің бар-жоғын тексеретінін көресіз.

1. Пәрменді іске қосу арқылы сынақтарды қолмен орындаңыз npm test курстың репозиторий қалтасында. Сынақтардың аяқталғанын тексеріңіз.
2. Іске қосу арқылы орындау ілмегін орнатыңыз (алдын ала орындалатын ілмек). install_hook.sh.
3. Өзгерістерді жергілікті репозиторийге енгізіңіз.
4. Жасалмас бұрын сынақтардың орындалғанына көз жеткізіңіз.

Осы қадамдарды орындағаннан кейін репозиторийіңіз осылай болуы керек.

Командалар

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

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

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

Кодты қашықтағы репозиторийге немесе қашықтағы филиалға жариялаңыз

Жергілікті жерде жұмыс істеп болғаннан кейін әзірлеушілер әдетте өз кодын көпшілікке қолжетімді етеді, осылайша ол сайып келгенде жұртшылықпен біріктіріледі. GitHub көмегімен бұл әдетте жұмысты репозиторийдің жеке көшірмесіне (жеке шанышқы) немесе жеке бөлімшеге жариялау арқылы қол жеткізіледі.

• Шанышқылардың көмегімен әзірлеуші ​​қашықтағы ортақ репозиторийді клондайды, оның жеке қашықтағы көшірмесін жасайды, сонымен қатар шанышқы ретінде белгілі. Содан кейін ол жергілікті түрде жұмыс істеу үшін осы жеке репозиторийді клондайды. Жұмыс аяқталып, міндеттеме жасалғанда, ол оларды басқаларға қолжетімді және ортақ репозиторийге біріктіруге болатын шанышқысына итереді. Бұл тәсіл әдетте GitHub жүйесіндегі ашық бастапқы жобаларда қолданылады. Ол менің кеңейтілген курсымда да қолданылады [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Басқа тәсіл – бір ғана қашықтағы репозиторийді пайдалану және тек филиалды санау master ортақ репозиторий "қорғалған". Бұл сценарийде жеке әзірлеушілер өздерінің кодын қашықтағы репозиторийдің филиалдарына жариялайды, осылайша басқалар осы кодты көре алады, егер бәрі тәртіпте болса, оны біріктіріңіз. master ортақ репозиторий.

Осы арнайы курста біз тармақтарды пайдаланатын жұмыс процесін қолданамыз.

Кодымызды жариялайық.

️Тапсырма

• Өзгерістерді жұмыс тармағымен бірдей атпен қашықтағы филиалға жариялаңыз

Командалар

git push --set-upstream origin feature

Тарту сұрауын жасаңыз

Тақырыппен тарту сұрауын жасаңыз Қадамдарды шолу... Орнату feature «бас тармақ» сияқты және master «негізгі филиал» сияқты.

Орнатқаныңызға көз жеткізіңіз master оның ішінде репозиторийді ашыңыз «Базалық филиал» ретінде мен курс материалдарының репозиторийіне өзгертулер енгізу туралы өтініштерге жауап бермеймін.

GitHub тіліндегі «негізгі тармақ» жұмысыңызды негіздейтін тармақ, ал «бас тармақ» - ұсынылған өзгерістерді қамтитын тармақ.

Өзгерістерді талқылаңыз, талқылау жалғасуда жаңа міндеттемелерді қосыңыз

Тарту сұрауы (PR)

Тарту сұрауы (PR) кодты талқылау және құжаттау, сондай-ақ кодты қарауды жүргізу тәсілі болып табылады. Тарту сұраулары жеке өзгерістерді жалпы кодқа біріктірудің жалпы тәсілімен аталады. Әдетте, адам жобаның қашықтағы ресми репозиторийін клондайды және кодта жергілікті түрде жұмыс істейді. Осыдан кейін ол кодты өзінің жеке қашықтағы репозиторийіне орналастырады және ресми репозиторийге жауаптылардан алуды сұрайды(Тарт) оның кодын жергілікті репозиторийлерге енгізеді, онда олар қарап шығады және мүмкін біріктіреді(қосылу) оның. Бұл ұғым басқа атаулармен де белгілі, мысалы, біріктіру сұрауы.

Сізге GitHub немесе ұқсас платформалардың тарту сұрау мүмкіндігін пайдаланудың қажеті жоқ. Әзірлеу топтары бетпе-бет сөйлесуді, дауыстық қоңырауларды немесе электрондық поштаны қоса, басқа байланыс әдістерін пайдалана алады, бірақ форум стиліндегі тарту сұрауларын пайдаланудың әлі де бірқатар себептері бар. Мұнда олардың кейбіреулері бар:

• арнайы код өзгерістеріне байланысты ұйымдастырылған талқылаулар;
• автотесттердің де, әріптестердің де аяқталмаған жұмыс туралы пікірлерін қарау орны ретінде;
• кодты қарауды ресімдеу;
• осылайша кейінірек сіз осы немесе басқа код бөлігінің себептері мен ойларын біле аласыз.

Әдетте бір нәрсені талқылау немесе кері байланыс алу қажет болғанда тарту сұрауын жасайсыз. Мысалы, бірнеше жолмен іске асырылуы мүмкін мүмкіндікте жұмыс істеп жатсаңыз, идеяларыңызбен бөлісу және жоспарларыңызды серіктестермен талқылау үшін кодтың бірінші жолын жазбас бұрын тарту сұрауын жасауға болады. Егер жұмыс оңайырақ болса, бірдеңе әлдеқашан орындалған, орындалған және талқылауға болатын кезде тарту сұрауы ашылады. Кейбір сценарийлерде PR-ды тек сапаны бақылау себептері үшін ашқыңыз келуі мүмкін: автоматтандырылған сынақтарды іске қосу немесе кодты қарап шығуды бастау. Қандай шешім қабылдасаңыз да, тарту сұрауында мақұлдауды қалайтын адамдарды @acib қоюды ұмытпаңыз.

Әдетте, PR жасау кезінде сіз келесі әрекеттерді орындайсыз.

• Нені және қайда өзгертуді ұсынатыныңызды көрсетіңіз.
• Өзгерістердің мақсатын түсіндіретін сипаттама жазыңыз. Сіз қалауыңыз мүмкін:
  • кодтан анық емес маңызды кез келген нәрсені немесе контекстті түсіну үшін пайдалы нәрсені қосыңыз, мысалы, сәйкес #қателер және орындалатын сандар;
  • Жұмысты бастағыңыз келетін кез келген адамды @mention немесе кейінірек түсініктемелерде оларды @metion қоюыңызға болады;
  • әріптестерден бір нәрсеге көмектесуін немесе нақты бір нәрсені тексеруін сұраңыз.

PR ашқаннан кейін мұндай жағдайларда іске қосу үшін конфигурацияланған сынақтар орындалады. Біздің жағдайда бұл біз жергілікті орындаған сынақтар жиынтығы болады, бірақ нақты жобада қосымша сынақтар мен тексерулер болуы мүмкін.

Сынақтар аяқталғанша күтіңіз. Тесттердің күйін GitHub интерфейсіндегі PR талқылауының төменгі жағында көруге болады. Сынақтар аяқталғаннан кейін жалғастырыңыз.

️ CI қадамдары тізімінің кездейсоқтығы туралы ескертпе қосыңыз

Бұл курста қолданылған тізім ерікті және субъективті, біз бұл туралы ескертуді қосуымыз керек.

️ Тапсырма: осы түсініктеме үшін тарту сұрауын жасаңыз

1. Филиалға ауысу master.
2. атты филиал жасаңыз bugfix.
3. Файлдың соңына ескертпе мәтінін қосыңыз 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. Өзгерістерді орындаңыз.
5. Жіпті жариялау bugfix қашықтағы репозиторийге.
6. деп аталатын тарту сұрауын жасаңыз Ескертпе қосу бас бұтағымен bugfix және базалық тармақmaster.

Орнатқаныңызға көз жеткізіңіз master оның ішінде репозиторийді ашыңыз «Базалық филиал» ретінде мен курс материалдарының репозиторийіне өзгертулер енгізу туралы өтініштерге жауап бермеймін.

Сіздің репозиторийіңіз осылай болуы керек.

Командалар

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

«Ескертпе қосу» тарту сұрауын мақұлдау

️Тапсырма

1. Тарту сұрауын жасаңыз.
2. «Біріктіру сұрауын» басыңыз.
3. «Біріктіруді растау» түймесін басыңыз.
4. «Бөлімшені жою» түймесін басыңыз, ол бізге енді қажет емес.

Бұл біріктіруден кейінгі міндеттемелер диаграммасы.

️ Жұмысты жалғастырыңыз және сынақтарды қосыңыз

Тарту сұрауы бойынша бірлесіп жұмыс істеу көбінесе қосымша жұмысқа әкеледі. Бұл әдетте кодты қараудың немесе талқылаудың нәтижесі болып табылады, бірақ біздің курста біз оны CI қадамдарының тізіміне жаңа элементтерді қосу арқылы модельдейтін боламыз.

Үздіксіз интеграция әдетте кейбір сынақ қамтуын қамтиды. Сынақпен қамту талаптары әр түрлі және әдетте «үлесі бойынша нұсқаулар» деп аталатын құжатта кездеседі. Біз оны қарапайым етіп сақтаймыз және бақылау парағына әрбір жолға сынақ қосамыз.

Тапсырмаларды орындау кезінде алдымен сынақтарды орындап көріңіз. Егер сіз дұрыс орнатқан болсаңыз pre-commit ертерек қоссаңыз, жаңадан қосылған сынақ іске қосылады, сәтсіздікке ұшырайды және ештеңе жасалмайды. Біздің сынақтар бір нәрсені сынап жатқанын осылай білеміз. Бір қызығы, егер тестілеуден бұрын кодпен бастасақ, сынақтардан өту кодтың күткендей жұмыс істегенін немесе сынақтар ештеңені тексермейтінін білдіруі мүмкін. Сонымен қатар, егер біз сынақтарды бірінші кезекте жазбаған болсақ, біз олар туралы мүлдем ұмытып кетуіміз мүмкін еді, өйткені бұл туралы ештеңе еске түсірмес еді.

Тестке негізделген әзірлеу (TDD)

TDD код алдында сынақ жазуды ұсынады. TDD пайдаланатын әдеттегі жұмыс процесі келесідей көрінеді.

1. Сынақ қосыңыз.
2. Барлық сынақтарды орындаңыз және жаңа сынақтың сәтсіздігіне көз жеткізіңіз.
3. Кодты жазыңыз.
4. Сынақтарды орындаңыз, барлық сынақтардың өткеніне көз жеткізіңіз.
5. Кодыңызды қайта өңдеңіз.
6. Қайталау.

Сәтсіз болған сынақтардың нәтижелері әдетте қызыл түспен, ал өткендері жасыл түспен көрсетілетіндіктен, цикл қызыл-жасыл-рефактор ретінде де белгілі.

️Тапсырма

Алдымен сынақтарды орындап көріңіз және олардың сәтсіз болуына жол беріңіз, содан кейін CI қадам тізімінің мәтінін өзі қосып, орындаңыз. Сіз сынақтардың өтіп жатқанын көресіз («жасыл»).
Содан кейін жаңа кодты қашықтағы репозиторийге жариялаңыз және тарту сұрауын талқылаудың төменгі жағындағы GitHub интерфейсінде орындалатын сынақтарды және PR күйін жаңартуды қараңыз.

1. Филиалға ауысу feature.

2. Осы сынақтарды қосыңыз ci.test.js соңғы қоңыраудан кейін 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. Тесттерді тапсырып көріңіз. Егер pre-commit ілмек орнатылған болса, орындау әрекеті сәтсіз болады.
4. Содан кейін осы мәтінді қосыңыз 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. Өзгерістерді жергілікті түрде жасаңыз және орындаңыз.
6. Филиалдағы өзгерістерді жариялау feature.

Енді сізде осындай нәрсе болуы керек

Командалар

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

Конфликті біріктіру

Өзгерту сұрауына өтіңіз Қадамдарды шолу.

Біз ешнәрсе дұрыс жасамағанымызға және кодтың сынақтарынан өткенімізге қарамастан, біз әлі де филиалды біріктіре алмаймыз. feature и master. Себебі басқа жіп bugfix -мен біріктірілді master біз осы PR-мен жұмыс істеген кезде.
Бұл қашықтағы филиалдың жағдайын жасайды master біз филиалға негізделген нұсқаға қарағанда жаңарақ нұсқасы бар feature. Осыған байланысты біз жай ғана HEAD артқа айналдыра алмаймыз master жіптің соңына дейін feature. Бұл жағдайда бізге міндеттемелерді біріктіру немесе қолдану қажет feature қайта құру master. Егер қайшылықтар болмаса, GitHub шын мәнінде автоматты біріктіруді орындай алады. Өкінішке орай, біздің жағдайымызда екі филиалда файлда бәсекелес өзгерістер бар ci.md. Бұл жағдай біріктіру қайшылығы ретінде белгілі және біз оны қолмен шешуіміз керек.

Біріктіру немесе қайта құру

Біріктіру

• Қосымша біріктіру тапсырмасын жасайды және жұмыс тарихын сақтайды.
  • Филиалдардың бастапқы тапсырмаларын түпнұсқа уақыт белгілерімен және авторларымен сақтайды.
  • Міндеттемелердің SHA мәнін және оларға сілтемелерді өзгерту сұрауын талқылауда сақтайды.
• Бір реттік қақтығысты шешуді талап етеді.
• Әңгімені сызықты емес етеді.
  • Тармақтардың көптігіне байланысты әңгімені оқу қиын болуы мүмкін (IDE кабелін еске түсіреді).
  • Автоматты жөндеуді қиындатады, мысалы. git bisect пайдалы емес - ол тек біріктіру тапсырмасын табады.

Бас тарту

• Негізгі тармақтың жоғарғы жағындағы ағымдағы тармақтан орындалатын әрекеттерді бірінен соң бірі қайталайды.
  • Жаңа SHA-лары бар жаңа міндеттемелер жасалады, бұл GitHub-тағы міндеттемелердің бастапқы тарту сұрауларына сәйкес келуіне әкеледі, бірақ сәйкес түсініктемелерге емес.
  • Тапсырмаларды процесте қайта біріктіруге және өзгертуге немесе тіпті біреуіне біріктіруге болады.
• Бірнеше қайшылықтарды шешу қажет болуы мүмкін.
• Сызықтық тарихты сақтауға мүмкіндік береді.
  • Ешқандай себепсіз тым ұзақ болмаса, әңгімені оқу оңай болуы мүмкін.
  • Автоматты түрде жөндеу және ақаулықтарды жою біршама оңайырақ: мүмкін етеді git bisect, автоматты кері қайтаруларды анық және болжамды ете алады.
• Жалаушасы бар көшірілген тапсырмалары бар филиалды жариялауды талап етеді --force тарту сұрауларымен пайдаланылғанда.

Әдетте, топтар өзгерістерді біріктіру қажет болғанда әрқашан бірдей стратегияны қолдануға келіседі. Бұл «таза» біріктіру немесе жоғарғы жағындағы «таза» міндеттеме немесе олардың арасындағы нәрсе болуы мүмкін, мысалы, интерактивті түрде жоғарғы жағында міндеттеме жасау(git rebase -i) жалпыға қолжетімді репозиторийге жарияланбаған филиалдар үшін жергілікті түрде, бірақ "қоғамдық" филиалдар үшін біріктіру.

Мұнда біз біріктіруді қолданамыз.

️Тапсырма

1. Кодтың жергілікті филиалда екеніне көз жеткізіңіз master қашықтағы репозиторийден жаңартылды.
2. Филиалға ауысу feature.
3. Филиалмен біріктіруді бастаңыз master. Бәсекелес өзгерістерге байланысты біріктіру қайшылығы ci.md.
4. CI қадамдарының тізімі де, ол туралы ескертпе де мәтінде қалатындай қақтығысты шешіңіз.
5. Біріктіру тапсырмасын қашықтағы филиалға жариялаңыз feature.
6. GitHub UI жүйесінде тарту сұрауының күйін тексеріңіз және біріктіру шешілгенше күтіңіз.

Командалар

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

Жақсы жұмыс!

Сіз тізіммен аяқталдыңыз және енді тарту сұрауын мақұлдауыңыз керек master.

️ Тапсырма: "Қадамдарды қарап шығу" сұрауын бекіту

1. Тарту сұрауын ашыңыз.
2. «Біріктіру сұрауын» басыңыз.
3. «Біріктіруді растау» түймесін басыңыз.
4. «Бөлімшені жою» түймесін басыңыз, себебі ол бізге енді қажет емес.

Бұл қазіргі уақытта сіздің репозиторийіңіз

Өнім қатесі

«Тестілеуді қателердің бар-жоғын көрсету үшін қолдануға болады, бірақ олардың жоқтығын ешқашан көрсетуге болмайды» делінген. Бізде сынақтар өткізіліп, олар бізге ешқандай қате көрсетпесе де, өндіріске жасырын қате шықты.

Мұндай сценарийде бізге қамқорлық қажет:

• өндірісте не қолданылады;
• ағындағы код master қате бар, одан әзірлеушілер жаңа жұмысты бастай алады.

Мен оны артқа айналдыруым керек пе немесе келесі нұсқада түзетуім керек пе?

Кері қайтару – белгілі жақсы бұрынғы нұсқаны өндіріске қолдану және қатесі бар міндеттемелерді қайтару процесі. "Алға бекіту" - бұл түзетуді қосу master және жаңа нұсқаны мүмкіндігінше тезірек қолдану. API интерфейстері мен дерекқор схемалары код өндіріске орналастырылған сайын өзгеретіндіктен, үздіксіз жеткізіліммен және жақсы сынақ қамтуымен, кері қайтару әдетте келесі нұсқада түзетуге қарағанда әлдеқайда қиын және қауіпті.

Біздің жағдайда кері бұрылу ешқандай қауіп төндірмейтіндіктен, біз осы жолмен жүреміз, өйткені бұл бізге мүмкіндік береді

• өнімдегі қатені мүмкіндігінше тез түзетіңіз;
• кодты енгізіңіз master жаңа жұмысқа бірден жарамды.

️Тапсырма

1. Филиалға ауысу master жергілікті
2. Қашықтағы репозиторийден жергілікті репозиторийді жаңартыңыз.
3. PR біріктіру міндеттемесін қайтарыңыз Қадамдарды шолу в master.
4. Өзгерістерді қашықтағы репозиторийге жариялау.

Бұл біріктіру міндеттемесі қайтарылған репозиторийдің тарихы

Командалар

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

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

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

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

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

️ Өзін-өзі сынау

Бұған көз жеткізіңіз ci.md біріктіру тапсырмасын қайтарғаннан кейін енді "жасырын қате" мәтінін қамтымайды.

CI қадамдарының тізімін түзетіп, оны негізгіге қайтарыңыз

Біз филиалдың біріктіру міндеттемесін толығымен қайтардық. feature. Жақсы жаңалық, бізде қазір қате жоқ master. Жаман жаңалық - үздіксіз интеграциялық қадамдарымыздың құнды тізімі де жойылды. Сонымен, ең дұрысы, біз түзетуді міндеттемелерге қолдануымыз керек feature және оларды қайтарыңыз master түзетумен бірге.

Мәселені шешуге әртүрлі жолдармен қарауға болады:

• біріктіруді тоқтататын міндеттемені қайтару feature с master;
• жылжыту біріншіден орындалады feature.

Әртүрлі әзірлеу топтары бұл жағдайда әртүрлі тәсілдерді пайдаланады, бірақ біз пайдалы міндеттемелерді бөлек филиалға жылжытамыз және осы жаңа филиал үшін бөлек тарту сұрауын жасаймыз.

️Тапсырма

1. деп аталатын ағынды жасаңыз feature-fix және оған ауысыңыз.

2. Бұрынғы филиалдан барлық міндеттемелерді тасымалдаңыз feature жаңа ағынға. Тасымалдау кезінде туындаған біріктіру қайшылықтарын шешіңіз.

   

3. Келесіге регрессия сынағы қосыңыз ci.test.js:

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

4. Сынақтардың орындалмайтынына көз жеткізу үшін жергілікті жерде орындаңыз.
5. Ішіндегі «жасырын қате бар» мәтінін алып тастаңыз ci.md.
6. Сынақ өзгерістерін және қадамдар тізімінің өзгертулерін индекске қосыңыз және оларды орындаңыз.
7. Филиалды қашықтағы репозиторийге жариялаңыз.

Сіз осыған ұқсас нәрсемен аяқтауыңыз керек:

Командалар

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

Тарту сұрауын жасаңыз.

Тақырыппен тарту сұрауын жасаңыз Функцияны түзету... Орнату feature-fix «бас тармақ» сияқты және master «негізгі филиал» сияқты.
Сынақтар аяқталғанша күтіңіз. Тесттердің күйін PR талқылауының төменгі жағында көруге болады.

Орнатқаныңызға көз жеткізіңіз master оның ішінде репозиторийді ашыңыз «Базалық филиал» ретінде мен курс материалдарының репозиторийіне өзгертулер енгізу туралы өтініштерге жауап бермеймін.

«Мүмкіндік түзетілуде» тарту сұрауын мақұлдау

Түзеткеніңіз үшін рақмет! Өзгерістерді мақұлдаңыз master тарту сұрауынан.

️Тапсырма

1. «Біріктіру сұрауын» басыңыз.
2. «Біріктіруді растау» түймесін басыңыз.
3. «Бөлімшені жою» түймесін басыңыз, себебі ол бізге енді қажет емес.

Дәл осы сәтте сізде болуы керек.

Құттықтаймыз!

Үздіксіз интеграция кезінде адамдар әдетте жасайтын барлық қадамдарды орындадыңыз.

Курста қандай да бір ақауларды байқасаңыз немесе оны жақсарту жолын білсеңіз, осы бөлімде мәселе жасаңыз курс материалдары бар репозиторийлер. Бұл курста да бар интерактивті нұсқасы платформа ретінде GitHub Learning Lab пайдалану.

Ақпарат көзі: www.habr.com