Nauczyłeś się poleceń Git, ale chcesz sobie wyobrazić, jak ciągła integracja (CI) działa w rzeczywistości? A może chcesz zoptymalizować swoje codzienne czynności? Dzięki temu kursowi zdobędziesz praktyczne umiejętności ciągłej integracji z wykorzystaniem repozytorium GitHub. Ten kurs nie ma być kreatorem, na który możesz po prostu kliknąć; wręcz przeciwnie, wykonasz te same czynności, które ludzie faktycznie wykonują w pracy, w ten sam sposób, w jaki to robią. Wyjaśnię teorię w trakcie wykonywania poszczególnych etapów.

Co robimy?

W miarę postępów będziemy stopniowo tworzyć listę typowych kroków CI, co jest świetnym sposobem na zapamiętanie tej listy. Innymi słowy, stworzymy listę działań, które podejmują programiści robiąc ciągłą integrację, robiąc ciągłą integrację. Wykorzystamy także prosty zestaw testów, aby przybliżyć nasz proces CI do rzeczywistego.

Ten GIF schematycznie pokazuje zatwierdzenia w twoim repozytorium w miarę postępów w kursie. Jak widać, nie ma tu nic skomplikowanego, a jedynie to, co niezbędne.

Przejdziesz przez następujące standardowe scenariusze CI:

• Pracuj nad funkcją;
• Stosowanie automatycznych testów w celu zapewnienia jakości;
• Realizacja zadania priorytetowego;
• Rozwiązywanie konfliktów podczas łączenia oddziałów (konflikt scalania);
• Wystąpił błąd w środowisku produkcyjnym.

Czego się nauczysz?

Będziesz mógł odpowiedzieć na następujące pytania:

• Czym jest ciągła integracja (CI)?
• Jakie rodzaje testów automatycznych wykorzystuje się w CI i w reakcji na jakie działania są uruchamiane?
• Co to są żądania ściągnięcia i kiedy są potrzebne?
• Co to jest rozwój oparty na testach (TDD) i jaki ma związek z CI?
• Czy powinienem scalić lub zmienić bazę zmian?
• Przywrócić lub naprawić w następnej wersji?

Na początku wszędzie tłumaczyłem takie rzeczy jak „pull request”, ale w rezultacie zdecydowałem się w niektórych miejscach zwrócić zwroty w języku angielskim, aby zmniejszyć stopień szaleństwa w tekście. Czasami będę używał słowa „programista surzhik” jako wspaniałego czasownika „zatwierdzić”, gdy ludzie faktycznie używają go w pracy.

Czym jest ciągła integracja?

епрерывная INTEGRACJAlub CI to praktyka techniczna, w której każdy członek zespołu przynajmniej raz dziennie integruje swój kod we wspólnym repozytorium, a powstały kod musi przynajmniej zostać zbudowany bez błędów.

Istnieją rozbieżności co do tego terminu

Punktem spornym jest częstotliwość integracji. Niektórzy twierdzą, że łączenie kodu tylko raz dziennie nie wystarczy, aby faktycznie integrować w sposób ciągły. Podano przykład zespołu, w którym wszyscy rano biorą świeży kod i integrują go wieczorem. Choć jest to uzasadniony zarzut, powszechnie uważa się, że definicja „jedzenia raz dziennie” jest w miarę praktyczna, konkretna i odpowiednia dla zespołów o różnej wielkości.

Kolejnym zarzutem jest to, że C++ nie jest już jedynym językiem używanym w programowaniu, a samo wymaganie bezbłędnego asemblowania jako sposobu sprawdzania poprawności jest słabe. Niektóre zestawy testów (na przykład testy jednostkowe wykonywane lokalnie) również muszą zakończyć się pomyślnie. W tej chwili społeczność zmierza w kierunku wprowadzenia tego wymogu, a w przyszłości „kompilacja + testy jednostkowe” prawdopodobnie staną się powszechną praktyką, jeśli jeszcze tego nie zrobiły.

епрерывная INTEGRACJA inny niż dostawa ciągła (Continious Delivery, CD), ponieważ nie wymaga wydania kandydata po każdym cyklu integracji.

