Natutunan mo ba ang mga utos ng Git ngunit nais mong isipin kung paano gumagana ang tuluy-tuloy na pagsasama (CI) sa katotohanan? O baka gusto mong i-optimize ang iyong pang-araw-araw na gawain? Ang kursong ito ay magbibigay sa iyo ng mga praktikal na kasanayan sa patuloy na pagsasama gamit ang isang GitHub repository. Ang kursong ito ay hindi nilayon na maging isang wizard na maaari mong i-click lamang; sa kabaligtaran, gagawin mo ang parehong mga aksyon na aktwal na ginagawa ng mga tao sa trabaho, sa parehong paraan na ginagawa nila ito. Ipapaliwanag ko ang teorya habang dumaraan ka sa mga hakbang na kasangkot.

Anong gagawin natin?

Habang sumusulong kami, unti-unti kaming gagawa ng listahan ng mga tipikal na hakbang ng CI, na isang mahusay na paraan upang matandaan ang listahang ito. Sa madaling salita, gagawa kami ng listahan ng mga pagkilos na ginagawa ng mga developer habang gumagawa ng tuluy-tuloy na pagsasama, paggawa ng tuluy-tuloy na pagsasama. Gagamit din kami ng isang simpleng hanay ng mga pagsubok para ilapit ang aming proseso sa CI sa tunay.

Ang GIF na ito ay schematically na nagpapakita ng mga commit sa iyong repository habang sumusulong ka sa kurso. Tulad ng nakikita mo, walang kumplikado dito at tanging ang pinaka kinakailangan.

Dadaan ka sa mga sumusunod na karaniwang sitwasyon ng CI:

• Magtrabaho sa isang tampok;
• Paglalapat ng mga awtomatikong pagsubok upang matiyak ang kalidad;
• Pagpapatupad ng prayoridad na gawain;
• Paglutas ng salungatan kapag pinagsasama ang mga sangay (pagsamahin ang salungatan);
• Ang isang error ay nangyayari sa isang kapaligiran ng produksyon.

Ano ang matututunan mo?

Masasagot mo ang mga sumusunod na tanong:

• Ano ang tuluy-tuloy na pagsasama (CI)?
• Anong mga uri ng mga automated na pagsubok ang ginagamit sa CI, at bilang tugon sa kung anong mga aksyon ang na-trigger ng mga ito?
• Ano ang mga pull request at kailan sila kailangan?
• Ano ang Test Driven Development (TDD) at paano ito nauugnay sa CI?
• Dapat ko bang pagsamahin o i-rebase ang mga pagbabago?
• Ibalik o ayusin sa susunod na bersyon?

Sa una ay isinalin ko ang mga bagay tulad ng "mga kahilingan sa paghila" sa lahat ng dako, ngunit bilang isang resulta nagpasya akong magbalik ng mga parirala sa Ingles sa ilang mga lugar upang mabawasan ang antas ng kabaliwan sa teksto. Gagamitin ko minsan ang "programmer surzhik" tulad ng magandang pandiwa na "commit" kung saan ginagamit ito ng mga tao sa trabaho.

Ano ang tuluy-tuloy na pagsasama?

Patuloy na integrasyon, o CI, ay isang teknikal na kasanayan kung saan isinasama ng bawat miyembro ng team ang kanilang code sa isang karaniwang repository nang hindi bababa sa isang beses sa isang araw, at ang resultang code ay dapat na mabuo man lang nang walang mga error.

May mga hindi pagkakasundo tungkol sa terminong ito

Ang punto ng pagtatalo ay ang dalas ng pagsasama. Ang ilan ay nangangatwiran na ang pagsasama-sama ng code nang isang beses lamang sa isang araw ay hindi sapat upang aktwal na pagsamahin ang tuluy-tuloy. Ang isang halimbawa ay ibinigay ng isang koponan kung saan ang lahat ay kumukuha ng bagong code sa umaga at isinasama ito nang isang beses sa gabi. Bagama't ito ay isang makatwirang pagtutol, karaniwang pinaniniwalaan na ang isang beses sa isang araw na kahulugan ay makatwirang praktikal, partikular, at angkop para sa mga pangkat na may iba't ibang laki.

Ang isa pang pagtutol ay ang C++ ay hindi na ang tanging wika na ginagamit sa pag-unlad, at ang simpleng nangangailangan ng error-free assembly bilang isang paraan ng pagpapatunay ay mahina. Ang ilang hanay ng mga pagsubok (halimbawa, mga unit test na isinagawa nang lokal) ay dapat ding matagumpay na makumpleto. Sa ngayon, ang komunidad ay sumusulong sa paggawa nito ng isang kinakailangan, at sa hinaharap ang "build + unit test" ay malamang na maging karaniwang kasanayan, kung hindi pa ito nagagawa.

