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

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

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

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

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

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

какво ще научиш?

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

• Какво е непрекъсната интеграция (CI)?
• Какви видове автоматизирани тестове се използват в CI и в отговор на какви действия се задействат?
• Какво представляват заявките за изтегляне и кога са необходими?
• Какво е разработка, управлявана от тестове (TDD) и каква е връзката му с CI?
• Трябва ли да обединя или пребазирам промените?
• Връщане назад или коригиране в следващата версия?

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

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

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

Има разногласия относно този термин

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

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

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

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

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. Използва се и в моя курс за напреднали [Работа в екип и CI с Git] (http://devops.redpill.solutions/).
• Друг подход е да използвате само едно отдалечено хранилище и да преброите само клона master споделено хранилище "защитено". В този сценарий отделни разработчици публикуват своя код в клонове на отдалечено хранилище, така че другите да могат да гледат този код, ако всичко е наред, да го обединят с master споделено хранилище.

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

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

️Задача

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

команди

git push --set-upstream origin feature

Създайте заявка за изтегляне

Създайте заявка за изтегляне със заглавие Преглед на стъпките... Инсталирай feature като "главен клон" и master като "базов клон".

Уверете се, че сте инсталирали master в неговия разклонете хранилището Като „базов клон“ няма да отговарям на искания за промени в хранилището на материалите за курса.

На езика на GitHub „базовият клон“ е клонът, върху който базирате работата си, а „главният клон“ е клонът, съдържащ предложените промени.

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

Заявка за изтегляне (PR)

Заявка за изтегляне (PR) е начин за обсъждане и документиране на код, както и за извършване на преглед на кода. Заявките за изтегляне са кръстени на общия начин за интегриране на отделни промени в общия код. Обикновено човек клонира отдалеченото официално хранилище на проекта и работи върху кода локално. След това той поставя кода в личното си отдалечено хранилище и моли отговорните за официалното хранилище да го вземат(издърпайте) неговия код в техните локални хранилища, където те преглеждат и евентуално интегрират (се сливат) неговият. Тази концепция е известна и под други имена, напр. заявка за сливане.

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

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

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

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

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

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

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

️ Добавете бележка относно произволността на списъка с 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 hook по-рано, новодобавеният тест ще бъде изпълнен, ще се провали и нищо няма да бъде ангажирано. Обърнете внимание, че по този начин знаем, че нашите тестове всъщност тестват нещо. Интересното е, че ако започнем с кода преди тестовете, преминаването на тестовете може или да означава, че кодът работи според очакванията, или че тестовете всъщност не тестват нищо. Освен това, ако не бяхме написали тестовете на първо място, може би щяхме да ги забравим напълно, тъй като нищо нямаше да ни напомня за това.

Разработка, управлявана от тестове (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 и изчакайте, докато сливането бъде разрешено.

команди

# Убедитесь, что код в локальное ветке `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 и го върнете на master

Ние напълно върнахме ангажимента за сливане на клона. 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