Да ли сте научили Гит команде, али желите да замислите како континуирана интеграција (ЦИ) функционише у стварности? Или можда желите да оптимизујете своје дневне активности? Овај курс ће вам дати практичне вештине у континуираној интеграцији помоћу ГитХуб репозиторија. Овај курс није замишљен да буде чаробњак на који можете једноставно да кликнете; напротив, извршићете исте радње које људи заправо раде на послу, на исти начин на који то раде. Објаснићу теорију док будете пролазили кроз наведене кораке.

Шта да радимо?

Како напредујемо, постепено ћемо креирати листу типичних ЦИ корака, што је одличан начин да запамтите ову листу. Другим речима, направићемо листу радњи које програмери предузимају док раде континуирану интеграцију, радећи континуирану интеграцију. Такође ћемо користити једноставан скуп тестова како бисмо наш ЦИ процес приближили стварном.

Овај ГИФ шематски приказује урезивање у вашем спремишту како напредујете кроз курс. Као што видите, овде нема ништа компликовано и само најнеопходније.

Проћи ћете кроз следеће стандардне ЦИ сценарије:

• Рад на особини;
• Примена аутоматизованих тестова за обезбеђивање квалитета;
• Реализација приоритетног задатка;
• Решавање конфликата при спајању грана (конфликт спајања);
• Дошло је до грешке у производном окружењу.

шта ћеш научити?

Моћи ћете да одговорите на следећа питања:

• Шта је континуирана интеграција (ЦИ)?
• Које врсте аутоматизованих тестова се користе у ЦИ и као одговор на које радње се покрећу?
• Шта су захтеви за повлачење и када су потребни?
• Шта је развој вођен тестом (ТДД) и како је повезан са ЦИ?
• Да ли да спојим или поново базирам промене?
• Вратити или поправити у следећој верзији?

У почетку сам свуда преводио ствари попут „захтева за повлачење“, али сам као резултат одлучио да на неким местима враћам фразе на енглеском како бих смањио степен лудости у тексту. Понекад ћу користити „суржик програмера“ као диван глагол „починити“ где га људи заправо користе на послу.

Шта је континуирана интеграција?

Континуирано интеграција, или ЦИ, је техничка пракса у којој сваки члан тима интегрише свој код у заједничко спремиште најмање једном дневно, а резултујући код мора бити изграђен без грешака.

Постоје неслагања око овог појма

Тачка спорења је учесталост интеграције. Неки тврде да спајање кода само једном дневно није довољно за континуалну интеграцију. Пример је тим где сви узимају свеж код ујутру и интегришу га једном увече. Иако је ово разуман приговор, опште је прихваћено да је дефиниција једном дневно прилично практична, специфична и погодна за тимове различитих величина.

Друга примедба је да Ц++ више није једини језик који се користи у развоју, и једноставно захтевање асемблера без грешака као начина валидације је слабо. Неки скуп тестова (на пример, јединични тестови који се извршавају локално) такође морају успешно да се заврше. У овом тренутку, заједница се креће ка томе да ово постане услов, а у будућности ће „буилд + унит тестови“ вероватно постати уобичајена пракса, ако већ није.

Континуирано интеграција разликује од континуирана испорука (Континуирана испорука, ЦД) јер не захтева кандидата за издавање након сваког циклуса интеграције.

Листа корака које ћемо користити током курса

1. Убаците најновији код. Направите грану из master. Почети са радом.
2. Креирајте урезивање на својој новој грани. Изградите и тестирајте локално. Проћи? Идите на следећи корак. Фаил? Исправите грешке или тестове и покушајте поново.
3. Гурните у своје удаљено спремиште или удаљену грану.
4. Направите захтев за повлачење. Разговарајте о променама, додајте још урезивања како се дискусија настави. Учините да тестови прођу на грани карактеристика.
5. Спајање/ребазовање урезивања са мастера. Нека тестови проследе резултат спајања.
6. Примена од гране функције до производње.
7. Ако је све добро у производњи неко време, спојите измене у мастер.

Припрема

