Umejifunza maagizo ya Git lakini unataka kufikiria jinsi ujumuishaji unaoendelea (CI) unavyofanya kazi katika ukweli? Au labda unataka kuboresha shughuli zako za kila siku? Kozi hii itakupa ujuzi wa vitendo katika ujumuishaji unaoendelea kwa kutumia hazina ya GitHub. Kozi hii haikusudiwi kuwa mchawi ambao unaweza kubofya tu; kinyume chake, utafanya vitendo sawa na ambavyo watu hufanya kazini, kwa njia sawa na wanafanya. Nitaeleza nadharia unapopitia hatua zinazohusika.

Tunafanya nini?

Tunapoendelea, tutaunda hatua kwa hatua orodha ya hatua za kawaida za CI, ambayo ni njia nzuri ya kukumbuka orodha hii. Kwa maneno mengine, tutaunda orodha ya vitendo ambavyo watengenezaji huchukua wakati wa kufanya ushirikiano unaoendelea, wakifanya ushirikiano unaoendelea. Pia tutatumia seti rahisi ya majaribio kuleta mchakato wetu wa CI karibu na ule halisi.

GIF hii inaonyesha kimkakati ahadi kwenye hazina yako unapoendelea kwenye kozi. Kama unaweza kuona, hakuna chochote ngumu hapa na muhimu zaidi.

Utapitia hali zifuatazo za kawaida za CI:

• Fanya kazi kwenye kipengele;
• Utumiaji wa vipimo vya kiotomatiki ili kuhakikisha ubora;
• Utekelezaji wa kazi ya kipaumbele;
• Utatuzi wa migogoro wakati wa kuunganisha matawi (unganisha migogoro);
• Hitilafu hutokea katika mazingira ya uzalishaji.

Utajifunza nini?

Utaweza kujibu maswali yafuatayo:

• Ujumuishaji endelevu (CI) ni nini?
• Ni aina gani za majaribio ya kiotomatiki hutumiwa katika CI, na kwa kujibu ni vitendo gani vinachochewa?
• Maombi ya kuvuta ni nini na yanahitajika lini?
• Maendeleo ya Kuendesha Mtihani (TDD) ni nini na inahusiana vipi na CI?
• Je, niunganishe au nibadilishe tena mabadiliko?
• Rudisha nyuma au urekebishe katika toleo linalofuata?

Mwanzoni nilitafsiri vitu kama "maombi ya kuvuta" kila mahali, lakini kwa sababu hiyo niliamua kurudisha misemo kwa Kiingereza katika sehemu zingine ili kupunguza kiwango cha wazimu katika maandishi. Wakati fulani nitatumia "programmer surzhik" kama vile kitenzi kizuri "commit" ambapo watu huitumia kazini.

Ushirikiano endelevu ni nini?

Kuendelea Kuunganishwa, au CI, ni mazoezi ya kiufundi ambapo kila mwanachama wa timu huunganisha misimbo yake kwenye hazina ya pamoja angalau mara moja kwa siku, na msimbo unaotokana lazima uundwe angalau bila hitilafu.

Kuna kutokubaliana kuhusu neno hili

Hatua ya ugomvi ni mzunguko wa ushirikiano. Wengine wanasema kuwa kuunganisha msimbo mara moja tu kwa siku haitoshi kuunganishwa kila wakati. Mfano umetolewa wa timu ambapo kila mtu huchukua nambari mpya asubuhi na kuiunganisha mara moja jioni. Ingawa hili ni pingamizi linalofaa, kwa ujumla inaaminika kuwa ufafanuzi wa mara moja kwa siku ni wa vitendo, mahususi na unafaa kwa timu za saizi tofauti.

Pingamizi lingine ni kwamba C++ sio lugha pekee inayotumiwa katika ukuzaji, na kuhitaji tu mkusanyiko usio na makosa kama njia ya uthibitishaji ni dhaifu. Baadhi ya majaribio (kwa mfano, majaribio ya vipimo yanayotekelezwa ndani ya nchi) lazima pia yakamilike kwa mafanikio. Kwa sasa, jumuiya inaelekea kufanya hili kuwa hitaji, na katika siku zijazo "majaribio ya kujenga + kitengo" labda yatakuwa mazoea ya kawaida, ikiwa haijafanya hivyo.

