Ĉu vi lernis Git-komandojn sed volas kompreni kiel Daŭra Integriĝo (CI) funkcias en realeco? Aŭ eble vi volas optimumigi viajn ĉiutagajn agadojn? Ĉi tiu kurso donos al vi praktikajn kapablojn en kontinua integriĝo uzante GitHub-deponejon. Ĉi tiu kurso ne celas esti sorĉisto, kiun vi povas simple alklaki, male, vi faros la samajn aferojn, kiujn homoj efektive faras en la laboro, same kiel ili faras ĝin. Mi klarigos la teorion dum vi trapasos la koncernajn paŝojn.

Kion ni faru?

Dum ni iras, ni iom post iom konstruos liston de tipaj CI-paŝoj, kio estas bonega maniero memori ĉi tiun liston. Alivorte, ni kreos liston de agadoj, kiujn programistoj plenumas kiam efektivigas kontinuan integriĝon, efektivigante kontinuan integriĝon. Ni ankaŭ uzos simplan testan aron por alproksimigi nian CI-procezon al la reala afero.

Ĉi tiu GIF skeme montras la kommitaĵojn en via deponejo dum vi progresas tra la kurso. Kiel vi povas vidi, estas nenio komplika kaj nur la plej necesa.

Vi ekzamenos la sekvajn normajn CI-scenarojn:

• Labori pri trajto;
• Apliko de aŭtotestoj por kvalito-certigo;
• Efektivigo de la prioritata tasko;
• Konfliktsolvado dum kunfandado de branĉoj (kunfandi konflikto);
• La okazo de eraro en produktadmedio.

Kion vi lernos?

Vi povos respondi demandojn kiel:

• Kio estas kontinua integriĝo (CI)?
• Kiuj specoj de aŭtotestoj estas uzataj en CI, kaj responde al kiaj agoj ili funkcias?
• Kio estas tirpeto kaj kiam ili bezonas?
• Kio estas Test Driven Development (TDD) kaj kiel ĝi rilatas al CI?
• Kunfandi aŭ apliki ŝanĝojn supre (rebazi)?
• Ĉu refari aŭ ripari en la sekva versio?

Komence mi tradukis aferojn kiel "pull request" ĉie, sed sekve mi decidis resendi frazojn en la angla kelkloke por malpliigi la gradon de frenezo en la teksto. Mi fojfoje uzos "programa surĵiko" kiel la fantazia verbo "demeti" kie homoj efektive uzas ĝin ĉe la laboro.

Kio estas kontinua integriĝo?

Kontinua Integriĝo, aŭ CI, estas teknika praktiko en kiu ĉiu grupano integras sian kodon en komunan deponejon almenaŭ unufoje tage, kaj la rezulta kodo almenaŭ devas konstrui sen eraroj.

Estas polemikoj pri ĉi tiu termino.

La punkto de disputo estas la ofteco de integriĝo. Iuj argumentas, ke kunfandi kodon unufoje tage ne sufiĉas por efektive integriĝi senĉese. Ekzemplo estas teamo kie ĉiuj prenas freŝan kodon matene kaj integriĝas unufoje vespere. Kvankam tio estas akceptebla obĵeto, estas ĝenerale kredite ke la difino de "unufoje tage" estas sufiĉe praktika, specifa, kaj taŭga por teamoj de malsamaj grandecoj.

Alia obĵeto estas ke C++ ne estis la nura lingvo uzita en evoluo por longa tempo, kaj simple postuli kunigon sen eraroj kiel validumadmetodo estas sufiĉe malforta. Aro de testoj (ekzemple, unutestoj funkcias loke) ankaŭ devas sukcesi. Nuntempe, la komunumo gravitas por fari tian postulon deviga, kaj en la estonteco, "konstruo + unuotestoj" verŝajne fariĝos kutima, se ĝi ne jam faris.

Kontinua Integriĝo diferencas de kontinua provizo (Kontinua Livero, KD) ĉar ĝi ne postulas eldonkandidaton post ĉiu integriĝociklo.