Уверите се да имате прави софтвер

Да бисте похађали овај курс биће вам потребно Ноде.јс и Гит клијент.

Можете користити било који Гит клијент, али ја ћу дати само команде за командну линију.

Уверите се да имате инсталиран Гит клијент који подржава командну линију

Ако још увек немате Гит клијент који подржава командну линију, можете пронаћи упутства за инсталацију овде.

Припремите спремиште

Мораћете да направите личну копију (виљушку) спремиште шаблона са кодом за курс на ГитХуб-у. Хајде да се договоримо да ову личну копију назовемо репозиторијум курса.

Готово? Ако нисте променили подразумевана подешавања, највероватније ће бити позвано ваше спремиште курса continuous-integration-team-scenarios-students, налази се на вашем ГитХуб налогу и УРЛ изгледа овако

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

Ја ћу једноставно назвати ову адресу <URL репозитория>.

Угаоне заграде као <тут> ће значити да такав израз морате заменити одговарајућом вредношћу.

Уверите се да ГитХуб акције укључено за ово спремиште курса. Ако нису омогућени, омогућите их тако што ћете кликнути на велико дугме на средини странице, на које можете доћи кликом на Акције у ГитХуб интерфејсу.

Нећете моћи да завршите курс пратећи моја упутства ако ГитХуб радње нису омогућене.

Увек можете користити ГитХуб-ову способност да прикаже Маркдовн да бисте видели тренутно стање листе коју састављамо овде

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

О одговорима

Иако је најбољи начин да завршите овај курс да то урадите сами, можда ћете имати потешкоћа.

Ако осећате да не разумете шта да радите и да не можете да наставите, можете погледати у нит solution, који се налази у вашем стартном спремишту.
Молим вас немојте спајати solution в master током. Можете користити ову грану да схватите шта да радите или да упоредите свој код са ауторским, користећи све могућности које нам Гит пружа. Ако сте потпуно изгубљени, можете потпуно заменити своју грану 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. Мало је вероватно да ћете то желети да радите често, али овде имамо врло специфичан сценарио са једним корисником спремишта који, поред тога, разуме шта ради.

Почетак рада

Почнимо са састављањем наше листе ЦИ корака. Обично бисте започели овај корак тако што ћете проверити најновију верзију кода из удаљеног спремишта, али још увек немамо локално спремиште, па га уместо тога клонирамо из удаљеног.

Задатак: ажурирање локалног спремишта, креирање гране из master, почети са радом

1. Клонирајте спремиште курсева из <URL репозитория>.
2. Трчи npm install у директоријуму репозиторијума курсева; Потребан нам је да инсталирамо Јест, који користимо за покретање тестова.
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 как описано выше

Креирајте урезивање на новој грани, направите и тестирајте локално

Поставићемо тестове да се покрећу пре урезивања, а затим урезати код.

Типични сценарији када се тестови покрећу аутоматски

• Локално:
  • Континуирано или као одговор на одговарајуће промене кода;
  • О чувању (за интерпретиране или ЈИТ-компајлиране језике);
  • Током склапања (када је потребна компилација);
  • Он цоммит;
  • Приликом објављивања у заједничком спремишту.

• На серверу за прављење или окружењу за прављење:
  • Када се код објави у личној грани/складишту.
  • Код у овој теми се тестира.
  • Потенцијални резултат спајања се тестира (обично са master).
  • Као фаза континуиране интеграције/континуирана испорука

Типично, што брже ради пакет за тестирање, то чешће можете себи приуштити да га покренете. Типична сценска дистрибуција може изгледати овако.

• Брзи тестови јединица - током изградње, у ЦИ цевоводу
• Спори јединични тестови, брзи тестови компоненти и интеграције - при урезивању, у ЦИ цевоводу
• Споре компоненте и тестови интеграције - у ЦИ цевоводу
• Безбедносно тестирање, тестирање оптерећења и други дуготрајни или скупи тестови - у ЦИ/ЦД цевоводима, али само у одређеним режимима/фазама/цевоводима градње, на пример, када се припрема кандидат за издање или када се покреће ручно.