Kuendelea Kuunganishwa tofauti na utoaji wa kuendelea (Utoaji Unaoendelea, CD) kwa kuwa hauhitaji mgombeaji wa toleo baada ya kila mzunguko wa ujumuishaji.

Orodha ya hatua tutakazotumia katika kipindi chote

1. Vuta msimbo wa hivi punde. Unda tawi kutoka master. Anza kufanya kazi.
2. Unda ahadi kwenye tawi lako jipya. Jenga na ujaribu ndani ya nchi. Kupitisha? Nenda kwa hatua inayofuata. Umeshindwa? Rekebisha hitilafu au majaribio na ujaribu tena.
3. Bonyeza kwenye hazina yako ya mbali au tawi la mbali.
4. Unda ombi la kuvuta. Jadili mabadiliko, ongeza ahadi zaidi mazungumzo yakiendelea. Fanya majaribio kupita kwenye tawi la kipengele.
5. Unganisha/punguza tena ahadi kutoka kwa bwana. Fanya vipimo kupita kwenye matokeo ya kuunganisha.
6. Sambaza kutoka kwa tawi la kipengele hadi toleo la umma.
7. Ikiwa kila kitu ni nzuri katika uzalishaji kwa muda fulani, unganisha mabadiliko kwa bwana.

️ Maandalizi

Hakikisha una programu sahihi

Ili kuchukua kozi hii utahitaji node.js и Mteja wa Git.

Unaweza kutumia mteja wowote wa Git, lakini nitatoa tu amri kwa safu ya amri.

Hakikisha umesakinisha mteja wa Git ambaye anaunga mkono safu ya amri

Ikiwa bado huna mteja wa Git anayetumia safu ya amri, unaweza kupata maagizo ya usakinishaji hapa.

Tayarisha hifadhi

Utahitaji kuunda nakala ya kibinafsi (uma) hazina ya kiolezo na nambari ya kozi kwenye GitHub. Tukubali kupiga nakala hii ya kibinafsi hazina ya kozi.

Umemaliza? Ikiwa haujabadilisha mipangilio chaguo-msingi, hazina yako ya kozi ina uwezekano mkubwa wa kuitwa continuous-integration-team-scenarios-students, iko katika akaunti yako ya GitHub na URL inaonekana kama hii

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

Nitaita anwani hii kwa urahisi <URL репозитория>.

Mabano ya pembe kama <тут> itamaanisha kuwa lazima ubadilishe usemi kama huo na thamani inayofaa.

Hakikisha kwamba Vitendo vya GitHub imejumuishwa kwa hazina hii ya kozi. Ikiwa hazijawezeshwa, tafadhali ziwezeshe kwa kubofya kitufe kikubwa katikati ya ukurasa, ambacho unaweza kupata kwa kubofya Vitendo kwenye kiolesura cha GitHub.

Hutaweza kukamilisha kozi kufuatia maagizo yangu ikiwa Vitendo vya GitHub havijawezeshwa.

Unaweza kutumia uwezo wa GitHub kila wakati kutoa Markdown ili kuona hali ya sasa ya orodha tunayounda hapa.

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

Kuhusu majibu

Ingawa njia bora ya kukamilisha kozi hii ni kuifanya wewe mwenyewe, unaweza kuwa na ugumu fulani.

Ikiwa unahisi kuwa huelewi nini cha kufanya na huwezi kuendelea, unaweza kuangalia kwenye thread solution, ambayo iko kwenye hazina yako ya kuanza.
Tafadhali usichanganye solution в master wakati wa kozi. Unaweza kutumia tawi hili kujua la kufanya, au kulinganisha nambari yako na ya mwandishi, kwa kutumia uwezo wote ambao Git inatupa. Ikiwa umepotea kabisa, unaweza kubadilisha kabisa tawi lako master kwenye tawi solution na kisha uweke upya saraka yako ya kufanya kazi kwa hatua ya kozi unayohitaji.

Tumia hii tu ikiwa unahitaji kweli

Weka nambari yako ya kuthibitisha

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

Amri hizi

• badilisha jina master в master-backup;
• badilisha jina solution в master;
• angalia tawi jipya master na uandike upya yaliyomo kwenye saraka ya kazi;
• Unda tawi la "suluhisho" kutoka kwa "bwana" (ambalo lilikuwa "suluhisho") ikiwa utahitaji tawi la "suluhisho" katika siku zijazo.

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

