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

Vankan DevOps-perustan luominen ei enää vie kuukausia. Oikealla lähestymistavalla ja työkaluilla pienissäkin projekteissa voidaan – ja pitäisi – ottaa käyttöön toimiva DevOps päivissä tai viikoissa. Siirrytään nyt CI/CD:n perusasioihin alkaen 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 luoda alusta asti ChatGPT 4:n avulla. Voit testata tuloksia käyttämällä samoja kehotteita kuin minä tässä (edellyttää ChatGPT 4 -versiota).

Kehote 1

Ensimmäinen kehote toimii yleensä johdantona aiheeseen. Näin voit tarkastella ensimmäistä vastausta ja nähdä, mihin suuntaan keskustelu etenee. Yksi kehote harvoin riittää. Lue eteenpäin nähdäksesi, miten ohjaan keskustelua seuraavaksi. Ensimmäinen kehotteeni kuuluu näin:

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

GPT:n vastaus

Vankan Git-työnkulun perusmallin 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 integraatiohaarana. Se sisältää aina seuraavaan julkaisuun toimitetut uusimmat kehitysmuutokset.

• Feature-haarat: Luo nämä haarat, kun aloitat uuden ominaisuuden kehittämisen. Haarauta ne develop-haarasta ja yhdistä ne 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 tiimi 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 automatisoidut testit ja muut tarkistukset, kuten linttauksen, aina kun uusi commit työnnetään 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ön hallintaa halutaan tiukentaa, käyttöönotot voidaan käynnistää manuaalisesti main-haarasta.

Versiotunnisteet:

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

Dokumentaatio:

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

Lisäksi vastauksessa on osiot commit-ohjeistuksista, 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 hyvä strategia, kun se toteutetaan oikein. Havainnollistamisen vuoksi esittelen kuitenkin suoraviivaisemman työnkulun, joka voi olla optimaalisempi.

Huomaa tärkeä asia: dokumentoi työnkulkusi ja pipelinesi! Tekoälyn ajatteluprosessi vaikuttaa tässä olevan hyvin kartalla ja useimmiten todellisuutta parempi.

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

Prompt #2

Nyt kun meillä on alustava vastaus ja ChatGPT:llä on tallessa keskusteluhistoriamme tulevia prompteja varten, pyydän tarkempia yksityiskohtia. Vastaus kannattaa arvioida ensimmäisen promptin jälkeen ja jokaisen sitä seuraavan vastauksen jälkeen. Tarvittaessa voit perehtyä tarkemmin esiin nouseviin uusiin aiheisiin.

Siirry seuraavaan promptiin vasta sen jälkeen, jotta chat-istunto ei häiriinny. Häiriöt voivat helposti johtaa ei-toivottuihin lopputuloksiin suurten kielimallien (LLM) kanssa.

Tee työnkulusta yksinkertaisempi ja poista develop- ja release-haarat. Käytän niiden sijaan Git-taggausta.

GPT:n vastaus

Totta kai! Git-työnkulun yksinkertaistaminen poistamalla develop- ja release-haarat sekä käyttämällä niiden sijaan Git-taggausta voi tehdä prosessista suoraviivaisemman, erityisesti pienemmille 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, bugikorjaukset ja hotfixit yhdistetään suoraan tähän haaraan.

Feature-haarat:

• Luo feature-haara aina, kun aloitat uuden ominaisuuden tai bugikorjauksen toteuttamisen.

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

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

Git-taggaus releaseja varten:

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

• Nimeä tagit semanttisen versionumeroinnin mukaisesti (esim. v1.0.0, v1.0.1), jotta voit seurata eri releaseja.

• Tagien avulla voidaan tarvittaessa käynnistää myös tiettyjä CI/CD-toimintoja.

Jatkuva käyttöönotto (CD):

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

• Jos ympäristössä tarvitaan enemmän hallintaa, voit ottaa tagatut versiot käyttöön manuaalisesti.

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

Johtopäätös työnkulun yksinkertaistamisesta sekä develop- ja release-haarojen poistamisesta

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

