Oletko oppinut Git-komentoja, mutta haluat kuvitella, kuinka jatkuva integrointi (CI) toimii todellisuudessa? Tai ehkä haluat optimoida päivittäisiä toimintojasi? Tämä kurssi antaa sinulle käytännön taitoja jatkuvaan integrointiin GitHub-tietovaraston avulla. Tätä kurssia ei ole tarkoitettu ohjatuksi, jota voit vain napsauttaa, vaan päinvastoin, suoritat samoja toimintoja, joita ihmiset todella tekevät töissä, samalla tavalla kuin he tekevät sen. Selitän teorian, kun käyt läpi vaiheet.

Mitä me teemme?

Edistyessämme luomme vähitellen luettelon tyypillisistä CI-vaiheista, mikä on loistava tapa muistaa tämä luettelo. Toisin sanoen luomme luettelon toimista, joita kehittäjät tekevät jatkuvan integroinnin, jatkuvan integroinnin aikana. Käytämme myös yksinkertaista testisarjaa tuodaksemme CI-prosessimme lähemmäksi todellista.

Tämä GIF näyttää kaavamaisesti arkistosi sitoumukset, kun etenet kurssin läpi. Kuten näet, tässä ei ole mitään monimutkaista ja vain kaikkein tarpeellisin.

Käyt läpi seuraavat vakio-CI-skenaariot:

• Työskentele ominaisuuden parissa;
• Automatisoitujen testien soveltaminen laadun varmistamiseksi;
• Ensisijaisen tehtävän toteuttaminen;
• Ristiriitojen ratkaisu haarakonttoreiden yhdistämisen yhteydessä (yhdistyskonflikti);
• Tuotantoympäristössä tapahtuu virhe.

Mitä opit?

Pystyt vastaamaan seuraaviin kysymyksiin:

• Mikä on jatkuva integrointi (CI)?
• Millaisia ​​automatisoituja testejä CI:ssä käytetään ja mihin toimiin ne käynnistetään?
• Mitä vetopyynnöt ovat ja milloin niitä tarvitaan?
• Mikä on Test Driven Development (TDD) ja miten se liittyy CI:ään?
• Pitäisikö minun yhdistää vai perustaa muutokset uudelleen?
• Palautetaanko vai korjataanko se seuraavassa versiossa?

Aluksi käänsin kaikkialla asioita, kuten "pull requests", mutta sen seurauksena päätin palauttaa paikoin englanninkielisiä lauseita vähentääkseni tekstin hulluutta. Käytän joskus "ohjelmoija surzhikia" kuten ihanaa verbiä "sitoutua", kun ihmiset todella käyttävät sitä töissä.

Mitä jatkuva integraatio on?

Jatkuva integraatioCI eli CI on tekninen käytäntö, jossa jokainen tiimin jäsen integroi koodinsa yhteiseen tietovarastoon vähintään kerran päivässä, ja tuloksena oleva koodi on rakennettava vähintään virheettömästi.

Tästä termistä on erimielisyyksiä

Kiistanalainen on integroinnin tiheys. Jotkut väittävät, että koodin yhdistäminen vain kerran päivässä ei riitä jatkuvaan integrointiin. Esimerkki on tiimi, jossa jokainen ottaa tuoreen koodin aamulla ja integroi sen kerran illalla. Vaikka tämä on kohtuullinen vastalause, on yleisesti hyväksyttyä, että kerran päivässä -määritelmä on kohtuullisen käytännöllinen, täsmällinen ja sopii erikokoisille ryhmille.

Toinen vastalause on, että C++ ei ole enää ainoa kehityksessä käytetty kieli, ja pelkkä virheettömän kokoonpanon vaatiminen validointikeinona on heikkoa. Jotkin testit (esimerkiksi paikallisesti suoritetut yksikkötestit) on myös suoritettava onnistuneesti. Tällä hetkellä yhteisössä ollaan menossa kohti tämän vaatimista, ja jatkossa "build + unit testeistä" tulee luultavasti yleinen käytäntö, ellei ole vielä käynyt.

