DevOpsin hallinta tekoälyn avulla: seuraavan tason CI/CD-putkien rakentaminen

Vankan DevOps-perustan luominen ei enää ole kuukausia kestävä hanke. Oikealla lähestymistavalla ja työkaluilla myös pienissä projekteissa voidaan ja kannattaa ottaa käyttöön toimivat DevOps-käytännöt päivissä tai viikoissa. Siirrytään nyt CI/CD:n perusasioihin aloittamalla Git-työnkulusta.

Git-työnkulku: hyvän CI/CD:n perusta

Kuten kaikki tiedämme, selkeät ja hyvin dokumentoidut Git-työnkulun käytännöt ovat ratkaisevan tärkeitä jokaisessa onnistuneessa kehitysprojektissa, erityisesti DevOpsissa. Tässä näytän, miten sellainen voidaan rakentaa alusta alkaen ChatGPT 4:n avulla. Voit testata tuloksia käyttämällä samoja prompteja kuin minä tässä (edellyttää ChatGPT 4 -versiota).

Prompti 1

Ensimmäinen prompti toimii yleensä johdatuksena aiheeseen. Näin voit tarkastella alkuvaiheen vastausta ja hahmottaa keskustelun suuntaa. Yksi prompti riittää harvoin. Jatka lukemista nähdäksesi, miten ohjaan keskustelua eteenpäin. Ensimmäinen promptini on seuraava:

Anna minulle Git-työnkulun perusta, jonka pohjalta voin myöhemmin toteuttaa Continuous Integration- ja Continuous Deployment -putket työnkulun käytäntöjen päälle

GPT:n vastaus

Vankan Git-työnkulun perustan luominen on olennaista, jotta Continuous Integration (CI)- ja Continuous Deployment (CD) -putket voidaan toteuttaa tehokkaasti. Tässä on ehdotus perusmalliksi, jota voit käyttää lähtökohtana:...

Haarautumisstrategia:

• Main-haara: Tämä on ensisijainen haara, jossa HEADin lähdekoodi vastaa aina tuotantovalmiissa tilassa olevaa versiota.

• Develop-haara: Tämä haara toimii ominaisuuksien integrointihaarana. Se sisältää aina seuraavaa julkaisua varten toimitetut uusimmat kehitysmuutokset.

• Feature-haarat: Luo nämä haarat, kun aloitat uuden ominaisuuden kehittämisen. Haarauta develop-haarasta ja yhdistä muutokset takaisin develop-haaraan, kun ominaisuus on valmis.

• Release-haarat: Haarauta develop-haarasta, kun olet valmis valmistelemaan uutta tuotantojulkaisua. Näin yksi tiimi voi viimeistellä nykyistä julkaisua samalla, kun toinen jatkaa seuraavan julkaisun ominaisuuksien kehittämistä.

Hotfix-haarat: Näitä haaroja käytetään tuotantojulkaisujen nopeaan korjaamiseen. Ne muistuttavat release- ja feature-haaroja, mutta ne perustuvat main-haaraan ja yhdistetään sekä main- että develop-haaraan.

Continuous Integration (CI):

• Ota käyttöön CI-putki, joka ajaa automaattiset testit ja muut tarkistukset, kuten linttauksen, aina kun uusi commit pushataan mihin tahansa haaraan, erityisesti develop- ja feature-haaroihin.

Continuous Deployment (CD):

• Kun CI-putki menee läpi ja muutokset yhdistetään main-haaraan, ota muutokset automaattisesti käyttöön tuotannossa, jos ympäristösi mahdollistaa sen.

• Jos ympäristössä tarvitaan enemmän hallintaa, voit käynnistää käyttöönotot manuaalisesti main-haarasta.

Versionumerointi tunnisteilla:

• Merkitse main-haaran koodi versionumerolla jokaisen julkaisun jälkeen.

Dokumentaatio:

• Pidä projektin dokumentaatio ajan tasalla. Tämä koskee koodidokumentaation lisäksi myös työnkulku- ja putkiprosesseja.

Lisäksi mukana on osiot commit-käytännöistä, koodikatselmoinnista ja yhdistämisestä, mutta emme käsittele niitä tässä blogikirjoituksessa, vaikka ne ovatkin tärkeitä.

Yhteenveto Git-työnkulun perusmallin käytöstä

Jopa tekoäly näyttää korostavan Git-työnkulkujen merkitystä. Se ehdottaa erillisiä kehitys- ja release-haaroja, mikä on oikein toteutettuna hyvä strategia. Havainnollistamisen vuoksi esittelen kuitenkin suoraviivaisemman työnkulun, joka voi olla optimaalisempi.