Patuloy na integrasyon naiiba mula sa tuloy-tuloy na paghahatid (Continuous Delivery, CD) dahil hindi ito nangangailangan ng release candidate pagkatapos ng bawat integration cycle.

Listahan ng mga hakbang na gagamitin namin sa buong kurso

1. Hilahin ang pinakabagong code. Gumawa ng sangay mula sa master. Magsimulang magtrabaho.
2. Gumawa ng mga commit sa iyong bagong branch. Bumuo at subukan nang lokal. pumasa? Pumunta sa susunod na hakbang. Nabigo? Ayusin ang mga error o pagsubok at subukang muli.
3. Push sa iyong remote repository o remote branch.
4. Gumawa ng pull request. Talakayin ang mga pagbabago, magdagdag ng higit pang mga pangako habang nagpapatuloy ang talakayan. Ipasa ang mga pagsubok sa sangay ng tampok.
5. Ang merge/rebase ay commit mula sa master. Ipasa ang mga pagsubok sa resulta ng pagsasanib.
6. I-deploy mula sa feature na sangay hanggang sa produksyon.
7. Kung ang lahat ay mabuti sa produksyon sa loob ng ilang panahon, pagsamahin ang mga pagbabago sa master.

️ Paghahanda

Tiyaking mayroon kang tamang software

Upang kunin ang kursong ito kakailanganin mo node.js и Git client.

Maaari kang gumamit ng anumang Git client, ngunit magbibigay lang ako ng mga command para sa command line.

Tiyaking mayroon kang naka-install na Git client na sumusuporta sa command line

Kung wala ka pang Git client na sumusuporta sa command line, makakahanap ka ng mga tagubilin sa pag-install dito.

Ihanda ang repositoryo

Kakailanganin mong gumawa ng personal na kopya (tinidor) template repository na may code para sa kurso sa GitHub. Sumang-ayon tayo na tawagan itong personal na kopya imbakan ng kurso.

Tapos na? Kung hindi mo pa binago ang mga default na setting, malamang na tinatawag ang iyong imbakan ng kurso continuous-integration-team-scenarios-students, ito ay matatagpuan sa iyong GitHub account at ang URL ay ganito ang hitsura

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

Tatawagan ko lang ang address na ito <URL репозитория>.

Angle bracket tulad ng <тут> ay nangangahulugan na dapat mong palitan ang naturang expression ng naaangkop na halaga.

Siguraduhin mo yan Mga pagkilos sa GitHub kasama para sa imbakan ng kursong ito. Kung hindi pinagana ang mga ito, mangyaring paganahin ang mga ito sa pamamagitan ng pag-click sa malaking button sa gitna ng page, na maaari mong makuha sa pamamagitan ng pag-click sa Mga Aksyon sa interface ng GitHub.

Hindi mo makukumpleto ang kurso na sumusunod sa aking mga tagubilin kung ang GitHub Actions ay hindi pinagana.

Maaari mong palaging gamitin ang kakayahan ng GitHub na mag-render ng Markdown para makita ang kasalukuyang estado ng listahang binubuo namin dito

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

Tungkol sa mga sagot

Habang ang pinakamahusay na paraan upang makumpleto ang kursong ito ay gawin ito sa iyong sarili, maaari kang magkaroon ng ilang mga paghihirap.

Kung sa tingin mo ay hindi mo naiintindihan kung ano ang gagawin at hindi mo maaaring magpatuloy, maaari mong tingnan ang thread solution, na nasa iyong panimulang imbakan.
Mangyaring huwag pagsamahin solution в master habang nasa kurso. Maaari mong gamitin ang sangay na ito upang malaman kung ano ang gagawin, o upang ihambing ang iyong code sa may-akda, gamit ang lahat ng mga kakayahan na ibinibigay sa amin ng Git. Kung ikaw ay ganap na nawala, maaari mong ganap na palitan ang iyong sangay master sa isang sangay solution at pagkatapos ay i-reset ang iyong gumaganang direktoryo sa hakbang ng kurso na kailangan mo.

Gamitin lamang ito kung talagang kailangan mo ito

Ibigay ang iyong code

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

Ang mga utos na ito

• palitan ang pangalan master в master-backup;
• palitan ang pangalan solution в master;
• checkout sa isang bagong branch master at muling isulat ang mga nilalaman ng gumaganang direktoryo;
• Lumikha ng isang "solusyon" na sangay mula sa "master" (na dating "solusyon") kung sakaling kailangan mo ng isang "solusyon" na sangay sa hinaharap.

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

