Cloud & IT Cert Prep · Oppitunti

Kehittäjän päästä päähän -työnkulku

Yhdistä GitHub Actions CI/CD, Azure Container Registry, Container Apps ja Application Insights kokonaiseksi kehittäjän sisäiseksi työnkuluksi commitista havainnoitavaan tuotantoon

Oppitunti 4/413 vaihetta

Kehittäjän päästä päähän -työnkulku on ilmainen Cloud & IT Cert Prep-oppitunti CoddyKitissä. Tämä on oppitunti 4/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Cloud & IT Cert Prep-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Cloud & IT Cert Prep-kurssilla on yhteensä 4 oppituntia.

Moderni Azure-kehittäjän työnkulku

Moderni Azure-kehittäjän työnkulku yhdistää lähteenhallinnan, CI/CD:n, säilöinfrastruktuurin ja havainnoinnin saumattomaksi sisäiseksi silmukaksi, joka ulottuu koodin commitoimisesta tuotannon havainnointiin. Keskeiset komponentit ovat: GitHub (lähde), GitHub Actions (koonti- ja käyttöönottoputki), Azure Container Registry (näköistiedostojen tallennus), Azure Container Apps (suoritusympäristö) ja Application Insights (havainnointi). Jokainen muutos siirtyy automaattisesti kehittäjän tietokoneelta tuotantoon muutamassa minuutissa, ja jokaisessa vaiheessa on laadunvarmistusportit.

Vaihe 1: lähteenhallinta ja haarautumisstrategia

Järjestäkää koodinne GitHub-repositorioon käyttämällä trunk-pohjaista kehitystä tai GitFlow-haarautumisstrategiaa. Useimmissa mikropalveluissa trunk-pohjainen kehitys (lyhytikäiset ominaisuushaarat yhdistetään main-haaraan päivittäin) vähentää integrointiristiriitoja ja pitää putken yksinkertaisena. Käyttäkää main-haarassa haaran suojaussääntöjä, jotka edellyttävät pull request -katselmointeja ja onnistuneita CI-tarkistuksia ennen yhdistämistä. CODEOWNERS-tiedosto varmistaa, että kriittisiin palveluihin tehtävät muutokset edellyttävät kyseisen tiimin vanhempien insinöörien hyväksyntää.

# Example .github/CODEOWNERS
# Require payments-team review for any changes under /src/payments/
/src/payments/ @payments-team
/infrastructure/   @platform-team

Vaihe 2: CI GitHub Actionsilla

CI-putki suoritetaan jokaisen pull requestin yhteydessä. Tyypillinen työnkulku on: koodin noutaminen → riippuvuuksien palauttaminen → yksikkötestien suorittaminen → integraatiotestien suorittaminen → Docker-näköistiedoston koonti → julkaiseminen Azure Container Registryyn. Näköistiedosto merkitään git commitin SHA-tunnisteella jäljitettävyyden varmistamiseksi. Käyttäkää GitHub Actionsin ja Azuren väliseen todentamiseen OIDC-pohjaista todennusta (federated identity -määrityksen kautta), jotta Azure-palvelun pään tunnistetietoja ei tarvitse tallentaa GitHubiin – tämä vastaa hallittua identiteettiä CI-putkille.