Huomaa tärkeä asia: dokumentoi työnkulkusi ja putkesi! Tässä tekoälyn ajatusprosessi vaikuttaa olevan hyvin kartalla ja useimmiten todellisuutta parempi.

Selkeä viestintä näistä aiheista ja retrospektiivit varmistavat, että Developer Experience (DevEx) pysyy hyvänä.

Prompt #2

Nyt kun olemme saaneet alkuvastauksen ja ChatGPT:llä on keskusteluhistoriamme tallessa tulevia prompteja varten, pyydän tarkempia tietoja. Vastaus kannattaa arvioida ensimmäisen promptin ja jokaisen seuraavan vastauksen jälkeen sekä syventyä tarvittaessa esiin nouseviin uusiin aiheisiin.

Siirry seuraavaan promptiin vasta sitten, jotta et häiritse chat-istuntoa. Se voi helposti johtaa ei-toivottuihin lopputuloksiin suurten kielimallien (LLM) kanssa. 

Yksinkertaista työnkulkua ja poista develop- ja release-haarat. Käytän niiden sijaan git-tägejä.

GPT:n vastaus

Totta kai! Git-työnkulun yksinkertaistaminen poistamalla develop- ja release-haarat sekä käyttämällä niiden sijaan Git-tägejä voi tehdä prosessista suoraviivaisemman, erityisesti pienille tiimeille tai projekteille. Tässä on työnkulun päivitetty versio:

Main-haara:

• Tämä on ensisijainen ja ainoa pitkäikäinen haarasi. Main-haara edustaa koodisi tuotantovalmiita tilaa.

• Kaikki ominaisuudet, virheenkorjaukset ja kiireelliset korjaukset yhdistetään suoraan tähän haaraan.

Ominaisuushaarat:

• Luo ominaisuushaara aina, kun aloitat uuden ominaisuuden tai virheenkorjauksen parissa työskentelyn.

• Luo haara main-haarasta ja yhdistä se takaisin main-haaraan, kun työ on valmis ja testattu.

• Ominaisuushaarojen nimeämiskäytäntö voi olla esimerkiksi feature/<feature-name> tai bugfix/<bug-name>.

Git-tägien käyttö releaseihin:

• Kun olet valmis julkaisemaan uuden version, käytä Git-tägejä main-haarassa.

• Nimeä tägit semanttisen versionumeroinnin mukaisesti (esim. v1.0.0, v1.0.1), jotta eri releaset on helppo pitää seurannassa.

• Tägejä voidaan tarvittaessa käyttää myös tiettyjen CI/CD-toimintojen käynnistämiseen.

Jatkuva käyttöönotto (CD):

• Jos projektisi kokoonpano sallii sen, määritä CD ottamaan main-haara automaattisesti käyttöön tuotannossa, kun se on läpäissyt CI-tarkistukset.

• Jos tarvitset enemmän hallintaa ympäristöissäsi, voit ottaa käyttöön tägittyjä versioita manuaalisesti.

Muut osat ovat hyvin samanlaisia kuin aiemmin, joten niitä ei tarvitse toistaa tässä.

Yhteenveto työnkulun yksinkertaistamisesta sekä develop- ja release-haarojen poistamisesta

Hyvä, tämä näyttää nyt siltä kuin pyysin. Huoli herää kuitenkin siitä, että GPT ehdottaa main-haaran automaattista käyttöönottoa tuotantoon CI:n jälkeen.

Tiedämme kaikki oman järkemme ja järjestelmän luotettavuuden vuoksi, että tarvitsemme ehdottomasti tuotantoa vastaavia ympäristöjä, kuten staging-ympäristön, asianmukaista laadunvarmistusta (QA) varten.

Automaattisten regressiotestien ajaminen tuotantoa vastaavissa ympäristöissä jokaisen muutoksen jälkeen on ratkaisevan tärkeää. Tämä koskee paitsi tuotteen koodimuutoksia myös infrastruktuuriin (IaC), putkiin ja muuhun liittyviä muutoksia.

Kehote #3

Jatkuvassa käyttöönotossa haluan ottaa main-haaran automaattisesti käyttöön vain tuotantoa vastaavissa ympäristöissä, kuten stagingissa. Tuotantoon käyttöönoton tulisi tapahtua käyttämällä Git-tageja, joiden etuliite on esimerkiksi "release-", kuten release-v1.0.0. Staging-käyttöönotossa etuliite olisi rc- (release candidate).