Tiedämme kaikki järkemme ja järjestelmän luotettavuuden vuoksi, että tarvitsemme ehdottomasti tuotantoa vastaavia ympäristöjä, kuten stagingin, kunnollista 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 käyttöön automaattisesti vain tuotantoa vastaavissa ympäristöissä, kuten stagingissa. Tuotantoon käyttöönoton tulisi tapahtua käyttämällä git-tägejä, 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öille käytetään tiettyjä Git-tägikä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 stagingin 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-tägit stagingille ja tuotannolle:

• Staging-tägit: Käytä staging-käyttöönottoihin etuliitettä rc- (release candidate). Esimerkiksi rc-v1.0.0 tarkoittaa version 1.0.0 julkaisuversioehdokasta. Kun pushaat tägin tällä etuliitteellä, se käynnistää käyttöönoton staging-ympäristöön.

• Tuotantotägit: Käytä tuotantokäyttöönottoihin etuliitettä release-. Tägit, kuten release-v1.0.0, käynnistävät manuaaliset käyttöönotot tuotantoympäristöön. Näin voit hallita sitä, mitä tuotantoon otetaan käyttöön ja milloin.

Työnkulun vaiheet:

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

• 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 käyttöönotto stagingiin: Main-haaraan yhdistäminen käynnistää automaattisesti käyttöönoton staging-ympäristöön. Tämä on tarkoitettu lopullista testausta ja validointia varten.

• Julkaisuversioehdokkaiden tägääminen: Kun tiimi on tyytyväinen stagingissa oleviin muutoksiin, luodaan rc-tägi merkitsemään julkaisuversioehdokasta virallisesti.

• Tuotantokäyttöönotto: Kun julkaisuversioehdokas on testattu perusteellisesti ja hyväksytty, luodaan release-tägi. Tätä tägiä käytetään sitten tuotantoympäristöön käyttöönoton käynnistämiseen manuaalisesti.

Continuous Integration ja käyttöönotto:

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

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

Dokumentaatio:

• Dokumentoi tämä prosessi selkeästi, mukaan lukien miten ja milloin tägejä käytetään staging- ja tuotantokäyttöönottoihin.

Tämä kokonaisuus varmistaa selkeän eron staging- ja tuotantokäyttöönottojen välillä sekä antaa tiimillesi hallinnan julkaisuprosessista. Käyttämällä eri tägejä stagingille (rc-) ja tuotannolle (release-) voit hallita ja seurata helposti eri julkaisujen etenemistä ympäristöissäsi.

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

Olen nyt tyytyväinen työnkulkuuni. Vastaavalla tavalla voit rakentaa työnkulun, jonka kanssa haluat edetä.

Jos tekoälyllä käytävä keskustelu menee täysin sekaisin, voi olla parempi aloittaa uusi keskustelu alusta, jotta vältät harhaanjohtavat vastaukset.

Tällä kertaa sain tuloksia jo ensimmäisessä keskustelussa, mutta usein se ei ollut yhtä helppoa. Seuraavaksi siirryn varsinaisen putken luomiseen koodina käyttäen taustateknologiana Atlassian Bitbucket Pipelinesia.

Generatiivinen tekoäly DevOps-putkille

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

Kehote #4

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

Haluan nyt, että annat minulle bitbucket-pipelines.yaml-tiedoston viimeisimmästä työnkulusta, johon juuri vastasit. Anna pipeline Python Flaskilla toteutetulle backend-palvelulleni, jonka haluan ottaa käyttöön GCP:n Google Kubernetesissa.

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 monimutkaisissa aiheissa. Tekoäly ei voi päätellä tarkkoja tarpeitasi yhdestä yksityiskohdiltaan rajallisesta kehotteesta. Lisäksi suuremmat tehtävät on tärkeää jakaa pienempiin, hallittaviin osiin. Tämä edellyttää myös kattavaa DevOps-ymmärrystä, jotta keskustelua voi ohjata tehokkaasti. Hyviä tuloksia ei kannata odottaa helposti.

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