Lista kroków, z których będziemy korzystać podczas całego kursu

1. Wprowadź najnowszy kod. Utwórz oddział z master. Rozpocząć pracę.
2. Utwórz zatwierdzenia w swoim nowym oddziale. Kompiluj i testuj lokalnie. Przechodzić? Przejdź do następnego kroku. Ponieść porażkę? Napraw błędy lub testy i spróbuj ponownie.
3. Wypchnij do zdalnego repozytorium lub oddziału zdalnego.
4. Utwórz żądanie ściągnięcia. Omów zmiany, w miarę kontynuacji dyskusji dodawaj więcej zatwierdzeń. Spraw, aby testy przechodziły w gałęzi funkcji.
5. Scal/zmień bazę zatwierdzeń z wzorca. Spraw, aby testy przekazały wynik scalania.
6. Wdróż z gałęzi funkcji do środowiska produkcyjnego.
7. Jeśli przez jakiś czas na produkcji wszystko jest w porządku, należy scalić zmiany z wersją wzorcową.

️ Przygotowanie

Upewnij się, że masz odpowiednie oprogramowanie

Aby wziąć udział w tym kursie, będziesz potrzebować node.js и Klient Gita.

Możesz użyć dowolnego klienta Git, ale podam tylko polecenia dla wiersza poleceń.

Upewnij się, że masz zainstalowanego klienta Git obsługującego wiersz poleceń

Jeśli nie masz jeszcze klienta Git obsługującego wiersz poleceń, możesz znaleźć instrukcje instalacji tutaj.

Przygotuj repozytorium

Będziesz musiał utworzyć osobistą kopię (widelec) repozytorium szablonów z kodem kursu na GitHubie. Zgódźmy się nazwać ten egzemplarz osobisty repozytorium kursów.

Zrobione? Jeśli nie zmieniłeś ustawień domyślnych, najprawdopodobniej zostanie wywołane Twoje repozytorium kursów continuous-integration-team-scenarios-students, znajduje się on na Twoim koncie GitHub, a adres URL wygląda następująco

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

Po prostu zadzwonię pod ten adres <URL репозитория>.

Nawiasy kątowe, np <тут> będzie oznaczać, że należy zastąpić takie wyrażenie odpowiednią wartością.

Upewnij się, że Działania GitHuba zawarte w tym repozytorium kursów. Jeśli nie są one włączone, włącz je, klikając duży przycisk na środku strony, do którego możesz przejść, klikając opcję Akcje w interfejsie GitHub.

Jeśli nie włączysz akcji GitHub, nie będziesz w stanie ukończyć kursu, postępując zgodnie z moimi instrukcjami.

Zawsze możesz użyć możliwości GitHuba do renderowania Markdown, aby zobaczyć aktualny stan listy, którą tutaj tworzymy

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

O odpowiedziach

Chociaż najlepszym sposobem na ukończenie tego kursu jest zrobienie tego samemu, mogą wystąpić pewne trudności.

Jeśli czujesz, że nie rozumiesz, co robić i nie możesz kontynuować, możesz zajrzeć do wątku solution, który znajduje się w repozytorium startowym.
Proszę nie łączyć solution в master podczas kursu. Możesz użyć tej gałęzi, aby dowiedzieć się, co zrobić, lub porównać swój kod z kodem autora, korzystając ze wszystkich możliwości, jakie daje nam Git. Jeśli całkowicie się zagubiłeś, możesz całkowicie zastąpić swój oddział master na gałęzi solution a następnie zresetuj katalog roboczy do wymaganego etapu kursu.

Używaj tego tylko, jeśli naprawdę tego potrzebujesz

Zatwierdź swój kod

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

Te polecenia

• Przemianować master в master-backup;
• Przemianować solution в master;
• kasę do nowego oddziału master i przepisz zawartość katalogu roboczego;
• Utwórz gałąź „rozwiązanie” z gałęzi „master” (która kiedyś była „rozwiązaniem”) na wypadek, gdybyś w przyszłości potrzebował gałęzi „rozwiązania”.

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