Jatkuva integraatio eroaa jatkuva toimitus (Continuous Delivery, CD) siinä mielessä, että se ei vaadi julkaisuehdokasta jokaisen integrointijakson jälkeen.

Luettelo vaiheista, joita käytämme koko kurssin ajan

1. Vedä uusin koodi sisään. Luo haara kohteesta master. Aloittaa työt.
2. Luo sitoumuksia uudelle haarallesi. Rakenna ja testaa paikallisesti. Kulkea? Siirry seuraavaan vaiheeseen. Epäonnistuuko? Korjaa virheet tai testit ja yritä uudelleen.
3. Työnnä etätietovarastoon tai etähaaraan.
4. Luo vetopyyntö. Keskustele muutoksista, lisää sitoumuksia keskustelun jatkuessa. Anna testien läpäistä ominaisuushaara.
5. Yhdistä/rebase sitoutuu isännältä. Anna testien välittää yhdistämistulos.
6. Ota käyttöön ominaisuushaaralta tuotantoon.
7. Jos kaikki on kunnossa tuotannossa jonkin aikaa, yhdistä muutokset masteriin.

️ Valmistelu

Varmista, että sinulla on oikea ohjelmisto

Tämän kurssin suorittamiseksi tarvitset Node.js и Hanki asiakas.

Voit käyttää mitä tahansa Git-asiakasta, mutta annan vain komennot komentoriville.

Varmista, että sinulla on asennettuna Git-asiakas, joka tukee komentoriviä

Jos sinulla ei vielä ole komentoriviä tukevaa Git-asiakasta, löydät asennusohjeet täällä.

Valmistele arkisto

Sinun on luotava henkilökohtainen kopio (haarukka) mallivarasto kurssin koodilla GitHubissa. Sovitaan, että tätä henkilökohtaista kopiota kutsutaan kurssivarasto.

Tehty? Jos et ole muuttanut oletusasetuksia, kurssivarastoa kutsutaan todennäköisesti continuous-integration-team-scenarios-students, se sijaitsee GitHub-tililläsi ja URL-osoite näyttää tältä

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

Soitan vain tähän osoitteeseen <URL репозитория>.

Kulmakiinnikkeet kuten <тут> tarkoittaa, että sinun on korvattava tällainen lauseke sopivalla arvolla.

Varmista että GitHub-toiminnot sisältyy tähän kurssivarastoon. Jos ne eivät ole käytössä, ota ne käyttöön napsauttamalla sivun keskellä olevaa suurta painiketta, johon pääset napsauttamalla GitHub-käyttöliittymän Toiminnot.

Et voi suorittaa kurssia ohjeideni mukaisesti, jos GitHub-toiminnot eivät ole käytössä.

Voit aina käyttää GitHubin kykyä renderöidä Markdown nähdäksesi tässä laatimamme luettelon nykyisen tilan

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

Tietoja vastauksista

Vaikka paras tapa suorittaa tämä kurssi on tehdä se itse, sinulla voi olla vaikeuksia.

Jos sinusta tuntuu, että et ymmärrä mitä tehdä, etkä voi jatkaa, voit tarkastella ketjua solution, joka on aloitusarkistossasi.
Älä yhdistä solution в master kurssin aikana. Voit käyttää tätä haaraa selvittääksesi, mitä tehdä, tai vertailla koodiasi kirjoittajan koodiin käyttämällä kaikkia Gitin meille tarjoamia ominaisuuksia. Jos olet täysin eksyksissä, voit korvata haarasi kokonaan master oksalla solution ja palauta sitten työhakemistosi tarvitsemaasi kurssivaiheeseen.

Käytä tätä vain, jos todella tarvitset sitä

Sitouta koodisi

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

Nämä komennot

• nimeä uudelleen master в master-backup;
• nimeä uudelleen solution в master;
• kassa uuteen konttoriin master ja kirjoittaa uudelleen työhakemiston sisältö;
• Luo "ratkaisu"-haara "masterista" (joka oli ennen "ratkaisu") siltä varalta, että tarvitset "ratkaisu"-haaran tulevaisuudessa.

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