GPT:n vastaus

Ehdottomasti. Lähestymistapasi jatkuvaan käyttöönottoon, jossa staging- ja tuotantoympäristöissä käytetään tiettyjä Git-tagikäytäntöjä, on erinomainen strategia. Näin voit jäsentää tämän työnkulun:

Main-haara staging-ympäristönä:

• Main-haara toimii staging-ympäristön kaltaisena ympäristönä. Jokainen yhdistäminen main-haaraan käynnistää automaattisen käyttöönoton staging-ympäristöön.

• Näin voit testata ympäristössä, joka vastaa läheisesti tuotantoa.

Git-tagien käyttö stagingissa ja tuotannossa:

• Staging-tagit: Käytä rc--etuliitettä (release candidate) staging-käyttöönottoihin. Esimerkiksi rc-v1.0.0 tarkoittaa version 1.0.0 release candidatea. Kun työnnät tällä etuliitteellä varustetun tagin, se käynnistää käyttöönoton staging-ympäristöön.

• Tuotantotagit: Käytä release--etuliitettä tuotantokäyttöönottoihin. Tägejä, kuten release-v1.0.0, käytetään tuotantoympäristön manuaalisen käyttöönoton käynnistämiseen. Näin voit hallita, mitä tuotantoon otetaan käyttöön ja milloin.

Työnkulun vaiheet:

• Kehitys: Kehittäjät työskentelevät main-haarasta luoduissa ominaisuus- tai bugikorjaushaaroissa.

• Koodikatselmointi ja yhdistäminen: Kun työ on valmis, luodaan pull request muutosten yhdistämiseksi main-haaraan. Koodikatselmoinnin ja onnistuneiden CI-tarkistusten jälkeen muutokset yhdistetään.

• Automaattinen staging-käyttöönotto: Main-haaraan yhdistäminen käynnistää automaattisesti käyttöönoton staging-ympäristöön. Tämä on tarkoitettu viimeistä testausta ja validointia varten.

• Release candidatejen taggaus: Kun tiimi on tyytyväinen stagingissa oleviin muutoksiin, luodaan rc--tagi, jolla release candidate merkitään virallisesti.

• Tuotantokäyttöönotto: Kun release candidate on testattu perusteellisesti ja hyväksytty, luodaan release--tagi. Tämän tagin avulla käynnistetään sitten manuaalisesti käyttöönotto tuotantoympäristöön.

Continuous Integration ja käyttöönotto:

• Määritä CI/CD-putket käsittelemään eri ympäristöjä tagikäytännön perusteella.

• Varmista, että CI-putki sisältää kaikki tarvittavat testit ja laatutarkistukset.

Dokumentaatio:

• Dokumentoi tämä prosessi selkeästi, mukaan lukien se, miten ja milloin staging- ja tuotantokäyttöönottoja varten luodaan tageja.

Tämä toimintamalli varmistaa staging- ja tuotantokäyttöönottojen selkeän erottelun ja antaa tiimillesi hallinnan julkaisuprosessista. Käyttämällä eri tageja stagingissa (rc-) ja tuotannossa (release-) voit helposti hallita ja seurata eri julkaisujen etenemistä ympäristöjesi läpi.

Yhteenveto tuotantoa vastaaviin ympäristöihin tehtävien käyttöönottojen automatisoinnista

Olen nyt tyytyväinen työnkulkuuni. Vastaavalla tavalla voit luoda työnkulun, jonka kanssa olet valmis jatkamaan.

Jos sotket tekoälyn kanssa käytävän chat-istunnon täysin, voi olla parempi aloittaa uusi istunto alusta, jotta vältät harhaanjohtavat vastaukset.

Tällä kertaa sain tuloksia jo ensimmäisessä chat-istunnossa, mutta usein se ei ollut yhtä helppoa. Seuraavaksi siirryn varsinaisen pipeline-määrityksen luomiseen koodina käyttäen taustateknologiana Atlassian Bitbucket Pipelinesia.

Generatiivinen tekoäly DevOps-putkiin

Tässä osiossa tarkastelemme, miten Chat GPT-4 voi luoda Bitbucket-pipeline-määritystiedoston edellä kuvatun toteuttamiseksi.

Kehote #4

Jatkan tässä kehotteiden antamista samassa chat-istunnossa, jotta LLM:llä on taustalla asiaankuuluva konteksti.

