Cloud & IT Cert Prep · leksjon

Utviklerarbeidsflyt fra ende til ende

Koble sammen GitHub Actions CI/CD, Azure Container Registry, Container Apps og Application Insights til en komplett intern utviklersyklus fra commit til observerbar produksjon.

Leksjon 4 av 413 trinn

Utviklerarbeidsflyt fra ende til ende er en gratis leksjon i Cloud & IT Cert Prep på CoddyKit. Dette er leksjon 4 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Cloud & IT Cert Prep, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Cloud & IT Cert Prep inneholder totalt 4 leksjoner.

Den moderne Azure-arbeidsflyten for utviklere

En moderne Azure-arbeidsflyt for utviklere kobler sammen kildekontroll, CI/CD, containerinfrastruktur og observability i en sømløs indre løkke fra kodeinnsjekking til produksjon du kan følge med på. De viktigste komponentene er: GitHub (kilde), GitHub Actions (byggings- og distribusjonspipeline), Azure Container Registry (bildelager), Azure Container Apps (kjøremiljø) og Application Insights (observability). Hver endring flyttes automatisk fra utviklerens datamaskin til produksjon i løpet av minutter, med kvalitetskontroller i hvert trinn.

Trinn 1: Kildekontroll og strategi for grener

Organiser koden i et GitHub-repositorium ved å bruke en trunk-basert utviklingsstrategi eller en GitFlow-strategi for grener. For de fleste mikrotjenester reduserer trunk-basert utvikling (kortvarige funksjonsgrener som flettes inn i main daglig) integrasjonskonflikter og holder pipelinen enkel. Bruk regler for grenbeskyttelse på main for å kreve gjennomgang av pull requests og beståtte CI-kontroller før fletting. En CODEOWNERS-fil sikrer at endringer i kritiske tjenester må godkjennes av seniorutviklere i det aktuelle teamet.

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

Trinn 2: CI med GitHub Actions

CI-pipelinen kjører for hver pull request. En typisk arbeidsflyt er: hent ut kode → gjenopprett avhengigheter → kjør enhetstester → kjør integrasjonstester → bygg Docker-image → push til Azure Container Registry. Imagets tag angis med SHA-en til git-innsjekkingen for sporbarhet. Bruk OIDC-basert autentisering fra GitHub Actions til Azure (via føderert identitet) for å unngå å lagre hemmeligheter for Azure-tjenesteidentiteten i GitHub – dette tilsvarer en administrert identitet for CI-pipelines.

# .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 }}

Trinn 3: CD til staging

Etter at CI-pipelinen er fullført uten feil ved en fletting til main, distribuerer CD-pipelinen automatisk til staging-miljøet. Pipelinen oppdaterer image-taggen for Container App til den nybygde SHA-en, venter på at den nye revisionen skal bli klar, og kjører smoketester mot staging-URL-en. Smoketester bekrefter at kritiske API-endepunkter returnerer de forventede svarene. Hvis smoketestene mislykkes, ruller pipelinen tilbake ved å føre ingress-trafikken tilbake til den forrige revisionen, uten manuell inngripen.

# 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

Trinn 4: Godkjenningskontroll for produksjon

Etter validering i staging settes CD-pipelinen på pause ved en godkjenningskontroll. Environment protections i GitHub Actions lar deg konfigurere obligatoriske godkjennere for production-miljøet. Pipelinen sender et Slack-varsel til den ansvarlige teknikeren, som gjennomgår resultatene fra staging-testene, diffen og eventuelle åpne hendelser før godkjenning. Først etter godkjenning fortsetter pipelinen med å distribuere det samme image-SHA-et til produksjon. Dette trinnet med menneskelig kontroll er avgjørende for tjenester med høy trafikk eller tjenester som er underlagt regelverk.

# 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 }}

Trinn 5: Observability i produksjon

Når løsningen er distribuert til produksjon, gir Application Insights innsyn i sanntid. App Insights SDK-et (eller automatisk instrumentering for støttede kjøremiljøer) sporer: forespørselsrater, feilrater og ventetid (de tre gylne signalene), avhengighetskall (til databaser, Service Bus og andre API-er) og unntak med fullstendige stack-tracer. Application Map visualiserer hvordan tjenester kaller hverandre og fremhever hvilke avhengigheter som bidrar mest til feil eller ventetid.

# 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)
)

Koble distribusjoner til sporing

Bruk Application Insights Annotations til å merke distribusjonshendelser i metrikkdiagrammene. Når en release-merknad opprettes (via GitHub Actions-handlingen azure/appinsights-annotation), vises den som en loddrett linje i alle metrikkdiagrammer i App Insights. Da blir det umiddelbart tydelig om en økning i ventetid eller feilrate sammenfaller med en nylig distribusjon, noe som reduserer tiden det tar å diagnostisere hendelser (MTTD) betydelig.