Näiden vaiheiden jälkeen voit käyttää git log master selvittääksesi minkä sitoumuksen tarvitset.
Voit nollata työhakemistosi tähän sitoumukseen seuraavasti:

git reset --hard <the SHA you need>

Jos olet tyytyväinen tulokseen, sinun on jossain vaiheessa julkaistava versiosi arkistosta etätietovarastoon. Älä unohda erikseen määrittää etähaaraa, kun teet tämän.

git push --force origin master

Huomaa, että käytämme git push --force. On epätodennäköistä, että haluat tehdä tämän kovin usein, mutta meillä on tässä hyvin erityinen skenaario yhden arkiston käyttäjän kanssa, joka lisäksi ymmärtää mitä tekee.

Työn aloittaminen

Aloitetaan CI-vaiheiden luettelon laatiminen. Normaalisti aloitat tämän vaiheen tarkistamalla koodin uusimman version etävarastosta, mutta meillä ei vielä ole paikallista arkistoa, joten kloonaamme sen etävarastosta.

️ Tehtävä: päivitä paikallinen arkisto, luo haara siitä master, aloittaa työt

1. Kloonaa kurssin arkisto kohteesta <URL репозитория>.
2. Juosta npm install kurssin arkistohakemistossa; Tarvitsemme sen Jestin asentamiseen, jota käytämme testien suorittamiseen.
3. Luo haara ja nimeä se feature. Vaihda tähän ketjuun.

4. Lisää testikoodi ci.test.js kommenttien välillä, joissa minua pyydetään tekemään tämä.

   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. Lisää tiedostoon teksti, jossa on ensimmäiset 4 vaihetta 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.  

   komennot

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

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

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

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

Luo sitoumuksia uudelle haaralle, rakenna ja testaa paikallisesti

Määritämme testit suoritettavaksi ennen sitoutumista ja sitten sitoudumme koodin.

Tyypillisiä skenaarioita, kun testit suoritetaan automaattisesti

• Paikallisesti:
  • Jatkuvasti tai vastauksena asianmukaisiin koodin muutoksiin;
  • Tallentamisesta (tulkkaille tai JIT-käänteisille kielille);
  • Kokoamisen aikana (kun kokoamista vaaditaan);
  • On sitoutunut;
  • Kun julkaistaan ​​jaettuun arkistoon.

• Rakennuspalvelimessa tai rakennusympäristössä:
  • Kun koodi julkaistaan ​​henkilökohtaiseen sivukonttoriin/tietovarastoon.
  • Tämän säikeen koodia testataan.
  • Sulautumisen mahdollinen tulos testataan (yleensä master).
  • Jatkuvana integrointivaiheena/jatkuvana toimitusputkena

Yleensä mitä nopeammin testisarja toimii, sitä useammin sinulla on varaa suorittaa sitä. Tyypillinen vaihejako voi näyttää tältä.

• Nopeat yksikkötestit - rakennuksen aikana, CI-valmisteessa
• Hitaat yksikkötestit, nopeat komponentti- ja integrointitestit - commitissa, CI-valmistelussa
• Hitaat komponentti- ja integrointitestit – CI-valmistelussa
• Tietoturvatestaus, kuormitustestaus ja muut aikaa vievät tai kalliit testit - CI/CD-putkissa, mutta vain tietyissä rakennuksen tiloissa/vaiheissa/putkistoissa, esimerkiksi julkaisuehdokasta valmisteltaessa tai manuaalisesti suoritettaessa.

️ Tehtävä

Suosittelen suorittamaan testit ensin manuaalisesti komennolla npm test. Lisätään sen jälkeen git-koukku commit-testien suorittamista varten. Siinä on yksi saalis: Git-koukkuja ei pidetä osana tietovarastoa, eikä niitä siksi voida kloonata GitHubista muiden kurssimateriaalien kanssa. Koukun asentamiseksi sinun on suoritettava install_hook.sh tai kopioi tiedosto repo/hooks/pre-commit paikalliseen hakemistoon .git/hooks/.
Kun sitoudut, näet, että testejä suoritetaan ja ne tarkistavat, onko luettelossa tiettyjä avainsanoja.