Listo de paŝoj, kiujn ni uzos dum la kurso

1. Enigu la lastan kodon. Kreu branĉon el master. Komencu labori.
2. Kreu komitojn sur via nova branĉo. Konstruu kaj provu loke. Pasi? Iru al la sekva paŝo. malsukcesi? Riparu erarojn aŭ provojn kaj provu denove.
3. Premu al via fora deponejo aŭ fora branĉo.
4. Kreu tiran peton. Diskutu la ŝanĝojn, aldonu pliajn kommitaĵojn dum diskuto daŭras. Faru testojn trapasi la ĉefbranĉon.
5. Kunfandi/rebazi komision de majstro. Faru provojn transdoni la kunfandan rezulton.
6. Deploji de la ĉefbranĉo al produktado.
7. Se ĉio estas bona en produktado dum iom da tempo, kunfandu ŝanĝojn al majstro.

️ Preparado

Certiĝu, ke vi havas la ĝustan programaron

Por preni ĉi tiun kurson vi bezonos node.js и Git-kliento.

Vi povas uzi ajnan Git-klienton, sed mi listigos nur komandojn por la komandlinio.

Certigu, ke vi havas Git-klienton instalitan, kiu subtenas la komandlinion

Se vi ne jam havas komandlinian Git-klienton instalitan, vi povas trovi instalinstrukciojn ĉi tie. tie.

Preparu la deponejon

Vi devos krei personan kopion (forko) deponejo-ŝablono kun la kodo por la kurso sur GitHub. Ni konsentu nomi ĉi tiun personan kopion kursdeponejo.

Farita? Se vi ne ŝanĝis la defaŭltajn agordojn, via kursa deponejo plej verŝajne estas nomita continuous-integration-team-scenarios-students, ĝi estas en via GitHub-konto kaj la URL aspektas tiel

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

Mi simple vokos ĉi tiun adreson <URL репозитория>.

angulaj krampoj kiel <тут> signifos, ke vi devas anstataŭigi tian esprimon per la responda valoro.

Certigu tion GitHub-agoj ebligita por ĉi tiu kursa deponejo. Se ili ne estas ebligitaj, bonvolu ebligi ilin alklakante la grandan butonon en la mezo de la paĝo, kiun vi povas aliri alklakante Agojn en la GitHub-interfaco.

Vi ne povos kompletigi la kurson laŭ miaj instrukcioj krom se GitHub-Agoj estas ebligitaj.

Vi ĉiam povas uzi la kapablon de GitHub montri Markdown por vidi la nunan staton de la listo, kiun ni komponas, ĉi tie

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

Pri respondoj

Kvankam la plej bona maniero por kompletigi ĉi tiun kurson estas fari ĝin mem, vi eble trovos ĝin malfacile plenumi.

Se vi sentas, ke vi ne komprenas kion fari kaj ne povas daŭrigi, vi povas rigardi en la fadenon solution, kiu estas en via komenca deponejo.
Bonvolu ne kunfandi solution в master dum la kurso. Vi povas uzi ĉi tiun branĉon por eltrovi kion fari, aŭ por kompari vian kodon kun tiu de la aŭtoro, uzante ĉiujn eblecojn, kiujn Git donas al ni. Se vi estas tute perdita, vi povas tute anstataŭigi vian branĉon master sur branĉo solution kaj poste restarigi vian labordosierujon al la kurso, kiun vi volas.

Uzu ĉi tion nur se vi vere bezonas ĝin.

Faru vian kodon

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

Ĉi tiuj komandoj

• renomi master в master-backup;
• renomi solution в master;
• ŝanĝu (elaĉeton) al nova branĉo master kaj anstataŭigu la enhavon de la labordosierujo;
• kreu branĉon "solvo" el "majstro" (kiu antaŭe estis "solvo"), se vi bezonos branĉon "solvo" estonte.

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

