Jenkinsin ohjelmisto. Jenkins. Jatkuva integrointi on tehty helpoksi. No melkein☺. Jenkins-tehtävän luominen

Tässä artikkelissa hahmotellaan jatkuvan integraation pääideat ja annetaan esimerkki Jenkinsin nopeasta käyttöönotosta projektissa.

Termit ja määritelmät

Ennen kuin siirryt pääosaan, on tarpeen määritellä käytetyt termit.

Jatkuva integrointi (CI, Continuous Integration)- Ohjelmistokehityskäytäntö, jossa työkopiot yhdistetään yhteiseksi master-kehityshaaralle useita kertoja päivässä ja projektin säännölliset automatisoidut koontiversiot mahdollisten vikojen tunnistamiseksi ja integrointiongelmien ratkaisemiseksi nopeasti. [wiki]

Jenkins on avoimen lähdekoodin jatkuva integraatioprojekti, joka on kirjoitettu Java-kielellä. [jenkins.io]

Automaattinen testaus on ohjelmiston varmennusprosessi, jossa testin perustoiminnot ja vaiheet, kuten suorittaminen, alustus, suoritus, analysointi ja tulos, suoritetaan automaattisesti käyttämällä automaattisia testaustyökaluja. [protestoi]

Hieman CI:stä

Tällä hetkellä jatkuva integrointi on yksi ketterän metodologian käytännöistä. Tällaisissa menetelmissä se yhdistetään onnistuneesti muihin käytäntöihin, kuten yksikkötestaukseen, uudelleenkäsittelyyn ja koodausstandardeihin. Mutta jopa ilman niitä, voit silti hyötyä jatkuvasta integraatiosta. Jatkuvan integraation määritelmä sisältää sen tärkeimmän idean - virheen löytäminen varhaisessa vaiheessa on helpompaa kehitykselle ja halvempaa yritykselle. Siksi, jos projektiin tehdään melko suuria muutoksia, on suoritettava testaus (yksikkötestit, automaattiset testit).

On syytä huomata, että käynnistystiloja voi olla useita:

• testit käynnistetään jokaisen sitoutumisen jälkeen - tämä on ihanteellinen yksikkötesteihin ja kiistanalainen päästä päähän. Selitän miksi alla;
• testit suoritetaan kerran päivässä (useimmiten yöllä). Tämä vaihtoehto ei sovellu yksikkötesteihin, koska sovellus saattaa jäädä toimimattomaksi pitkään, mutta se on varsin hyvä vaihtoehto automatisoituihin toiminnallisiin päästä päähän -testeihin, varsinkin kun testit kestävät kauan;
• testit ajetaan ennen julkaisun julkaisua - yksi pahimmista käyttötapauksista, mutta sitä voidaan käyttää myös rajallisten resurssien olosuhteissa, ja uusia, omalla haarallaan kehitettyjä toimintoja testataan kerran tai useita kertoja päivässä.

CI:lle on olemassa melko paljon työkaluja:

• Paikallisia ovat: GitLab CI, TeamCity, Bamboo, Jenkins, Hudson, Circle CI;
• pilvi - BitBucket Pipelines, Heroku CI, Travis, Codeship, Buddy CI, AWS CodeBuild.

Jenkins

Miksi sinun pitäisi käyttää Jenkinsiä:

• ilmainen ja luotettava;
• suuri määrä työoppaita, mikä tarkoittaa, että on helpompi oppia työskentelemään sen kanssa;
• helppo varmuuskopioida ja ottaa käyttöön toisella koneella 5 minuutissa;
• Voit hallita sitä määrittämällä ja siirtämällä xml-tiedostoja.

Miinuksista haluaisin huomioida:

• uusien versioiden toistuva julkaiseminen, jos käytetään muuta kuin LTS:ää;
• integrointi eri palvelujen kanssa on sidottu useisiin erilaisiin laajennuksiin;
• Joskus saattaa ilmestyä tehtävä, joka vaatii epätyypillistä lähestymistapaa.

Annan sinulle ikimuistoisen esimerkin. On tarpeen tukea useita tuotteen versioita, jotka toimivat eri Java-versioiden kanssa, ja jos projekti käynnistettiin väärällä versiolla, testit alkoivat jatkuvasti epäonnistua. Tätä varten minun oli lisättävä laajennus - Environment Injector ja lisättävä kokoonpanoon myös lisävaihe, joka tuotteen versiosta riippuen muutti työympäristön parametrit käyttämään tiettyä Java-versiota:

Yllä olevassa esimerkissä kuvatussa tapauksessa TeamCityssä riitti java-version määrittäminen ajon alkaessa.

Huomaan erikseen, että tässä tapauksessa Jenkinsiä käytettiin yksinomaan automaattisten testien suorittamiseen, koska ne olivat melko pitkiä ja vaativat korkeaa tuottavuutta.

Ihanteellinen kehitysprosessi voidaan esittää seuraavasti:

• kehittäjä lähettää koodin arkistoon;
• jatkuvan integroinnin palvelimella muutokset yhdistetään pääkoodiin, suoritetaan yksikkötestejä;
• edellisessä vaiheessa saadut artefaktit ladataan erilliseen testiympäristöön, jossa sovellus testataan automaattisilla testeillä;
• Sitten kaikki tarkistetaan päästäkseen tuotantoon;
• käyttöönotto tuotantoon.

Jenkinsin asennus

Asennuksesta on kirjoitettu melko paljon ja yksityiskohtaisesti, paras käsikirja on tietysti kehittäjiltä – Installing Jenkins.

Varmuuskopioida

Voit käyttää sisäänrakennettuja laajennuksia, mutta yhteensopivuusongelmia voi esiintyä eri laajennusversioiden välillä, joten tähän tarkoitukseen alettiin käyttää bash-skriptejä, jotka sisältyivät erilliseen kokoonpanoon, joka ajettiin useita kertoja päivässä/viikossa. Esimerkiksi jenkins-backup.sh-skripti tallensi nykyisen työkokoonpanon: näkymän, työn, ympäristön asetukset, liitännäiset, jotka tallennettiin erilliseen arkistoon, jota voidaan siirtää ja käyttää edelleen.

Asennus tallennetusta kopiosta

1.Sinun on asennettava Java ja arkistointityökalu, tässä tapauksessa pura.

2. Pura aiemmin tallennettu tiedosto (mentyäsi hakemistoon, jossa tallennettu arkisto):

pura Jenkins.zip -d %path_To_Jenkins%

3. Siirry Jenkins-hakemistoon ja suorita Jenkins komennolla

cd %path_To_Jenkins% && java -jar jenkins.war

4. Kirjaudu WEB-käyttöliittymään portin 8080 kautta.

Jos työskentelet Linux-koneen kanssa ssh:n kautta, Jenkins todennäköisesti pysähtyy yhteyden sulkemisen jälkeen. Tämän toiminnan välttämiseksi voit käyttää seuraavaa tekniikkaa: suorita komento lisäämällä &-symboli - seurauksena komento suoritetaan taustalla ja ohjaus palautetaan komentoriville ja Jotta käynnissä olevat tehtävät eivät keskeydy, kun yhteys katkaistaan ​​etäjärjestelmästä, voit käyttää nohup-apuohjelmaa, jonka avulla prosessit voivat jatkaa toimintaansa myös uloskirjautumisen jälkeen:

nohup java -jar jenkins.war &

Jenkinsin lisääminen palveluihin

Välttääksesi edellisessä kappaleessa kuvatun tilanteen Linux-järjestelmissä, voit asentaa Jenkinsin palveluna niin, että Jenkins käynnistyy automaattisesti aina uudelleenkäynnistyksen jälkeen. Tätä varten sinun on luotava tiedosto /etc/systemd/system/jenkins.service komento:

Sudo cat /etc/systemd/system/jenkins.service sudo vi /etc/systemd/system/jenkins.service

ja lisää sisältöä jenkins.serviceen:

Description=Jenkins Daemon Environment="JENKINS_HOME=%path_To_Jenkins%" ExecStart=/usr/bin/java -jar %path_To_Jenkins%/jenkins.war User=nykyinen käyttäjänimi WantedBy=multi-user.target

Käynnistä palvelupalvelu uudelleen: sudo systemctl daemon-reload

Komento käynnistää jenkins-palvelu: sudo systemctl käynnistä jenkins.service

uudelleenkäynnistää sudo systemctl käynnistä jenkins.service uudelleen

On tärkeää huomata että jenkins.war-tiedosto voi sijaita missä tahansa. Nykyisten projektiparametrien "poimimiseksi" voit käyttää komentoa, joka liittää Jenkins-osion käynnissä olevaan jenkinsiin:

sudo mount -o bind /%path_To_Jenkins%/ ~/.jenkins/

Tämä vaihtoehto toimii vain, kunnes järjestelmä käynnistetään uudelleen, joten voit luoda symbolilinkin ~/-hakemistoon:

cd ~/ && sudo ln -s /%path_To_Jenkins%/ .jenkins

Solmun lisääminen ja valmistelu työhön Jenkinsissä

Tämä osio on kirjoitettu ottaen huomioon käytäntö, että Jenkinsin ja solmun elinkaari on rajoitettu, esimerkiksi 2 viikkoa tai kuukausi.

Jos haluat lisätä orjasolmun Jenkinsiin, voit lisätä jokaisen koneen manuaalisesti, mutta tämän vuoksi sinun on jatkuvasti kirjauduttava koneeseen ja suoritettava samat toiminnot, ja tämä johtaa ajatukseen, että kaikki voidaan automatisoida mahdollisimman paljon.
Tätä varten riittää, että luot useita töitä, jotka suoritetaan peräkkäin:

1. koneiden lisääminen orjasolmuiksi Jenkinsiin;
2. lisää aiemmin tilatut koneet Jenkinsiin käyttämällä rest api tai Jenkins cli;
3. ottaa käyttöön tarvittava ympäristö.

Kaikki edellä mainitut toiminnot voidaan suorittaa lisätyökaluilla: mahdollinen - tarvittavien parametrien ja telakointiaseman käyttöönottoon ja konfigurointiin - sekä Jenkinsin käyttöönottoon että ympäristön asentamiseen orjasolmuihin.

Johtopäätös

Tärkeintä on, että lause "jatkuva integrointi" projektissasi ei ole vain kauniita uusia sanoja, vaan myös tekoja. Ja jos noudatat ainakin minimaalisesti CI:n periaatteita, niin kehityksen elinkaaressa tulee paljon vähemmän ongelmia ja itse prosessista tulee nautinnollisempaa. Mielenkiintoisia tilastoja sisältävä kysely CI:n käytöstä projektissa –

Meillä on palvelin, jolla on monia WordPress- ja Magento CMS -pohjaisia ​​projekteja. PHP-kehittäjänä sain tehtäväksi toteuttaa Jenkins näissä projekteissa, jotta lähdekoodimuutosten julkaiseminen palvelimelle tapahtuisi nopeammin.

Miksi tarvitsemme jatkuvaa integraatiota?

Ohjelmistotuotteiden kehittämisen ja ylläpidon tehokkuuden lisääminen on minulle web-kehittäjänä aina ollut ja on edelleen ajankohtainen ja mielenkiintoinen. Projektin kokoamisen ja palvelimelle julkaisemisen prosessit ovat linkki, joka voidaan helposti automatisoida työkalujen avulla Jatkuva integrointi (CI).

Monet ovat käyttäneet CI:tä menestyksekkäästi jo pitkään. Käyttämällä tätä kehitysmenetelmä avulla voit lyhentää merkittävästi projektin julkaisuaikaa palvelimella, mikä vähentää tämän työn useiden konsolikomentojen suorittamiseen. Lisäksi CI:tä käytettäessä on mahdollista palata nopeasti milloin tahansa projektin edelliseen versioon, koska jatkuva integrointi liittyy erottamattomasti versionhallintajärjestelmän arkistoon.

CI:n periaate on melko yksinkertainen. Minun tapauksessani oli mukana kolme palvelinta:

• Versionhallintajärjestelmä (VCS) -palvelin, johon on tallennettu arkisto projektin toimivalla versiolla, johon kehittäjä tallentaa tekemänsä muutokset.
• Jatkuva integrointipalvelin, johon jokin CI-hallintajärjestelmistä on asennettu.
• Palvelin, jossa projektin työversio otetaan käyttöön.

Välittömästi versionhallintajärjestelmän arkiston muuttamisen jälkeen VCS-palvelin aloittaa tehtävän suorittamisen CI-palvelimella (yleensä webhookia käyttämällä). Tämä tehtävä rakentaa ja ottaa käyttöön lähdekoodin VCS-tietovarastosta projektin työversion palvelimelle.

Voit lukea lisää jatkuvan integroinnin tarjoamista eduista tästä artikkelista.

Tämä opas sisältää tarpeeksi tietoa CI Jenkins -järjestelmän nopeaan määrittämiseen ja sen käytön aloittamiseen. Se tarjoaa myös tietoa tällaisen suositun CI-järjestelmän sekä yhtä tunnetun Git-versionhallintajärjestelmän käyttöönotosta ja vuorovaikutuksen järjestämisestä. Käytämme GitHubia gitin verkkopalveluna.

Huomio, tehtävä

Jenkins on asennettava ja konfiguroitava siten, että GitHub-arkistoon työnnettäessä muuttuneet tiedostot päivitetään projektin työversion palvelimelle. Varastossa:

• Debian 8.2 x64 -palvelin.
• Järjestelmä paikallisella koneella: Linux Mint 17.2.

Edellytyksenä on, että git on asennettu molemmille koneille. Voit lukea sen asentamisesta.

Ratkaisu

1. Asenna Jenkins

Asennus suoritetaan CI:lle omistetulle palvelimelle. Lisää Jenkins-tietovarasto järjestelmätietovarastojen luetteloon antamalla seuraavat komennot:

Sudo wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | apt-key add - sudo echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list

Päivitä apt ja asenna Jenkins:

Sudo apt-get päivitys sudo apt-get install jenkins Käynnistä Jenkins uudelleen: /etc/init.d/jenkins restart