Baada ya hatua hizi unaweza kutumia git log master ili kujua ni ahadi gani unahitaji.
Unaweza kuweka upya saraka yako ya kufanya kazi kwa ahadi hii kama hii:

git reset --hard <the SHA you need>

Ikiwa umefurahiya matokeo, wakati fulani utahitaji kuchapisha toleo lako la hazina kwenye hazina ya mbali. Usisahau kutaja wazi tawi la mbali unapofanya hivi.

git push --force origin master

Tafadhali kumbuka kuwa tunatumia git push --force. Haiwezekani kwamba utataka kufanya hivi mara nyingi sana, lakini tuna hali maalum hapa na mtumiaji mmoja wa hazina ambaye, kwa kuongezea, anaelewa anachofanya.

Kuanza kufanya kazi

Wacha tuanze kuandaa orodha yetu ya hatua za CI. Kwa kawaida ungeanza hatua hii kwa kuangalia toleo la hivi punde la msimbo kutoka hazina ya mbali, lakini bado hatuna hazina ya ndani, kwa hivyo tunaiiga kutoka kwa ile ya mbali badala yake.

️ Kazi: sasisha hazina ya ndani, unda tawi kutoka master, anza kufanya kazi

1. Funga hazina ya kozi kutoka <URL репозитория>.
2. Endesha npm install katika saraka ya hazina ya kozi; Tunaihitaji ili kusakinisha Jest, ambayo tunaitumia kufanya majaribio.
3. Unda tawi na uipe jina feature. Badili hadi kwenye uzi huu.

4. Ongeza nambari ya jaribio kwa ci.test.js kati ya maoni kuniuliza nifanye hivi.

   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. Ongeza maandishi na hatua 4 za kwanza kwenye faili 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 как описано выше

Unda ahadi kwenye tawi jipya, jenga na ujaribu ndani ya nchi

Tutaweka majaribio ya kufanya kabla ya kufanya, na kisha kutekeleza nambari.

Matukio ya kawaida wakati majaribio yanaendeshwa kiotomatiki

• Ndani ya nchi:
  • Kuendelea au kwa kukabiliana na mabadiliko sahihi ya kanuni;
  • Unapohifadhi (kwa lugha zilizotafsiriwa au zilizokusanywa na JIT);
  • Wakati wa kusanyiko (wakati mkusanyiko unahitajika);
  • Juu ya ahadi;
  • Wakati wa kuchapisha kwenye hazina iliyoshirikiwa.

• Kwenye seva ya ujenzi au mazingira ya ujenzi:
  • Wakati msimbo unachapishwa kwa tawi la kibinafsi/hazina.
  • Msimbo katika mazungumzo haya unajaribiwa.
  • Matokeo yanayoweza kutokea ya muunganisho yanajaribiwa (kawaida na master).
  • Kama hatua ya ujumuishaji endelevu/bomba la uwasilishaji endelevu

Kwa kawaida, kadiri kikundi cha majaribio kinavyofanya kazi kwa haraka, ndivyo unavyoweza kumudu kukiendesha mara nyingi zaidi. Usambazaji wa hatua ya kawaida unaweza kuonekana kama hii.

• Vipimo vya kitengo cha haraka - wakati wa kujenga, katika bomba la CI
• Majaribio ya vipimo vya polepole, sehemu ya haraka na majaribio ya ujumuishaji - kwa ahadi, katika bomba la CI
• Vipimo vya polepole vya sehemu na ujumuishaji - kwenye bomba la CI
• Upimaji wa usalama, upimaji wa upakiaji na majaribio mengine ya muda au ya gharama kubwa - katika mabomba ya CI/CD, lakini tu katika hali/hatua/mabomba fulani ya muundo, kwa mfano, wakati wa kuandaa mgombeaji wa toleo au wakati wa kukimbia mwenyewe.

️ Kazi

Ninapendekeza kuendesha majaribio kwa mikono kwanza kwa kutumia amri npm test. Baada ya hapo, wacha tuongeze ndoano ya git ili kuendesha majaribio yetu kwa kujitolea. Kuna mtego mmoja: Kulabu za Git hazizingatiwi kama sehemu ya hazina na kwa hivyo haziwezi kutengenezwa kutoka kwa GitHub pamoja na vifaa vingine vya kozi. Ili kufunga ndoano unahitaji kukimbia install_hook.sh au nakili faili repo/hooks/pre-commit kwa saraka ya ndani .git/hooks/.
Unapojitolea, utaona kwamba majaribio yanaendeshwa na wanaangalia ili kuona ikiwa maneno fulani yapo kwenye orodha.

