Jatkuva integrointi (CI) ja jatkuva jakelu (CD) ilmentävät kulttuuria, toimintaperiaatteita ja käytäntöjen kokoelmaa, joiden avulla sovelluskehitystiimit voivat toimittaa koodimuutoksia useammin ja luotettavammin. Toteutus tunnetaan myös nimellä CI / CD putki.
CI / CD on yksi parhaista käytännöistä, joita devops-tiimit voivat toteuttaa. Se on myös ketterä metodologian paras käytäntö, koska sen avulla ohjelmistokehitystiimit voivat keskittyä vastaamaan liiketoiminnan vaatimuksiin, koodin laatuun ja tietoturvaan, koska käyttöönottovaiheet ovat automatisoituja.
CI / CD määritelty
Jatkuva integraatio on koodausfilosofia ja käytäntöjoukot, jotka ohjaavat kehitystiimejä toteuttamaan pieniä muutoksia ja tarkistamaan koodin versionhallintavarastoihin usein. Koska useimmat modernit sovellukset edellyttävät koodin kehittämistä eri alustoille ja työkaluille, tiimi tarvitsee mekanismin muutosten integroimiseksi ja vahvistamiseksi.
CI: n teknisenä tavoitteena on luoda yhtenäinen ja automatisoitu tapa rakentaa, pakata ja testata sovelluksia. Kun integraatioprosessi on yhtenäinen, tiimit tekevät todennäköisemmin koodimuutoksia useammin, mikä johtaa parempaan yhteistyöhön ja ohjelmistojen laatuun.
Jatkuva toimitusjatkuu, missä jatkuva integraatio loppuu. CD automatisoi sovellusten toimituksen valittuihin infrastruktuuriympäristöihin. Suurin osa tiimeistä työskentelee useiden muiden kuin tuotantoympäristöjen, kuten kehitys- ja testausympäristöjen kanssa, ja CD varmistaa, että koodimuutokset voidaan siirtää automaattisesti.
CI / CD-työkalut auttavat tallentamaan ympäristökohtaiset parametrit, jotka on pakattava jokaisen toimituksen mukana. CI / CD-automaatio suorittaa sitten kaikki tarvittavat palvelupyynnöt verkkopalvelimille, tietokannoille ja muille palveluille, jotka on ehkä käynnistettävä uudelleen tai noudattavat muita menettelyjä sovelluksia asennettaessa.
Jatkuva integrointi ja jatkuva toimitus edellyttävätjatkuva testauskoska tavoitteena on toimittaa laadukkaita sovelluksia ja koodia käyttäjille. Jatkuva testaus toteutetaan usein joukkoa automaattisia regressio-, suorituskyky- ja muita testejä, jotka suoritetaan CI / CD-putkessa.
Kypsä CI / CD-devops-käytäntö on mahdollisuus toteuttaa jatkuva käyttöönotto, jossa sovelluksen muutokset suoritetaan CI / CD-putkilinjan kautta ja välittyvät koontiversiot otetaan käyttöön suoraan tuotantoympäristöihin. Ryhmät, jotka harjoittavat jatkuvaa toimitusta, valitsevat tuotantoon päivittäisen tai jopa tunnin aikataulun, vaikka jatkuva toimitus ei ole aina optimaalinen kaikille liiketoimintasovelluksille.
Liittyvä video: Kuinka toimittaa koodi nopeammin CI / CD: llä
Kuinka jatkuva integraatio parantaa yhteistyötä ja laatua
Jatkuva integraatio on prosessimekaniikan ja jonkin verran automaatiota tukeva kehitysfilosofia. CI: tä harjoitellessaan kehittäjät sitovat koodinsa versionhallintavarastoon usein, ja useimmilla tiimeillä on vähimmäistaso koodin antamiseen vähintään päivittäin. Tämän taustalla on se, että vikoja ja muita ohjelmistolaatuongelmia on helpompi tunnistaa pienemmistä koodieroista pikemminkin kehittyneiden suurempien sijaan. Lisäksi kun kehittäjät työskentelevät lyhyemmillä sitoutumisjaksoilla, on vähemmän todennäköistä, että useat kehittäjät muokkaavat samaa koodia ja vaativat yhdistämistä sitoutuessaan.
Jatkuvaa integraatiota toteuttavat tiimit aloittavat usein versionhallinnan määrityksillä ja käytännön määrittelyillä. Vaikka koodin tarkistus tapahtuu usein, ominaisuudet ja korjaukset toteutetaan sekä lyhyellä että pidemmällä aikavälillä. Jatkuvaa integraatiota harjoittavat kehitystiimit käyttävät erilaisia tekniikoita hallitsemaan, mitkä ominaisuudet ja koodi ovat valmiita tuotantoon.
Monet joukkueet käyttävät ominaisuusliput, määritysmekanismi ominaisuuksien ja koodin kytkemiseksi päälle tai pois päältä ajon aikana. Ominaisuudet, joita vielä kehitetään, on kääritty ominaisuuslippuilla koodiin, otettu käyttöön päähaaran kanssa tuotantoon ja sammutettu, kunnes ne ovat käyttövalmiita. Tuoreen tutkimuksen mukaan 63 prosenttia ominaisuuslippuja käyttävistä joukkueista raportoi paremmasta testauksesta ja korkealaatuisemmista ohjelmistoista. Ominaisuuksien merkintätyökalut, kuten CloudBees Rollout, Optimizely Rollouts ja LaunchDarkly, integroituvat CI / CD-työkaluihin ja mahdollistavat ominaisuustason määritykset.
Toinen tekniikka ominaisuuksien hallitsemiseksi onversionhallinnan haarautuminen. Haarautumisstrategia, kuten Gitflow, valitaan määrittämään protokollat siitä, kuinka uusi koodi sulautetaan vakiohakemistoihin kehitystä, testausta ja tuotantoa varten. Niille, jotka vievät pidemmät kehitysjaksot, luodaan lisäominaisuushaaroja. Kun ominaisuus on valmis, kehittäjät voivat yhdistää muutokset ominaisuushaaroista ensisijaiseen kehityshaaraan. Tämä lähestymistapa toimii hyvin, mutta voi olla vaikea hallita, jos useita ominaisuuksia kehitetään samanaikaisesti.
Itse rakennusprosessi automatisoidaan pakkaamalla kaikki ohjelmistot, tietokanta ja muut komponentit. Jos esimerkiksi kehität Java-sovellusta, CI pakkaa kaikki staattiset verkkopalvelintiedostot, kuten HTML, CSS ja JavaScript, yhdessä Java-sovelluksen ja mahdollisten tietokannan komentosarjojen kanssa.
CI ei vain pakkaa kaikkia ohjelmistoja ja tietokantakomponentteja, vaan automaatio suorittaa myös yksikötestit ja muut testaukset. Tämä testaus antaa kehittäjille palautetta siitä, että heidän koodimuutoksensa eivät rikkoneet olemassa olevia yksikötestejä.
Suurin osa CI / CD-työkaluista antaa kehittäjille mahdollisuuden käynnistää kysynnän perusteella versiohallinnan arkistossa olevien koodisitoumusten tai määritetyn aikataulun mukaisesti. Joukkueiden on keskusteltava kokoonpanoaikataulusta, joka toimii parhaiten tiimin koon, odotettavissa olevien päivittäisten sitoumusten määrän ja muiden sovelluksen näkökohtien mukaan. Paras käytäntö varmistaa, että sitoumukset ja koontiversiot ovat nopeita, muuten se voi estää tiimejä, jotka yrittävät koodata nopeasti ja sitoutua usein.
Jatkuva testaus ylittää testausautomaation
Automaattiset testauskehykset auttavat laadunvarmistusinsinöörejä määrittelemään, suorittamaan ja automatisoimaan erityyppisiä testejä, jotka voivat auttaa kehitystiimejä tietämään, onnistuuko ohjelmiston koontiversio vai epäonnistuminen. Ne sisältävät toiminnallisuustestit, jotka kehitetään jokaisen sprintin lopussa ja kootaan a regressiotesti koko sovellukselle. Nämä regressiotestit ilmoittavat sitten joukkueelle, onnistuiko koodimuutos yhdellä tai useammalla testillä, jotka on kehitetty sovelluksen kaikilla toiminnallisilla alueilla, joissa testit kattavat.
Paras käytäntö on antaa kehittäjille mahdollisuus vaatia kaikkia regressiotestejä tai niiden osajoukko paikallisissa ympäristöissä. Tämä vaihe varmistaa, että kehittäjät sitovat koodin versionhallintaan vasta sen jälkeen, kun regressiotestit välittävät koodimuutokset.
Regressiotestit ovat vasta alkua. Suorituskykytestaus, API-testaus, staattisen koodin analyysi, tietoturvatestaus ja muut testausmuodot voidaan myös automatisoida. Avain on pystyä käynnistämään nämä testit joko komentorivillä, verkkokoukulla tai verkkopalvelulla ja että ne vastaavat onnistuneiden tai epäonnistuneiden tilakoodien avulla.
Kun testaus on automatisoitu, jatkuva testaus tarkoittaa, että automaatio on integroitu CI / CD-putkistoon. Jotkut yksikkö- ja toimintatestit voidaan integroida CI: hen, joka ilmoittaa ongelmista ennen integraatioprosessia tai sen aikana. Testit, jotka edellyttävät täyttä toimitusympäristöä, kuten suorituskyky ja suojaustestaus, integroidaan usein CD-levylle ja suoritetaan sen jälkeen, kun koontiversiot on toimitettu kohdeympäristöihin.
CD-putki automatisoi muutokset useisiin ympäristöihin
Jatkuva toimitus on automaatio, joka ajaa sovellukset toimitusympäristöihin. Suurimmalla osalla kehitystiimejä on tyypillisesti yksi tai useampi kehitys- ja testausympäristö, jossa sovelluksen muutokset tehdään testausta ja tarkistusta varten. CI / CD-työkalua, kuten Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo tai Travis CI, käytetään vaiheiden automatisointiin ja raportoinnin tarjoamiseen.
Tyypillisellä CD-putkilinjalla on rakennus-, testaus- ja käyttöönottovaiheet. Kehittyneemmät putkilinjat sisältävät monia näistä vaiheista:
- Koodin vetäminen versionhallinnasta ja koontiversio.
- Suoritetaan vaaditut infrastruktuurivaiheet, jotka on automatisoitu koodina pilviinfrastruktuurin nousemiseksi tai hajottamiseksi.
- Koodin siirtäminen tietojenkäsittelyympäristöön.
- Ympäristömuuttujien hallinta ja määrittäminen kohdeympäristöä varten.
- Sovelluskomponenttien siirtäminen sopiviin palveluihin, kuten web-palvelimet, API-palvelut ja tietokantapalvelut.
- Suorittamalla tarvittavat vaiheet palvelujen uudelleenkäynnistämiseksi tai uusien palvelupyyntöjen edellyttämien palvelupäätepisteiden soittamiseksi.
- Jatkuvien testien ja palautusympäristöjen suorittaminen, jos testit epäonnistuvat.
- Toimitetaan lokitietoja ja ilmoituksia toimituksen tilasta.
Esimerkiksi Jenkins-käyttäjät määrittelevät putkilinjansa Jenkins-tiedostossa, joka kuvaa eri vaiheita, kuten rakentamisen, testauksen ja käyttöönoton. Ympäristömuuttujat, vaihtoehdot, salaiset avaimet, sertifikaatit ja muut parametrit ilmoitetaan tiedostossa ja niihin viitataan vaiheittain. Viestiosio käsittelee virheolosuhteet ja ilmoitukset.
Kehittyneemmällä CD-levyllä voi olla muita vaiheita, kuten tietojen synkronoinnin suorittaminen, tietoresurssien arkistointi tai sovellusten ja kirjastojen korjaustöiden suorittaminen. CI / CD-työkalut tukevat tyypillisesti laajennusten markkinapaikkaa. Esimerkiksi Jenkins listaa yli 1500 laajennusta, jotka tukevat integrointia kolmansien osapuolten alustoihin, käyttöliittymää, hallintaa, lähdekoodien hallintaa ja koontiversioiden hallintaa.
Kun CI / CD-työkalu on valittu, kehitystiimien on varmistettava, että kaikki ympäristömuuttujat on määritetty sovelluksen ulkopuolelle. CI / CD-työkalut mahdollistavat näiden muuttujien asettamisen, muuttujien, kuten salasanojen ja tiliavainten, peittämisen ja niiden määrittämisen käyttöönoton yhteydessä kohdeympäristöön.
CD-työkalut tarjoavat myös koontinäyttö- ja raportointitoiminnot. Jos koontiversiot tai toimitukset epäonnistuvat, ne ilmoittavat kehittäjille virheistä. Ne integroituvat versionhallinta- ja ketteriin työkaluihin, joten niitä voidaan käyttää etsimään, mitkä koodimuutokset ja käyttäjätarinat muodostivat rakennelman.
CI / CD-putkistojen toteuttaminen Kubernetesilla ja palvelimettomilla arkkitehtuureilla
Monet CI / CD-putkistoja pilviympäristöissä käyttävät joukkueet käyttävät myös kontteja, kuten Docker, ja orkesterijärjestelmiä, kuten Kubernetes. Säiliöt mahdollistavat pakkaus- ja lähetyssovellukset tavallisilla, kannettavilla tavoilla. Säiliöiden avulla on helppo skaalata tai purkaa ympäristöjä, joilla on vaihteleva kuormitus.
Konttien, infrastruktuurin koodina ja CI / CD-putkilinjojen yhdessä käyttämistä on monia tapoja. Voit tutkia vaihtoehtoja tekemällä opetusohjelmia, kuten Kubernetes Jenkinsin kanssa tai Kubernetes Azure DevOpsin kanssa.
Palvelimettomat tietojenkäsittelyarkkitehtuurit tarjoavat uuden mahdollisuuden sovellusten käyttöönottoon ja skaalaamiseen. Palvelimettomassa ympäristössä pilvipalvelujen tarjoaja hallinnoi infrastruktuuria täysin ja sovellus kuluttaa resursseja tarpeen mukaan kokoonpanonsa perusteella. Esimerkiksi AWS: ssä Lambda-toimintoina toimivat palvelimettomat sovellukset ja käyttöönotot voidaan integroida Jenkinsin CI / CD-putkiin laajennuksella.
CI / CD mahdollistaa useamman koodin käyttöönoton
Yhteenvetona voidaan todeta, että CI-paketit ja testausohjelmistot rakentavat ja varoittavat kehittäjiä, jos heidän muutoksensa eivät onnistuneet yksikötesteissä. CD on automaatio, joka tarjoaa muutoksia infrastruktuuriin ja suorittaa lisätestejä.
CI / CD-putkistot on suunniteltu yrityksille, jotka haluavat parantaa sovelluksia usein ja vaativat luotettavaa toimitusprosessia. Lisäosa rakenteiden standardointiin, testien kehittämiseen ja käyttöönoton automatisointiin on valmistusprosessi koodimuutosten käyttöönottamiseksi. Kun se on paikallaan, se antaa tiimille mahdollisuuden keskittyä sovellusten parantamiseen ja vähemmän järjestelmän yksityiskohtiin sen toimittamiseksi tietokoneympäristöihin.
CI / CD on parhaita käytäntöjä, koska se korjaa kehittäjien välisen epätasapainon, joka haluaa vauhdittaa muutoksia usein, toiminnoilla, jotka haluavat vakaita sovelluksia. Kun automaatio on paikallaan, kehittäjät voivat ajaa muutoksia useammin. Operatiiviset ryhmät näkevät suuremman vakauden, koska ympäristöissä on vakiokonfiguraatiot, toimitusprosessissa on jatkuvaa testausta, ympäristömuuttujat erotetaan sovelluksesta ja palautusprosessit ovat automatisoituja.
CI / CD-putkistojen toteuttamisen vaikutusta voidaan mitata devops key performance -indikaattorina (KPI). KPI: t, kuten käyttöönottotiheys, muutosten läpimenoaika ja keskimääräinen aika palautumiseen (MTTR) tapahtumasta, paranevat usein, kun jatkuvan testauksen CI / CD otetaan käyttöön. CI / CD on kuitenkin vain yksi prosessi, joka voi ohjata näitä parannuksia, ja käyttöönottotaajuuksien parantamiseen on muita edellytyksiä.
CI / CD: n käytön aloittaminen vaatii kehitystiimejä ja operatiivisia tiimejä tekemään yhteistyötä tekniikoiden, käytäntöjen ja prioriteettien suhteen. Joukkueiden on kehitettävä yksimielisyys oikeasta lähestymistavasta liiketoimintaansa ja tekniikkaansa, jotta kun CI / CD on paikallaan, joukkue on mukana laivalla noudattamalla jatkuvasti käytäntöjä.
