Azure Fundamentals · Pelajaran

Alur Kerja Pengembang Menyeluruh

Alur Kerja Pengembang Menyeluruh adalah pelajaran Azure Fundamentals gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Azure Fundamentals, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Azure Fundamentals mencakup 4 pelajaran total.

Siklus Pengembang Azure Modern

Alur kerja pengembang Azure modern menghubungkan kontrol sumber, CI/CD, infrastruktur kontainer, dan observabilitas menjadi siklus internal yang lancar dari penerapan kode hingga produksi yang dapat diamati. Komponen utamanya adalah: GitHub (sumber), GitHub Actions (pipeline build dan deploy), Azure Container Registry (penyimpanan citra), Azure Container Apps (waktu proses), dan Application Insights (observabilitas). Setiap perubahan berpindah secara otomatis dari laptop pengembang ke produksi dalam hitungan menit, dengan gerbang kualitas di setiap langkah.

Langkah 1: Kontrol Sumber dan Strategi Percabangan

Atur kode Anda dalam repositori GitHub menggunakan pengembangan berbasis trunk atau strategi percabangan GitFlow. Untuk sebagian besar layanan mikro, pengembangan berbasis trunk (cabang fitur berumur pendek yang digabungkan ke main setiap hari) mengurangi konflik integrasi dan menjaga pipeline tetap sederhana. Gunakan aturan perlindungan cabang pada main untuk mewajibkan peninjauan pull request dan pemeriksaan CI yang berhasil sebelum penggabungan. Berkas CODEOWNERS memastikan perubahan pada layanan penting memerlukan persetujuan dari insinyur senior tim terkait.

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

Langkah 2: CI dengan GitHub Actions

Pipeline CI berjalan pada setiap pull request. Alur kerja yang umum: checkout kode → pulihkan dependensi → jalankan pengujian unit → jalankan pengujian integrasi → buat citra Docker → dorong ke Azure Container Registry. Citra diberi tag dengan SHA commit git untuk pelacakan. Gunakan autentikasi berbasis OIDC dari GitHub Actions ke Azure (melalui identitas terfederasi) agar tidak perlu menyimpan rahasia perwakilan layanan Azure di GitHub—setara dengan identitas terkelola untuk pipeline CI.

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

Langkah 3: CD ke Staging

Setelah pipeline CI berhasil pada penggabungan ke main, pipeline CD secara otomatis melakukan deploy ke lingkungan staging. Pipeline memperbarui tag citra Container App ke SHA yang baru dibuat, menunggu revisi baru menjadi sehat, lalu menjalankan pengujian asap terhadap URL staging. Pengujian asap memverifikasi bahwa titik akhir API penting mengembalikan respons yang diharapkan. Jika pengujian asap gagal, pipeline melakukan pengembalian dengan mengalihkan lalu lintas ingress kembali ke revisi sebelumnya tanpa intervensi manual.

# 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

Langkah 4: Gerbang Persetujuan untuk Produksi

Setelah validasi staging, pipeline CD berhenti sementara di gerbang persetujuan. Perlindungan lingkungan GitHub Actions memungkinkan Anda mengonfigurasi peninjau wajib untuk lingkungan production. Pipeline mengirimkan notifikasi Slack kepada insinyur yang sedang bertugas, yang meninjau hasil pengujian staging, perbedaan perubahan, dan setiap insiden yang masih terbuka sebelum memberikan persetujuan. Pipeline hanya melanjutkan deploy SHA citra yang sama ke produksi setelah disetujui. Langkah dengan manusia dalam proses ini sangat penting untuk layanan dengan lalu lintas tinggi atau yang diatur oleh peraturan.

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

Langkah 5: Observabilitas Produksi

Setelah di-deploy ke produksi, Application Insights menyediakan visibilitas waktu nyata. SDK App Insights (atau instrumentasi otomatis untuk waktu proses yang didukung) melacak: tingkat permintaan, tingkat kegagalan, dan latensi (tiga sinyal utama), panggilan dependensi (ke basis data, Service Bus, dan API lain), serta pengecualian dengan jejak tumpukan lengkap. Peta Aplikasi memvisualisasikan cara layanan saling memanggil dan menyoroti dependensi mana yang paling banyak berkontribusi terhadap kegagalan atau latensi.

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

Menghubungkan Deployment dengan Jejak

Gunakan Anotasi Application Insights untuk menandai peristiwa deployment pada diagram metrik Anda. Saat anotasi rilis dibuat (melalui tindakan GitHub Actions azure/appinsights-annotation), anotasi tersebut muncul sebagai garis vertikal pada semua diagram metrik App Insights. Dengan demikian, Anda dapat segera melihat apakah lonjakan latensi atau peningkatan tingkat kesalahan berkorelasi dengan deployment terbaru, sehingga secara signifikan mengurangi waktu rata-rata untuk mendiagnosis (MTTD) selama insiden.

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

Pengembalian Otomatis saat Lonjakan Tingkat Kesalahan