#6 - Tämä on hyvä, mutta miten se toimii, jos release-*-tagi käynnistetään manuaalisesti?

#7 - Haluan ottaa käyttöön Bitbucketin deployment-ympäristöt. Voisitko antaa uusimman bitbucket-pipelines.yaml-tiedoston muokkauksilla, jotka sisältävät nämä tiedot?

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

GPT-4:n vastaus

Jos haluat muokata pipelineasi niin, että Docker-image buildataan vain kerran ja tagitetaan sitten uudelleen eri ympäristöjä varten, sinun on tehtävä muutamia muutoksia bitbucket-pipelines.yml-tiedostoosi. Ideana on buildata Docker-image kerran, pushata se Google Container Registryyn (GCR) yleisellä tagilla ja tagittaa se tarvittaessa uudelleen staging- tai tuotantokäyttöönottoa varten.

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

Keskeiset muutokset

Yksi image-build: Docker-image buildataan ja pushataan vain kerran main-haaraan tehtävien commitien yhteydessä. Se tagitetaan latestiksi.

Uudelleentagitukset stagingia ja tuotantoa varten:

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

• 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 uudelleentagituksesta sopivalla tagilla (commitin tai release-tagin perusteella) ja sen jälkeen deployata se kyseiseen ympäristöön.

Skriptit uudelleentagittamiseen ja käyttöönottoon

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

• ./retag-deploy-staging.sh:n ja ./retag-deploy-production.sh:n tulisi: Hakea uusin image GCR:stä. Tagittaa se uudelleen tietyllä commit- tai release-tagilla. Työntää uudelleentagitettu image takaisin GCR:ään. Päivittää Kubernetes-käyttöönotto käyttämään uutta tagia.

• Hae uusin image GCR:stä.

• Tagita se uudelleen tietyllä commit- tai release-tagilla.

• Työnnä uudelleentagitettu image takaisin GCR:ään.

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

Tämä toimintatapa varmistaa, että Docker-image rakennetaan vain kerran, mikä säästää aikaa ja resursseja. Uudelleentagitusskriptit 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 projektitiedoillasi.

Johtopäätökset LLM:n lopullisesta tulosteesta

Toista nämä vaiheet järjestelmäsi jokaiselle komponentille, olipa kyse palvelusta, käyttöliittymästä tai sovelluksesta. Bitbucket-pipelineista kertyneen kokemukseni ansiosta pystyn arvioimaan vastauksia melko luottavaisesti ja ymmärtämään, mitä niiden ottaminen käyttöön edellyttää. Jos teknologiat olisivat minulle tuntemattomia, odottaisin kuitenkin kohtaavani joitakin odottamattomia haasteita.

Kun LLM:t kehittyvät ja erikoistuneempia versioita kehitetään, 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ä 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.

Perustason jälkeen on vielä parannettavaa monessa asiassa, kuten kattavan Continuous Integrationin toteuttamisessa, mukaan lukien DevSecOps ja IaC.

Tekoäly helpottaa DevOps-aiheisiin perehtymistä. Internetissä on saatavilla valtavasti hyvää materiaalia, ja se vaikuttaa olevan hyvin integroituna LLM:iin. On kuitenkin tärkeää ymmärtää, että tällaiset suunnittelukeskustelut ovat tehokkaampia 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 helposti ylittää kustannukset, joita syntyisi, jos asia laiminlyötäisiin tai toteutettaisiin vasta myöhemmin. DevOpsiin investointia heti alusta alkaen ei pitäisi enää olla syytä epäröidä.

Ajan myötä odotan yhä kattavampien kehitysalustojen yleistyvän. Niissä monet prosessit ovat automatisoituja, mikä tekee kehityksestä ja DevOpsista abstraktimpaa. Ongelmanratkaisutaidot ja syvällinen ymmärrys taustalla olevista periaatteista säilyvät silti tärkeinä.

Toivon, että tämä blogikirjoitus on inspiroinut sinua ottamaan DevOpsin käyttöön heti 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.