Post ĉi tiuj paŝoj, vi povas uzi git log master por eltrovi kian devontigon vi bezonas.
Vi povas restarigi vian labordosierujon al ĉi tiu kommit tiel:

git reset --hard <the SHA you need>

Se vi estas kontenta pri la rezulto, iam vi devos publikigi vian version de la deponejo al fora deponejo (fora). Ne forgesu eksplicite specifi la malproksiman branĉon kiam vi faras tion.

git push --force origin master

Bonvolu noti, ke ni uzas git push --force. Vi verŝajne ne volas fari tion tre ofte, sed ni havas tre specifan scenaron ĉi tie kun unu uzanto de la deponejo, kiu, krome, komprenas kion li faras.

Komencante labori

Ni komencu kompili nian liston de CI-paŝoj. Vi kutime komencas ĉi tiun paŝon tirante la plej novan kodon de fora deponejo, sed ni ankoraŭ ne havas lokan deponejon, do ni klonas ĝin de fora deponejo anstataŭe.

️ Tasko: ĝisdatigi lokan deponejon, krei branĉon el master, eklaboru

1. Klonu la kursdeponejon de <URL репозитория>.
2. Kuri npm install en la dosierujo de la kurso; ni bezonas ĝin por instali Jest, kiun ni uzas por ruli testojn.
3. Kreu branĉon kaj nomu ĝin feature. Ŝanĝu al ĉi tiu fadeno.

4. Aldonu testan kodon al ci.test.js inter komentoj petantaj vin fari tion.

   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. Aldonu tekston kun la unuaj 4 paŝoj al dosiero 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.  

   Teamoj

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

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

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

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

Kreu komitojn sur nova branĉo, konstruu kaj provu loke

Ni tuj starigos la testojn por kuri antaŭ la kompromiso, kaj poste fari la kodon.

Tipaj Scenaroj Kiam Testoj Kuras Aŭtomate

• Loke:
  • Daŭre aŭ en respondo al taŭgaj kodŝanĝoj;
  • Sur konservado (por interpretitaj aŭ JIT-kompilitaj lingvoj);
  • Sur konstruo (kiam kompilo estas postulata);
  • Sur kompromiso;
  • Dum publikigado al komuna deponejo.

• Sur la konstruservilo aŭ konstrumedio:
  • Kiam kodo estas publikigita al persona branĉo/deponejo.
  • La kodo en ĉi tiu fadeno estas testata.
  • Ebla kunfandrezulto estas testita (kutime kun master).
  • Kiel kontinua integriga paŝo/kontinua livera dukto

Ĝenerale, ju pli rapide funkcias testaro, des pli ofte vi povas pagi ĝin funkciigi. Tipa surscenigo povus aspekti tiel.

• Rapidaj unutestoj - ĉe konstruo, en CI-dukto
• Malrapidaj unuotestoj, rapidaj komponentaj kaj integrigaj testoj - ĉe kommit, en la CI-dukto
• Malrapidaj komponentaj kaj integrigaj testoj - en la CI-dukto
• Sekureca testado, ŝarĝo-testado kaj aliaj longaj aŭ multekostaj provoj - en CI/KD-duktoj, sed nur en certaj reĝimoj/etapoj/konstruo-duktoj, ekzemple, kiam oni preparas eldonkandidaton aŭ kiam oni komencas mane.

️ Serĉo

Mi proponas unue ruli la testojn permane uzante la komandon npm test. Post tio, ni aldonu git-hokon por ruli niajn testojn sur commit. Estas unu kapto: Git-hokoj ne estas konsiderataj parto de la deponejo kaj tial ne povas esti klonitaj de GitHub kune kun la resto de la kursenhavo. Por instali hokon vi devas kuri install_hook.sh aŭ kopii dosieron repo/hooks/pre-commit al loka adresaro .git/hooks/.
Kiam vi faras, vi vidos, ke la testoj estas rulitaj kaj ili kontrolas ĉu iuj ŝlosilvortoj ĉeestas en la listo.