1. Suorita testit manuaalisesti suorittamalla komento npm test kurssin arkistokansiossasi. Varmista, että testit on suoritettu.
2. Aseta sitoutumiskoukku (pre-commit hook) juoksemalla install_hook.sh.
3. Tee muutokset paikalliseen arkistoon.
4. Varmista, että testit suoritetaan ennen sitoutumista.

Arkistosi pitäisi näyttää tältä näiden vaiheiden suorittamisen jälkeen.

komennot

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

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

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

Julkaise koodi etävarastoon tai etähaaraan

Kun kehittäjät ovat työskennelleet paikallisesti, he yleensä asettavat koodinsa julkisesti saataville, jotta se voidaan lopulta integroida yleisön kanssa. GitHubilla tämä saavutetaan tyypillisesti julkaisemalla teos joko henkilökohtaiseen arkiston kopioon (henkilökohtaiseen haarukkaan) tai henkilökohtaiseen haaraan.

• Haarukoilla kehittäjä kloonaa jaetun etävaraston ja luo siitä henkilökohtaisen etäkopion, joka tunnetaan myös nimellä haarukka. Sitten se kloonaa tämän henkilökohtaisen arkiston toimiakseen paikallisesti. Kun työ on valmis ja sitoumukset tehty, hän työntää ne haarukkaan, jossa ne ovat muiden saatavilla ja voidaan integroida yhteiseen arkistoon. Tätä lähestymistapaa käytetään yleisesti avoimen lähdekoodin projekteissa GitHubissa. Sitä käytetään myös jatkokurssillani [Tiimityö ja CI Gitin kanssa] (http://devops.redpill.solutions/).
• Toinen tapa on käyttää vain yhtä etävarastoa ja laskea vain haara master jaettu arkisto "suojattu". Tässä skenaariossa yksittäiset kehittäjät julkaisevat koodinsa etävaraston haaroihin, jotta muut voivat katsoa tätä koodia. Jos kaikki on kunnossa, yhdistä se master jaettu arkisto.

Tällä kurssilla käytämme työnkulkua, joka käyttää haaroja.

Julkaistaan ​​koodimme.

️ Tehtävä

• Julkaise muutokset etähaaralle samalla nimellä kuin työhaarasi

komennot

git push --set-upstream origin feature

Luo vetopyyntö

Luo vetopyyntö otsikolla Vaiheiden tarkistus... Asentaa feature kuten "päähaara" ja master kuten "perushaara".

Varmista, että olet asentanut master hänen haara arkiston "Perushaarana" en vastaa kurssimateriaalien arkiston muutospyyntöihin.

GitHub-lingossa "perushaara" on haara, johon perustat työsi, ja "päähaara" on haara, joka sisältää ehdotetut muutokset.

Keskustele muutoksista, lisää uusia sitoumuksia keskustelun edetessä

Vetopyyntö (PR)

Vetopyyntö (PR) on tapa keskustella ja dokumentoida koodia sekä suorittaa koodin tarkistus. Vetopyynnöt on nimetty yleisen tavan mukaan integroida yksittäiset muutokset yleiseen koodiin. Tyypillisesti henkilö kloonaa projektin virallisen etävaraston ja työskentelee koodin parissa paikallisesti. Tämän jälkeen hän asettaa koodin henkilökohtaiseen etätietovarastoonsa ja pyytää virallisesta arkistosta vastaavia poimimaan (vetää) sen koodin paikallisiin arkistoihinsa, joissa he tarkistavat ja mahdollisesti integroivat (yhdistää) hänen. Tämä käsite tunnetaan myös muilla nimillä, esim. yhdistämispyyntö.

Sinun ei itse asiassa tarvitse käyttää GitHubin tai vastaavien alustojen vetopyyntöominaisuutta. Kehitystiimit voivat käyttää muita viestintätapoja, kuten kasvokkain tapahtuvaa viestintää, äänipuheluita tai sähköpostia, mutta silti on useita syitä käyttää foorumityylisiä vetopyyntöjä. Tässä muutama niistä:

• tiettyihin koodin muutoksiin liittyvät keskustelut;
• paikkana katsella palautetta keskeneräisistä töistä sekä automaattisilta testaajilta että vertaisilta;
• koodien tarkistusten virallistaminen;
• jotta voit myöhemmin selvittää syyt ja näkökohdat tämän tai toisen koodinpalan takana.

Yleensä luot vetopyynnön, kun haluat keskustella jostain tai saada palautetta. Jos esimerkiksi työskentelet ominaisuuden parissa, joka voidaan ottaa käyttöön usealla tavalla, voit luoda vetopyynnön ennen ensimmäisen koodirivin kirjoittamista jakaaksesi ideasi ja keskustellaksesi suunnitelmistasi yhteistyökumppaneiden kanssa. Jos työ on yksinkertaisempaa, vetopyyntö avataan, kun jotain on jo tehty, sitoutunut ja siitä voidaan keskustella. Joissakin tilanteissa saatat haluta avata PR:n vain laadunvalvontasyistä: suorittaaksesi automaattisia testejä tai käynnistääksesi koodin tarkistuksia. Mitä tahansa päätätkin, älä unohda @mainita ihmisiä, joiden hyväksynnän haluat vetopyynnössäsi.

Yleensä PR:tä luodessasi teet seuraavaa.

• Ilmoita, mitä aiot muuttaa ja missä.
• Kirjoita kuvaus, jossa selitetään muutosten tarkoitus. Saatat haluta:
  • lisää jotain tärkeää, mikä ei käy ilmi koodista, tai jotain hyödyllistä kontekstin ymmärtämiselle, kuten asiaankuuluvat #bugit ja sitoumukset;
  • @mainitse kuka tahansa, jonka kanssa haluat aloittaa työskentelyn, tai voit @mainita heidät kommenteissa myöhemmin;
  • pyydä kollegoita auttamaan jossain tai tarkista jotain erityistä.

Kun avaat PR:n, tällaisissa tapauksissa suoritettavaksi määritetyt testit suoritetaan. Meidän tapauksessamme tämä on sama testisarja, jonka suoritimme paikallisesti, mutta todellisessa projektissa voi olla lisätestejä ja tarkistuksia.

Odota, kun testit on suoritettu. Testien tilan näet GitHub-käyttöliittymän PR-keskustelun alalaidasta. Jatka, kun testit on suoritettu.

️ Lisää huomautus CI-vaiheiden luettelon satunnaisuudesta

Tällä kurssilla käytetty luettelo on mielivaltainen ja subjektiivinen, tähän kannattaa lisätä huomautus.

️ Tehtävä: luo vetopyyntö tälle kommentille

1. Vaihda haaraan master.
2. Luo haara nimeltä bugfix.
3. Lisää muistiinpanoteksti tiedoston loppuun 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. Sitoudu muutokset.
5. Julkaise lanka bugfix etävarastoon.
6. Luo vetopyyntö nimeltä Lisätään huomautus päähaaralla bugfix ja perushaaramaster.

Varmista, että olet asentanut master hänen haara arkiston "Perushaarana" en vastaa kurssimateriaalien arkiston muutospyyntöihin.

Tältä arkiston pitäisi näyttää.

komennot

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

Hyväksy vetopyyntö "Huomautuksen lisääminen"

️ Tehtävä

1. Luo vetopyyntö.
2. Napsauta "Yhdistä vetopyyntö".
3. Napsauta "Vahvista yhdistäminen".
4. Napsauta "Poista haara", emme enää tarvitse sitä.

Tämä on kaavio sitoumuksista yhdistämisen jälkeen.

️ Jatka työskentelyä ja testien lisäämistä

Yhteistyö vetopyynnön parissa johtaa usein lisätyöhön. Tämä on yleensä tulos koodin tarkistuksesta tai keskustelusta, mutta kurssillamme mallinnetaan tätä lisäämällä uusia kohteita CI-vaiheiden luetteloomme.

Jatkuva integrointi sisältää tyypillisesti jonkin verran testikattavuutta. Testin kattavuusvaatimukset vaihtelevat, ja ne löytyvät yleensä asiakirjasta, jota kutsutaan nimellä "avustusohjeet". Pidämme sen yksinkertaisena ja lisäämme testin jokaiselle tarkistuslistamme riville.

Kun suoritat tehtäviä, yritä suorittaa testit ensin. Jos olet asentanut oikein pre-commit koukku aikaisemmin, äskettäin lisätty testi suoritetaan, epäonnistuu eikä mitään sitouduta. Huomaa, että näin tiedämme, että testimme todella testaavat jotain. Mielenkiintoista on, että jos aloitimme koodilla ennen testejä, testien läpäiseminen voi tarkoittaa joko sitä, että koodi toimi odotetusti tai että testit eivät varsinaisesti testanneet mitään. Lisäksi, jos emme olisi kirjoittaneet kokeita alun perin, olisimme saaneet unohtaa ne kokonaan, koska mikään ei olisi muistuttanut meitä siitä.

Test Driven Development (TDD)

TDD suosittelee testien kirjoittamista ennen koodia. Tyypillinen TDD:tä käyttävä työnkulku näyttää tältä.

1. Lisää testi.
2. Suorita kaikki testit ja varmista, että uusi testi epäonnistuu.
3. Kirjoita koodi.
4. Suorita testit ja varmista, että kaikki testit läpäisevät.
5. Refaktoroi koodisi.
6. Toistaa.

Koska epäonnistuneiden testien tulokset näkyvät yleensä punaisella ja läpäisseet vihreällä, sykli tunnetaan myös punavihreä-refaktorina.

️ Tehtävä

Kokeile ensin suorittaa testit ja antaa niiden epäonnistua, sitten lisää ja sitoa itse CI-vaiheluettelon teksti. Näet, että testit ovat läpäisseet ("vihreä").
Julkaise sitten uusi koodi etävarastoon ja katso testit, jotka suoritetaan GitHub-käyttöliittymässä vetopyyntökeskustelun ja PR-tilan päivityksen alaosassa.

1. Vaihda haaraan feature.

2. Lisää nämä testit ci.test.js viimeisen puhelun jälkeen 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. Yritä suorittaa testit. Jos pre-commit koukku on asennettu, vahvistusyritys epäonnistuu.
4. Lisää sitten tämä teksti 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. Tee ja tee muutoksia paikallisesti.
6. Lähetä muutokset haaraan feature.

Sinulla pitäisi nyt olla jotain tällaista

komennot

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

Yhdistä ristiriita

Siirry kohtaan Muutospyyntö Vaiheiden tarkistus.

Vaikka emme tehneet mitään väärää ja koodimme testit läpäisivät, emme silti voi yhdistää haaraa feature и master. Se johtuu toisesta langasta bugfix yhdistettiin master kun työskentelimme tämän PR:n parissa.
Tämä luo tilanteen, jossa etähaara master on uudempi versio kuin se, johon haaramme perustui feature. Tämän vuoksi emme voi vain kelata PÄÄTÄ taaksepäin master langan loppuun feature. Tässä tilanteessa meidän on joko yhdistettävä tai sovellettava sitoumuksia feature rebase master. GitHub voi itse asiassa suorittaa automaattisia yhdistämisiä, jos ristiriitoja ei ole. Valitettavasti meidän tilanteessamme molemmilla sivuilla on kilpailevia muutoksia tiedostossa ci.md. Tämä tilanne tunnetaan yhdistämisristiriidana, ja meidän on ratkaistava se manuaalisesti.

Yhdistä tai perustaa uudelleen

mennä

• Luo ylimääräisen yhdistämissitoumuksen ja tallentaa työhistorian.
  • Säilyttää haarojen alkuperäiset sitoumukset alkuperäisine aikaleimoineen ja tekijöineen.
  • Tallentaa sitoumusten SHA:n ja linkit niihin muutospyyntökeskusteluissa.
• Vaatii kertaluonteisen konfliktinratkaisun.
• Tekee tarinasta epälineaarisen.
  • Tarinaa voi olla vaikea lukea johtuen suuresta haarojen määrästä (muistuttaa IDE-kaapelia).
  • Vaikeuttaa automaattista virheenkorjausta, esim. git bisect vähemmän hyödyllinen - se löytää vain yhdistämistoimituksen.

Perusta uudelleen

• Toistaa sitoumukset nykyisestä haarasta perushaaran päälle peräkkäin.
  • Uusia sitoumuksia uusilla SHA:illa luodaan, jolloin GitHubin sitoumukset vastaavat alkuperäisiä vetopyyntöjä, mutta eivät vastaavia kommentteja.
  • Sitoumuksia voidaan yhdistää ja muokata prosessin aikana tai jopa yhdistää yhdeksi.
• Useita ristiriitoja voi olla tarpeen ratkaista.
• Mahdollistaa lineaarisen tarinan ylläpitämisen.
  • Tarina voi olla helpompi lukea, kunhan se ei ole liian pitkä ilman järkevää syytä.
  • Automaattinen virheenkorjaus ja vianmääritys on hieman helpompaa: mahdollistaa sen git bisect, voi tehdä automaattisista peruutuksista selkeämpiä ja ennakoitavampia.
• Edellyttää haaran julkaisemista, jossa on siirretyt sitoumukset lipulla --force kun sitä käytetään vetopyyntöjen kanssa.

Tyypillisesti tiimit sopivat käyttävänsä aina samaa strategiaa, kun niiden on yhdistettävä muutoksia. Tämä voi olla "puhdas" yhdistäminen tai "puhdas" sitoutuminen päälle, tai jotain siltä väliltä, ​​kuten sitoumuksen tekeminen päälle interaktiivisesti (git rebase -i) paikallisesti sivuliikkeiden osalta, joita ei ole julkaistu julkiseen tietovarastoon, mutta yhdistäminen "julkisille" sivuliikkeille.

Tässä käytämme yhdistämistä.

️ Tehtävä

1. Varmista, että koodi on paikallisessa konttorissa master päivitetty etävarastosta.
2. Vaihda haaraan feature.
3. Aloita yhdistäminen haarakonttoriin master. Yhdistämisristiriita kilpailevien muutosten vuoksi ci.md.
4. Ratkaise ristiriita niin, että sekä CI-vaiheiden luettelomme että huomautus siitä jäävät tekstiin.
5. Julkaise yhdistämissitoumus etähaaralle feature.
6. Tarkista vetopyynnön tila GitHub-käyttöliittymässä ja odota, kunnes yhdistäminen on ratkaistu.

komennot

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

Hyvää työtä!

Olet valmis luettelon kanssa ja nyt sinun on hyväksyttävä vetopyyntö master.

️ Tehtävä: Hyväksy vetopyyntö "Vaihetarkistus"

1. Avaa vetopyyntö.
2. Napsauta "Yhdistä vetopyyntö".
3. Napsauta "Vahvista yhdistäminen".
4. Napsauta "Poista haara", koska emme enää tarvitse sitä.

Tämä on arkistosi tällä hetkellä

Tuotevirhe

Sanotaan, että "testausta voidaan käyttää osoittamaan virheiden olemassaolo, mutta ei koskaan osoittamaan niiden puuttumista". Vaikka meillä oli testejä ja niissä ei näkynyt virheitä, tuotantoon hiipi salakavala bugi.

Tällaisessa tilanteessa meidän on huolehdittava:

• mitä tuotannossa käytetään;
• koodi ketjussa master jossa on virhe, josta kehittäjät voivat aloittaa uuden työn.

Pitäisikö minun peruuttaa vai korjata se seuraavassa versiossa?

Palauttaminen on prosessi, jossa otetaan käyttöön tunnettu hyvä aikaisempi versio tuotantoon ja palautetaan virheen sisältävät sitoumukset. "Korjaus eteenpäin" on korjauksen lisääminen tiedostoon master ja ottaa uuden version käyttöön mahdollisimman pian. Koska API:t ja tietokantakaaviot muuttuvat koodin käyttöönoton yhteydessä tuotantoon, jatkuvan toimituksen ja hyvän testikattavuuden ansiosta, palauttaminen on yleensä paljon vaikeampaa ja riskialtisempaa kuin sen korjaaminen seuraavassa versiossa.

Koska peruuttamiseen ei meidän tapauksessamme liity riskiä, ​​lähdemme tälle tielle, koska se sallii meille

• korjaa tuotteen virhe mahdollisimman pian;
• laita koodi sisään master sopiva heti uuden työn aloittamiseen.

️ Tehtävä

1. Vaihda haaraan master paikallisesti.
2. Päivitä paikallinen arkisto etävarastosta.
3. Peruuta PR-yhdistämissitoumus Vaiheiden tarkistus в master.
4. Julkaise muutokset etävarastoon.

Tämä on sellaisen arkiston historia, jonka yhdistämissitoumus on palautettu

komennot

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

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

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

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

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

️ Itsetestaus

Varmista että ci.md ei enää sisällä tekstiä "sneaky bug" yhdistämistoimituksen palauttamisen jälkeen.

Korjaa CI-vaiheiden luettelo ja palauta se masterille

Olemme peruuttaneet sivuliikkeen yhdistämissitoumuksen kokonaan. feature. Hyvä uutinen on, että meillä ei nyt ole virhettä master. Huono uutinen on, että myös arvokas luettelomme jatkuvista integraatiovaiheista on poissa. Joten ihannetapauksessa meidän on sovellettava korjausta sitoumuksiin alkaen feature ja palauttaa ne master korjauksen mukana.

Voimme lähestyä ongelmaa eri tavoin:

• peruuta sitoumus, joka kumoaa yhdistämisen feature с master;
• siirtää sitoumuksia entisestä feature.

Eri kehitystiimit käyttävät tässä tapauksessa erilaisia ​​lähestymistapoja, mutta siirrämme hyödylliset sitoumukset erilliseen haaraan ja luomme erillisen vetopyynnön tälle uudelle haaralle.

️ Tehtävä

1. Luo ketju nimeltä feature-fix ja vaihda siihen.

2. Siirrä kaikki sitoumukset entisestä haarasta feature uuteen ketjuun. Ratkaise siirron aikana ilmenneet yhdistämisristiriidat.

   

3. Lisää regressiokoe ci.test.js:

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

4. Suorita testit paikallisesti varmistaaksesi, etteivät ne epäonnistu.
5. Poista teksti "jossa on ovela bugi". ci.md.
6. Lisää testimuutokset ja vaiheluettelomuutokset hakemistoon ja vahvista ne.
7. Julkaise haara etävarastoon.

Sinun pitäisi päätyä johonkin tämän kaltaiseen:

komennot

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

Luo vetopyyntö.

Luo vetopyyntö otsikolla Ominaisuuden korjaaminen... Asentaa feature-fix kuten "päähaara" ja master kuten "perushaara".
Odota, kun testit valmistuvat. Testien tilan näet PR-keskustelun alalaidasta.

Varmista, että olet asentanut master hänen haara arkiston "Perushaarana" en vastaa kurssimateriaalien arkiston muutospyyntöihin.

Hyväksy vetopyyntö "Ominaisuuden korjaaminen"

Kiitos oikaisusta! Hyväksy muutokset master vetopyynnöstä.

️ Tehtävä

1. Napsauta "Yhdistä vetopyyntö".
2. Napsauta "Vahvista yhdistäminen".
3. Napsauta "Poista haara", koska emme enää tarvitse sitä.

Tämä sinun pitäisi olla tällä hetkellä.

Onneksi olkoon!

Olet suorittanut kaikki vaiheet, jotka ihmiset yleensä tekevät jatkuvan integroinnin aikana.

Jos huomaat kurssilla ongelmia tai tiedät kuinka parantaa sitä, ole hyvä ja luo ongelma arkistot kurssimateriaalien kanssa. Tällä kurssilla on myös interaktiivinen versio käyttämällä GitHub Learning Labia alustana.

Lähde: will.com