Po tych krokach możesz użyć git log master aby dowiedzieć się, jakiego zatwierdzenia potrzebujesz.
Możesz zresetować swój katalog roboczy do tego zatwierdzenia w następujący sposób:

git reset --hard <the SHA you need>

Jeśli jesteś zadowolony z wyniku, w pewnym momencie będziesz musiał opublikować swoją wersję repozytorium w zdalnym repozytorium. Robiąc to, nie zapomnij jawnie określić oddziału zdalnego.

git push --force origin master

Należy pamiętać, że używamy git push --force. Jest mało prawdopodobne, że będziesz chciał to robić bardzo często, ale mamy tutaj bardzo specyficzny scenariusz z jednym użytkownikiem repozytorium, który w dodatku rozumie, co robi.

Rozpoczęcie pracy

Zacznijmy kompilować naszą listę kroków CI. Zwykle zacząłbyś ten krok od sprawdzenia najnowszej wersji kodu ze zdalnego repozytorium, ale nie mamy jeszcze lokalnego repozytorium, więc zamiast tego sklonujemy go ze zdalnego repozytorium.

ℹ Zadanie: zaktualizuj lokalne repozytorium, utwórz oddział z master, rozpocząć pracę

1. Sklonuj repozytorium kursów z <URL репозитория>.
2. Biegać npm install w katalogu repozytorium kursów; Potrzebujemy go do zainstalowania Jest, którego używamy do przeprowadzania testów.
3. Utwórz gałąź i nadaj jej nazwę feature. Przejdź do tego wątku.

4. Dodaj kod testowy do ci.test.js między komentarzami, w których prosi się mnie o zrobienie tego.

   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. Dodaj do pliku tekst z pierwszymi 4 krokami 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.  

   Polecenia

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

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

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

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

Twórz zatwierdzenia w nowej gałęzi, buduj i testuj lokalnie

Skonfigurujemy testy do uruchomienia przed zatwierdzeniem, a następnie zatwierdzimy kod.

Typowe scenariusze, w których testy uruchamiają się automatycznie

• Lokalnie:
  • Stale lub w odpowiedzi na odpowiednie zmiany w kodzie;
  • Podczas zapisywania (dla języków interpretowanych lub kompilowanych przez JIT);
  • Podczas montażu (gdy wymagana jest kompilacja);
  • Po zatwierdzeniu;
  • Podczas publikowania w udostępnionym repozytorium.

• Na serwerze kompilacji lub w środowisku kompilacji:
  • Kiedy kod jest publikowany w osobistym oddziale/repozytorium.
  • Kod w tym wątku jest testowany.
  • Testowany jest potencjalny wynik fuzji (zwykle za pomocą master).
  • Jako etap ciągłej integracji/rurociąg ciągłych dostaw

Zwykle im szybciej działa zestaw testów, tym częściej możesz sobie pozwolić na jego uruchamianie. Typowy rozkład sceniczny może wyglądać następująco.

• Szybkie testy jednostkowe - podczas kompilacji, w potoku CI
• Powolne testy jednostkowe, szybkie testy komponentowe i integracyjne – po zatwierdzeniu, w potoku CI
• Powolne testy komponentowe i integracyjne – w potoku CI
• Testowanie bezpieczeństwa, testowanie obciążenia i inne czasochłonne lub drogie testy - w potokach CI/CD, ale tylko w niektórych trybach/etapach/potokach kompilacji, na przykład podczas przygotowywania wersji Release Candidate lub podczas ręcznego uruchamiania.

️Zadanie

Sugeruję najpierw ręczne uruchomienie testów za pomocą polecenia npm test. Następnie dodajmy hak git, aby uruchamiać nasze testy po zatwierdzeniu. Jest jeden haczyk: haki Git nie są uważane za część repozytorium i dlatego nie można ich klonować z GitHub wraz z resztą materiałów kursu. Aby zainstalować hak, musisz uruchomić install_hook.sh lub skopiuj plik repo/hooks/pre-commit do katalogu lokalnego .git/hooks/.
Po zatwierdzeniu zobaczysz, że uruchamiane są testy, które sprawdzają, czy na liście znajdują się określone słowa kluczowe.