Untuk pipeline yang paling tangguh, terapkan pengembalian otomatis. Setelah deployment produksi, pipeline menunggu 10 menit lalu membuat kueri ke Application Insights untuk mendapatkan tingkat kesalahan. Jika tingkat kesalahan melampaui ambang yang dapat dikonfigurasi (misalnya, >5%), pipeline secara otomatis melakukan pengembalian dengan memperbarui lalu lintas ingress Container App agar 100% diarahkan ke revisi sebelumnya. Pola pengiriman progresif ini mengurangi dampak penyebaran deployment yang buruk dan memungkinkan tim melakukan deployment dengan percaya diri, bahkan untuk perubahan yang kompleks atau sensitif.

# 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

Produktivitas Pengembang: Pengembangan Lokal dengan Emulator

Pengembang harus dapat menjalankan dan menguji seluruh tumpukan secara lokal tanpa terhubung ke sumber daya Azure produksi. Gunakan Azure Storage Emulator (Azurite) untuk penyimpanan blob dan antrean lokal, Cosmos DB Emulator untuk pengujian basis data lokal, serta Service Bus Emulator untuk pengiriman pesan lokal. Variabel lingkungan AZURE_ENVIRONMENT=local dapat mengalihkan DefaultAzureCredential agar menggunakan string koneksi yang menunjuk ke emulator, sementara kode yang sama menggunakan identitas terkelola di Azure. Docker Compose mengatur semua dependensi lokal dalam satu perintah 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'

Keamanan dalam Alur Kerja Pengembang

Integrasikan keamanan ke setiap tahap alur kerja pengembang: Dependabot memindai dependensi yang rentan dalam pull request; GitHub Advanced Security (pemindaian kode dengan CodeQL) mendeteksi kerentanan seperti injeksi SQL dan rahasia yang ditulis langsung dalam kode; Microsoft Defender for DevOps terintegrasi dengan GitHub untuk menampilkan rekomendasi keamanan Azure bersama perubahan kode; dan pemindaian kerentanan ACR Defender memeriksa citra kontainer untuk CVE pada lapisan OS dan aplikasi setelah setiap pendorongan. Temuan keamanan muncul sebagai komentar pull request sehingga dapat ditangani sebelum penggabungan.

Menggabungkan Semuanya

Alur kerja pengembang lengkap merupakan siklus umpan balik berkelanjutan: pengembang melakukan commit kode, CI membuat dan menguji citra kontainer, citra didorong ke ACR dengan SHA commit sebagai tag, CD melakukan deploy ke staging dan menjalankan pengujian asap, manusia menyetujui deployment produksi, pipeline melakukan deploy ke produksi dan membuat anotasi rilis, lalu Application Insights memantau tingkat kesalahan dengan pengembalian otomatis jika ambang batas terlampaui. Infrastruktur sebagai kode (Bicep atau Terraform) dalam repositori yang sama memastikan pipeline, Container App, dan konfigurasi pemantauan semuanya dikontrol versinya bersama kode aplikasi.

Pemeriksaan Singkat

Uji pemahaman Anda tentang konsep Microsoft Azure Fundamentals (AZ-900) dari pelajaran ini.

Rangkuman Pelajaran

Dalam pelajaran ini Anda mempelajari bahwa alur kerja pengembang dari ujung ke ujung menghubungkan kontrol sumber GitHub, CI/CD GitHub Actions, Azure Container Registry, Container Apps, dan Application Insights; anotasi rilis menghubungkan deployment dengan perubahan metrik untuk mempercepat diagnosis insiden; dan pengembalian otomatis berdasarkan kueri tingkat kesalahan mengurangi dampak penyebaran deployment yang buruk. Berikutnya, kita beralih ke persiapan ujian dengan tinjauan menyeluruh tentang konsep cloud dan arsitektur Azure.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Alur Kerja Pengembang Menyeluruh” gratis?

Ya — teks lengkap “Alur Kerja Pengembang Menyeluruh” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Azure Fundamentals, upgrade ke CoddyKit PRO. Kursus Azure Fundamentals mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Alur Kerja Pengembang Menyeluruh”?

Hubungkan GitHub Actions CI/CD, Azure Container Registry, Container Apps, dan Application Insights menjadi siklus kerja internal pengembang yang lengkap, dari commit hingga produksi yang dapat diamat… Kamu berlatih Azure Fundamentals dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai Azure Fundamentals?

Tidak diperlukan pengalaman sebelumnya. Azure Fundamentals di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.

Berapa lama pelajaran “Alur Kerja Pengembang Menyeluruh” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran Azure Fundamentals ini?

Ya. Setiap pelajaran Azure Fundamentals menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

Managed Identity untuk Autentikasi Tanpa Kata Sandi
Azure Service Bus untuk Pesan yang Terpisah
Azure Container Apps
Alur Kerja Pengembang Menyeluruh

← Kembali ke Azure Fundamentals