Nyt Jenkins "kuuntelee" CI-palvelimen porttia 8080. Tämä tarkoittaa, että kun siirryt selaimesi osoitteeseen 8080 , käyttäjä ohjataan Jenkinsin ohjauspaneeliin. Tämä pääsytapa ei tietenkään ole kovin kätevä, joten CI-palvelimella voit määrittää pääsyn Jenkinsiin käyttämällä Apachen tai Nginxin virtuaalisia isäntiä.

Seuraava tärkeä vaihe on käyttöoikeuksien määrittäminen. Tämä on erittäin tärkeää, varsinkin jos palvelin on käytettävissä Internetin kautta. Ilman asianmukaisia ​​asetuksia se on avoin kaikille.

2. Järjestelmänvalvojan lisääminen

Hallitse Jenkinsiä → Määritä yleinen suojaus(maailmanlaajuinen suojausasetus).

1. Täytä vaaditut tiedot:

• Ota suojaus käyttöön- totta; //ota suojaus käyttöön;
• Jenkinsin oma käyttäjätietokanta— "Jenkinsin oma käyttäjätietokanta"; //käytä Jenkins-tietokantaa valtuutukseen;
• Valtuutus— "Matriisipohjainen tietoturva"; //käyttöoikeuksien matriisijako (oikeuksien jakaminen projektitasolla);
• Lisättävä käyttäjä/ryhmä- "järjestelmänvalvoja". //myönnä käyttäjälle "admin" käyttöoikeudet Jenkinsin ohjauspaneeliin.

2. Tallenna asetukset.

Nyt kun Jenkins yrittää kirjautua ohjauspaneeliin, se vaatii käyttäjän kirjautumaan sisään.

3. Luo käyttäjä GitHubille

Nyt sinun on luotava tunnistetiedot GitHubin pääsyä varten Jenkins-palvelimeen.

Siirry Jenkinsin ohjauspaneelissa kohtaan Hallitse Jenkinsiä → Hallitse käyttäjiä → Luo käyttäjä. Täytämme rekisteröintilomakkeen, joka on identtinen järjestelmänvalvojaksi rekisteröitymisen yhteydessä käytetyn lomakkeen kanssa, napsauta Kirjaudu.

Kun olet luonut käyttäjän, sinun on annettava hänelle tarvittavat oikeudet. Tätä varten mennään kohtaan Hallitse jenkinejä → Määritä yleinen suojaus(maailmanlaajuinen suojausasetus).

Kaikista näistä asetuksista tarvitsemme turvallisuusmatriisi.

Ensin lisätään käyttäjä tähän matriisiin. Kirjoita "Lisättävä käyttäjä/ryhmä" -kenttään luodun käyttäjän nimi ja napsauta Lisätä. Käyttäjä näkyy matriisissa. Annetaan sille luku- ja rakennusoikeudet. Voit tehdä tämän alisarakkeissa Lukea Ja Rakentaa Aseta "Työ" -sarakkeessa luodun käyttäjän nimeä vastapäätä valintaruudut ja napsauta Tallentaa.

4. GitHubin laajennuksen asentaminen

Mennään Hallitse Jenkinsiä → Hallitse laajennuksia → "Saatavilla"-välilehti. Valitsemme kolme lisäosaa asennettavaksi:

• Github Authentication -laajennus;
• GitHub-laajennus;
• GitHub API -laajennus.

Napsauta painiketta "Lataa nyt ja asenna uudelleenkäynnistyksen jälkeen" ja odota asennuksen valmistumista.

5. Palvelimen määrittäminen toimimaan Jenkinsin kanssa

Projektin tuotantopalvelimelle (jossa automaattinen käyttöönotto suoritetaan) sinun on luotava käyttäjä "jenkins":

Ssh-keygen

Ja syötä tarvittavat tiedot.

Lisäksi pääsyä varten sinun on lisättävä julkinen avain tiedostoon... /jenkins/.ssh/authorized_keys (jos tiedostoa ei ole olemassa, sinun on luotava se)

Lisäksi sinun on luotava julkinen SSH-avain tälle palvelimelle GitHubissa. Voit nähdä, miten tämä tehdään.

Tämä vaihe on valmis.

Jos jokin ssh-todennuksesta on epäselvää, suosittelen lukemaan erittäin hyödyllisen artikkelin tästä aiheesta.

6. Palvelimen käyttöoikeuden määrittäminen

Jotta Jenkins voi valtuuttaa sen automaattisesti ottaessaan käyttöön palvelimella, jossa on toimiva versio projektista, sinun on luotava tarvittavat todennustiedot ohjauspaneelissa. Voit tehdä tämän siirtymällä Jenkinsin ohjauspaneeliin Tunnistetiedot → Yleiset tunnistetiedot → Lisää tunnistetiedot ja toimi seuraavasti:

1. Kuten Ystävällinen valitse "SSH-käyttäjänimi yksityisellä avaimella";
2. Käyttäjätunnus— kirjoita palvelimelle luodun käyttäjän nimi ("jenkins");
3. Yksityinen avain— "Syötä suoraan", kopioi jenkins-käyttäjän yksityisen avaintiedoston koko sisältö tekstikenttään. (".../jenkins/.ssh/id_rsa");
4. Napsauta "OK".

Nyt sinun on määritettävä yhteys palvelimeen. Voit tehdä tämän siirtymällä jenkinsin ohjauspaneeliin Hallitse Jenkinsiä → Hallitse solmuja → Uusi solmu. Suoritamme seuraavat toimenpiteet:

1. Anna tuotantopalvelimen nimi (esimerkiksi "target"), aseta "Dumb Slave", napsauta "OK";
2. Anna polku tuotantopalvelimen Jenkinsin juurihakemistoon. Kohdepalvelimen juurihakemisto on yleensä jenkins-käyttäjähakemisto (".../jenkins");
3. Kirjoita "Labels"; esimerkiksi - "target_server". Tunniste on tunniste, jolla tehtävä liitetään tiettyyn palvelimeen.
4. Isäntä - kirjoita isännän nimi, johon otamme yhteyttä;
5. Valtuustiedot - valitse aiemmin luodut todennustiedot;
6. Napsauta "Tallenna".

Jonkin ajan kuluttua yhteyden palvelimeen pitäisi muodostua onnistuneesti. Jos kaikki meni hyvin, sisään Hallitse Jenkinsiä → Hallitse solmuja sinun pitäisi nähdä jotain tällaista:

Jos yhteyttä ei muodosteta, napsauta luotua yhteyttä ("kohde"), valitse vasemmasta navigointivalikosta "Loki" ja katso mitä tapahtui väärin.

Yleisimmät virheet ovat:

Ensimmäinen ratkaisu— muuta yhteysasetusten juurihakemisto Jenkins-käyttäjän kotihakemistoksi.

Toinen ratkaisu— myöntää Jenkins-käyttäjälle oikeudet kirjoittaa ja lukea yhteysasetuksissa määritettyä hakemistoa.

7. GitHub-koukun määrittäminen

Käytettävälle GitHub-arkistolle sinun on määritettävä webhook niin, että kun tietovarasto päivitetään, koukku lähettää pyynnön Jenkinsin päivittämisestä. Tätä varten:

• Siirry luotuun arkistoon GitHubissa.
• "Asetukset" → "Webhookit ja palvelut".
• "Lisää webhook".
• Kirjoita "Payload URL" (johon GitHub menee). Sillä pitäisi olla seuraava muoto

  <протокол>: //<имя пользователя для github в jenkins>: <пароль пользователя github в jenkins>@<домен>/github-webhook/

  (esimerkiksi - http://github: [sähköposti suojattu]:8080/github-webhook/).
• "Sisältötyyppi" - "sovellus/json".
• "Mitä tapahtumia haluaisit käynnistää tämän webhookin?" - "Vain työntötapahtuma."
• "Aktiivinen" - totta.
• Napsauta "Lisää webhook".

Webhook on luotu.

8. Luo Jenkins-tehtävä

Nyt sinun on luotava tehtävä, joka suoritetaan, kun arkisto päivitetään. Jenkinsin hallintapaneelissa teemme seuraavaa:

• Napsauta "Uusi kohde".
• Kirjoita tehtävän nimi "Tuotenimi" -kenttään.
• Valitse "Freestyle-projekti" ja napsauta "OK".
• "Rajoita, missä tämä projekti voidaan suorittaa" - kirjoita tunnisteen nimi, joka valittiin palvelinta lisättäessä (esimerkiksi "target_server").
• "Lähdekoodin hallinta" - valitse "Git" ja kirjoita arkiston osoite "Arkiston URL-osoite" -kenttään (esimerkiksi - " [sähköposti suojattu]: TestCi/Continuous-integration.git").
• Valitse Tunnukset-kentässä aiemmin luodut tunnistetiedot.
• "Build Triggers" - "Koonna, kun muutos työnnetään GitHubiin."
• "Build" - "Execute shell" (komentotulkkikomentosarja suoritetaan jokaisella github-työntöllä): sudo rsync -a -cvs-exclude -delete -omit-dir-times. /<директория проекта>sudo chown -R www-data:jenkins< директория проекта>

  Ensimmäinen rivi synkronoi Jenkinsin työhakemiston tuotantopalvelimen kohdeprojektihakemiston kanssa. Toinen rivi on määrittää projektitiedostojen omistaja.

  - artikkeli virtuaalisten isäntien määrittämisestä Nginxissä;

• digitalocean.com - artikkeli virtuaalisten isäntien määrittämisestä Apachessa.

Nykyään (kyllä, juuri nyt) luodaan ja tuotetaan monia erilaisia ​​organisaatiolaitteita ja gadgeteja, jotka eivät voi toimia eivätkä toimi oikein ilman asianmukaista ohjelmistoa. Ja sitten se alkoi 🤯

Mennään järjestyksessä

Ohjelmisto on ohjelma tai luettelo ohjelmista, joita tarvitaan tietokoneen tai sen laitteiden toimintaan. Vau.

Joka päivä luodaan yhä enemmän uusia ohjelmia, pelejä, lisäyksiä ja päivityksiä. Joka päivä tuotetaan erilaisia ​​laitteita ja laitteita, erilaisia ​​ääni- ja videokortteja, levyasemia, tulostimia ja muita. Nämä laitteet eivät tietenkään pysty toimimaan ilman asianmukaista ohjelmistoa, joka puolestaan ​​​​vanhenee ja vaatii päivitystä.

Ohjelmoijat saavat erilaisia ​​tehtäviä ohjelmistojen kirjoittamiseen, mutta inhimillinen tekijä tapahtuu aina ja ohjelmaa kirjoitettaessa saattaa tulla virheitä, minkä vuoksi ohjelmisto ei yksinkertaisesti käynnisty tai tuottaa virheen, jonka korjaaminen saattaa kestää paljon aikaa, mikä nykyaikaisissa olosuhteissa talous on erittäin kannattamatonta. Ja kehittäjä on vaarassa joutua joukkueen johtajan perseeseen.

Luojan kiitos - tämän tehtävän yksinkertaistamiseksi ja nopeuttamiseksi se luotiin vuonna 2008 Jenkins.

Jenkins järjestelmä on avoimen lähdekoodin eli tuote on katsottavissa, tutkittavissa ja vaihdettavissa. Muuten, se luotiin perusteella Java. Jenkinsin avulla voit automatisoida osan ohjelmistokehitysprosessista ilman ihmisen puuttumista. Tämä järjestelmä on suunniteltu varmistamaan jatkuva ohjelmistointegraatio. vau vau.

Jatkuva integraatio (Jatkuva integrointi, CI) on ohjelmistokehitysprosessi, jonka tarkoituksena on jatkuvasti työkopioiden yhdistäminen yhteiseksi kehityslinjaksi ja suorittaa käynnissä olevia automatisoituja projektin koontiversioita mahdollisten virheiden tunnistamiseksi ja integrointiongelmien ratkaisemiseksi nopeasti. Tässä on sellainen kuljetin.

Toisin sanoen kyseessä on hankkeen useiden luonnosversioiden (luonnosten) eli kopioiden luominen projektin esikokoonpanossa.

Tällä hetkellä Jenkinsiä käytetään melkein kaikissa nykyaikaisissa yrityksissä, joissa tarvitaan sovellusten automaattista käyttöönottoa sekä erilaisten tehtävien kätevää hallintaa.

Selvitetään ensin, mitä käyttöönotto on yleensä. Englannista" ottaa käyttöön"kääntää nimellä" käyttöönottoa". Ja tämä on koko prosessi toimenpiteitä, jotka tekevät ohjelmistotuotteen käyttövalmiiksi:

• vapauttaa;
• asennus;
• aktivointi;
• sopeutumista;
• päivittää;
• korjaus virheitä ja muut.

Automaattinen käyttöönotto on käyttöönottoa automaattisten ratkaisujen avulla.

Monet käyttäjät sanovat: "Miksi tarvitset Jenkins, kun on Buildbot?. Meillä on vastaus.

Jenkinsin tärkeimmät edut ja erot ovat, että tavallinen, tavallinen ohjelmoija tai esimies, jolla ei ole johtamiskokemusta, voi ymmärtää sen. Ja hän tekee sen lyhyessä ajassa.

Voit tietysti määrittää ohjelmiston Buildbotissa, mutta sen jatkaminen vaatii erityisen koulutetun henkilön, mikä ei ole kovin kätevää.

Jos tapahtuu tai havaitaan epätyypillinen virhe, Jenkins korjaa tämän ongelman lisälaajennuksilla ilman ihmisen apua. Jenkins on ilmainen työkalu, jolla on valtavia ominaisuuksia tuhansien laajennusten muodossa, joita lisätään ja päivitetään jatkuvasti.

Kytkeä tämä on ohjelmistolohko, joka on sisäänrakennettu ohjelmaan ja laajentaa sen ominaisuuksia, ja koska Jenkinsillä on paljon kaikenlaisia ​​​​laajennuksia, tällaisen automaattisen käyttöönoton mahdollisuudet eivät ole rajoitettuja.

Jenkins on standardoitu ohjelma, jonka jopa vähän IT-taustaa (kokemusta) omaava asiantuntija hallitsee muutamassa tunnissa.

On syytä huomata Jenkinsin tärkeimmät edut:

• toimintatila kahdessa tai useammassa ympäristössä kerralla;
• käyttöönotettujen ohjelmistojen luotettavuuden lisääntyminen;
• inhimillisiin tekijöihin liittyvien virheiden vähentäminen;
• henkilöstökulujen vähentäminen. Hei – hei hei käyttöjärjestelmä ja hinta;
• työprosessin yksinkertaistaminen (ei tarvitse palkata kallista kokeneiden asiantuntijoiden tiimiä; pieni joukko työntekijöitä ilman erityistä pätevyyttä pystyy käsittelemään Jenkinsin).

Katso YouTuben opetusohjelmat ja muista kokeilla tätä työkalua. Olemme varmoja, että et tule katumaan sitä ollenkaan. Mutta se ei ole aivan.

Oliko tämä artikkeli sinulle hyödyllinen?

Kerro minulle miksi?

Olemme pahoillamme, että artikkelista ei ollut sinulle hyötyä: (Ole hyvä ja kerro miksi se ei ole vaikeaa? Olemme erittäin kiitollisia yksityiskohtaisesta vastauksesta. Kiitos, että autat meitä tulemaan paremmiksi!

Kehitysympäristön progressiivinen osa harjoittaa jatkuvan integroinnin (CI) menetelmää, ja Live Typingin iOS-osasto päätti liittyä siihen ottamalla käyttöön palvelimen kokoonpanoille Jenkins-alustalle. Siitä lähtien alkoi täysin erilainen elämä.

Mitä saimme tuloksena:

1. Palvelin aloittaa rakentamisen:
   1. webhookilla, jos työnnetään päähaaraan;
   2. komennolla löysässä chatissa, joka osoittaa halutun haaran ja lisäosan. parametrit.
2. Suorittaa yksikkö- ja käyttöliittymätestejä.
3. Saa seuraavat mittarit:
   1. koodin kattavuus testeillä;
   2. koodirivien määrä;
   3. koodin kopiointi;
   4. koodin syklomaattinen monimutkaisuus.
4. Arkistoi projektin ipa:ssa, lähettää sen sitten kokoonpanopalvelimelle (oman suunnittelun) ja lähettää linkin kokoonpanoon löysälle.

Aloita lukemalla seuraavat vastuuvapauslausekkeet ja ymmärtämällä, onko oppaamme yhteensopiva tehtäviesi kanssa:

1. palvelin otettiin käyttöön iOS-kehityksen tarpeisiin;
2. useimpien apuohjelmien asennus homebrew'n kautta, mukaan lukien itse Jenkins (nopeat päivitykset ja helppokäyttöisyys);
3. xcodebuilderin käyttäminen kaikkiin kokoonpanotestaustehtäviin (hylkäsimme xctoolin käytön, koska emme pystyneet suorittamaan käyttöliittymätestejä);
4. Käytämme GitLabia arkistona;
5. Käytämme kokoonpanojen säilyttämiseen omaa suunnitteluamme. Jokaiselle koontiversiolle luodaan yksilöllinen URL-osoite. Avaa sitten linkki mobiililaitteeltasi selaimessa ja napsauta "Asenna" - Enterprise-tilin ansiosta kuka tahansa voi asentaa sovelluksen puhelimeensa. Tiedostojen lähettämiseen palvelimellemme liittyvien toimien erityispiirteiden vuoksi tätä vaihetta ei kuvata artikkelissa.
6. Kaikissa projekteissamme käytetään CocoaPods-riippuvuuden hallintajärjestelmää.

Opas osoittautui melko hankalaksi, joten päätimme jakaa sen kahteen osaan. Tämä osa kattaa Jenkinsin perusasennuksen ja konfiguroinnin.

Mitä tarvitaan:

1. Mac, johon on asennettu OS X ja Xcode (Meidän tapauksessamme MacBook Pro 2011, jossa on OS X 10.11.4);
2. muutama tunti vapaa-aikaa.

Jenkins-käyttäjän luominen ja sen määrittäminen

Käyttäjä voidaan luoda joko konsolin kautta tai graafisen käyttöliittymän avulla. On epätodennäköistä, että toisessa vaihtoehdossa on vaikeuksia, joten meidän on parempi harkita ensimmäistä ():

#Sovellukset-ryhmän luominen dseditgroup -o create -n . -u käyttäjätunnus -p -r Sovellukset -sovellukset #Hae ryhmän tunnus sudo dscl . -read /Ryhmät/sovellukset #Hanki luettelo käyttäjien tunnisteista (tarvitset yksilöllisen tunnisteen käyttäjälle) sudo dscl . -list /Users UniqueID #Luo käyttäjä (tunnistearvojen on oltava yksilöllisiä) sudo dscl . -luo /Users/jenkins sudo dscl . -create /Users/jenkins PrimaryGroupID 777 sudo dscl . -luo /Users/jenkins UniqueID 1777 sudo dscl . -luo /Users/jenkins UserShell /bin/bash sudo ddcl. -create /Users/jenkins RealName "Jenkins" sudo dscl . -luo /Käyttäjät/jenkins NFSHomeDirectory /Käyttäjät/jenkins sudo dscl . -passwd /Käyttäjät/jenkins #Luo kotihakemisto ja aseta siihen oikeudet sudo mkdir /Käyttäjät/jenkins sudo chown -R jenkins /Käyttäjät/jenkins

Käyttäjämme on valmis, ja nyt meidän on mentävä hänen taakseen. Voimme kirjautua sisään graafisen käyttöliittymän kautta tai konsolin avulla:

Sudo -u jenkins -i

Huomio: Suoritamme kaikki muut toiminnot Jenkins-käyttäjän alaisuudessa.

Tarvittavien ohjelmien asentaminen

Jenkinsin asentamiseen käytämme Homebrew-paketinhallintajärjestelmää. Tulevaisuudessa tämä yksinkertaistaa myös lisäpakettien asennus- ja päivitysprosessia, joita käytämme koodimittareiden hankkimiseen.

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

2. Jenkinien asentaminen:

Brew asentaa jenkins

Cocoapods-riippuvuuden hallintajärjestelmän asentaminen:

Sudo gem install -n /usr/local/bin cocoapods

Jotta palvelimemme käynnistyisi automaattisesti, kun järjestelmä käynnistyy, meidän on määritettävä vastaavan tehtävän käynnistys käynnistettäessä. Meillä on mahdollisuus tehdä tämä LaunchAgentsin tai LaunchDaemonin kautta. Käytämme LaunchAgentteja, koska... tämä yksinkertaistaa* jatkotyötä Jenkinsin kanssa. Katso vain alla olevaa taulukkoa ymmärtääksesi tämän:

*Daemonin läpikäymisen suurin ongelma on, että et voi suorittaa testausta ilman iOS-simulaattoria (voit lukea lisää demonin ja agentin käytön eroista)

LaunchAgents-valinnan vuoksi meidän on kuitenkin ratkaistava ongelma, joka liittyy siihen, että käyttäjällä ei ole sisäänkirjautumista, kun järjestelmä käynnistyy. Tätä varten sinun on määritettävä automaattinen sisäänkirjautuminen. Tiedän vain yhden tavan tehdä tämä: graafisen käyttöliittymän kautta (Järjestelmäasetukset -> Käyttäjät ja ryhmät -> Kirjautumisasetukset -> Automaattinen sisäänkirjautuminen). Jos joku tietää, miten tämä tehdään kuoren kautta, kirjoita kommentteihin!

Voit määrittää käynnistyksen LaunchAgentsin kautta seuraavasti:

1. purka demoni (se luotiin automaattisesti Jenkinsin asennuksen yhteydessä):

Sudo launchctl unload /Library/LaunchDaemons/homebrew.mxcl.jenkins.plist

2. poista demoni:

Sudo rm /Library/LaunchDaemons/homebrew.mxcl.jenkins.plist

3. luo agentti:

Cd /Users/jenkins/Library/LaunchAgents tap homebrew.mxcl.jenkins.plist

4. Määritä agentti vim-editorilla:

Vim homebrew.mxcl.jenkins.plist

Esimerkki plist-tiedoston sisällöstä:

Label homebrew.mxcl.jenkins Ohjelma-argumentit /usr/bin/java -Dmail.smtp.starttls.enable=true -purkki /usr/local/opt/jenkins/libexec/jenkins.war -httpListenAddress=0.0.0.0 --httpPort=8080 RunAtLoad Käyttäjänimi jenkins

Tässä kannattaa kiinnittää huomiota httpListenAddress-kenttään, jonka arvo on 0.0.0.0 ja httpPort-kenttään, jonka arvo on 8080 - näin palvelin "kuuntelee" kaikkia määritetyn portin IP-osoitteita.

Muistutan sinua: sulje ja tallenna tiedosto vim-editoriin kirjoittamalla: wq
Asennuksen jälkeen Jenkins on oletusarvoisesti saatavilla osoitteessa 127.0.0.1 (localhost).
Jos haluat käyttää ulkoista verkkoa, voit välittää reitittimen portteja: 8080 Jenkinsin verkkoliittymää varten ja 22 porttia ssh:n kautta.

Laajennusten asentaminen Jenkinsille

Siirry Jenkins-palvelimeen -> Määritä Jenkins -> Hallitse laajennuksia. "Saatavilla"-välilehdeltä löydämme ja asennamme seuraavat laajennukset:

1. Rooliperusteinen valtuutusstrategia - turvallisuuden varmistaminen. Mahdollistaa käyttäjäryhmien luomisen oikeuksien jakelulla;
2. GitLab Plugin ja Gitlab Hook Plugin - laajennukset gitlabin kanssa työskentelemiseen;
3. Xcode-integraatio - integrointi Xcoden kanssa;
4. Avainnippujen ja hallintaprofiilien hallinta – helpottaa hallintaprofiilien käyttöä.

Jenkinsin perusasetukset

Siirry Jenkinsin verkkokäyttöliittymän kautta kohtaan "Asetukset" ja sitten "Järjestelmän asetukset" -osioon. Mihin tässä kannattaa kiinnittää huomiota:

1. Xcode Builderin asetukset. Jos asensit Xcoden vakiohakemistoon, sinun ei tarvitse muuttaa asetuksia. Muussa tapauksessa sinun on määritettävä polku määritetyille komponenteille. Koska aloitimme palvelimen LaunchAgentsilla, Xcodella on pääsy login.keychain-tiedostoon. Mutta jos haluat pelata varman päälle, voit lisätä tähän osioon avaimenperän, kuten kuvakaappauksessa on osoitettu (tämän jälkeen napsauta kuvaa nähdäksesi).

Nyt voimme ladata tarvittavat sertifikaatit graafisen käyttöliittymän tai shellin kautta login.keychainiin, ja Xcode hakee automaattisesti tarvitsemansa sertifikaatit rakennusaikana.

2. Voit määrittää pääsyn ssh:n kautta seuraavasti:

a. luo shh-avain, jos sitä ei ole olemassa (esimerkin ohjeet löytyvät);

b. lisää avain CVS-osioon;

c. Pääset GitLabiin siirtymällä Tunnistetiedot-osioon Jenkinsin verkkokäyttöliittymän pääsivulla. Täällä meidän on lisättävä yksityinen avain käyttäjällemme (Jenkins tässä tapauksessa GitLabiin rekisteröitynyt käyttäjä). Voit liittää sen suoraan alla olevan esimerkin mukaisesti tai määrittää polun siihen:

d. Itse GitLabin asetuksissa sinun on määritettävä vastaava julkinen avain:

3. Käytämme suojauksen määrittämiseen Role-based Authorization Strategy -laajennusta. Siirrytään asetuksiin Jenkinsin verkkokäyttöliittymän kautta ja sitten Hallitse ja määritä rooleja -osioon. Täällä voimme luoda erilaisia ​​käyttäjille ja ryhmille osoitettuja rooleja ja määrittää heille oikeudet tiettyjen toimintojen suorittamiseen. Täällä jokainen tekee kaiken oman harkintansa mukaan. Mutta jos olet määrittänyt ulkoisen pääsyn palvelimeen, suosittelen, että poistat kaikki oikeudet "vierailijalta".

Työpaikan luominen ja projektin rakentaminen

1. Valitse Jenkinsin verkkokäyttöliittymän pääsivulta "Luo kohde". Valitse seuraavaksi kohta "Luo tehtävä ilmaisella kokoonpanolla" ja kirjoita projektin nimi;
2. Työasetussivulla menemme ensin "Lähdekoodin hallinta" -välilehdelle ja määritämme projektin lataamisen GitLabista. Täällä meidän on syötettävä projektimme arkiston osoite, ilmoitettava millä tunnistetiedoilla palvelimella on pääsy GitLabiin ja mikä projektin haara on rakennettava:

3. Siirry seuraavaksi "Kokoonpano"-osioon. Jos käytät CocoaPods-riippuvuuden hallintajärjestelmää etkä lisää Pod-tiedostoja gitiin, sinun on lisättävä "Run shell command" -koontivaihe suorittaaksesi podien asennuksen:

#!/bin/bash -l vienti LANG=UTF-8 pod install if [ $(($(päivämäärä +"%s") - $(stat -f %m Podfile))) -le 60 ]; sitten pod asenna fi

4. Lisää koontivaihe: Xcode. Jos käytät CocoaPods-riippuvuuden hallintajärjestelmää, sinun ei tule määrittää arvoa Kohde-kenttään, vaan määritä Advanced Xcode build options -osiossa suoritettavan mallin ja .xcworkspace-tiedoston nimi. Esimerkki minimaalisesta kokoonpanosta näkyy alla olevissa kuvakaappauksissa:

On syytä huomata, että projektisi asetuksissa suoritettava skeema on merkittävä jaetuksi (säilö voi olla joko työtila tai projekti):

Työskentely varmenteiden ja provisiointiprofiilin kanssa

Keychains and Provisioning Profiles Management -laajennuksen ansiosta voit yksinkertaistaa huomattavasti provisiointiprofiilin asentamista.

Käyttöönottoprofiilin lisääminen:

1. mene Jenkinsin asetuksiin;
2. valitse luettelosta Avainnippujen ja hallintaprofiilien hallinta;
3. Napsauta "Valitse tiedosto" -painiketta, etsi hallintaprofiilisi ja napsauta Lataa.

Jos haluat määrittää tietyn hallintaprofiilin, tarvittaessa "Build Environment" -osion työasetuksissa sinun on asetettava Mobile Provisioning Profiles -lippu ja valittava yksi ladatuista profiileista:

Sitten Xcode-asetuksissa sinun on asetettava mukautetut xcodebuild-argumentit, kuten kuvakaappauksessa:

Voit ladata varmenteen login.keychain-avainnippuun käyttämällä graafista käyttöliittymää (klikkaa vain varmennetta), mutta tämä ei aina ole mahdollista. Siksi harkitsemme hieman monimutkaisempaa vaihtoehtoa - lisäämistä ssh:n kautta:

1. lataa vaadittu varmenne Mac-tietokoneellesi ja asenna se paikalliseen avainnippuun kaksoisnapsauttamalla;
2. siirry avainnippuun, etsi tarvittava varmenne ja vie avain .p12-muotoon;
3. siirrä varmenne palvelimelle:

Scp-sertifikaatti.crt jenkins@server:/Käyttäjät/jenkins

sertifikaatti - varmenteen nimi;

jenkins - käyttäjätunnus;

palvelin - palvelimen osoite;

:/Users/jenkins - tallennetun tiedoston polku;

(Voit käyttää parametria halutun portin määrittämiseen muodossa: scp -P 20 certificate.crt jenkins@server:/Users/jenkins)

4. siirrä avain palvelimelle:

Scp privatekey.p12 jenkins@server:/Käyttäjät/jenkins

5. muodosta yhteys palvelimeen ssh:n kautta:

Ssh jenkins@server

6. avoin pääsy avainnippuun:

Security unlock-keychain -p-salasana /Users/jenkins/Library/Keychains/login.keychain

7. asenna varmenne:

Turvallisuuslisäsertifikaatit ./certificate.crt

8. kopioi avain:

Tietoturvan tuonti privatekey.p12 -k /Users/jenkins/Library/Keychains/login.keychain -P salasana -A

Ennen käynnistystä

Nyt olemme valmiita napsauttamaan Built Now -painiketta Jenkinsin verkkokäyttöliittymän pääsivulla tai itse projektisivulla. Napsauta ja siirry aloitetun koontiversion Console Output -osioon. Täältä löydät lokeista paljon hyödyllistä tietoa, myös virheitä.
Jos teit kaiken oikein, rakennuksen lopussa lokin lopussa ilmoitetaan: Valmis: SUCCESS, ja Jenkinsin pääsivulla rakennuksen nimen vieressä syttyy sininen SUCCESS-merkkivalo.

Kaikkien tarvittavien ohjelmien ja lisäosien asennus.

Ensin asennetaan ohjelmia, jotka keräävät meille tilastoja:

#Koodin kattavuuden määrittäminen testeillä brew install gcovr #Koodilaskuririvi brew install cloc #Koodilaskuririvi, vaihtoehtoinen brew install sloccount #Koodin monistamisen löytäminen brew install pmd #Testitulosraporttien luominen (luo myös tietoja oclintille) sudo gem install xcpretty #Staattinen koodianalyysi brew tap oclint/formulae brew install oclint

Hidas chat-integraatio

Jotta voimme vastaanottaa koontiversion tilailmoituksia Slackin tiimikeskustelussa, meidän on lisättävä asianmukainen Jenkins-integraatio Slackin asetuksiin. Se voi olla tehty .
Integroinnin luomisen jälkeen luodaan yksilöllinen tunnus, joka on lisättävä Jenkins-asetuksiin (tai erillisen työn asetuksiin) - kuten kuvakaappauksessa olevassa esimerkissä:

Seuraavaksi määritämme koontiversioiden käynnistämisen käyttämällä Slackin sisäänrakennettua komentomekanismia. Ensin meidän on lisättävä integraatio. Voit tehdä tämän siirtymällä Mukautetut integraatiot -osion Slash-komennot -alaosioon ja napsauttamalla Lisää määritykset -painiketta. Tämä toimenpide voidaan suorittaa.
Kun määrität, sinun on määritettävä tiimisi nimi, valittava POST-tiedonsiirtotapa ja määritettävä URL-osoite, johon pyyntö lähetetään.

Katsotaanpa yksityiskohtaisemmin esimerkkiä URL-osoitteen muodostamisesta pyyntöä varten. Esimerkki-URL-osoite näyttää tältä:

Http://server:8080/buildByToken/buildWithParameters?job=JenkinsExecutor&token=XXXXXXXXXXXXXXXXXX

Jaetaan se osiin:

1. palvelin on palvelimesi ulkoinen osoite. Tarvittaessa ilmoitamme tässä myös vaaditun portin (tapauksessamme 8080);
2. buildByToken on Build Authorization Token Root Pluginin tarjoama ominaisuus. Mahdollistaa työn käynnistämisen tunnuksen määrittävän linkin kautta (tässä tapauksessa XXXXXXXXXXXXXXXXX);
3. buildWithParameters - osoittaa, että parametroitu koontiversio on suoritettava;
4. JenkinsExecutor on työpaikan nimi, jonka luomme ja käytämme muiden töiden käynnistämiseen. Siitä keskustellaan jäljempänä;
5. XXXXXXXXXXXXXXXXXXXX - tunnuksen arvo, joka asetetaan liitännäisasetuksissa kunkin yksittäisen työn kokoonpanossa.

Esimerkkinä käytämme seuraavaa komentorakennetta:

/build Esimerkki testipäällikkö

1. /build - tiimimme nimi;
2. Esimerkki - työn nimi;
3. testi - apulippu, joka liittyy testien suorittamiseen ja raporttien luomiseen mittareilla;
4. master - haara rakentamiseen.

Tarkastelun kokoonpanon avulla voimme käynnistää minkä tahansa projektin rakentamisen, joka osoittaa halutun haaran, ja käytetään yhtä komentoa: /build.

Aputyön määritys - JenkinsExecutor

Tarvitsemme tätä työtä voidaksemme käynnistää muita työpaikkoja. On myös mahdollista käsitellä virheitä, jos käyttäjä syöttää olemattoman projektin, ja lisätä tietoja komennosta (eräänlainen apu).
Menemme palvelimelle ja luomme uuden tehtävän ilmaisella kokoonpanolla ja nimellä JenkinsExecutor. Seuraavaksi työn asetuksissa asetamme lipun, joka osoittaa, että kokoonpano on parametroitu ja hyväksyy tekstiparametrin. Kun suoritat komennon Slackissa, kaikki tiedot (esimerkkipäätesti) lähetetään yhtenä rivinä tekstimuuttujassa.

Nyt meidän on poimittava arvot tekstimuuttujasta. Voit tehdä tämän siirtymällä "Build" -osioon ja lisäämällä "execute shell command" -koontivaihe. Esimerkkikomento:

#Luo joukko merkkijonoelementtejä välilyönnillä erotettuina IFS=" " lue -taulukko<<< "$text" #Согласно нашему примеру, первое значение - это название проекта JOB_NAME=${array} #Флаг, ответственный за тесты TEST=${array} #Название ветки проекта BRANCH=${array} #Если необходимо, можно также получить другие значения: USER_NAME=${user_name} CHANNEL_NAME=${channel_name}

Aloittaaksesi rakentamisen parametreilla, lähetämme POST-pyynnön tietyn työn suorittamiseksi. Voit tehdä tämän lisäämällä seuraavan rivin edelliseen komentotulkkikomentoon:

Curl -d TEST=$(TESTI) -d BRANCH=$(BRANCH) -X POST \ -u käyttäjätunnus:salasana http://127.0.0.1:8080/job/$(JOB_NAME)/buildWithParameters

Huomaa, että kaikki käynnistetyt kokoonpanot on parametroitava!

Rakenna asetukset

1. Ensimmäinen asia, johon sinun tulee kiinnittää huomiota työtä määritettäessä, on se, että kokoonpano on parametroitava. Tätä varten aseta sopiva lippu, lisää tekstiparametrit BRANCH ja TEST ja aseta niiden oletusparametrit:

Tässä on syytä huomata, että sinun on lisäksi lisättävä oletusarvo BRANCH-muuttujalle. Tosiasia on, että jos käynnistät koontiversion Slackista määrittämättä haaraa, BRANCH-muuttujalla on tyhjä arvo ja vastaavasti tapahtuu virhe. Tätä varten lisäämme Suorita rakennusvaihe ennen SCM:n suorittamista -lipun Build Environment -osioon. Sitten lisäämme "suorita shell-komento" -vaiheen ja lisäämme ympäristömuuttujat -vaiheen. Noudatetaan esimerkkiä:

4. Rakennusvaihe alkaa suorittamalla komentotulkkikomento, joka asentaa Podit, jos tiedosto on päivitetty:

Jos [ $(($(päivämäärä +"%s") - $(stat -f %m Podfile))) -le 60 ]; sitten pod asenna fi

Asetetaan sitten mukavuussyistä joitain muuttujia projektille ja kirjoitetaan ne tiedostoon:

#Nimi.ipa-tiedoston PROJECT_NAME="Esimerkki" #Tiedoston nimi.xcworkspace WORKSPACE_NAME="Esimerkki" #Suoritettavan ohjelman nimi SCHEME_NAME="Esimerkki" #Kansion nimi lähteineen. Käytetään koodirivien laskemiseen FOLDER_NAME_WITH_CODE="Esimerkki" #Kirjoita muuttujat tiedostoon käytettäväksi muissa koontivaiheissa echo PROJECT_NAME=$PROJECT_NAME > build.properties echo WORKSPACE_NAME=$TYÖPAJAN_NAME >> build.properties echo SCHEME_NAME=$SCHEME_NAME >> build.properties

Asetetusta TEST-parametrista riippuen aloitamme tai ohitamme testausvaiheen ja raportin luomisen. Esimerkki siitä, miltä tämä voisi näyttää:

Jos [ "$TEST" == "testi" ]; sitten #Raporttikansion luominen, johon laitamme raportit, jos [ ! -d "raportit" ]; sitten mkdir "raportit" fi #Testaus ja raporttien luominen analysointia varten xcodebuild -workspace $(WORKSPACE_NAME).xcworkspace \ -scheme $(SCHEME_NAME) \ -configuration Debug \ -sdk iphonesimulator \ -destination "platform=iOS Simulator,name=iPhone 6 " \ -IDECustomDerivedDataLocation="build_ccov" \ GCC_GENERATE_TEST_COVERAGE_FILES=KYLLÄ \ GCC_INSTRUMENT_PROGRAM_FLOW_ARCS=KYLLÄ \ puhdas testi | xcpretty -r junit -o reports/junit.xml -r json-compilation-database -o compile_commands.json #Julkaise JUNIT-testi = **/reports/junit.xml #Analysoi koodin oclint-json-compilation-database syntaktinen monimutkaisuus - v -e Pods -- \ -rc=LONG_LINE=200 \ -rc=NCSS_METHOD=60 \ -rc=LONG_METHOD=100 \ -rc=MINIMUM_CASES_IN_SWITCH=1 \ -report-type pmd \ -o reports/oclint.xml \ - max -priority-1 1000 \ -max-priority-2 1000 \ -max-priority-3 1000 #Julkaise PMD-analyysi = **/reports/oclint.xml #Koodipeittoanalyysi gcovr --object-directory="build_ccov/$ (SCHEME_NAME)/Build/Intermediates/$(SCHEME_NAME).build/"\ "Debug-iphonesimulator/$(SCHEME_NAME).build/Objects-normal/x86_64/" \ --xml \ --print-summary \ --exclude ".*Testit.*" \ --exclude ".*Libs.*" \ --exclude ".*ExternalFrameworks.*" \ --exclude ".*Platforms.*" \ --output=reports/coverage.xml #Julkaise Coberturan kattavuus = **/reports/coverage.xml #Koodirivien laskenta (kaksi vaihtoehtoa): cloc $(TYÖPAIKKA)/$(KANSIJOIDEN_NIMI_WITH_CODE) -tiedostoittain -ohita-ainutlaatuisuus -xml -out=$(TYÖPAIKKA) / reports/cloc.xml #Julkaise SLOCCount-analyysi = **/reports/cloc.xml sloccount --kaksoiskappaleet --wide --details $(TYÖTILA)/$(KANSIJOIDEN_NIMI_KOODI) -v > reports/sloccount.sc #Julkaise SLOCCount-analyysi = **/reports/sloccount.sc #Koodin monistamisen analyysi pmd cpd --tiedostot $(TYÖTILA)/$(KANSIJO_NIMI_WITH_CODE) \ --minimi-tokens 10 --language objectc \ --encoding UTF-8 \ --format net. sourceforge.pmd.cpd.XMLRenderer | iconv -f macRoman -t utf-8 | sed "s/MacRoman/UTF-8/g" > reports/duplicated-code.xml #Julkaise kaksoiskoodi = **/reports/duplicated-code.xml muuten kosketa reports/junit.xml #Tätä riviä tarvitaan virheiden välttämiseksi kokoonpanon aikana liitännäisen raportin luomisen vuoksi Julkaise JUNIT testitulosraportti fi

Tässä vaiheessa voimme lähettää vastaanotetun .ipa-tiedoston, jos se onnistuu, minne sitä tarvitsemme (palvelimelle, sähköpostilla jne.). Jos haluat lähettää tiedostoja palvelimelle SFTP:n kautta ja käytät Publish Over SSH -laajennusta, sinun on siirryttävä "Build Environment" -osioon, asetettava lippu Lähetä tiedostoja tai suoritettava komentoja SSH:n kautta koontiversion suorittamisen jälkeen ja määritä laajennus tarpeidesi mukaan.

Viimeinen vaihe, joka meidän on lisättävä, on Slack Notification, joka, arvasit sen, lähettää ilmoituksia Slackiin. Laajennuksen lisäasetuksissa voit määrittää yksittäisiä asetuksia nykyiselle työlle. On syytä huomata, että voit määrittää viestiksi muuttujan (esimerkki: $MESSAGE ), jonka arvoa voidaan muuttaa rakentamisen eri vaiheissa ja lähettää siten informatiivisempia viestejä Slackiin.

Tässä vaiheessa CI:n käyttöönottoa voidaan pitää valmiina. Toivomme, että artikkelistamme on sinulle hyötyä.