# .github/workflows/ci.yml (abbreviated)
name: CI
on: [pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Login to ACR
        uses: azure/docker-login@v1
        with:
          login-server: myacr.azurecr.io
          username: ${{ secrets.AZURE_CLIENT_ID }}
          password: ${{ secrets.AZURE_CLIENT_SECRET }}
      - name: Build and push image
        run: |
          docker build -t myacr.azurecr.io/myapi:${{ github.sha }} .
          docker push myacr.azurecr.io/myapi:${{ github.sha }}

Vaihe 3: CD testiympäristöön

Kun CI-putki onnistuu yhdistettäessä muutokset main-haaraan, CD-putki ottaa ne automaattisesti käyttöön staging-ympäristössä. Putki päivittää Container Appin näköistiedoston tunnisteen juuri koostettuun SHA-tunnisteeseen, odottaa uuden revision muuttumista toimintakuntoiseksi ja suorittaa smoke-testit staging-URL-osoitetta vastaan. Smoke-testit varmistavat, että kriittiset API-päätepisteet palauttavat odotetut vastaukset. Jos smoke-testit epäonnistuvat, putki palauttaa tilanteen ennalleen ohjaamalla ingress-liikenteen takaisin edelliseen revisioon ilman manuaalisia toimia.

# CD stage: update Container App to new image
- name: Deploy to staging
  uses: azure/cli@v2
  with:
    azcliversion: latest
    inlineScript: |
      az containerapp update \
        --name myapi-staging \
        --resource-group myRG \
        --image myacr.azurecr.io/myapi:${{ github.sha }}

- name: Run smoke tests
  run: |
    STAGING_URL=$(az containerapp show --name myapi-staging \
      --resource-group myRG \
      --query 'properties.configuration.ingress.fqdn' -o tsv)
    curl -f https://$STAGING_URL/health || exit 1

Vaihe 4: tuotannon hyväksyntäportti

Staging-ympäristön validoinnin jälkeen CD-putki pysähtyy hyväksyntäportille. GitHub Actionsin Environment protections -ominaisuudella voitte määrittää production-ympäristölle pakolliset tarkastajat. Putki lähettää Slack-ilmoituksen päivystävälle insinöörille, joka tarkistaa staging-testien tulokset, muutokset ja avoimet häiriöt ennen hyväksymistä. Vasta hyväksynnän jälkeen putki jatkaa saman näköistiedoston SHA-tunnisteen käyttöönottoa tuotannossa. Tämä ihmisen osallistumisen sisältävä vaihe on ratkaisevan tärkeä vilkkaasti käytetyille tai säännellyille palveluille.

# In GitHub: create 'production' environment with required reviewers
# .github/workflows/cd.yml (abbreviated)
jobs:
  deploy-production:
    environment:
      name: production
      url: https://myapi.contoso.com
    needs: deploy-staging
    steps:
      - name: Deploy to production
        uses: azure/cli@v2
        with:
          inlineScript: |
            az containerapp update \
              --name myapi \
              --resource-group myRG \
              --image myacr.azurecr.io/myapi:${{ github.sha }}

Vaihe 5: tuotannon havainnointi

Kun sovellus on otettu käyttöön tuotannossa, Application Insights tarjoaa reaaliaikaisen näkyvyyden. App Insights SDK (tai tuettujen suoritusympäristöjen automaattinen instrumentointi) seuraa seuraavia tietoja: pyyntömäärät, virhemäärät ja viive (kolme kultaista signaalia), riippuvuuskutsut (tietokantoihin, Service Busiin ja muihin API-rajapintoihin) sekä poikkeukset täydellisine pinon jäljitystietoineen. Application Map havainnollistaa, miten palvelut kutsuvat toisiaan, ja korostaa riippuvuuksia, jotka vaikuttavat eniten virheisiin tai viiveeseen.

# Python: Add Application Insights SDK
from opencensus.ext.azure.log_exporter import AzureLogHandler
from opencensus.ext.azure.trace_exporter import AzureExporter
from opencensus.trace.samplers import ProbabilitySampler
from opencensus.trace.tracer import Tracer

tracer = Tracer(
  exporter=AzureExporter(connection_string='InstrumentationKey=<key>'),
  sampler=ProbabilitySampler(1.0)
)

Käyttöönottojen yhdistäminen jäljitystietoihin

Merkitkää käyttöönottotapahtumat metriikkakaavioihin Application Insights Annotations -ominaisuuden avulla. Kun julkaisumerkintä luodaan (GitHub Actionsin azure/appinsights-annotation-actionin kautta), se näkyy pystysuorana viivana kaikissa App Insightsin metriikkakaavioissa. Näin on heti nähtävissä, liittyykö viivepiikki tai virhemäärän kasvu äskettäiseen käyttöönottoon, mikä lyhentää merkittävästi häiriöiden keskimääräistä diagnosointiaikaa (MTTD).

# Create a release annotation in Application Insights
- name: Annotate release in App Insights
  uses: azure/appinsights-annotation@v1
  with:
    appInsightsResourceName: myAppInsights
    resourceGroupName: myRG
    releaseName: '${{ github.run_id }}-${{ github.sha }}'

Automaattinen palautus virhemäärän kasvaessa

Kaikkein vikasietoisimmissa putkissa kannattaa ottaa käyttöön automaattinen palautus. Tuotantokäyttöönoton jälkeen putki odottaa 10 minuuttia ja kysyy virhemäärän Application Insightsista. Jos virhemäärä ylittää määritettävän raja-arvon (esimerkiksi >5 %), putki palauttaa tilanteen automaattisesti ennalleen päivittämällä Container Appin ingress-liikenteen osoittamaan 100-prosenttisesti edelliseen revisioon. Tämä progressive delivery -malli pienentää virheellisen käyttöönoton vaikutusaluetta ja antaa tiimeille mahdollisuuden ottaa käyttöön muutoksia luottavaisin mielin myös monimutkaisissa tai arkaluonteisissa tilanteissa.

# Query App Insights error rate via REST (abbreviated)
QUERY='requests | where timestamp > ago(10m) | summarize failed = countif(success == false), total = count() | extend errorRate = round(100.0 * failed / total, 2)'
RESULT=$(az monitor app-insights query \
  --apps myAppInsights \
  --resource-group myRG \
  --analytics-query "$QUERY" \
  --query 'tables[0].rows[0][2]' -o tsv)
if [ $(echo '$RESULT > 5' | bc -l) -eq 1 ]; then
  echo 'Error rate $RESULT% - rolling back!'
  az containerapp ingress traffic set --name myapi --resource-group myRG --revision-weight stable=100
fi

Kehittäjän tuottavuus: paikallinen kehitys emulaattoreilla

Kehittäjien pitäisi voida suorittaa ja testata koko pinoa paikallisesti ilman yhteyttä tuotannon Azure-resursseihin. Käyttäkää paikalliseen blob- ja jonotallennukseen Azure Storage Emulator (Azurite) -emulaattoria, paikalliseen tietokantatestaukseen Cosmos DB Emulator -emulaattoria ja paikalliseen viestintään Service Bus Emulator -emulaattoria. Ympäristömuuttuja AZURE_ENVIRONMENT=local voi vaihtaa DefaultAzureCredential-määrityksen käyttämään emulaattoreihin osoittavia yhteysmerkkijonoja, kun taas sama koodi käyttää Azuressa hallittua identiteettiä. Docker Compose orkestroi kaikki paikalliset riippuvuudet yhdellä komennolla: docker compose up.

# docker-compose.yml for local development
services:
  azurite:
    image: mcr.microsoft.com/azure-storage/azurite
    ports:
      - '10000:10000'
      - '10001:10001'
  cosmos-emulator:
    image: mcr.microsoft.com/cosmosdb/linux/azure-cosmos-emulator
    ports:
      - '8081:8081'

Tietoturva kehittäjän työnkulussa

Integroikaa tietoturva työnkulun jokaiseen vaiheeseen: Dependabot etsii pull requesteissa haavoittuvia riippuvuuksia; GitHub Advanced Security (CodeQL-koodiskannaus) tunnistaa SQL-injektion ja kovakoodattujen salaisuuksien kaltaisia haavoittuvuuksia; Microsoft Defender for DevOps integroituu GitHubiin ja tuo Azuren tietoturvasuositukset näkyviin koodimuutosten yhteydessä; ja ACR Defender vulnerability scanning tarkistaa säilöjen näköistiedostot käyttöjärjestelmä- ja sovelluskerroksen CVE-haavoittuvuuksien varalta jokaisen julkaisemisen jälkeen. Tietoturvalöydökset näkyvät pull request -kommentteina, joten ne käsitellään ennen yhdistämistä.

Kaiken yhdistäminen

Täydellinen kehittäjän työnkulku on jatkuva palautesilmukka: kehittäjä commitoi koodin, CI koostaa ja testaa säilön näköistiedoston, näköistiedosto julkaistaan ACR:ään commitin SHA-tunnisteella merkittynä, CD ottaa sen käyttöön staging-ympäristössä ja suorittaa smoke-testit, ihminen hyväksyy tuotantokäyttöönoton, putki ottaa sen käyttöön tuotannossa ja luo julkaisumerkinnän, ja Application Insights valvoo virhemääriä sekä käynnistää automaattisen palautuksen, jos raja-arvot ylittyvät. Saman repositorion Infrastructure as Code (Bicep tai Terraform) varmistaa, että putki, Container App ja valvontamääritykset ovat kaikki versionhallinnassa sovelluskoodin rinnalla.

Pikatesti

Testaa tämän oppitunnin Microsoft Azure Fundamentals (AZ-900) -käsitteiden ymmärtämistä.

Oppitunnin yhteenveto

Tässä oppitunnissa opitte, että päästä päähän ulottuva kehittäjän työnkulku yhdistää GitHub-lähteenhallinnan, GitHub Actionsin CI/CD:n, Azure Container Registryn, Container Appsin ja Application Insightsin, julkaisumerkinnät yhdistävät käyttöönotot metriikkamuutoksiin häiriöiden nopeampaa diagnosointia varten ja virhemääräkyselyihin perustuva automaattinen palautus pienentää virheellisten käyttöönottojen vaikutusaluetta. Seuraavaksi siirrymme kokeeseen valmistautumiseen kattavan pilvikäsitteiden ja Azure-arkkitehtuurin kertauksen avulla.

Aloita maksutta

Opi Cloud & IT Cert Prep tekoälytuutorin avulla — ilmaiseksi

Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.

Kurssit
150
Oppitunnit
600

Usein kysytyt kysymykset

Onko oppitunti ”Kehittäjän päästä päähän -työnkulku” ilmainen?

Kyllä – oppitunnin ”Kehittäjän päästä päähän -työnkulku” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Cloud & IT Cert Prep-kurssin, päivitä CoddyKit PROhon. Cloud & IT Cert Prep-kurssilla on yhteensä 4 oppituntia.

Mitä opin oppitunnilla ”Kehittäjän päästä päähän -työnkulku”?

Yhdistä GitHub Actions CI/CD, Azure Container Registry, Container Apps ja Application Insights kokonaiseksi kehittäjän sisäiseksi työnkuluksi commitista havainnoitavaan tuotantoon Harjoittelet Cloud & IT Cert Prep-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.

Tarvitsenko kokemusta aloittaakseni Cloud & IT Cert Prep-opiskelun?

Aiempi kokemus ei ole tarpeen. CoddyKitin Cloud & IT Cert Prep-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 4/4.

Kuinka kauan ”Kehittäjän päästä päähän -työnkulku”-oppitunnin suorittaminen kestää?

Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.

Voinko kirjoittaa ja suorittaa koodia tällä Cloud & IT Cert Prep-oppitunnilla?

Kyllä. Jokainen Cloud & IT Cert Prep-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.

Kaikki tämän kurssin oppitunnit

  1. Hallittu identiteetti salasanattomaan todentamiseen
  2. Azure Service Bus irrotettuun viestintään
  3. Azure Container Apps
  4. Kehittäjän päästä päähän -työnkulku
← Takaisin: Cloud & IT Cert Prep