1. Endesha majaribio kwa mikono kwa kuendesha amri npm test kwenye folda yako ya hazina ya kozi. Thibitisha kuwa majaribio yamekamilika.
2. Weka ndoano ya ahadi (ndoano ya kujitolea kabla) kwa kukimbia install_hook.sh.
3. Toa mabadiliko yako kwenye hazina yako ya karibu.
4. Hakikisha majaribio yanaendeshwa kabla ya kufanya.

Hifadhi yako inapaswa kuonekana kama hii baada ya kufuata hatua hizi.

Команды

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

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

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

Chapisha msimbo kwenye hazina ya mbali au tawi la mbali

Pindi tu zinapomaliza kufanya kazi ndani ya nchi, wasanidi kwa kawaida hufanya msimbo wao upatikane hadharani ili hatimaye uweze kuunganishwa na umma. Kwa GitHub, hii kawaida hupatikana kwa kuchapisha kazi hiyo kwa nakala ya kibinafsi ya hazina (uma ya kibinafsi) au tawi la kibinafsi.

• Kwa uma, msanidi programu hutengeneza hazina iliyoshirikiwa ya mbali, na kuunda nakala yake ya kibinafsi ya mbali, inayojulikana pia kama uma. Kisha huunganisha hazina hii ya kibinafsi kufanya kazi nayo ndani. Wakati kazi imekamilika na ahadi zinafanywa, anazisukuma kwenye uma wake, ambapo zinapatikana kwa wengine na zinaweza kuunganishwa kwenye hifadhi ya kawaida. Njia hii hutumiwa sana katika miradi ya chanzo wazi kwenye GitHub. Inatumika pia katika kozi yangu ya juu [Kazi ya Timu na CI na Git] (http://devops.redpill.solutions/).
• Njia nyingine ni kutumia hazina moja tu ya mbali na kuhesabu tawi tu master hazina iliyoshirikiwa "iliyolindwa". Katika hali hii, wasanidi programu binafsi huchapisha msimbo wao kwenye matawi ya hazina ya mbali ili wengine waweze kuangalia msimbo huu, ikiwa kila kitu kiko sawa, iunganishe na master hazina iliyoshirikiwa.

Katika kozi hii mahususi, tutakuwa tukitumia mtiririko wa kazi unaotumia matawi.

Wacha tuchapishe nambari yetu.

️ Kazi

• Chapisha mabadiliko kwenye tawi la mbali lenye jina sawa na tawi lako linalofanya kazi

Команды

git push --set-upstream origin feature

Unda ombi la kuvuta

Unda ombi la kuvuta na kichwa Mapitio ya hatua. Sakinisha feature kama "tawi la kichwa" na master kama "tawi la msingi".

Hakikisha umesakinisha master katika yake uma hazina Kama "tawi la msingi", sitajibu maombi ya mabadiliko kwenye hazina ya vifaa vya kozi.

Katika GitHub lingo, "tawi la msingi" ni tawi ambalo unaweka kazi yako, na "tawi la kichwa" ni tawi lililo na mabadiliko yaliyopendekezwa.

Jadili mabadiliko, ongeza ahadi mpya wakati mjadala unaendelea

Vuta ombi (PR)

Vuta ombi (PR) ni njia ya kujadili na kuandika msimbo, pamoja na kufanya uhakiki wa kanuni. Maombi ya kuvuta yanaitwa baada ya njia ya jumla ya kuunganisha mabadiliko ya mtu binafsi kwenye msimbo wa jumla. Kwa kawaida, mtu hutengeneza hazina rasmi ya mbali ya mradi na kufanya kazi kwenye msimbo ndani ya nchi. Baada ya hayo, anaweka nambari hiyo kwenye hazina yake ya kibinafsi na kuwauliza wale wanaohusika na hazina rasmi kuchukua(kuvuta) nambari yake kwenye hazina zao za ndani, ambapo wanakagua na ikiwezekana kujumuisha(kuunganisha) yake. Dhana hii pia inajulikana kwa majina mengine, kwa mfano, unganisha ombi.

Sio lazima utumie kipengele cha ombi la kuvuta la GitHub au majukwaa kama hayo. Timu za maendeleo zinaweza kutumia mbinu nyingine za mawasiliano, ikiwa ni pamoja na mawasiliano ya ana kwa ana, simu za sauti au barua pepe, lakini bado kuna sababu kadhaa za kutumia maombi ya kuvuta kwa mtindo wa mijadala. Hapa kuna baadhi yao:

• majadiliano yaliyopangwa kuhusiana na mabadiliko maalum ya kanuni;
• kama mahali pa kutazama maoni kuhusu kazi inayoendelea kutoka kwa waendeshaji otomatiki na wenzao;
• urasimishaji wa mapitio ya kanuni;
• ili baadaye uweze kujua sababu na mazingatio nyuma ya hii au kipande cha msimbo.

Kwa kawaida huunda ombi la kuvuta unapohitaji kujadili kitu au kupata maoni. Kwa mfano, ikiwa unafanyia kazi kipengele ambacho kinaweza kutekelezwa kwa zaidi ya njia moja, unaweza kuunda ombi la kuvuta kabla ya kuandika mstari wa kwanza wa msimbo ili kushiriki mawazo yako na kujadili mipango yako na washirika wako. Ikiwa kazi ni rahisi, ombi la kuvuta linafunguliwa wakati kitu tayari kimefanywa, kimejitolea, na kinaweza kujadiliwa. Katika baadhi ya matukio, unaweza kutaka kufungua PR kwa sababu za udhibiti wa ubora pekee: kufanya majaribio ya kiotomatiki au kuanzisha ukaguzi wa misimbo. Chochote utakachoamua, usisahau @ kutaja watu ambao unataka idhini yao katika ombi lako la kuvuta.

Kwa kawaida, wakati wa kuunda PR, unafanya zifuatazo.

• Onyesha unachopendekeza kubadilisha na wapi.
• Andika maelezo ukieleza madhumuni ya mabadiliko. Unaweza kutaka:
  • ongeza kitu chochote muhimu ambacho hakiko wazi kutoka kwa msimbo, au kitu muhimu kwa kuelewa muktadha, kama vile #bugs na nambari za kufanya;
  • @mtaja mtu yeyote unayetaka kuanza kufanya naye kazi, au unaweza @kumtaja kwenye maoni baadaye;
  • waombe wenzako wakusaidie kwa jambo fulani au uangalie jambo mahususi.

Mara tu unapofungua PR, majaribio yaliyosanidiwa kufanya kazi katika hali kama hizi hutekelezwa. Kwa upande wetu, hii itakuwa seti sawa ya vipimo ambavyo tuliendesha ndani ya nchi, lakini katika mradi halisi kunaweza kuwa na vipimo vya ziada na hundi.

Tafadhali subiri wakati majaribio yanakamilika. Unaweza kuona hali ya majaribio chini ya majadiliano ya PR kwenye kiolesura cha GitHub. Endelea wakati majaribio yamekamilika.

️ Ongeza dokezo kuhusu kubahatisha kwa orodha ya hatua za CI

Orodha iliyotumiwa katika kozi hii ni ya kiholela na ya kibinafsi, tunapaswa kuongeza maelezo kuhusu hili.

️ Kazi: unda ombi la kuvuta maoni haya

1. Badilisha hadi tawi master.
2. Unda tawi linaloitwa bugfix.
3. Ongeza maandishi hadi mwisho wa faili 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. Fanya mabadiliko.
5. Chapisha thread bugfix kwa hazina ya mbali.
6. Unda ombi la kuvuta lililopewa jina Kuongeza maoni na tawi la kichwa bugfix na tawi la msingimaster.

Hakikisha umesakinisha master katika yake uma hazina Kama "tawi la msingi", sitajibu maombi ya mabadiliko kwenye hazina ya vifaa vya kozi.

Hivi ndivyo hazina yako inapaswa kuonekana kama.

Команды

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

Idhinisha ombi la kuvuta "Kuongeza maoni"

️ Kazi

1. Unda ombi la kuvuta.
2. Bonyeza "Unganisha ombi la kuvuta".
3. Bonyeza "Thibitisha kuunganisha".
4. Bofya "Futa tawi", hatuhitaji tena.

Huu ni mchoro wa ahadi baada ya kuunganishwa.

️ Endelea kufanya kazi na kuongeza vipimo

Kushirikiana kwenye ombi la kuvuta mara nyingi husababisha kazi ya ziada. Kawaida haya ni matokeo ya ukaguzi wa msimbo au majadiliano, lakini katika kozi yetu tutaiga hii kwa kuongeza vitu vipya kwenye orodha yetu ya hatua za CI.

Ujumuishaji unaoendelea kwa kawaida huhusisha ufunikaji wa majaribio. Mahitaji ya chanjo ya jaribio hutofautiana na kwa kawaida hupatikana katika hati inayoitwa kitu kama "miongozo ya michango". Tutaiweka rahisi na kuongeza jaribio kwa kila mstari katika orodha yetu ya ukaguzi.

Wakati wa kutekeleza kazi, jaribu kufanya majaribio kwanza. Ikiwa umewekwa kwa usahihi pre-commit ndoano mapema, mtihani mpya ulioongezwa utaendeshwa, utashindwa, na hakuna kitakachofanywa. Kumbuka kuwa hivi ndivyo tunavyojua kwamba majaribio yetu yanajaribu kitu. Inafurahisha, ikiwa tulianza na nambari kabla ya majaribio, kupitisha majaribio kunaweza kumaanisha kuwa nambari ilifanya kazi kama inavyotarajiwa, au kwamba majaribio hayakuwa yakijaribu chochote. Zaidi ya hayo, ikiwa hatungeandika majaribio hayo hapo awali, tungeweza kuwasahau kabisa, kwa kuwa hakuna kitu ambacho kingetukumbusha.

Maendeleo Yanayoendeshwa na Mtihani (TDD)

TDD inapendekeza uandike majaribio kabla ya msimbo. Mtiririko wa kawaida wa kazi kwa kutumia TDD inaonekana kama hii.

1. Ongeza mtihani.
2. Fanya majaribio yote na uhakikishe kuwa jaribio jipya halifaulu.
3. Andika msimbo.
4. Fanya vipimo, hakikisha vipimo vyote vinapita.
5. Rekebisha msimbo wako.
6. Rudia.

Kwa sababu matokeo ya majaribio ambayo hayakufaulu kawaida huonyeshwa kwa rangi nyekundu, na yale yaliyofaulu kawaida huonyeshwa kwa kijani, mzunguko huo pia hujulikana kama kiashiria-kijani-nyekundu.

️ Kazi

Kwanza, jaribu kufanya majaribio na kuwaacha washindwe, kisha ongeza na utoe maandishi ya orodha ya hatua ya CI yenyewe. Utaona kwamba vipimo vinapita ("kijani").
Kisha uchapishe nambari mpya kwenye hazina ya mbali na uangalie majaribio yanayoendeshwa kwenye kiolesura cha GitHub chini ya majadiliano ya ombi la kuvuta na sasisho la hali ya PR.

1. Badilisha hadi tawi feature.

2. Ongeza majaribio haya kwa ci.test.js baada ya simu ya mwisho 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. Jaribu kufanya majaribio. Kama pre-commit ndoano imewekwa, jaribio la kujitolea litashindwa.
4. Kisha ongeza maandishi haya kwa 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. Fanya na ufanye mabadiliko ndani ya nchi.
6. Chapisha mabadiliko kwenye tawi feature.

Unapaswa sasa kuwa na kitu kama hiki

Команды

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

Unganisha migogoro

Nenda kwa Badilisha Ombi Mapitio ya hatua.

Ingawa hatukufanya chochote kibaya na majaribio ya nambari yetu yamepita, bado hatuwezi kuunganisha tawi feature и master. Ni kwa sababu thread nyingine bugfix iliunganishwa na master tulipokuwa tukifanyia kazi hii PR.
Hii inaunda hali ambapo tawi la mbali master ina toleo jipya zaidi kuliko lile tuliloweka msingi wa tawi feature. Kwa sababu hii hatuwezi tu kurudisha nyuma HEAD master hadi mwisho wa thread feature. Katika hali hii, tunahitaji ama kuunganisha au kuomba ahadi feature weka upya master. GitHub inaweza kweli kuunganisha kiotomatiki ikiwa hakuna migogoro. Ole, katika hali yetu, matawi yote mawili yana mabadiliko ya kushindana kwenye faili ci.md. Hali hii inajulikana kama mzozo wa kuunganisha, na tunahitaji kuitatua sisi wenyewe.

Unganisha au uweke upya

Kuunganisha

• Huunda ahadi ya ziada ya kuunganisha na kuhifadhi historia ya kazi.
  • Huhifadhi ahadi za awali za matawi na mihuri yao ya awali ya nyakati na waandishi.
  • Huhifadhi SHA ya ahadi na viungo kwao katika mijadala ya ombi la mabadiliko.
• Inahitaji utatuzi wa migogoro ya mara moja.
• Hufanya hadithi isiwe ya mstari.
  • Hadithi inaweza kuwa ngumu kusoma kwa sababu ya idadi kubwa ya matawi (kukumbusha kebo ya IDE).
  • Hufanya utatuzi wa kiotomatiki kuwa mgumu zaidi, k.m. git bisect haifai sana - itapata tu ahadi ya kuunganisha.

Rudisha tena

• Marudio hujitolea kutoka kwa tawi la sasa juu ya tawi la msingi moja baada ya jingine.
  • Ahadi mpya zilizo na SHA mpya zinatolewa, na kusababisha ahadi katika GitHub kuendana na maombi ya asili ya kuvuta, lakini sio maoni yanayolingana.
  • Ahadi zinaweza kuunganishwa na kurekebishwa katika mchakato, au hata kuunganishwa kuwa moja.
• Mizozo mingi inaweza kuhitaji kutatuliwa.
• Inakuruhusu kudumisha hadithi ya mstari.
  • Hadithi inaweza kuwa rahisi kusoma mradi sio ndefu sana bila sababu nzuri.
  • Utatuzi otomatiki na utatuzi ni rahisi kidogo: hufanya iwezekanavyo git bisect, inaweza kufanya urejeshaji wa kiotomatiki kuwa wazi na kutabirika zaidi.
• Inahitaji kuchapisha tawi lililo na ahadi zilizohamishwa na bendera --force inapotumiwa na maombi ya kuvuta.

Kwa kawaida, timu hukubali kutumia mbinu sawa kila wakati zinapohitaji kuunganisha mabadiliko. Hii inaweza kuwa muunganisho "safi" au ahadi "safi" juu, au kitu katikati, kama vile kufanya ahadi ya juu kwa maingiliano(git rebase -i) ndani ya nchi kwa matawi ambayo hayajachapishwa kwenye hazina ya umma, lakini yanaunganishwa kwa matawi ya "umma".

Hapa tutatumia kuunganisha.

️ Kazi

1. Hakikisha msimbo uko katika tawi la karibu master imesasishwa kutoka kwa hifadhi ya mbali.
2. Badilisha hadi tawi feature.
3. Anzisha unganisho na tawi master. Mzozo wa kuunganisha kwa sababu ya mabadiliko shindani ya ci.md.
4. Tatua mzozo ili orodha yetu ya hatua za CI na dokezo kuuhusu zibaki kwenye maandishi.
5. Chapisha ahadi ya kuunganisha kwa tawi la mbali feature.
6. Angalia hali ya ombi la kuvuta kwenye GitHub UI na usubiri hadi muunganisho utatuliwe.

Команды

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

Kazi nzuri!

Umemaliza na orodha na sasa unahitaji kuidhinisha ombi la kuvuta ndani master.

️ Kazi: Idhinisha ombi la kuvuta "Mapitio ya hatua"

1. Fungua ombi la kuvuta.
2. Bonyeza "Unganisha ombi la kuvuta".
3. Bonyeza "Thibitisha kuunganisha".
4. Bonyeza "Futa tawi" kwani hatuitaji tena.

Hili ni hazina yako kwa sasa

Hitilafu ya bidhaa

Inasemekana kwamba “kupima kunaweza kutumiwa kuonyesha kuwepo kwa makosa, lakini kamwe kutoonyesha kutokuwepo kwao.” Ingawa tulikuwa na majaribio na hawakutuonyesha makosa, mdudu wa hila aliingia katika uzalishaji.

Katika hali kama hii, tunahitaji kutunza:

• ni nini kinachotumika katika uzalishaji;
• kanuni katika thread master na hitilafu, ambayo watengenezaji wanaweza kuanza kazi mpya.

Je, nirudishe nyuma au nirekebishe katika toleo linalofuata?

Kurudisha nyuma ni mchakato wa kupeleka toleo zuri la awali linalojulikana kwa uzalishaji na kurejesha ahadi zilizo na hitilafu. "Kurekebisha mbele" ni nyongeza ya kurekebisha master na kupeleka toleo jipya haraka iwezekanavyo. Kwa sababu API na miundo ya hifadhidata hubadilika jinsi msimbo unavyotumwa kwa uzalishaji, uwasilishaji unaoendelea na ufunikaji mzuri wa majaribio, kurejesha nyuma kwa kawaida ni ngumu zaidi na hatari kuliko kuirekebisha katika toleo linalofuata.

Kwa kuwa kurudi nyuma hakubeba hatari yoyote kwa upande wetu, tutaenda kwa njia hii, kwa sababu inaturuhusu

• kurekebisha kosa kwenye bidhaa haraka iwezekanavyo;
• weka kanuni ndani master mara moja inafaa kwa kuanza kazi mpya.

️ Kazi

1. Badilisha hadi tawi master kienyeji.
2. Sasisha hazina ya ndani kutoka kwa hazina ya mbali.
3. Rejesha ahadi ya kuunganisha PR Mapitio ya hatua в master.
4. Chapisha mabadiliko kwenye hazina ya mbali.

Hii ni historia ya hazina iliyo na ahadi ya kuunganisha iliyorejeshwa

Команды

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

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

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

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

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

️ Jipime

Hakikisha kwamba ci.md haina tena maandishi "mdudu mjanja" baada ya kurudisha ahadi ya kuunganisha.

Rekebisha orodha ya hatua za CI na uirudishe kwa bwana

Tumerejesha kabisa ahadi ya kuunganisha ya tawi. feature. Habari njema ni kwamba sasa hatuna makosa master. Habari mbaya ni kwamba orodha yetu ya thamani ya hatua za ujumuishaji endelevu pia imetoweka. Kwa hivyo, kwa kweli, tunahitaji kutumia urekebishaji kwa ahadi kutoka feature na kuwarudisha kwa master pamoja na kurekebisha.

Tunaweza kushughulikia shida kwa njia tofauti:

• rudisha ahadi ambayo inatengua unganisho feature с master;
• kuhama ahadi kutoka kwa zamani feature.

Timu tofauti za maendeleo hutumia mbinu tofauti katika kesi hii, lakini tutahamisha ahadi muhimu kwa tawi tofauti na kuunda ombi tofauti la kuvuta kwa tawi hili jipya.

️ Kazi

1. Unda thread inayoitwa feature-fix na kubadili kwake.

2. Hamisha ahadi zote kutoka kwa tawi la zamani feature kwa thread mpya. Tatua migogoro ya kuunganisha iliyotokea wakati wa uhamishaji.

   

3. Ongeza jaribio la urejeshaji kwa ci.test.js:

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

4. Fanya majaribio ndani yako ili kuhakikisha kuwa hayashindwi.
5. Ondoa maandishi "na mdudu mjanja" ndani ci.md.
6. Ongeza mabadiliko ya jaribio na mabadiliko ya orodha ya hatua kwenye faharasa na uyafanye.
7. Chapisha tawi kwenye hazina ya mbali.

Unapaswa kuishia na kitu kama hiki:

Команды

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

Unda ombi la kuvuta.

Unda ombi la kuvuta na kichwa Kurekebisha kipengele. Sakinisha feature-fix kama "tawi la kichwa" na master kama "tawi la msingi".
Tafadhali subiri wakati majaribio yanakamilika. Unaweza kuona hali ya majaribio chini ya majadiliano ya PR.

Hakikisha umesakinisha master katika yake uma hazina Kama "tawi la msingi", sitajibu maombi ya mabadiliko kwenye hazina ya vifaa vya kozi.

Idhinisha ombi la kuvuta "Kurekebisha kipengele"

Asante kwa kusahihisha! Tafadhali idhinisha mabadiliko kwa master kutoka kwa ombi la kuvuta.

️ Kazi

1. Bonyeza "Unganisha ombi la kuvuta".
2. Bonyeza "Thibitisha kuunganisha".
3. Bonyeza "Futa tawi" kwani hatuitaji tena.

Hii ndio unapaswa kuwa nayo kwa sasa.

Hongera!

Umekamilisha hatua zote ambazo kwa kawaida watu huchukua wakati wa ujumuishaji unaoendelea.

Ukigundua matatizo yoyote kwenye kozi au unajua jinsi ya kuiboresha, tafadhali fungua tatizo hazina zilizo na vifaa vya kozi. Kozi hii pia ina toleo la mwingiliano kutumia GitHub Learning Lab kama jukwaa.

Chanzo: mapenzi.com