Изучили ли сте командите на Git, но искате да разберете как наистина протича непрекъсната интеграция (Continuous Integration, CI)? Или може би искате да оптимизирате ежедневните си действия? Този курс ще ви предостави практически умения за непрекъсната интеграция с използване на хранилище в GitHub. Курсът не е замислен като някакъв wizard, който просто да кликате, а напротив, ще извършвате същите действия, които хората реално правят на работа, по същия начин, по който те го правят. Ще обяснявам теорията, докато преминавате през стъпките, свързани с нея.

Какво ще правим?

С напредването ще започнем постепенно да създаваме списък с типични стъпки за CI, което е отличен начин да запомните този списък. С други думи, ще създадем списък с действия, които разработчиците извършват, реализирайки непрекъсната интеграция. Също така ще използваме прост набор от тестове, за да приближим нашия CI процес до реалността.

Този GIF илюстрира комитите във вашето хранилище, докато напредвате в курса. Както виждате, няма нищо сложно — само най-необходимото.

Ще преминете през стандартни за CI сценарии:

• Работа по функция;
• Прилагане на автотестове за осигуряване на качество;
• Реализация на приоритетна задача;
• Разрешаване на конфликт при сливане на клонове (merge conflict);
• Възникване на грешка в продуктивна среда.

Какво ще научите?

Ще можете да отговорите на следните въпроси:

• Какво е непрекъсната интеграция (CI)?
• Какви типове автотестове се използват при CI и при какви действия се стартират?
• Какво е pull request и кога са необходими?
• Какво е разработка през тестиране (Test Driven Development, TDD) и как тя съотнася с CI?
• Да осъществим сливане (merge) или да приложим промените (rebase)?
• Да откатим или да поправим в следващата версия?

В началото превеждах термини като "pull request", но в крайна сметка реших да оставя фразите на английски на някои места, за да намаля степента на объркване в текста. Понякога ще използвам "програматорски суржик" като интересния глагол "закомитя", там където хората наистина го използват в работата си.

Какво е непрекъсната интеграция?

Непрекъсната интеграция, или CI, това е техническа практика, при която всеки член на екипа интегрира своя код в общото хранилище поне веднъж на ден, като полученото кодово решение трябва поне да се компилира без грешки.

Има разминавания относно този термин.

Предмет на спора е честотата на интеграция. Някои твърдят, че обединяването на кода само веднъж на ден не е достатъчно и всъщност трябва да се интегрира непрекъснато. Като пример се посочва екип, където всички взимат нов код сутрин и се интегрират веднъж вечерта. Макар че това е разумно възражение, все пак по принцип се счита, че вариантът с определение "веднъж на ден" е достатъчно практичен, конкретен и подходящ за екипи с различен размер.

Друго възражение е, че C++ отдавна не е единственият език, използван при разработка, и простото изискване за компилиране без грешки, като начин за валидиране, е недостатъчно. Набор от тестове (например модулни) също трябва да завърши успешно. В момента общността се стреми към това изискването да стане задължително, и в бъдеще "компилация + модулни тестове" очевидно ще стане общоприето, ако това вече не се е случило.

Непрекъсната интеграция се различава от непрекъсната доставка (Continuous Delivery, CD) по това, че не изисква кандидат за версия след всеки цикъл на интеграция.

Списък на стъпките, които ще използваме през курса.

1. Изтеглете последния код. Създайте клон от master. Започнете работа.
2. Създайте комити на новия си клон. Компилирайте и тествате локално. Успех? Преминете към следващата стъпка. Неуспех? Поправете грешките или тестовете и опитайте отново.
3. Изпратете на отдалеченото си хранилище или отдалечения клон.
4. Създайте pull request. Обсъдете промените, добавете още комити, докато дискусията продължава. Направете тестовете успешни на клон за функцията.
5. Обединете/преосновете комитите от master. Направете тестовете успешни на резултата от обединението.
6. Разположете от клона за функцията в продукция.
7. Ако всичко е добре в продукция за определен период от време, обединете промените в master.

️ Подготовка

Уверете се, че имате нужното софтуерно осигуряване

За да преминете през този курс, ще ви е необходим Node.js и Git клиент.

Можете да използвате всеки Git клиент, но аз ще представям команди само за командния ред.

Уверете се, че имате инсталиран Git клиент, който поддържа командния ред.