1. Uruchom testy ręcznie, uruchamiając polecenie npm test w folderze repozytorium kursów. Sprawdź, czy testy zostały zakończone.
2. Ustaw hak zatwierdzający (hak przed zatwierdzeniem), uruchamiając install_hook.sh.
3. Zatwierdź zmiany w lokalnym repozytorium.
4. Przed zatwierdzeniem upewnij się, że testy zostały uruchomione.

Twoje repozytorium powinno wyglądać tak po wykonaniu tych kroków.

Polecenia

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

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

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

Opublikuj kod w zdalnym repozytorium lub zdalnej gałęzi

Po zakończeniu pracy lokalnie programiści zazwyczaj udostępniają swój kod publicznie, aby ostatecznie można go było zintegrować z publicznością. W przypadku GitHuba zwykle osiąga się to poprzez publikację pracy w osobistej kopii repozytorium (personal fork) lub w gałęzi osobistej.

• Za pomocą forków programista klonuje zdalne udostępnione repozytorium, tworząc jego osobistą zdalną kopię, zwaną również forkiem. Następnie klonuje to osobiste repozytorium, aby móc z nim pracować lokalnie. Po zakończeniu pracy i dokonaniu zatwierdzeń umieszcza je w swoim forku, gdzie są dostępne dla innych i można je zintegrować ze wspólnym repozytorium. To podejście jest powszechnie stosowane w projektach open source w serwisie GitHub. Jest również używany w moim zaawansowanym kursie [Praca zespołowa i CI z Git] (http://devops.redpill.solutions/).
• Innym podejściem jest użycie tylko jednego zdalnego repozytorium i zliczenie tylko gałęzi master współdzielone repozytorium „chronione”. W tym scenariuszu poszczególni programiści publikują swój kod w oddziałach zdalnego repozytorium, aby inni mogli zajrzeć do tego kodu, jeśli wszystko jest w porządku, połącz go z master wspólne repozytorium.

W tym konkretnym kursie będziemy używać przepływu pracy wykorzystującego gałęzie.

Opublikujmy nasz kod.

️Zadanie

• Opublikuj zmiany w oddziale zdalnym o tej samej nazwie, co oddział roboczy

Polecenia

git push --set-upstream origin feature

Utwórz żądanie ściągnięcia

Utwórz żądanie ściągnięcia z tytułem Przegląd kroków... zainstalować feature jak „gałąź główna” i master jak „gałąź podstawowa”.

Upewnij się, że zainstalowałeś master w jego forkuj repozytorium Jako „gałąź bazowa” nie będę odpowiadać na prośby o wprowadzenie zmian w repozytorium materiałów szkoleniowych.

W żargonie GitHub „gałąź podstawowa” to gałąź, na której opierasz swoją pracę, a „gałąź główna” to gałąź zawierająca proponowane zmiany.

Omów zmiany, w miarę kontynuacji dyskusji dodawaj nowe zatwierdzenia

Żądanie ściągnięcia (PR)

Żądanie ściągnięcia (PR) to sposób na dyskusję i udokumentowanie kodu, a także przeprowadzenie przeglądu kodu. Żądania ściągnięcia nazywane są na cześć ogólnego sposobu integrowania poszczególnych zmian w całym kodzie. Zazwyczaj osoba klonuje zdalne oficjalne repozytorium projektu i pracuje nad kodem lokalnie. Następnie umieszcza kod w swoim osobistym zdalnym repozytorium i prosi osoby odpowiedzialne za oficjalne repozytorium o pobranie(Ciągnąć) swój kod do swoich lokalnych repozytoriów, gdzie przeglądają i ewentualnie integrują (łączyć) jego. Pojęcie to znane jest także pod innymi nazwami, np. żądanie połączenia.

W rzeczywistości nie musisz korzystać z funkcji żądania ściągnięcia w GitHub lub podobnych platformach. Zespoły programistów mogą korzystać z innych metod komunikacji, w tym komunikacji twarzą w twarz, połączeń głosowych lub poczty elektronicznej, ale nadal istnieje wiele powodów, aby korzystać z żądań ściągnięcia w stylu forum. Tutaj jest kilka z nich:

• zorganizowane dyskusje związane z konkretnymi zmianami w kodzie;
• jako miejsce, w którym można zapoznać się z opiniami na temat prac w toku, zarówno od autotesterów, jak i współpracowników;
• formalizacja przeglądów kodu;
• abyś później mógł poznać przyczyny i rozważania stojące za tym czy innym fragmentem kodu.

Zazwyczaj tworzysz żądanie ściągnięcia, gdy chcesz coś omówić lub uzyskać opinię. Na przykład, jeśli pracujesz nad funkcją, którą można zaimplementować na więcej niż jeden sposób, możesz utworzyć żądanie ściągnięcia przed napisaniem pierwszego wiersza kodu, aby podzielić się swoimi pomysłami i omówić plany ze współpracownikami. Jeśli praca jest prostsza, żądanie ściągnięcia jest otwierane, gdy coś zostało już zrobione, zatwierdzone i można omówić. W niektórych scenariuszach możesz chcieć otworzyć PR tylko ze względów związanych z kontrolą jakości: aby przeprowadzić automatyczne testy lub zainicjować przeglądy kodu. Niezależnie od tego, jaką decyzję podejmiesz, nie zapomnij o @wzmiance o osobach, których zgodę chcesz uzyskać w swoim żądaniu ściągnięcia.

Zazwyczaj podczas tworzenia PR wykonujesz następujące czynności.

• Wskaż, co i gdzie proponujesz zmienić.
• Napisz opis wyjaśniający cel zmian. Może chcesz:
  • dodaj wszystko, co nie jest oczywiste w kodzie, lub coś przydatnego do zrozumienia kontekstu, na przykład odpowiednie #bugi i numery zatwierdzeń;
  • @wzmianka o dowolnej osobie, z którą chcesz rozpocząć współpracę, lub możesz później @wzmiankować o niej w komentarzach;
  • poproś kolegów o pomoc w jakiejś sprawie lub sprawdź coś konkretnego.

Po otwarciu PR zostaną wykonane testy skonfigurowane do uruchomienia w takich przypadkach. W naszym przypadku będzie to ten sam zestaw testów, który przeprowadziliśmy lokalnie, jednak w prawdziwym projekcie mogą pojawić się dodatkowe testy i sprawdzenia.

Proszę poczekać na zakończenie testów. Status testów możesz zobaczyć na dole dyskusji PR w interfejsie GitHub. Kontynuuj po zakończeniu testów.

‼️Dodaj notatkę o losowości listy kroków CI

Lista zastosowana w tym kursie ma charakter arbitralny i subiektywny, należy o tym dodać adnotację.

ℹ Zadanie: utwórz żądanie ściągnięcia dla tego komentarza

1. Przejdź do oddziału master.
2. Utwórz gałąź o nazwie bugfix.
3. Dodaj tekst notatki na końcu pliku 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. Zatwierdź zmiany.
5. Opublikuj wątek bugfix do zdalnego repozytorium.
6. Utwórz żądanie ściągnięcia o nazwie Dodanie uwagi z gałęzią głowy bugfix i gałąź bazowamaster.

Upewnij się, że zainstalowałeś master w jego forkuj repozytorium Jako „gałąź bazowa” nie będę odpowiadać na prośby o wprowadzenie zmian w repozytorium materiałów szkoleniowych.

Tak powinno wyglądać Twoje repozytorium.

Polecenia

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

Zatwierdź żądanie ściągnięcia „Dodawanie uwagi”

️Zadanie

1. Utwórz żądanie ściągnięcia.
2. Kliknij „Połącz żądanie ściągnięcia”.
3. Kliknij „Potwierdź połączenie”.
4. Kliknij „Usuń oddział”, nie jest nam już potrzebny.

To jest diagram zatwierdzeń po fuzji.

‼️ Pracuj dalej i dodawaj testy

Współpraca nad żądaniem ściągnięcia często skutkuje dodatkową pracą. Zwykle jest to wynikiem przeglądu kodu lub dyskusji, ale w naszym kursie będziemy to modelować, dodając nowe elementy do naszej listy kroków CI.

Ciągła integracja zazwyczaj obejmuje pewien zakres testów. Wymagania dotyczące zakresu testów są różne i zwykle można je znaleźć w dokumencie zwanym „wytycznymi dotyczącymi wkładu”. Uprościmy to i dodamy test dla każdej linii na naszej liście kontrolnej.

Wykonując zadania, spróbuj najpierw zatwierdzić testy. Jeśli zainstalowałeś poprawnie pre-commit hook wcześniej, nowo dodany test zostanie uruchomiony, zakończy się niepowodzeniem i nic nie zostanie zatwierdzone. Pamiętaj, że w ten sposób wiemy, że nasze testy faktycznie coś testują. Co ciekawe, jeśli zaczniemy od kodu przed testami, pomyślne zdanie testów może oznaczać, że kod działa zgodnie z oczekiwaniami, lub że testy tak naprawdę niczego nie testują. Poza tym gdybyśmy od razu nie napisali testów, moglibyśmy o nich zupełnie zapomnieć, bo nic by nam o tym nie przypominało.

Rozwój oparty na testach (TDD)

TDD zaleca pisanie testów przed kodem. Typowy przepływ pracy przy użyciu TDD wygląda następująco.

1. Dodaj test.
2. Uruchom wszystkie testy i upewnij się, że nowy test zakończy się niepowodzeniem.
3. Napisz kod.
4. Uruchom testy i upewnij się, że wszystkie testy poszły pomyślnie.
5. Refaktoryzuj swój kod.
6. Powtarzać.

Ponieważ wyniki testów, które zakończyły się niepowodzeniem, są zwykle wyświetlane na czerwono, a te, które zaszły, są zwykle wyświetlane na zielono, cykl jest również nazywany refaktorem czerwono-zielonym.

️Zadanie

Najpierw spróbuj zatwierdzić testy i pozwolić na ich niepowodzenie, a następnie dodaj i zatwierdź tekst samej listy kroków CI. Zobaczysz, że testy przechodzą („zielone”).
Następnie opublikuj nowy kod w zdalnym repozytorium i obejrzyj testy uruchamiane w interfejsie GitHub na dole dyskusji dotyczącej żądania ściągnięcia i aktualizacji statusu PR.

1. Przejdź do oddziału feature.

2. Dodaj te testy do ci.test.js po ostatnim połączeniu 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. Spróbuj zatwierdzić testy. Jeśli pre-commit hook jest zainstalowany, próba zatwierdzenia zakończy się niepowodzeniem.
4. Następnie dodaj ten tekst do 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. Wprowadzaj i zatwierdzaj zmiany lokalnie.
6. Opublikuj zmiany w oddziale feature.

Powinieneś teraz mieć coś takiego

Polecenia

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

Konflikt scalania

Przejdź do żądania zmiany Przegląd kroków.

Mimo że nie zrobiliśmy nic złego i testy naszego kodu przebiegły pomyślnie, nadal nie możemy połączyć gałęzi feature и master. To dlatego, że inny wątek bugfix został połączony z master podczas gdy pracowaliśmy nad tym PR.
Stwarza to sytuację, w której zdalny oddział master ma nowszą wersję niż ta, na której oparliśmy gałąź feature. Z tego powodu nie możemy po prostu przewinąć HEAD master do końca wątku feature. W tej sytuacji musimy albo scalić, albo zastosować zatwierdzenia feature ponownie bazować master. GitHub może faktycznie wykonać automatyczne scalanie, jeśli nie ma konfliktów. Niestety w naszej sytuacji obie gałęzie mają konkurencyjne zmiany w pliku ci.md. Taka sytuacja nazywana jest konfliktem scalania i musimy ją rozwiązać ręcznie.

Scal lub zmień bazę

Łączyć

• Tworzy dodatkowe zatwierdzenie scalania i zapisuje historię pracy.
  • Zachowuje oryginalne zatwierdzenia gałęzi z ich oryginalnymi znacznikami czasu i autorami.
  • Zapisuje SHA zatwierdzeń i łącza do nich w dyskusjach na temat żądań zmian.
• Wymaga jednorazowego rozwiązania konfliktu.
• Sprawia, że ​​historia jest nieliniowa.
  • Opowieść może być trudna do odczytania ze względu na dużą liczbę odgałęzień (przypominających kabel IDE).
  • Utrudnia automatyczne debugowanie, np. git bisect mniej przydatne - znajdzie tylko zatwierdzenie scalania.

Zmień bazę

• Odtwarza po kolei zatwierdzenia z bieżącej gałęzi na gałęzi podstawowej.
  • Generowane są nowe zatwierdzenia z nowymi SHA, co powoduje, że zatwierdzenia w GitHub są zgodne z oryginalnymi żądaniami ściągnięcia, ale nie z odpowiadającymi im komentarzami.
  • Zatwierdzenia można w trakcie procesu ponownie łączyć i modyfikować, a nawet łączyć w jedno.
• Być może trzeba będzie rozwiązać wiele konfliktów.
• Pozwala zachować liniową historię.
  • Opowieść może być łatwiejsza do przeczytania, o ile nie jest zbyt długa bez rozsądnego powodu.
  • Automatyczne debugowanie i rozwiązywanie problemów jest trochę łatwiejsze: sprawia, że ​​jest to możliwe git bisect, może sprawić, że automatyczne wycofywanie zmian będzie jaśniejsze i bardziej przewidywalne.
• Wymaga opublikowania gałęzi z migrowanymi zatwierdzeniami z flagą --force w przypadku użycia z żądaniami ściągnięcia.

Zazwyczaj zespoły zgadzają się, aby zawsze używać tej samej strategii, gdy muszą scalić zmiany. Może to być „czyste” scalanie, „czyste” zatwierdzenie na górze lub coś pomiędzy, na przykład interaktywne zatwierdzenie na górze (git rebase -i) lokalnie dla oddziałów, które nie są publikowane w publicznym repozytorium, ale łączą się dla oddziałów „publicznych”.

Tutaj użyjemy scalania.

️Zadanie

1. Upewnij się, że kod znajduje się w oddziale lokalnym master aktualizowane ze zdalnego repozytorium.
2. Przejdź do oddziału feature.
3. Zainicjuj połączenie z gałęzią master. Konflikt scalania spowodowany konkurencyjnymi zmianami w pliku ci.md.
4. Rozwiąż konflikt tak, aby zarówno nasza lista kroków CI, jak i notatka na jej temat pozostały w tekście.
5. Opublikuj zatwierdzenie scalania w zdalnej gałęzi feature.
6. Sprawdź status żądania ściągnięcia w interfejsie użytkownika GitHub i poczekaj, aż scalanie zostanie rozwiązane.

Polecenia

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

Dobra robota!

Skończyłeś z listą i teraz musisz zatwierdzić żądanie ściągnięcia master.

️ Zadanie: Zatwierdź żądanie ściągnięcia „Przegląd kroków”

1. Otwórz żądanie ściągnięcia.
2. Kliknij „Połącz żądanie ściągnięcia”.
3. Kliknij „Potwierdź połączenie”.
4. Kliknij „Usuń oddział”, ponieważ już go nie potrzebujemy.

To jest w tej chwili Twoje repozytorium

Błąd produktu

Mówi się, że „testowanie można wykorzystać do wykazania obecności błędów, ale nigdy do wykazania ich braku”. Mimo że mieliśmy testy i nie wykazały one żadnych błędów, do produkcji wkradł się podstępny błąd.

W takiej sytuacji musimy zadbać o:

• co jest wdrażane w produkcji;
• kod w wątku master z błędem, od którego programiści mogą rozpocząć nową pracę.

Czy powinienem cofnąć czy naprawić to w następnej wersji?

Wycofywanie zmian to proces wdrażania znanej, dobrej wcześniejszej wersji w środowisku produkcyjnym i przywracania zatwierdzeń zawierających błąd. „Naprawianie w przód” to dodanie poprawki do pliku master i jak najszybsze wdrożenie nowej wersji. Ponieważ interfejsy API i schematy baz danych zmieniają się w miarę wdrażania kodu w środowisku produkcyjnym, przy ciągłym dostarczaniu i dobrym zasięgu testów, wycofanie jest zwykle znacznie trudniejsze i ryzykowne niż naprawianie tego w następnej wersji.

Ponieważ wycofanie się nie niesie w naszym przypadku żadnego ryzyka, pójdziemy tą drogą, bo nam na to pozwala

• jak najszybciej napraw błąd w produkcie;
• wprowadź kod master od razu nadaje się do rozpoczęcia nowej pracy.

️Zadanie

1. Przejdź do oddziału master lokalnie.
2. Zaktualizuj repozytorium lokalne z repozytorium zdalnego.
3. Cofnij zatwierdzenie scalania PR Przegląd kroków в master.
4. Opublikuj zmiany w zdalnym repozytorium.

To jest historia repozytorium z cofniętym zatwierdzeniem scalania

Polecenia

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

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

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

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

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

️ Autotest

Upewnij się, że ci.md nie zawiera już tekstu „podstępny błąd” po cofnięciu zatwierdzenia scalania.

Napraw listę kroków CI i zwróć ją do mastera

Całkowicie cofnęliśmy zatwierdzenie scalania gałęzi. feature. Dobra wiadomość jest taka, że ​​nie mamy teraz żadnych błędów master. Zła wiadomość jest taka, że ​​zniknęła także nasza cenna lista etapów ciągłej integracji. W idealnym przypadku musimy zastosować poprawkę do zatwierdzeń z feature i zwróć je master wraz z poprawką.

Do problemu możemy podejść na różne sposoby:

• cofnij zatwierdzenie, które cofa scalanie feature с master;
• przenieś zatwierdzenia z pierwszego feature.

Różne zespoły programistów stosują w tym przypadku różne podejścia, ale my przeniesiemy przydatne zatwierdzenia do osobnej gałęzi i utworzymy osobne żądanie ściągnięcia dla tej nowej gałęzi.

️Zadanie

1. Utwórz wątek o nazwie feature-fix i przełączyć się na nie.

2. Przeprowadź migrację wszystkich zatwierdzeń z poprzedniej gałęzi feature do nowego wątku. Rozwiąż konflikty scalania, które wystąpiły podczas migracji.

   

3. Dodaj test regresji do ci.test.js:

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

4. Uruchom testy lokalnie, aby upewnić się, że nie zawiodą.
5. Usuń tekst „z podstępnym błędem” w ci.md.
6. Dodaj zmiany testowe i zmiany listy kroków do indeksu i zatwierdź je.
7. Opublikuj gałąź w zdalnym repozytorium.

Powinieneś otrzymać coś podobnego do tego:

Polecenia

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

Utwórz żądanie ściągnięcia.

Utwórz żądanie ściągnięcia z tytułem Naprawianie funkcji... zainstalować feature-fix jak „gałąź główna” i master jak „gałąź podstawowa”.
Proszę poczekać na zakończenie testów. Status testów możesz zobaczyć na dole dyskusji PR.

Upewnij się, że zainstalowałeś master w jego forkuj repozytorium Jako „gałąź bazowa” nie będę odpowiadać na prośby o wprowadzenie zmian w repozytorium materiałów szkoleniowych.

Zatwierdź żądanie ściągnięcia „Naprawianie funkcji”

Dziękuję za korektę! Proszę zatwierdzić zmiany w master z żądania ściągnięcia.

️Zadanie

1. Kliknij „Połącz żądanie ściągnięcia”.
2. Kliknij „Potwierdź połączenie”.
3. Kliknij „Usuń oddział”, ponieważ już go nie potrzebujemy.

To jest to, co powinieneś mieć w tej chwili.

Gratulacje!

Wykonałeś wszystkie kroki, które zwykle podejmują ludzie podczas ciągłej integracji.

Jeśli zauważysz jakieś problemy z kursem lub wiesz jak go ulepszyć, utwórz problem w repozytoria materiałów szkoleniowych. Ten kurs również ma wersja interaktywna używając GitHub Learning Lab jako platformy.

Źródło: www.habr.com