1. Rulu la testojn permane rulante la komandon npm test en via kursa dosierujo. Kontrolu, ke la testoj estis rulitaj.
2. Instalu kommit-hokon (antaŭ-kommit-hokon) per kurado install_hook.sh.
3. Faru la ŝanĝojn al la loka deponejo.
4. Certigu, ke la testoj estas rulitaj antaŭ la transdono.

Via deponejo devus aspekti tiel post plenumi ĉi tiujn paŝojn.

Teamoj

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

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

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

Eldonu kodon al fora deponejo aŭ fora branĉo

Post finlaboro surloke, programistoj kutime publikigas sian kodon por ke ĝi eventuale estu integrita kun la publiko. Kun GitHub, ĉi tio estas kutime atingita per publikigado de la laboro aŭ al persona kopio de la deponejo (persona forko, forko) aŭ al persona branĉo.

• Per forkoj, la programisto klonas la malproksiman komunan deponejon, kreante personan malproksiman kopion de ĝi, ankaŭ konatan kiel forko. Post tio, li klonas ĉi tiun personan deponejon por ke li povu labori kun ĝi loke. Kiam la laboro estas farita kaj la kommits estas kreitaj, li metas ilin en sian forkon, kie ili estas haveblaj al aliaj kaj povas esti integritaj en komunan deponejon. Ĉi tiu aliro estas ofte uzata en malfermfontaj projektoj sur GitHub. Ĝi ankaŭ estas uzata en mia progresinta kurso [Teamlaboro kaj CI kun Git] (http://devops.redpill.solutions/).
• Alia aliro estas uzi nur unu malproksiman deponejon kaj nur nombri la branĉon master la komuna deponejo estas "protektita". En ĉi tiu scenaro, individuaj programistoj publikigas sian kodon al la branĉoj de la fora deponejo por ke aliaj povu vidi ĉi tiun kodon, se ĉio estas en ordo, kunfandiĝu kun master komuna deponejo.

En ĉi tiu aparta kurso, ni uzos laborfluon, kiu uzas branĉojn.

Ni publikigu nian kodon.

️ Serĉo

• Afiŝu ŝanĝojn al fora branĉo kun la sama nomo kiel via laborbranĉo

Teamoj

git push --set-upstream origin feature

Kreu tiran peton

Kreu tiran peton kun titolo Revizio de paŝoj... Instali feature kiel "kapbranĉo" kaj master kiel "baza branĉo".

Certiĝu, ke vi instalis master en sia deponejo forko kiel "baza branĉo", mi ne respondos al ŝanĝpetoj al la kursenhava deponejo.

En slango de GitHub, "baza branĉo" estas la branĉo sur kiu vi bazas vian laboron, kaj "kapa branĉo" estas la branĉo enhavanta la proponitajn ŝanĝojn.

Diskutu ŝanĝojn, aldonu novajn kommitaĵojn dum diskuto daŭras

Tiro-peto (PR)

Tiro-peto (PR) estas maniero diskuti kaj dokumenti kodon, kaj ankaŭ fari kodan revizion. Tirpetoj estas nomitaj laŭ la ĝenerala maniero kiel individuaj ŝanĝoj estas integritaj en la totalan kodon. Kutime persono klonas malproksiman oficialan projekt-deponejon kaj laboras pri la kodo loke. Post tio, li metas la kodon en sian personan malproksiman deponejon kaj petas al la respondecaj pri la oficiala deponejo preni ĝin (tiri) ĝia kodo al iliaj lokaj deponejoj kie ili revizias kaj eventuale integras (iri) lia. Ĉi tiu koncepto ankaŭ estas konata sub aliaj nomoj, ekzemple, kunfandi peton.

Fakte, vi ne devas uzi la tirpeton de GitHub aŭ similaj platformoj. Evoluigaj teamoj povas uzi aliajn komunikilojn, inkluzive de vizaĝ-al-vizaĝa komunikado, voĉvokoj aŭ retpoŝto, sed ankoraŭ ekzistas kelkaj kialoj por uzi tiajn forum-stilajn tirpetojn. Jen kelkaj el ili:

• organizitaj diskutoj rilataj al specifaj ŝanĝoj en la kodo;
• kiel loko por vidi komentojn pri laboro en progreso de kaj aŭtotestoj kaj kunuloj;
• formaligo de kodaj kontroloj;
• por ke vi poste eksciu la kialojn kaj konsiderojn malantaŭ tiu aŭ alia kodo.

Kutime vi kreas tiran peton kiam vi bezonas diskuti ion aŭ ricevi komentojn. Ekzemple, se vi laboras pri funkcio kiu povas esti efektivigita en pluraj manieroj, vi povas krei tiran peton antaŭ ol la unua linio de kodo estas skribita por kunhavi viajn ideojn kaj diskuti viajn planojn kun kunlaborantoj. Se la laboro estas pli simpla, tira peto estas malfermita kiam io jam estas farita, farita kaj diskutebla. En iuj scenaroj, vi eble volas malfermi PR nur pro kvalitkontrolaj kialoj: por fari aŭtomatigitajn testojn aŭ komenci kodajn recenzojn. Kion ajn vi decidas, ne forgesu @mencii la homojn, kiujn vi volas aprobon en via tira peto.

Kutime, kreante PR, vi faras la jenon.

• Indiku kion vi proponas ŝanĝi kaj kie.
• Skribu priskribon klarigante la celon de la ŝanĝo. Vi eble volas:
  • aldonu ion gravan, kiu ne estas evidenta el la kodo, aŭ ion utilan por kompreni la kuntekston, kiel koncernajn #cimojn kaj kommit-numerojn;
  • @menciu iun ajn kun kiu vi volas labori, aŭ vi povas @mencii ilin en la komentoj poste;
  • petu kolegojn helpi pri io aŭ kontroli ion specifan.

Post kiam vi malfermas PR, la testoj agorditaj por funkcii en tiaj kazoj estas ekzekutitaj. En nia kazo, ĉi tio estos la sama testaro, kiun ni kuris loke, sed povas esti pliaj testoj kaj kontroloj en reala projekto.

Bonvolu atendi dum la testoj finiĝas. Vi povas vidi la staton de la testoj ĉe la fundo de la PR-fadeno en la GitHub-interfaco. Daŭrigu kiam la provoj finiĝos.

️ Aldonu noton pri la arbitreco de la listo de CI-paŝoj

La listo uzata en ĉi tiu kurso estas arbitra kaj subjektiva, ni devas aldoni noton pri tio.

️ Defio: Kreu tiran peton por ĉi tiu noto

1. Ŝanĝu al branĉo master.
2. Kreu branĉon nomitan bugfix.
3. Aldonu notan tekston al la fino de la dosiero 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. Faru la ŝanĝojn.
5. Eldoni branĉon bugfix al fora deponejo.
6. Kreu tiran peton nomitan Aldonante rimarkon kun kapobranĉo bugfix kaj baza branĉomaster.

Certiĝu, ke vi instalis master en sia deponejo forko kiel "baza branĉo", mi ne respondos al ŝanĝpetoj al la kursenhava deponejo.

Jen kiel via deponejo devus aspekti.

Teamoj

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

Aprobas la tiran peton "Aldonante rimarkon"

️ Serĉo

1. Kreu tiran peton.
2. Alklaku "Kunfandi tirpeton".
3. Alklaku "Konfirmu kunfandi".
4. Alklaku "Forigi branĉon", ni ne plu bezonas ĝin.

Ĉi tio estas diagramo de la kommits post la kunfando.

️ Daŭre laboru kaj aldonu testojn

Kunlabori pri tira peto ofte rezultigas pli da laboro. Ĉi tio kutime estas la rezulto de koda revizio aŭ diskuto, sed en nia kurso ni modelos ĉi tion aldonante novajn erojn al nia listo de CI-paŝoj.

Kun kontinua integriĝo, iu testpriraportado estas kutime aplikata. Testaj kovropostuloj varias kaj estas kutime trovitaj en dokumento kun titolo kiel "kontribuaj gvidlinioj". Ni iros facile kaj aldonos teston por ĉiu linio en nia kontrolo.

Dum rulado de laboroj, unue provu fari la testojn. Se vi instalis ĝuste pre-commit hoko antaŭe, la lastatempe aldonita testo funkcios, malsukcesos, kaj nenio estos farita. Notu, ke jen kiel ni scias, ke niaj testoj efektive testas ion. Kurioze, se ni komencus per la kodo antaŭ la testoj, trapasi la testojn povus aŭ signifi, ke la kodo funkcias kiel atendite, aŭ ke la testoj fakte ne provas ion ajn. Ankaŭ, se ni unue ne skribus la testojn, ni eble tute forgesus ilin, ĉar nenio rememorigus pri tio.

Testa Disvolvita (TDD)

TDD rekomendas verki testojn antaŭ kodo. Tipa laborfluo uzanta TDD aspektas tiel.

1. Aldonu teston.
2. Rulu ĉiujn provojn kaj kontrolu, ke la nova testo malsukcesas.
3. Skribu kodon.
4. Faru provojn, certigu, ke ĉiuj testoj trapasas.
5. Refaktoru vian kodon.
6. Ripeti.

Ĉar testrezultoj kiuj malsukcesas estas tipe montritaj en ruĝa, kaj testoj kiuj trapasas estas montritaj en verda, la ciklo ankaŭ estas konata kiel ruĝa-verda-refaktoro.

️ Serĉo

Unue provu fari la testojn kaj lasi ilin malsukcesi, poste aldonu kaj transdonu la CI-paŝan listtekston mem. Vi vidos, ke la testoj trapasas ("verdaj").
Poste publikigu la novan kodon al fora deponejo kaj rigardu, ke la testoj funkcias en la GitHub-interfaco ĉe la fundo de la traktado pri tirado kaj la PR-statuso estas ĝisdatigita.

1. Ŝanĝu al branĉo feature.

2. Aldonu ĉi tiujn provojn al ci.test.js post la lasta voko 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. Provu fari la provojn. Se pre-commit hoko estas fiksita, la provo malsukcesos.
4. Poste aldonu ĉi tiun tekston al 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. Faru kaj faru ŝanĝojn loke.
6. Afiŝu ŝanĝojn al branĉo feature.

Nun vi devus havi ion tian

Teamoj

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

Kunfandi konflikton

Iru por ŝanĝi peton Revizio de paŝoj.

Kvankam ni faris nenion malbonan kaj la testoj por nia kodo pasis, ni ankoraŭ ne povas kunfandi la branĉon. feature и master. Ĉi tio estas ĉar la alia fadeno bugfix estis kunfandita kun master dum ni laboris pri ĉi tiu PR.
Ĉi tio kreas situacion kie la malproksima branĉo master havas pli novan version ol tiu, sur kiu ni bazigis la branĉon feature. Pro tio, ni ne povas simple rebobeni HEAD master ĝis la fino de la branĉo feature. En ĉi tiu situacio, ni devas aŭ kunfandi aŭ apliki kommits feature super(rebazo) master. GitHub efektive povas fari aŭtomatan kunfandiĝon se ne ekzistas konfliktoj. Ve, en nia situacio, ambaŭ branĉoj havas konkurantajn ŝanĝojn en la dosiero ci.md. Ĉi tiu situacio estas konata kiel kunfanda konflikto kaj ni devas solvi ĝin permane.

Kunfandi aŭ rebazi

Kunfandi

• Kreas plian kunfanan komision kaj konservas la laborhistorion.
  • Konservas la originajn branĉojn kun siaj originaj tempomarkoj kaj aŭtoroj.
  • Stokas la kommit SHA-ojn kaj ligilojn al kommits en ŝanĝpetodiskutoj.
• Postulas unufojan konfliktsolvon.
• Faras la rakonton nelinia.
  • La historio povas esti malfacile legebla pro la granda nombro da branĉoj (memorigas min pri IDE-kablo).
  • Malfaciligas aŭtomatan elpurigon, ekzemple, fari git bisect malpli utila - ĝi nur trovos la merge-kommit.

Rebazi

• Ripetoj de la nuna branĉo super la bazo unu post la alia.
  • Novaj komitaĵoj estas generitaj kun novaj SHA-oj, igante GitHub-komisiojn kongrui kun la originaj tiraj petoj sed ne kun la respondaj komentoj.
  • Commits povas esti rekombinitaj kaj ŝanĝitaj en la procezo, aŭ eĉ kunfanditaj en unu.
• Vi eble bezonos solvi plurajn konfliktojn.
• Ebligas al vi konservi linearan historion.
  • La rakonto povas esti pli facile legebla, kondiĉe ke ĝi ne estas tro longa sen bona kialo.
  • Aŭtomata senararigado kaj solvi problemojn estas iom pli facila: ebligas ĝin git bisect, povas fari aŭtomatajn retrovojojn pli klaraj kaj antaŭvideblaj.
• Postulas publikigi branĉon kun revertitaj komitaĵoj kun flago --force kiam uzata kun ŝanĝpetoj.

Teamoj kutime konsentas ĉiam uzi la saman strategion kiam ili bezonas kunfandi ŝanĝojn. Ĉi tio povas esti "pura" kunfandiĝo aŭ "pura" transdono supre, aŭ io intere, kiel fari kommit super interaga reĝimo (git rebase -i) loke por branĉoj ne publikigitaj al komuna deponejo, sed kunfandi por "publikaj" branĉoj.

Ĉi tie ni uzos kunfandi.

️ Serĉo

1. Certigu, ke la kodo estas en la loka branĉo master ĝisdatigita de fora deponejo.
2. Ŝanĝu al branĉo feature.
3. Komencu kunfandiĝon kun branĉo master. Kunfanda konflikto estos raportita pro konkurantaj ŝanĝoj en ci.md.
4. Solvu la konflikton por ke kaj nia listo de CI-paŝoj kaj noto pri ĝi restu en la teksto.
5. Afiŝu kunfandan devontigon al fora branĉo feature.
6. Kontrolu la staton de la tirpeto en la GitHub UI, atendu ĝis la kunfando estas solvita.

Teamoj

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

Bonega laboro!

Vi finis kun la listo kaj nun vi devas aprobi la tirpeton enen master.

️ Tasko: Aprobas la tiran peton "Revizio de Paŝoj"

1. Malfermu tirpeton.
2. Alklaku "Kunfandi tirpeton".
3. Alklaku "Konfirmu kunfandi".
4. Alklaku "Forigi branĉon" ĉar ni ne plu bezonas ĝin.

Ĉi tiu estas via deponejo nuntempe

Produkta eraro

Ili diras ke "testado povas esti uzata por montri la ĉeeston de eraroj, sed neniam por montri ilian foreston." Malgraŭ tio, ke ni havis testojn kaj ili ne montris al ni erarojn, insida eraro ŝteliris en produktadon.

En scenaro kiel ĉi tiu, ni devas prizorgi:

• tio estas deplojita sur la produktiva;
• filiokodo master kun eraro, de kiu programistoj povas komenci novan laboron.

Ĉu refari aŭ ripari en la sekva versio?

"Reruliĝado" estas la ago de deploji konatan bonan pli fruan version al produktadmedio kaj restarigi la kommitaĵojn kiuj enhavas la eraron. "Fiksi antaŭen" estas la aldono de riparo al master kaj deplojante la novan version kiel eble plej baldaŭ. Ĉar APIoj kaj datumbazaj skemoj ŝanĝiĝas dum kodo estas deplojita al produktado, kun kontinua livero kaj bona testa priraportado, refari estas ĝenerale multe pli malfacila kaj riska ol ripari en la venonta eldono.

Ĉar ruliĝi reen ne portas neniun riskon en nia kazo, ni iros ĉi tiun vojon, ĉar ĝi permesas al ni

• ripari la cimon sur la produktado kiel eble plej baldaŭ;
• enigi kodon master tuj preta komenci novan laboron.

️ Serĉo

1. Ŝanĝu al branĉo master loke.
2. Ĝisdatigu la lokan deponejon de la fora deponejo.
3. Reverti la PR-kunfandan devontigon Revizio de paŝoj в master.
4. Publikigi ŝanĝojn al fora deponejo.

Ĉi tio estas la historio de la deponejo kun la kunfanda komito revenita

Teamoj

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

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

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

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

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

️ Memkontrolo

Certigu tion ci.md ne plu enhavas la tekston "sneaky bug" post kunfandado estas revertita.

Riparu CI-paŝliston kaj revenu al majstro

Ni tute revertis la branĉon kunfandi kommit feature. La bona novaĵo estas, ke nun ni ne havas eraron master. La malbona novaĵo estas, ke nia altvalora listo de kontinuaj integriĝaj paŝoj ankaŭ malaperis. Do, ideale, ni volas apliki la riparo al la kommits de feature kaj resendu ilin al master kune kun la riparo.

Ni povas trakti la problemon en malsamaj manieroj:

• reverti la kommit, kiu renversas la kunfadon feature с master;
• migri faras de la unua feature.

Malsamaj evoluigaj teamoj prenas malsamajn alirojn en ĉi tiu kazo, sed ni movos utilajn komitojn al aparta branĉo kaj kreos apartan tirpeton por ĉi tiu nova branĉo.

️ Serĉo

1. Kreu branĉon nomitan feature-fix kaj ŝanĝu al ĝi.

2. Migri ĉiujn komitaĵojn el la antaŭa branĉo feature al nova fadeno. Solvu kunfandikonfliktojn kiuj okazis dum la migrado.

   

3. Aldonu regresteston al ci.test.js:

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

4. Rulu la testojn loke por certigi, ke ili ne sukcesas sukcese.
5. Forigu la tekston "kun ruza cimo" en ci.md.
6. Aldonu testajn ŝanĝojn kaj ŝanĝojn al la listo de paŝoj al la indekso kaj faru ilin.
7. Eldonu la branĉon al la fora deponejo.

Vi devus fini kun io simila

Teamoj

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

Kreu tiran peton.

Kreu tiran peton kun titolo Ripari la funkcion... Instali feature-fix kiel "kapbranĉo", kaj master kiel "baza branĉo".
Bonvolu atendi dum la testoj finiĝas. Vi povas vidi la staton de la testoj ĉe la fundo de la PR-diskuto.

Certiĝu, ke vi instalis master en sia deponejo forko kiel "baza branĉo", mi ne respondos al ŝanĝpetoj al la kursenhava deponejo.

Aprobas la tiran peton "Ripari la funkcion"

Dankon pro korekto! Bonvolu aprobi la ŝanĝojn en master de tirpeto.

️ Serĉo

1. Alklaku "Kunfandi tirpeton".
2. Alklaku "Konfirmu kunfandi".
3. Alklaku "Forigi branĉon" ĉar ni ne plu bezonas ĝin.

Jen kion vi devus havi nun.

Gratulon!

Vi plenumis ĉiujn paŝojn, kiujn homoj kutime faras en kontinua integriga procezo.

Se vi rimarkas problemojn kun la kurso aŭ scias kiel plibonigi ĝin, bonvolu krei problemon en kursenhavaj deponejoj. Ĉi tiu kurso ankaŭ havas interaga versio uzante GitHub Learning Lab kiel platformon.

fonto: www.habr.com