Ако все още не сте инсталирали Git клиент, който поддържа командния ред, можете да намерите инструкции за инсталиране. тук..

Подгответе хранилището.

Ще трябва да създадете лична копия (fork) на шаблонното хранилище с код за курса в GitHub. Нека се разберем да наричаме тази лична копия хранилище на курса..

Сигурно ли е? Ако не сте променяли настройките по подразбиране, вашият курс репозитори е вероятно наречен continuous-integration-team-scenarios-students, той се намира в акаунта ви в GitHub и URL адресът изглежда така

https://github.com//continuous-integration-team-scenarios-students

Ще нарека този адрес просто <URL репозитория>.

Ъгловите скоби като <тут> ще означават, че трябва да замените такова изражение с подходящата стойност.

Уверете се, че GitHub действия са активирани за този курс репозитория. Ако не са активирани, моля, активирайте ги, като натиснете голямото копче в средата на страницата, до което можете да достигнете, като кликнете върху Actions в интерфейса на GitHub.

Няма да можете да преминете курса, следвайки моите инструкции, ако GitHub действия не са активирани.

Винаги можете да използвате възможността на GitHub да показва Markdown, за да видите текущото състояние на списъка, който съставяме, тук

https://github.com//continuous-integration-team-scenarios-students/blob/master/ci.md

За отговорите

Докато най-добрият начин да завършите този курс е да правите всичко сами, може да срещнете трудности.

Ако усещате, че не разбирате какво да правите и не можете да продължите, можете да погледнете в клона solution, който съществува в вашето стартиране репозитория.
Моля, не осъществявайте сливане solution в master по време на курса. Можете да използвате този клон, за да разберете какво да правите или да сравните кода си с оригинала, използвайки всички възможности, предоставени от Git. Ако сте напълно загубени, можете напълно да замените своя клон master с клона solution и след това да нулирате работната си директория до стъпката от курса, която ви е нужна.

Използвайте това само ако наистина е нужно

Запишете (commit) кода си

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

Тези команди

• преименуват master в master-backup;
• преименуват solution в master;
• превключват (checkout) на нов клон master и презаписват съдържанието на работната директория;
• създават клон "solution" от "master" (който преди беше "solution") в случай че в бъдеще ви е нужен клона "solution".

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

След тези действия можете да използвате git log master за да разберете, кой commit ви е нужен.
Можете да нулирате работната си директория до този commit така:

git reset --hard

Ако сте доволни от резултата, в определен момент ще трябва да публикувате версията на вашия репозиторий в отдалечения репозиторий. Не забравяйте да посочите отдалечен клон, когато го правите.

git push --force origin master

Моля, обърнете внимание, че използваме git push --force. Малко вероятно е да искате да действате по този начин често, но имаме много специфичен сценарий с един потребител на репозитория, който освен това разбира какво прави.

Започваме работа

Нека съставим нашия списък от стъпки CI. Обикновено започвате тази стъпка с извличане на последната версия на кода от отдалечения репозиторий, но нямаме локален репозиторий, затова вместо това го клонираме от отдалечения.

️ Задание: обновете локалния репозиторий, създайте клон от master, започнете работа

1. Клонирайте курса на репозитория от <URL репозитория>.
2. Стартирайте npm install в каталога на курса; нужен е за инсталиране на Jest, който използваме за стартиране на тестове.
3. Създайте клон и го наречете feature. Превключете се на този клон.

4. Добавете тестовия код в ci.test.js между коментарите с молба да го направите.

   it('1. извлечете последния код', () => {
     expect(/.*pull.*?/ig.test(fileContents)).toBe(true);
   });
   
   it('2. добавете комити', () => {
     expect(/.*commit.*?/ig.test(fileContents)).toBe(true);
   });
   
   it('3. натиснете до отдалечения клон със същото име', () => {
     expect(/.*push.*?/ig.test(fileContents)).toBe(true);
   });
   
   it('4. създайте pull request и продължете работа', () => {
     expect(/.*pulls+request.*?/ig.test(fileContents)).toBe(true);
   });

5. Добавете текста с първите 4 стъпки в файла ci.md.

   1. Извлечете последния код. Създайте клон от `master`. Започнете работа.
   2. Създайте комити на новия си клон. Сглобете и тествайте локално.
   Минава? Отидете на следващата стъпка. Не минава? Поправете грешките или тестовете и пробвайте отново.
   3. Натиснете до вашия отдалечен репозиторий или отдалечен клон.
   4. Създайте pull request. Обсъдете промените, добавяйте повече комити в хода на обсъждането. Накарайте тестовете да минат в клона с функциите.  

   Отбори

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

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

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

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