# 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 }}'

Automatisk tilbakeføring ved økning i feilrate

For de mest robuste pipelinene bør du implementere automatisk tilbakeføring. Etter distribusjon til produksjon venter pipelinen i 10 minutter og spør Application Insights etter feilraten. Hvis feilraten overskrider en konfigurerbar terskel (for eksempel >5 %), ruller pipelinen automatisk tilbake ved å oppdatere ingress-trafikken for Container App slik at 100 % sendes til den forrige revisionen. Dette mønsteret for progressiv levering begrenser konsekvensene av en feilaktig distribusjon og gjør det mulig for team å distribuere med trygghet, også ved komplekse eller sensitive endringer.

# 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

Utviklerproduktivitet: Lokal utvikling med emulatorer

Utviklere bør kunne kjøre og teste hele stakken lokalt uten å koble seg til Azure-ressurser i produksjon. Bruk Azure Storage Emulator (Azurite) for lokal blob- og kølagring, Cosmos DB Emulator for lokal databasetesting og Service Bus Emulator for lokale meldinger. Miljøvariabelen AZURE_ENVIRONMENT=local kan bytte DefaultAzureCredential til å bruke tilkoblingsstrenger som peker på emulatorer, mens den samme koden bruker administrert identitet i Azure. Docker Compose orkestrerer alle lokale avhengigheter med én enkelt 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'

Sikkerhet i utviklerarbeidsflyten

Integrer sikkerhet i alle trinn av utviklerarbeidsflyten: Dependabot søker etter sårbare avhengigheter i pull requests; GitHub Advanced Security (kodeskanning med CodeQL) oppdager sårbarheter som SQL-injeksjon og hardkodede hemmeligheter; Microsoft Defender for DevOps integreres med GitHub for å vise Azure-sikkerhetsanbefalinger sammen med kodeendringer; og ACR Defender vulnerability scanning kontrollerer container-images for CVE-er i operativsystemet og applikasjonslaget etter hver push. Sikkerhetsfunn vises som kommentarer i pull requests, slik at de håndteres før fletting.

Sett alt sammen

Den komplette utviklerarbeidsflyten er en kontinuerlig tilbakemeldingssløyfe: En utvikler sjekker inn kode, CI bygger og tester container-imaget, imaget pushes til ACR med innsjekkingens SHA som tag, CD distribuerer til staging og kjører smoketester, et menneske godkjenner produksjonsdistribusjonen, pipelinen distribuerer til produksjon og oppretter en release-merknad, og Application Insights overvåker feilrater med automatisk tilbakeføring hvis tersklene overskrides. Infrastruktur som kode (Bicep eller Terraform) i det samme repositoriet sikrer at konfigurasjonen for pipelinen, Container App og overvåkingen er versjonskontrollert sammen med applikasjonskoden.

Hurtigsjekk

Test forståelsen din av konseptene i Microsoft Azure Fundamentals (AZ-900) fra denne leksjonen.

Besvar den i den interaktive leksjonen

Oppsummering av leksjonen

I denne leksjonen har du lært at ende-til-ende-arbeidsflyten for utviklere kobler sammen kildekontroll i GitHub, CI/CD med GitHub Actions, Azure Container Registry, Container Apps og Application Insights, at release-merknader knytter distribusjoner til endringer i metrikk for raskere diagnostisering av hendelser, og at automatisk tilbakeføring basert på spørringer etter feilrate begrenser konsekvensene av feilaktige distribusjoner. Neste steg er eksamensforberedelser med en omfattende gjennomgang av skykonsepter og Azure-arkitektur.

Gratis å komme i gang

Lær deg Cloud & IT Cert Prep med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 150
Leksjoner: 600

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Utviklerarbeidsflyt fra ende til ende» gratis?

Ja – hele teksten i «Utviklerarbeidsflyt fra ende til ende» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Cloud & IT Cert Prep-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Cloud & IT Cert Prep inneholder totalt 4 leksjoner.

Hva lærer jeg i «Utviklerarbeidsflyt fra ende til ende»?

Koble sammen GitHub Actions CI/CD, Azure Container Registry, Container Apps og Application Insights til en komplett intern utviklersyklus fra commit til observerbar produksjon. Du øver på Cloud & IT Cert Prep med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Cloud & IT Cert Prep?

Ingen tidligere erfaring er nødvendig. Cloud & IT Cert Prep på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 4 av 4.

Hvor lang tid tar leksjonen «Utviklerarbeidsflyt fra ende til ende»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Cloud & IT Cert Prep-leksjonen?

Ja. Alle Cloud & IT Cert Prep-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

Administrert identitet for passordløs autentisering
Azure Service Bus for frakoblet meldingsformidling
Azure Container Apps
Utviklerarbeidsflyt fra ende til ende

← Tilbake til Cloud & IT Cert Prep