Haluan nyt, että tuot minulle bitbucket-pipelines.yaml-tiedoston viimeisimmän työnkulun pohjalta, johon vastasit hiljattain. Laadi pipeline Python Flaskilla toteutetulle backend-palvelulleni, jonka haluan ottaa käyttöön Google Kubernetesissa GCP:ssä.

Sain tässä korkean tason toteutuksen, jossa suurin osa yksityiskohdista oli siirretty erillisiin shell-skriptitiedostoihin. Tämä ei ollut tarkoitukseni, joten en näytä vastausta tässä. Keskustelukierrosten jälkeen sain kuitenkin etsimäni.

Kehotteet #5–#8

Useat kehotteet ovat tavallisia, kun generatiivista tekoälyä käytetään monimutkaisten aiheiden käsittelyyn. Tekoäly ei voi päätellä täsmällisiä tarpeitasi yhdestä yksityiskohdiltaan rajallisesta kehotteesta. Lisäksi suuremmat tehtävät on tärkeää jakaa pienempiin, hallittaviin osiin. Tämä prosessi edellyttää myös kattavaa DevOps-ymmärrystä, jotta keskustelua voi ohjata tehokkaasti. Hyviä tuloksia ei kannata odottaa saavansa helposti.

#5 - Tämä on hieman liian korkean tason kuvaus. Haluan, että lisäät Docker-imagen buildauksen ja imagen pushauksen Google Cloud Repositoryyn gcr.io:hon. Lisää lisäksi gcloud CLI- ja kubectl-komennot sekä tarvittaviin kohtiin paikkamerkit ympäristömuuttujille ja salaisuuksille.

#6 - Hyvä, mutta miten tämä toimii, jos release-*-tagi käynnistetään manuaalisesti?

#7 - Haluan ottaa käyttöön Bitbucketin deployment-ympäristöt. Voisitko antaa minulle uusimman bitbucket-pipelines.yaml-tiedoston, johon on tehty tämän huomioivat muutokset.

#8 - Haluan muuttaa pipelinea niin, että Docker-image buildataan vain kerran ja sille voidaan myöhemmin tehdä uusi tagi. Sitä ei pitäisi joutua buildaamaan uudelleen.

GPT-4:n vastaus

Jotta Docker-image buildataan pipelinessasi vain kerran ja sille tehdään sitten uusi tagi eri ympäristöjä varten, sinun täytyy tehdä muutamia muutoksia bitbucket-pipelines.yml-tiedostoosi. Ideana on buildata Docker-image kerran, puskea se Google Container Registryyn (GCR) yleisellä tagilla ja tehdä sille sitten uusi tagi staging- tai tuotantokäyttöönottoja varten tarpeen mukaan.

Tässä on päivitetty versio bitbucket-pipelines.yml-tiedostostasi näillä muutoksilla:

image: atlassian/default-image:2
pipelines:
  default:
    - step:
        name: Build and Test
        caches:
          - pip
        script:
          - pip install -r requirements.txt
          - python -m unittest discover tests
  branches:
    main:
      - step:
          name: Build and Push Docker Image
          script:
            - echo $GCLOUD_SERVICE_KEY | base64 --decode --ignore-garbage > ${HOME}/gcloud-service-key.json
            - docker build -t gcr.io/$GCLOUD_PROJECT/your-app:latest .
            - gcloud auth configure-docker --quiet
            - docker push gcr.io/$GCLOUD_PROJECT/your-app:latest
      - step:
          name: Deploy to Staging
          deployment: staging
          script:
            - echo "Deploying to Staging Environment"
            - ./deploy-staging.sh # This script should handle the retagging for staging
  tags:
    'rc-*':
      - step:
          name: Retag and Deploy to Staging
          deployment: staging
          script:
            - echo "Retagging and Deploying Release Candidate to Staging"
            - ./retag-deploy-staging.sh # Script to retag the image for staging
    'release-*':
      - step:
          name: Retag and Deploy to Production
          deployment: production
          trigger: manual
          script:
            - echo "Retagging and Deploying to Production Environment"
            - ./retag-deploy-production.sh # Script to retag the image for production
definitions:
  caches:
    pip: ~/.cache/pip

Tärkeimmät muutokset

Yksi imagen buildaus: Docker-image buildataan ja pushataan vain kerran main-haaraan tehtävien commitien yhteydessä. Se tagitetaan latest-tagilla.

Uudelleentagitus stagingia ja tuotantoa varten:

• ./deploy-staging.sh-skriptiä käytetään latest-tagin suoraan käyttöönottoon staging-ympäristössä.