Pagkatapos ng mga hakbang na ito maaari mong gamitin git log master para malaman kung aling commit ang kailangan mo.
Maaari mong i-reset ang iyong gumaganang direktoryo sa commit na ito tulad nito:

git reset --hard <the SHA you need>

Kung masaya ka sa resulta, sa isang punto kakailanganin mong i-publish ang iyong bersyon ng repository sa isang remote na repository. Huwag kalimutang tahasang tukuyin ang malayong sangay kapag ginawa mo ito.

git push --force origin master

Mangyaring tandaan na ginagamit namin git push --force. Hindi malamang na gugustuhin mong gawin ito nang madalas, ngunit mayroon kaming isang napaka-espesipikong senaryo dito na may isang user ng repositoryo na, bilang karagdagan, ay nauunawaan kung ano ang kanyang ginagawa.

Nagsisimulang magtrabaho

Simulan natin ang pag-compile ng aming listahan ng mga hakbang sa CI. Karaniwang sisimulan mo ang hakbang na ito sa pamamagitan ng pagsuri sa pinakabagong bersyon ng code mula sa remote na repository, ngunit wala pa kaming lokal na repositoryo, kaya kine-clone namin ito mula sa remote.

️ Gawain: i-update ang lokal na imbakan, lumikha ng isang sangay mula sa master, magsimulang magtrabaho

1. I-clone ang repository ng kurso mula sa <URL репозитория>.
2. Takbo npm install sa direktoryo ng imbakan ng kurso; Kailangan namin ito upang i-install ang Jest, na ginagamit namin upang magpatakbo ng mga pagsubok.
3. Gumawa ng isang sangay at pangalanan ito feature. Lumipat sa thread na ito.

4. Magdagdag ng test code sa ci.test.js sa pagitan ng mga komento na humihiling sa akin na gawin ito.

   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. Magdagdag ng text na may unang 4 na hakbang sa file 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.  

   Mga Koponan

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

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

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

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

Gumawa ng mga commit sa isang bagong branch, bumuo at subukan nang lokal

Ise-set up namin ang mga pagsubok na tatakbo bago mag-commit, at pagkatapos ay i-commit ang code.

Mga karaniwang sitwasyon kapag awtomatikong tumatakbo ang mga pagsubok

• Lokal:
  • Patuloy o bilang tugon sa naaangkop na mga pagbabago sa code;
  • Sa pag-save (para sa mga interpreted o JIT-compiled na mga wika);
  • Sa panahon ng pagpupulong (kapag kinakailangan ang compilation);
  • Sa commit;
  • Kapag nag-publish sa isang shared repository.

• Sa build server o build environment:
  • Kapag na-publish ang code sa isang personal na sangay/imbakan.
  • Sinusubukan ang code sa thread na ito.
  • Ang potensyal na resulta ng pagsasama ay nasubok (karaniwan ay may master).
  • Bilang isang tuluy-tuloy na yugto ng pagsasama/patuloy na pipeline ng paghahatid

Kadalasan, mas mabilis na tumatakbo ang isang test suite, mas madalas mong kayang patakbuhin ito. Maaaring ganito ang hitsura ng isang tipikal na yugto ng pamamahagi.

• Mabilis na mga pagsubok sa yunit - sa panahon ng pagbuo, sa pipeline ng CI
• Mabagal na unit test, mabilis na component at integration test - on commit, sa pipeline ng CI
• Mabagal na bahagi at mga pagsubok sa pagsasama - sa pipeline ng CI
• Pagsusuri sa seguridad, pagsubok sa pag-load at iba pang nakakaubos ng oras o mamahaling pagsubok - sa mga pipeline ng CI/CD, ngunit sa ilang partikular na mga mode/yugto/pipeline lang ng build, halimbawa, kapag naghahanda ng kandidato sa pagpapalabas o kapag manu-manong tumatakbo.

️Gawain

Iminumungkahi kong patakbuhin muna ang mga pagsubok gamit ang command npm test. Pagkatapos nito, magdagdag tayo ng git hook upang patakbuhin ang ating mga pagsubok sa commit. May isang catch: Ang mga Git hook ay hindi itinuturing na bahagi ng repository at samakatuwid ay hindi maaaring i-clone mula sa GitHub kasama ang iba pang mga materyales sa kurso. Upang mag-install ng hook kailangan mong tumakbo install_hook.sh o kopyahin ang file repo/hooks/pre-commit sa lokal na direktoryo .git/hooks/.
Kapag nag-commit ka, makikita mo na ang mga pagsubok ay pinapatakbo at tinitingnan nila kung may ilang partikular na keyword sa listahan.