Създавайте комити в новия клон, правете сборки и тестове локално

Ще настроим тестовете да се изпълняват преди комит, а след това ще комитираме кода.

Типични сценарии, при които тестовете се изпълняват автоматично

• Локално:
  • Постоянно или в отговор на съответни промени в кода;
  • При запазване (за интерпретируеми или JIT-компилирани езици);
  • При сборка (когато е необходима компилация);
  • При комит;
  • При публикуване в общ репозиторий.

• На сървъра за сборки (build server) или в средата за сборка:
  • Когато кодът се публикува в личен клон / репозиторий.
  • Кодът в този клон се тества.
  • Тества се потенциалният резултат от сливане (обикновено с master).
  • Като етап от непрекъсната интеграция/непрекъсната доставка

Обикновено, колкото по-бързо се изпълнява набор от тестове, толкова по-често можете да си позволите да ги стартирате. Типичното разпределение на етапите може да изглежда така.

• Бързи модулни тестове — при изграждане, в CI конвейера
• Бавни модулни тестове, бързи компонентни и интеграционни тестове — при комит, в CI конвейера
• Бавни компонентни и интеграционни тестове — в CI конвейера
• Тестове за сигурност, натоварващи и други дългосрочни или скъпи тестове — в CI/CD конвейерите, но само в определени режими/етапи/конвейери на сглобяване, например при подготовка на кандидат за версия или при ръчно стартиране.

️ Задача

Предлагам първо да стартираме тестовете ръчно, като използваме командата npm test. След това да добавим git hook, за да стартираме тестовете си при комит. Има едно уловка: Git hooks не се считат за част от репозитория и следователно не могат да бъдат клонирани от GitHub заедно с останалото съдържание на курса. За да установите hook, трябва да стартирате install_hook.sh или да копирате файла repo/hooks/pre-commit в локалната директория .git/hooks/.
При комит ще видите, че тестовете се изпълняват и те проверяват дали определени ключови думи са налични.

1. Стартирайте тестовете ръчно, като изпълните командата npm test в папката на репозитория на курса. Уверете се, че тестовете са били изпълнени.
2. Настройте hook за комит (pre-commit hook), като стартирате 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 това обикновено се постига чрез публикуване на работата или в лична копия на репозитория (personal fork, форк), или в личен клон.

• При използване на форкове разработчикът клонира отдалечено обществено хранилище, създавайки собствено отдалечено копие, известно също като форк. След това той клонира това собствено хранилище, за да работи с него локално. Когато работата е завършена и комитите са създадени, той ги поставя във своя форк, където те са достъпни за другите и могат да бъдат интегрирани в общото хранилище. Този подход обикновено се използва в проекти с отворен код в GitHub. Той също така се използва в моя разширен курс [Team Work and CI with Git]http://devops.redpill.solutions/).
• Друг подход е да се използва само едно отдалечено хранилище и да се счита само клонът master на споделеното хранилище за "защитен". В този сценарий отделни разработчици публикуват своя код в клонове на отдалеченото хранилище, за да може другите да видят този код, и ако всичко е наред, да го обединят с master общото хранилище.

В този конкретен курс ще използваме работен процес, който използва клони.

Нека публикуваме нашия код.

️ Задача

• Публикувайте промените в отдалечен клон с същото име като вашия работен клон

Отбори

git push --set-upstream origin feature

Създайте pull request

Създайте pull request с име Стъпки за преглед. Задайте feature като "head branch" и master като "base branch".

Уверете се, че сте задали master в своя форка на хранилището като "base branch", няма да отговарям на заявки за промени в хранилището с материалите на курса.

На жаргона на GitHub "base branch" е клона, на който основавате работата си, а "head branch" е клона, съдържащ предложените промени.

Обсъдете промените, добавете нови комити, докато продължава обсъждането

Pull request (PR)

Pull request (PR) е начин да се обсъжда и документира кода, а също и да се проведе проверка на кода (code review). Pull request-ите са наречени на общия начин за интегриране на отделни промени в общия код. Обикновено човек клонира отдалеченото официално хранилище на проекта и работи над кода локално. След това той поставя кода в собственото си отдалечено хранилище и моли отговорниците за официалното хранилище да взематpull) неговия код в своите локални хранилища, където те го преглеждат и, възможно, интегриратmerge) го. Това понятие е известно и под други имена, например, merge request.