• rc-*- ja release-*-tageille käytetään erillisiä skriptejä (./retag-deploy-staging.sh ja ./retag-deploy-production.sh). Näiden skriptien tulee huolehtia Docker-imagen tagittamisesta uudelleen sopivalla tagilla (commitin tai release-tagin perusteella) ja sen jälkeen käyttöönotosta kyseiseen ympäristöön.

Skriptit tagien muuttamiseen ja käyttöönottoon

• ./deploy-staging.sh:n tulee ottaa käyttöön uusin image staging-ympäristössä ilman tagin muuttamista.

• ./retag-deploy-staging.sh:n ja ./retag-deploy-production.sh:n tulee: hakea uusin image GCR:stä, lisätä sille tietty commit- tai release-tagi, puskea uudelleentagattu image takaisin GCR:ään ja päivittää Kubernetes-käyttöönotto käyttämään uutta tagia.

• Hae uusin image GCR:stä.

• Lisää sille tietty commit- tai release-tagi.

• Puske uudelleentagattu image takaisin GCR:ään.

• Päivitä Kubernetes-käyttöönotto käyttämään uutta tagia.

Tällä tavalla Docker-image rakennetaan vain kerran, mikä säästää aikaa ja resursseja. Uudelleentagaukseen tarkoitetut skriptit tuovat joustavuutta eri ympäristöjen hallintaan ilman, että imagea tarvitsee rakentaa uudelleen. Varmista, että GCP-palvelutililläsi on tarvittavat oikeudet, ja korvaa paikkamerkit omilla projektisi tiedoilla.

LLM:n lopullisen tuotoksen yhteenveto

Toista nämä vaiheet järjestelmäsi jokaiselle komponentille, olipa kyseessä palvelu, käyttöliittymä tai sovellus. Bitbucket Pipelinesista kertyneen kokemukseni ansiosta pystyn arvioimaan vastauksia melko luottavaisesti ja ymmärrän, mitä niiden saaminen tuotantokäyttöön vaatii. Jos teknologiat olisivat minulle vieraita, odottaisin kuitenkin kohtaavani odottamattomia haasteita.

Kun LLM:t kehittyvät ja niistä tehdään erikoistuneempia versioita, vastausten laatu paranee varmasti. Tekoäly nopeuttaa merkittävästi uusien teknologioiden ja prosessien käyttöönottoa DevOpsissa.

DevOps-perustason saavuttaminen käytännössä tekoälyn avulla

Siinä se oli: esittelyni siitä, miten DevOps-perustaso voidaan saavuttaa käytännössä tekoälyn avulla. Promptauksen aloittaminen ei vaadi edistyneitä taitoja, mutta kuten kaikissa urheilulajeissa, harjoittelu tuottaa parempia tuloksia.

Perustasoa voi vielä parantaa monin tavoin, esimerkiksi kattavalla Continuous Integrationilla, joka sisältää muun muassa DevSecOpsin ja IaC:n.

Tekoälyn avulla DevOps-aiheisiin perehtyminen helpottuu. Internetissä on saatavilla runsaasti hyvää materiaalia, ja se näyttää olevan hyvin integroitunut LLM:iin. On kuitenkin tärkeää ymmärtää, että tällaiset suunnittelukeskustelut toimivat paremmin kehittyneimpien LLM:ien kanssa. Esimerkiksi sama keskustelu GPT-3.5:n kanssa olisi hyvin erilainen.

Usein ajatellaan, että CI/CD on liian suuri investointi pienempiin projekteihin. Se kuitenkin ylittää helposti ne kustannukset, joita syntyisi, jos se laiminlyötäisiin tai toteutettaisiin vasta myöhemmässä vaiheessa. DevOpsiin investointia ei enää pitäisi olla syytä epäröidä heti alusta alkaen.

Ajan myötä uskon yhä kattavampien kehitysalustojen yleistyvän. Niissä monet prosessit ovat automatisoituja, mikä nostaa kehityksen ja DevOpsin abstraktiotasoa. Ongelmanratkaisutaidot ja syvällinen ymmärrys taustalla olevista periaatteista säilyvät silti tärkeinä.

Toivon, että tämä blogikirjoitus on innostanut sinua ottamaan DevOpsin käyttöön alusta alkaen ja/tai parantamaan nykyistä tilannettasi.

Jos pidit tästä blogikirjoituksesta, saatat pitää myös podcast-jaksostamme, joka käsittelee tekoälyä DevOps-työkaluketjussa.