1. Patakbuhin ang mga pagsubok nang manu-mano sa pamamagitan ng pagpapatakbo ng command npm test sa iyong folder ng imbakan ng kurso. I-verify na nakumpleto na ang mga pagsubok.
2. Magtakda ng commit hook (pre-commit hook) sa pamamagitan ng pagtakbo install_hook.sh.
3. I-commit ang iyong mga pagbabago sa iyong lokal na imbakan.
4. Siguraduhin na ang mga pagsubok ay tumatakbo bago gumawa.

Dapat ganito ang hitsura ng iyong repository pagkatapos sundin ang mga hakbang na ito.

Mga Koponan

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

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

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

I-publish ang code sa isang malayuang imbakan o malayong sangay

Kapag tapos na silang magtrabaho nang lokal, karaniwang ginagawa ng mga developer na available sa publiko ang kanilang code upang sa kalaunan ay maisama ito sa publiko. Sa GitHub, ito ay karaniwang nakakamit sa pamamagitan ng pag-publish ng gawa sa alinman sa isang personal na kopya ng repositoryo (personal na tinidor) o isang personal na sangay.

• Gamit ang mga tinidor, kino-clone ng developer ang isang malayuang nakabahaging imbakan, na gumagawa ng personal na malayuang kopya nito, na kilala rin bilang isang tinidor. Pagkatapos ay kino-clone nito ang personal na imbakan na ito upang gumana sa lokal. Kapag kumpleto na ang trabaho at nagawa na ang mga commit, itinutulak niya ang mga ito sa kanyang tinidor, kung saan available ang mga ito sa iba at maaaring isama sa karaniwang repositoryo. Ang diskarte na ito ay karaniwang ginagamit sa mga open source na proyekto sa GitHub. Ginagamit din ito sa aking advanced na kurso [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Ang isa pang diskarte ay gumamit lamang ng isang malayong imbakan at bilangin lamang ang sangay master nakabahaging repositoryo na "protektado". Sa sitwasyong ito, inilathala ng mga indibidwal na developer ang kanilang code sa mga sangay ng isang malayong repository upang tingnan ng iba ang code na ito, kung maayos ang lahat, pagsamahin ito sa master nakabahaging imbakan.

Sa partikular na kursong ito, gagamit tayo ng workflow na gumagamit ng mga sangay.

I-publish natin ang ating code.

️Gawain

• Mag-publish ng mga pagbabago sa isang malayong sangay na may parehong pangalan ng iyong nagtatrabaho na sangay

Mga Koponan

git push --set-upstream origin feature

Gumawa ng pull request

Gumawa ng pull request na may pamagat Pagsusuri ng mga hakbang... I-install feature tulad ng "head branch" at master parang "base branch".

Tiyaking na-install mo master sa kanyang tinidor ang imbakan Bilang isang "base branch", hindi ako tutugon sa mga kahilingan para sa mga pagbabago sa imbakan ng mga materyales sa kurso.

Sa lingo ng GitHub, ang "base branch" ay ang sangay kung saan mo pinagbabatayan ang iyong trabaho, at ang "head branch" ay ang sangay na naglalaman ng mga iminungkahing pagbabago.

Talakayin ang mga pagbabago, magdagdag ng mga bagong commit habang nagpapatuloy ang talakayan

Pull request(PR)

Pull request(PR) ay isang paraan upang talakayin at idokumento ang code, gayundin ang pagsasagawa ng pagsusuri sa code. Ang mga kahilingan sa paghila ay pinangalanan sa pangkalahatang paraan ng pagsasama ng mga indibidwal na pagbabago sa pangkalahatang code. Karaniwan, kino-clone ng isang tao ang malayong opisyal na repositoryo ng proyekto at gumagana sa lokal na code. Pagkatapos nito, inilalagay niya ang code sa kanyang personal na remote na imbakan at hinihiling sa mga responsable para sa opisyal na imbakan na kunin (paghila) ang code nito sa kanilang mga lokal na repositoryo, kung saan sinusuri nila at posibleng isama(pagsamahin) kanyang. Ang konseptong ito ay kilala rin sa iba pang mga pangalan, halimbawa, kahilingan sa pagsamahin.

Hindi mo talaga kailangang gamitin ang tampok na pull request ng GitHub o mga katulad na platform. Maaaring gumamit ang mga development team ng iba pang paraan ng komunikasyon, kabilang ang face-to-face na komunikasyon, voice call, o email, ngunit mayroon pa ring ilang dahilan para gumamit ng mga kahilingan sa paghugot sa istilo ng forum. Narito ang ilan sa mga ito:

• organisadong mga talakayan na may kaugnayan sa mga partikular na pagbabago sa code;
• bilang isang lugar upang tingnan ang feedback sa work-in-progress mula sa parehong mga autotester at mga kapantay;
• pormalisasyon ng mga pagsusuri sa code;
• nang sa gayon ay malalaman mo ang mga dahilan at pagsasaalang-alang sa likod nito o ng piraso ng code na iyon.

Karaniwang gumagawa ka ng pull request kapag kailangan mong talakayin ang isang bagay o makakuha ng feedback. Halimbawa, kung gumagawa ka ng feature na maaaring ipatupad sa higit sa isang paraan, maaari kang gumawa ng pull request bago isulat ang unang linya ng code upang ibahagi ang iyong mga ideya at talakayin ang iyong mga plano sa iyong mga collaborator. Kung ang trabaho ay mas simple, ang isang pull request ay magbubukas kapag ang isang bagay ay nagawa na, nakatuon, at maaaring talakayin. Sa ilang mga sitwasyon, maaaring gusto mong magbukas ng PR para lang sa mga kadahilanang pangkontrol sa kalidad: upang magpatakbo ng mga awtomatikong pagsubok o magsimula ng mga pagsusuri sa code. Anuman ang desisyon mo, huwag kalimutang @banggitin ang mga tao na gusto mo ng approval sa iyong pull request.

Kadalasan, kapag gumagawa ng PR, ginagawa mo ang sumusunod.

• Ipahiwatig kung ano ang iminumungkahi mong baguhin at kung saan.
• Sumulat ng isang paglalarawan na nagpapaliwanag sa layunin ng mga pagbabago. Maaaring gusto mo:
  • magdagdag ng anumang mahalagang bagay na hindi halata mula sa code, o isang bagay na kapaki-pakinabang para sa pag-unawa sa konteksto, tulad ng mga nauugnay na #bugs at mga commit na numero;
  • @banggitin ang sinumang gusto mong magsimulang magtrabaho, o maaari mo silang @banggitin sa mga komento sa ibang pagkakataon;
  • hilingin sa mga kasamahan na tumulong sa isang bagay o suriin ang isang partikular na bagay.

Kapag binuksan mo ang PR, ang mga pagsubok na na-configure upang tumakbo sa mga ganitong kaso ay isasagawa. Sa aming kaso, ito ang parehong hanay ng mga pagsubok na lokal naming pinatakbo, ngunit sa isang tunay na proyekto ay maaaring may mga karagdagang pagsubok at pagsusuri.

Mangyaring maghintay habang nakumpleto ang mga pagsusulit. Makikita mo ang status ng mga pagsubok sa ibaba ng talakayan sa PR sa interface ng GitHub. Magpatuloy kapag natapos na ang mga pagsusulit.

️ Magdagdag ng tala tungkol sa randomness ng listahan ng mga hakbang ng CI

Ang listahang ginamit sa kursong ito ay arbitrary at subjective, dapat tayong magdagdag ng tala tungkol dito.

️ Gawain: gumawa ng pull request para sa komentong ito

1. Lumipat sa sangay master.
2. Lumikha ng isang sangay na pinangalanan bugfix.
3. Magdagdag ng teksto ng tala sa dulo ng file 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. Ibigay ang mga pagbabago.
5. I-publish ang thread bugfix sa isang malayuang imbakan.
6. Gumawa ng pull request na pinangalanan Pagdaragdag ng komento na may sanga ng ulo bugfix at ang batayang sangaymaster.

Tiyaking na-install mo master sa kanyang tinidor ang imbakan Bilang isang "base branch", hindi ako tutugon sa mga kahilingan para sa mga pagbabago sa imbakan ng mga materyales sa kurso.

Ganito dapat ang hitsura ng iyong repository.

Mga Koponan

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

Aprubahan ang kahilingan sa paghila "Pagdaragdag ng komento"

️Gawain

1. Gumawa ng pull request.
2. I-click ang "Pagsamahin ang kahilingan sa paghila".
3. I-click ang "Kumpirmahin ang pagsasama".
4. I-click ang "Delete branch", hindi na namin ito kailangan.

Isa itong diagram ng mga commit pagkatapos ng pagsasama.

️ Patuloy na magtrabaho at magdagdag ng mga pagsubok

Ang pakikipagtulungan sa isang pull request ay kadalasang nagreresulta sa karagdagang trabaho. Ito ay karaniwang resulta ng isang pagsusuri o talakayan ng code, ngunit sa aming kurso ay imodelo namin ito sa pamamagitan ng pagdaragdag ng mga bagong item sa aming listahan ng mga hakbang sa CI.

Ang patuloy na pagsasama ay karaniwang nagsasangkot ng ilang saklaw ng pagsubok. Iba-iba ang mga kinakailangan sa saklaw ng pagsubok at kadalasang makikita sa isang dokumentong tinatawag na isang bagay tulad ng "mga alituntunin sa kontribusyon." Pananatilihin namin itong simple at magdagdag ng pagsubok para sa bawat linya sa aming checklist.

Kapag nagpapatakbo ng mga takdang-aralin, subukang gawin muna ang mga pagsubok. Kung na-install mo nang tama pre-commit hook kanina, ang bagong idinagdag na pagsubok ay tatakbo, mabibigo, at walang gagawin. Tandaan na ito ay kung paano namin malalaman na ang aming mga pagsubok ay aktwal na sumusubok ng isang bagay. Kapansin-pansin, kung nagsimula kami sa code bago ang mga pagsubok, ang pagpasa sa mga pagsubok ay maaaring mangahulugan na gumagana ang code gaya ng inaasahan, o na ang mga pagsubok ay hindi aktwal na sumusubok ng anuman. Dagdag pa, kung hindi namin isinulat ang mga pagsusulit sa unang lugar, maaaring nakalimutan namin ang tungkol sa mga ito nang buo, dahil walang magpapaalala sa amin nito.

Test Driven Development (TDD)

Inirerekomenda ng TDD ang pagsulat ng mga pagsubok bago ang code. Ang isang karaniwang daloy ng trabaho gamit ang TDD ay ganito ang hitsura.

1. Magdagdag ng pagsubok.
2. Patakbuhin ang lahat ng pagsubok at tiyaking mabibigo ang bagong pagsubok.
3. Isulat ang code.
4. Patakbuhin ang mga pagsusulit, siguraduhing makapasa ang lahat ng pagsusulit.
5. I-refactor ang iyong code.
6. Ulitin.

Dahil ang mga resulta ng mga pagsubok na nabigo ay karaniwang ipinapakita sa pula, at ang mga pumasa ay karaniwang ipinapakita sa berde, ang cycle ay kilala rin bilang isang red-green-refactor.

️Gawain

Una, subukang gawin ang mga pagsubok at hayaan silang mabigo, pagkatapos ay idagdag at i-commit ang teksto ng mismong listahan ng hakbang ng CI. Makikita mo na ang mga pagsusulit ay pumasa ("berde").
Pagkatapos ay i-publish ang bagong code sa remote na repository at panoorin ang mga pagsubok na tumatakbo sa interface ng GitHub sa ibaba ng talakayan ng pull request at ang PR status update.

1. Lumipat sa sangay feature.

2. Idagdag ang mga pagsubok na ito sa ci.test.js pagkatapos ng huling tawag 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. Subukang gawin ang mga pagsubok. Kung pre-commit naka-install ang hook, mabibigo ang pagtatangka ng commit.
4. Pagkatapos ay idagdag ang tekstong ito sa 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. Gumawa at gumawa ng mga pagbabago nang lokal.
6. Mag-post ng mga pagbabago sa sangay feature.

Dapat mayroon ka na ngayong ganito

Mga Koponan

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

Pagsamahin ang salungatan

Pumunta sa Change Request Pagsusuri ng mga hakbang.

Kahit na wala kaming ginawang mali at ang mga pagsubok para sa aming code ay pumasa, hindi pa rin namin maaaring pagsamahin ang sangay feature и master. Yung kabilang thread kasi bugfix ay pinagsama sa master habang ginagawa namin itong PR.
Lumilikha ito ng isang sitwasyon kung saan ang malayong sangay master ay may mas bagong bersyon kaysa sa pinagbatayan namin sa sangay feature. Dahil dito hindi lang natin mai-rewind ang HEAD master hanggang dulo ng thread feature. Sa sitwasyong ito, kailangan nating pagsamahin o ilapat ang mga commit feature rebase master. Ang GitHub ay maaaring aktwal na magsagawa ng mga awtomatikong pagsasanib kung walang mga salungatan. Naku, sa aming sitwasyon, ang parehong mga sangay ay may nakikipagkumpitensyang pagbabago sa file ci.md. Ang sitwasyong ito ay kilala bilang isang merge conflict, at kailangan namin itong lutasin nang manu-mano.

Pagsamahin o i-rebase

Pagsamahin

• Gumagawa ng karagdagang merge commit at sine-save ang kasaysayan ng trabaho.
  • Pinapanatili ang mga orihinal na commit ng mga sangay kasama ng kanilang mga orihinal na timestamp at mga may-akda.
  • Sine-save ang SHA ng mga commit at nagli-link sa kanila sa mga talakayan sa kahilingan sa pagbabago.
• Nangangailangan ng isang beses na paglutas ng salungatan.
• Ginagawang non-linear ang kwento.
  • Maaaring mahirap basahin ang kuwento dahil sa malaking bilang ng mga sangay (nakapagpapaalaala sa isang IDE cable).
  • Ginagawang mas mahirap ang awtomatikong pag-debug, hal. git bisect hindi gaanong kapaki-pakinabang - mahahanap lamang nito ang merge commit.

I-rebase

• Ang mga replay ay nagko-commit mula sa kasalukuyang sangay sa tuktok ng base na sangay nang sunud-sunod.
  • Nabubuo ang mga bagong commit na may mga bagong SHA, na nagiging dahilan upang tumugma ang mga commit sa GitHub sa orihinal na mga pull request, ngunit hindi ang mga kaukulang komento.
  • Ang mga commit ay maaaring muling pagsamahin at baguhin sa proseso, o kahit na pagsamahin sa isa.
• Maaaring kailangang lutasin ang maraming salungatan.
• Binibigyang-daan kang mapanatili ang isang linear na kuwento.
  • Maaaring mas madaling basahin ang kwento hangga't hindi ito masyadong mahaba nang walang makatwirang dahilan.
  • Ang awtomatikong pag-debug at pag-troubleshoot ay medyo mas madali: ginagawang posible git bisect, ay maaaring gawing mas malinaw at mas predictable ang mga awtomatikong rollback.
• Nangangailangan ng pag-publish ng isang sangay na may mga inilipat na commit na may flag --force kapag ginamit sa mga kahilingan sa paghila.

Karaniwan, sumasang-ayon ang mga koponan na palaging gumamit ng parehong diskarte kapag kailangan nilang pagsamahin ang mga pagbabago. Ito ay maaaring isang "pure" merge o isang "pure" commit sa itaas, o isang bagay sa pagitan, gaya ng paggawa ng commit sa itaas nang interactive(git rebase -i) lokal para sa mga sangay na hindi nai-publish sa pampublikong imbakan, ngunit pinagsama para sa mga "pampublikong" sangay.

Dito gagamitin natin ang merge.

️Gawain

1. Tiyaking nasa lokal na sangay ang code master na-update mula sa isang malayuang imbakan.
2. Lumipat sa sangay feature.
3. Magsimula ng pagsasama sa isang sangay master. Isang pagsasanib na salungatan dahil sa mga nakikipagkumpitensyang pagbabago sa ci.md.
4. Resolbahin ang salungatan upang ang aming listahan ng mga hakbang sa CI at isang tala tungkol dito ay manatili sa text.
5. Mag-publish ng merge commit sa isang malayong branch feature.
6. Suriin ang status ng pull request sa GitHub UI at maghintay hanggang sa malutas ang merge.

Mga Koponan

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

Mahusay na trabaho!

Tapos ka na sa listahan at ngayon ay kailangan mong aprubahan ang pull request in master.

️ Gawain: Aprubahan ang pull request "Steps review"

1. Magbukas ng pull request.
2. I-click ang "Pagsamahin ang kahilingan sa paghila".
3. I-click ang "Kumpirmahin ang pagsasama".
4. I-click ang "Delete branch" dahil hindi na namin ito kailangan.

Ito ang iyong repositoryo sa ngayon

Error sa produkto

Sinasabi na "ang pagsubok ay maaaring gamitin upang ipakita ang pagkakaroon ng mga pagkakamali, ngunit hindi kailanman upang ipakita ang kanilang kawalan." Kahit na mayroon kaming mga pagsubok at hindi sila nagpakita sa amin ng mga pagkakamali, isang mapanlinlang na bug ang pumasok sa produksyon.

Sa ganitong sitwasyon, kailangan nating alagaan:

• kung ano ang ipinakalat sa produksyon;
• code sa thread master na may error, kung saan maaaring magsimula ang mga developer ng bagong trabaho.

Dapat ko bang ibalik o ayusin ito sa susunod na bersyon?

Ang pagbabalik ay ang proseso ng pag-deploy ng isang kilalang mas naunang bersyon sa produksyon at pagbabalik ng mga commit na naglalaman ng error. Ang "pag-aayos ng pasulong" ay ang pagdaragdag ng isang pag-aayos sa master at pag-deploy ng bagong bersyon sa lalong madaling panahon. Dahil nagbabago ang mga API at database schema habang ang code ay na-deploy sa produksyon, na may tuluy-tuloy na paghahatid at mahusay na saklaw ng pagsubok, ang pagbabalik ay karaniwang mas mahirap at peligroso kaysa sa pag-aayos nito sa susunod na bersyon.

Dahil ang pag-urong ay hindi nagdadala ng anumang panganib sa aming kaso, pupunta kami sa rutang ito, dahil pinapayagan kami nito

• ayusin ang error sa produkto sa lalong madaling panahon;
• gumawa ng code sa master kaagad na angkop para sa pagsisimula ng bagong trabaho.

️Gawain

1. Lumipat sa sangay master sa lokal
2. I-update ang lokal na imbakan mula sa malayong imbakan.
3. Ibalik ang PR merge commit Pagsusuri ng mga hakbang в master.
4. I-publish ang mga pagbabago sa isang malayuang imbakan.

Ito ang kasaysayan ng isang repository na may na-revert na merge commit

Mga Koponan

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

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

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

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

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

️ Pagsusuri sa sarili

Siguraduhin na ci.md hindi na naglalaman ng text na "sneaky bug" pagkatapos ibalik ang isang merge commit.

Ayusin ang listahan ng mga hakbang sa CI at ibalik ito sa master

Ganap naming ibinalik ang merge commit ng branch. feature. Ang mabuting balita ay wala na tayong pagkakamali master. Ang masamang balita ay ang aming mahalagang listahan ng patuloy na mga hakbang sa pagsasama ay wala na rin. Kaya, sa isip, kailangan nating ilapat ang pag-aayos sa mga commit mula sa feature at ibalik ang mga ito sa master kasama ang pag-aayos.

Maaari nating lapitan ang problema sa iba't ibang paraan:

• ibalik ang isang commit na nag-undo sa isang pagsasama feature с master;
• move commits mula sa dating feature.

Iba't ibang development team ang gumagamit ng iba't ibang approach sa kasong ito, ngunit ililipat namin ang mga kapaki-pakinabang na commit sa isang hiwalay na branch at gagawa kami ng hiwalay na pull request para sa bagong branch na ito.

️Gawain

1. Gumawa ng thread na tinatawag feature-fix at lumipat dito.

2. I-migrate ang lahat ng commit mula sa dating branch feature sa bagong thread. Lutasin ang mga pagsasalungat sa pagsasanib na naganap sa panahon ng paglipat.

   

3. Magdagdag ng regression test sa ci.test.js:

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

4. Patakbuhin ang mga pagsubok nang lokal upang matiyak na hindi sila mabibigo.
5. Alisin ang text na "na may palihim na bug" sa ci.md.
6. Magdagdag ng mga pagbabago sa pagsubok at mga pagbabago sa listahan ng hakbang sa index at i-commit ang mga ito.
7. I-publish ang sangay sa isang malayong imbakan.

Dapat kang magtapos sa isang bagay na katulad nito:

Mga Koponan

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

Gumawa ng pull request.

Gumawa ng pull request na may pamagat Pag-aayos ng tampok... I-install feature-fix tulad ng "head branch" at master parang "base branch".
Mangyaring maghintay habang nakumpleto ang mga pagsubok. Maaari mong makita ang katayuan ng mga pagsusulit sa ibaba ng talakayan sa PR.

Tiyaking na-install mo master sa kanyang tinidor ang imbakan Bilang isang "base branch", hindi ako tutugon sa mga kahilingan para sa mga pagbabago sa imbakan ng mga materyales sa kurso.

Aprubahan ang pull request "Pag-aayos ng feature"

Salamat sa pagwawasto! Mangyaring aprubahan ang mga pagbabago sa master mula sa pull request.

️Gawain

1. I-click ang "Pagsamahin ang kahilingan sa paghila".
2. I-click ang "Kumpirmahin ang pagsasama".
3. I-click ang "Delete branch" dahil hindi na namin ito kailangan.

Ito ang dapat na mayroon ka sa ngayon.

Binabati kita!

Nakumpleto mo na ang lahat ng hakbang na karaniwang ginagawa ng mga tao sa patuloy na pagsasama.

Kung may napansin kang anumang problema sa kurso o alam mo kung paano ito pagbutihin, mangyaring lumikha ng isyu sa mga imbakan na may mga materyales sa kurso. Ang kursong ito ay mayroon ding interactive na bersyon gamit ang GitHub Learning Lab bilang isang platform.

Pinagmulan: www.habr.com