Всъщност, не е задължително да използвате функцията pull request на GitHub или подобни платформи. Разработващите екипи могат да използват и други средства за комуникация, включително лични срещи, разговори по телефон или имейл, но все пак има редица причини да се използват такива pull requests под формата на обсъждане. Ето някои от тях:

• организирани обсъждания, свързани с конкретни промени в кода;
• като място за преглед на отзиви за незавършена работа от автоматизирани тестове и колеги;
• формализиране на проверки на кода;
• за да може по-късно да се изяснят причините и съображенията зад определен фрагмент от кода.

Обикновено създавате pull request, когато имате нужда да обсъдите нещо или да получите обратна връзка. Например, ако работите по функция, която може да бъде реализирана по няколко начина, можете да създадете предложение за промяна дори преди да напишете първия ред код, за да споделите идеите си и да обсъдите плановете си с колегите. Ако работата е по-проста, pull request се отваря, когато нещо е вече направено, фиксирано и може да бъде обсъждано. В някои сценарии можете да отворите PR само от съображения за контрол на качеството: за да стартирате автоматични тестове или да инициирате проверка на кода. Каквото и да решите, не забравяйте да @споменете хората, чийто одобрение е необходимо за вашия pull request.

Обикновено, когато създавате PR, правите следното.

• Указвате какво предлагате да промените и къде.
• Пишете описание, което обяснява целта на промените. Може да искате:
  • да добавите нещо важно, което не е очевидно от кода, или нещо полезно за разбирането на контекста, например съответстващи #бъгове и номера на комити;
  • @да споменете всички, с които искате да работите заедно, или можете да @споменете тях по-късно в коментарите;
  • да помолите колеги да помогнат с нещо или да проверят нещо конкретно.

След като отворите PR, се изпълняват тестове, настроени да се стартират в такива случаи. В нашия случай това ще бъде същият набор от тестове, който стартирахме локално, но в истински проект могат да има допълнителни тестове и проверки.

Моля, изчакайте, докато завършат тестовете. Можете да видите статуса на тестовете в долната част на дискусията PR в интерфейса на GitHub. Продължете, когато тестовете приключат.

️ Добавете коментар относно произволността на списъка с етапи CI

Списъкът, използван в този курс, е произволен и субективен, трябва да добавим коментар за това.

️ Задача: създаване на pull request за това изменение