Таск

Предлажем да прво покренете тестове ручно користећи команду npm test. После тога, додајмо гит куку за покретање наших тестова приликом урезивања. Постоји једна квака: Гит куке се не сматрају делом спремишта и стога се не могу клонирати са ГитХуб-а заједно са остатком материјала за курс. Да бисте инсталирали куку, морате покренути 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"

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

Објавите код у удаљеном спремишту или удаљеној грани

Када заврше са радом на локалном нивоу, програмери обично чине свој код јавно доступним како би на крају могао бити интегрисан са јавношћу. Са ГитХуб-ом, ово се обично постиже објављивањем дела или у личној копији спремишта (лични форк) или у личној грани.

• Помоћу форкс-а, програмер клонира удаљено дељено складиште, стварајући његову личну удаљену копију, такође познату као виљушка. Затим клонира ово лично спремиште за локални рад. Када је посао завршен и урезивања су направљена, он их гура у своју виљушку, где су доступни другима и могу се интегрисати у заједничко складиште. Овај приступ се обично користи у пројектима отвореног кода на ГитХуб-у. Такође се користи у мом напредном курсу [Тимски рад и ЦИ са Гитом] (http://devops.redpill.solutions/).
• Други приступ је да се користи само једно удаљено спремиште и да се рачуна само грана master заједничко складиште „заштићено“. У овом сценарију, појединачни програмери објављују свој код у гранама удаљеног спремишта како би други могли да погледају овај код, ако је све у реду, спојите га са master заједничко складиште.

У овом конкретном курсу користићемо ток посла који користи гране.

Хајде да објавимо наш код.

Таск

• Објавите промене у удаљеној грани са истим именом као и ваша радна грана

Тимови

git push --set-upstream origin feature

Направите захтев за повлачење

Направите захтев за повлачење са насловом Преглед корака... Инсталирај feature попут „главне гране“ и master попут "основне гране".

Уверите се да сте инсталирали master у његовој форк тхе репозиторијум Као „основна грана“, нећу одговарати на захтеве за измене у спремишту материјала за курс.

У ГитХуб језику, „основна грана“ је грана на којој заснивате свој рад, а „главна грана“ је грана која садржи предложене измене.

Разговарајте о променама, додајте нова урезивања како се дискусија настави

Захтев за повлачење (ПР)

Захтев за повлачење (ПР) је начин да се дискутује и документује код, као и да се изврши преглед кода. Захтеви за повлачење су названи према општем начину интеграције појединачних промена у целокупни код. Типично, особа клонира удаљено званично складиште пројекта и ради на коду локално. Након тога, он поставља код у своје лично удаљено спремиште и тражи од одговорних за званично складиште да га преузму (повући) његов код у своја локална спремишта, где прегледају и евентуално интегришу(стопити) његов. Овај концепт је познат и под другим именима, нпр. захтев за спајање.

У ствари, не морате да користите функцију захтева за повлачење на ГитХуб-у или сличним платформама. Развојни тимови могу да користе друге методе комуникације, укључујући комуникацију лицем у лице, гласовне позиве или е-пошту, али још увек постоји низ разлога да се користе захтеви за повлачење у стилу форума. Ево неких од њих:

• организоване дискусије везане за специфичне промене кода;
• као место за преглед повратних информација о раду у току од стране аутотестера и колега;
• формализација прегледа кода;
• тако да касније можете сазнати разлоге и разматрања иза овог или оног дела кода.

Обично креирате захтев за повлачење када треба да разговарате о нечему или добијете повратне информације. На пример, ако радите на функцији која се може применити на више начина, можете да креирате захтев за повлачење пре него што напишете прву линију кода да бисте поделили своје идеје и разговарали о својим плановима са својим сарадницима. Ако је посао једноставнији, отвара се захтев за повлачење када је нешто већ урађено, ангажовано и може се разговарати. У неким сценаријима, можда ћете желети да отворите ПР само из разлога контроле квалитета: да покренете аутоматизоване тестове или покренете преглед кода. Шта год да одлучите, не заборавите да @поменете људе чије одобрење желите у свом захтеву за повлачење.

Обично, када креирате ПР, радите следеће.

• Наведите шта предлажете да промените и где.
• Напишите опис који објашњава сврху промена. Можда желите:
  • додајте било шта важно што није очигледно из кода, или нешто корисно за разумевање контекста, као што су релевантне # грешке и бројеви урезивања;
  • @помени свакога са ким желиш да почнеш да радиш, или можеш да га @поменеш у коментарима касније;
  • замолите колеге да вам помогну у нечему или проверите нешто конкретно.

Када отворите ПР, извршавају се тестови конфигурисани за покретање у таквим случајевима. У нашем случају, ово ће бити исти скуп тестова који смо покренули локално, али у стварном пројекту може бити додатних тестова и провера.

Сачекајте док се тестови заврше. Статус тестова можете видети на дну ПР дискусије у ГитХуб интерфејсу. Наставите када се тестови заврше.

Додајте напомену о насумичности листе ЦИ корака

Листа која се користи у овом курсу је произвољна и субјективна, о томе треба додати напомену.

Задатак: креирајте захтев за повлачење за овај коментар

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. Кликните на "Избриши грану", више нам није потребна.

Ово је дијаграм урезивања након спајања.

Наставите са радом и додајте тестове

Сарадња на захтеву за повлачењем често резултира додатним радом. Ово је обично резултат прегледа кода или дискусије, али у нашем курсу ћемо то моделирати додавањем нових ставки на нашу листу ЦИ корака.

Континуирана интеграција обично укључује покривеност тестом. Захтеви за покривеност тестом се разликују и обично се налазе у документу који се зове нешто попут „смерница за допринос“. Одржаћемо то једноставним и додати тест за сваку линију на нашој контролној листи.

Када извршавате задатке, покушајте прво да извршите тестове. Ако сте правилно инсталирали pre-commit закачите раније, новододати тест ће бити покренут, неће успети и ништа неће бити урезано. Имајте на уму да тако знамо да наши тестови заправо нешто тестирају. Занимљиво, ако бисмо почели са кодом пре тестова, пролазак тестова би могао да значи да је код радио како се очекивало или да тестови заправо ништа не тестирају. Осим тога, да нисмо уопште написали тестове, можда бисмо их потпуно заборавили, јер нас ништа не би подсећало на то.

Тест вођен развој (ТДД)

ТДД препоручује писање тестова пре кода. Типичан ток рада који користи ТДД изгледа овако.

1. Додајте тест.
2. Покрените све тестове и уверите се да нови тест не успе.
3. Напишите код.
4. Покрените тестове, уверите се да сви тестови прођу.
5. Рефакторите свој код.
6. Понављање.

Пошто су резултати тестова који нису успели обично приказани црвеном бојом, а они који су прошли обично зеленом бојом, циклус је познат и као црвено-зелени рефактор.

Таск

Прво, покушајте да извршите тестове и пустите их да не успеју, а затим додајте и урезујте текст саме листе корака ЦИ. Видећете да тестови пролазе („зелено“).
Затим објавите нови код у удаљеном спремишту и гледајте како се покрећу тестови у ГитХуб интерфејсу на дну дискусије о захтеву за повлачење и ажурирању ПР статуса.

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 док смо радили на овом ПР-у.
Ово ствара ситуацију у којој удаљена грана master има новију верзију од оне на којој смо засновали грану feature. Због овога не можемо само да премотамо ХЕАД master до краја конца feature. У овој ситуацији, морамо или да спојимо или применимо урезивање feature ребасе master. ГитХуб заправо може да изврши аутоматско спајање ако нема сукоба. Нажалост, у нашој ситуацији, обе гране имају конкурентне измене у датотеци ci.md. Ова ситуација је позната као конфликт спајања и морамо да је решимо ручно.

Спојите или поново базирајте

Стопити

• Прави додатно урезивање спајања и чува радну историју.
  • Чува оригиналне урезивања грана са њиховим оригиналним временским ознакама и ауторима.
  • Чува СХА урезивања и везе до њих у дискусијама о захтевима за измену.
• Захтева једнократно решавање сукоба.
• Чини причу нелинеарном.
  • Прича може бити тешка за читање због великог броја грана (подсећа на ИДЕ кабл).
  • Отежава аутоматско отклањање грешака, нпр. git bisect мање корисно - наћи ће само урезивање спајања.

Ребасе

• Понавља урезивања из тренутне гране на врху основне гране један за другим.
  • Генеришу се нова урезивања са новим СХА-овима, што доводи до тога да се урезивања у ГитХуб-у подударају са оригиналним захтевима за повлачење, али не и са одговарајућим коментарима.
  • Урезивања се могу поново комбиновати и модификовати у процесу, или чак спојити у једно.
• Можда ће бити потребно решити више конфликата.
• Омогућава вам да одржите линеарну причу.
  • Причу је можда лакше читати све док није предугачка без разумног разлога.
  • Аутоматско отклањање грешака и решавање проблема је мало лакше: омогућава git bisect, може учинити аутоматско враћање јаснијим и предвидљивијим.
• Захтева објављивање гране са мигрираним урезивањем са заставицом --force када се користи са захтевима за повлачење.

Типично, тимови се слажу да увек користе исту стратегију када треба да споје промене. Ово може бити „чисто“ стапање или „чисто“ урезивање на врху, или нешто између, као што је интерактивно обављање урезивања на врху (git rebase -i) локално за гране које нису објављене у јавном спремишту, али се спајају за "јавне" гране.

Овде ћемо користити спајање.

Таск

1. Уверите се да је код у локалној грани master ажурирано из удаљеног спремишта.
2. Пребаците се на грану feature.
3. Покрените стапање са граном master. Конфликт спајања због конкурентних промена у ci.md.
4. Решите конфликт тако да наша листа ЦИ корака и напомена о томе остану у тексту.
5. Објавите урезивање спајањем на удаљену грану feature.
6. Проверите статус захтева за повлачење у корисничком интерфејсу ГитХуб-а и сачекајте док се спајање не реши.

Тимови

# Убедитесь, что код в локальное ветке `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 и примену нове верзије што је пре могуће. Пошто се АПИ-ји и шеме базе података мењају како се код примењује у производњу, уз континуирану испоруку и добру покривеност тестом, враћање је обично много теже и ризичније од поправљања у следећој верзији.

Пошто враћање уназад не носи никакав ризик у нашем случају, ми ћемо ићи овим путем, јер нам то дозвољава

• поправите грешку на производу што је пре могуће;
• направите код master одмах погодан за почетак новог посла.

Таск

1. Пребаците се на грану master локално.
2. Ажурирајте локално спремиште из удаљеног спремишта.
3. Вратите ПР обједињавање Преглед корака в 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 више не садржи текст "снеаки буг" након враћања урезивања спајања.

Поправите листу корака ЦИ и вратите је на мастер

Потпуно смо вратили урезивање стапања гране. 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 попут "основне гране".
Сачекајте док се тестови заврше. Статус тестова можете видети на дну ПР дискусије.

Уверите се да сте инсталирали master у његовој форк тхе репозиторијум Као „основна грана“, нећу одговарати на захтеве за измене у спремишту материјала за курс.

Одобри захтев за повлачење „Поправљање функције“

Хвала на исправци! Молимо вас да одобрите измене у master из захтева за повлачење.

Таск

1. Кликните на „Споји захтев за повлачење“.
2. Кликните на „Потврди спајање“.
3. Кликните на „Избриши грану“ јер нам више није потребна.

Ово је оно што би требало да имате у овом тренутку.

Честитамо!

Завршили сте све кораке које људи обично предузимају током континуиране интеграције.

Ако приметите проблеме са курсом или знате како да га побољшате, молимо вас да направите проблем у спремишта са материјалом за курс. Овај курс такође има интерактивна верзија користећи ГитХуб Леарнинг Лаб као платформу.

Извор: ввв.хабр.цом