1. auth0 master.
2. Създайте клон с име bugfix.
3. Добавете текста на бележката в края на файла ci.md.

   > **GitHub flow** понякога се използва като прякор за вид на разработка, базирана на основната клонка, когато кодът се разполага директно от клонове на функции. Този списък е просто интерпретация, която използвам в моите [DevOps курсове](http://redpill.solutions). Официалният урок е [тук](https://guides.github.com/introduction/flow/).

4. Закомитете промените.
5. Публикувайте клона bugfix в отдалечения репозиторий.
6. Създайте pull request с име Добавяне на коментар с основния клон bugfix и базовия клонmaster.

Уверете се, че сте задали master в своя форка на хранилището като "base branch", няма да отговарям на заявки за промени в хранилището с материалите на курса.

Ето как трябва да изглежда вашият репозиторий.

Отбори

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

Утвърдете pull request "Добавяне на коментар"

️ Задача

1. Създайте pull request.
2. Натиснете "Merge pull request".
3. Натиснете "Confirm merge".
4. Натиснете "Delete branch", вече не ни е нужен.

Това е диаграмата на комитите след сливането.

️ Продължете да работите и да добавяте тестове

Съвместната работа по pull request често налага допълнителна работа. Обикновено това е резултат от преглед на кода или обсъждане, но в нашия курс ще симулираме това, като добавим нови елементи в нашия списък с етапи CI.

При непрекъсната интеграция обикновено се прилага тестово покритие. Изискванията към покритие с тестове варират и обикновено са в документ с име, подобно на "ръководство за автори" (contribution guidelines). Ние ще процедим просто и ще добавим по тест за всеки ред в нашия контролен списък.

Когато изпълнявате задания, първо опитайте да закомитите тестовете. Ако сте настроили правилно pre-commit хук преди, новосъздаденият тест ще се стартира, няма да премине и нищо няма да бъде закомитено. Обърнете внимание: така ще разберем, че нашите тестове наистина проверяват нещо. Интересно е, че ако бяхме започнали с код преди тестовете, преминаването на тестовете можеше да означава както, че кодът работи, както се очаква, така и че тестовете всъщност не проверяват нищо. Освен това, ако не бяхме написали тестовете в първо място, можехме изцяло да ги забравим, тъй като нищо нямаше да ни напомня за тях.

Разработка чрез тестове (TDD)

TDD препоръчва да се пишат тестове преди кода. Обичайната работна процедура с TDD изглежда така.

1. Добавете тест.
2. Стартирайте всички тестове и се уверете, че новият тест не минава успешно.
3. Напишете кода.
4. Стартирайте тестовете, уверете се, че всички тестове минават успешно.
5. Извършете рефакторинг на кода.
6. Повторете.

Тъй като резултатите от тестовете, които не са минали успешно, обикновено се показват в червено, а успешно изпълнените — в зелено, цикълът също е известен като "червен-зелен-рефакторинг".

️ Задача

Първо опитайте да закомитирате тестовете и да ги оставите да завършат неуспешно, след което добавете и закомитете самия текст на стъпките CI. Ще видите, че тестовете минават ("зелени").
След това публикувайте новия код в отдалечения репозиторий и вижте как се изпълняват тестовете в интерфейса на GitHub в долната част на дискусията за заявката за промяна и статусът на PR се актуализира.

1. auth0 feature.

2. Добавете тези тестове в ci.test.js след последния извикване it (...);.

   it('5. Обединяване/повторно интегриране на комити от master. Направете тестовете да минават с резултата от обединението.', () => {
     expect(/.*merge.*commits.*tests+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Разгръщане от клон на функция до продукция.', () => {
     expect(/.*Deploy.*to+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. Ако всичко е наред в продукцията за определен период от време, обединете промените в master.', () => {
     expect(/.*merge.*to+master.*/ig.test(fileContents)).toBe(true);
   });

3. Опитайте да закомитирате тестовете. Ако pre-commit hook е инсталиран, опитът за комит ще завърши с грешка.
4. След това добавете този текст в ci.md.

   5. Обединяване/повторно интегриране на комити от master. Направете тестовете да минават с резултата от обединението.  
   6. Разгръщане от клон на функция с тайна грешка до продукция.
   7. Ако всичко е наред в продукцията за определен период от време, обединете промените в master. 

5. Направете и закомитетe промените локално.
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 отгоре. masterGitHub всъщност може да извършва автоматично сливане, ако няма конфликти. За съжаление, в нашата ситуация и двете клонове имат конкуриращи се промени в файла. ci.mdТази ситуация е известна като конфликт при сливане (merge conflict) и трябва да я разрешим ръчно.

Merge или rebase

Merge

• Създава допълнителен комит за сливане (merge commit) и запазва историята на работата.
  • Запазва оригиналните комити на клоновете с оригиналните времеви марки и автори.
  • Запазва SHA на комитите и препратките към тях в обсъжданията на заявки за промени.
• Изисква еднократно разрешаване на конфликтите.
• Прави историята нелинейна.
  • Историята може да бъде трудна за четене заради многото клони (напомня на кабелите на IDE).
  • Усложнява автоматичната отладка, например, прави git bisect по-малко полезен — той само ще намери комита за сливане.

Rebase

• Възпроизвежда комитите от текущия клон върху базовия един след друг.
  • Създават се нови комити с нови SHA, в резултат на което комитите в GitHub кореспондират с оригиналните pull requests, но не и с съответстващите коментари.
  • Комитите могат да бъдат рекомбинирани и променяни в процеса или дори обединени в един.
• Може да се наложи да разрешите няколко конфликта.
• Позволява поддържането на линейна история.
  • Историята може да бъде по-лесна за четене, освен ако не е твърде дълга без разумна причина.
  • Автоматичната отладка и отстраняването на проблеми са малко по-лесни: прави възможни git bisectавтоматични откати, които са по-ясни и предсказуеми.
• Изисква публикуване на клона с пренесените комити с флага --force при използване с заявки за внесени промени.

Обикновено екипите се съгласяват винаги да използват една и съща стратегия, когато им е нужно да сливат промени. Това може да бъде "чисто" сливане или "чисто" прилагане на комити отгоре или нещо междинно, например, упражняване на прилагане на комити в интерактивен режим (git rebase -i) локално за клонове, които не са публикувани в общия репозиторий, но сливане (merge) за "публични" клони.

Тук ще използваме сливане.

️ Задача

1. Уверете се, че кодът в локалния клон master е актуализиран от отдалечения репозиторий.
2. auth0 feature.
3. Инициирайте сливането с клона master. Ще бъде съобщено за конфликт при сливането, свързан с конкуриращите се промени в ci.md.
4. Разрешете конфликта така, че в текста да остане и нашият списък стъпки CI, и забележка за него.
5. Публикувайте комита от сливането в отдалената клонка feature.
6. Проверете статуса на pull request в потребителския интерфейс на GitHub, изчакайте сливането да бъде разрешено.

Отбори

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

Отлична работа!

С приключване на работа по списъка, сега трябва да одобрите pull request в master.

️ Задача: Одобрете pull request "Преглед на стъпките"

1. Отворете pull request.
2. Натиснете "Merge pull request".
3. Натиснете "Confirm merge".
4. Натиснете "Изтрий клон", тъй като вече не ни е нужен.

Това е вашето хранилище в момента

Грешка в продукция

Казват, че "тестовете могат да се използват, за да покажат наличие на грешки, но никога да покажат тяхното отсъствие". Въпреки че имахме тестове и те не показаха никакви грешки, измамна грешка се промъкна в продукция.

В подобен сценарий трябва да се погрижим за:

• това, което е разположено в продукция;
• кода в клона master с грешка, от който разработчиците могат да започнат нова работа.

Да върнем или да поправим в следващата версия?

"Връщането"(rolling back) е разгръщането на предварително коригиран по-ранен вариант в продуктивна среда и отмяната(revert) на комити, съдържащи грешката. "Поправка в следващата версия"(fixing forward) е добавянето на поправка в master и разгръщането на нова версия възможно най-скоро. Тъй като API и схемите на базата данни се променят с разгръщането на кода в оперативната среда, при непрекъсната доставка и добро покритие с тестове, връщането обикновено е много по-сложно и рисковано, отколкото поправянето в следващата версия.

Тъй като връщането не носи риск в нашия случай, ще тръгнем по този път, тъй като това ни позволява

• да поправим грешката в продукция възможно най-скоро;
• да направим кода в master веднага подходящ за започване на нова работа.

️ Задача

1. auth0 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 повече не съдържа текста "sneaky bug" след отмена на комит от сливането.

Поправете списъка стъпки CI и го върнете в master

Пълно отменихме комита от сливането на клона feature. Добрата новина е, че сега нямаме грешка в masterЛошата новина е, че изчезна и нашият ценен списък с стъпки за непрекъсната интеграция. Така че, идеално е да приложим поправка към комитите от feature и да ги върнем в master заедно с поправката.

Можем да подходим към задачата по различни начини:

• да отменим (revert) комита, който отменя сливането feature с master;
• да прехвърлим комитите от бившата feature.

Различните разработващи екипи в този случай използват различни подходи, ние ще прехвърлим полезните комити в отделен клон и ще създадем отделен pull request за новия клон.

️ Задача

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. Премахнете текста " with a sneaky bug" в 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

Създайте pull request.

Създайте pull request с име Fixing the feature. Задайте feature-fix като "head branch", а master като "base branch".
Моля, изчакайте, докато тестовете завършат. Можете да видите статуса на тестовете в долната част на дискусията по PR.

Уверете се, че сте задали master в своя форка на хранилището като "base branch", няма да отговарям на заявки за промени в хранилището с материалите на курса.

Одобрете pull request "Fixing the feature"

Благодаря ви за поправката! Моля, одобрете промените в master от pull request.

️ Задача

1. Натиснете "Merge pull request".
2. Натиснете "Confirm merge".
3. Натиснете "Изтрий клон", тъй като вече не ни е нужен.

Това, което трябва да имате в момента

Поздравления!

Изпълнили сте всички действия, които хората обикновено извършват в процеса на непрекъсната интеграция.

Ако забележите някакви проблеми с курса или знаете как да го подобрите, създайте issue в репозитория с материалите на курса. Този курс също така има интерактивна версия използваща GitHub Learning Lab като платформа.

Източник: habr.com