Cloud & IT Cert Prep · บทเรียน

เวิร์กโฟลว์นักพัฒนาแบบต้นจนจบ

เวิร์กโฟลว์นักพัฒนาแบบต้นจนจบ เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

วงจรการพัฒนา Azure สมัยใหม่

เวิร์กโฟลว์การพัฒนา Azure สมัยใหม่เชื่อมการควบคุมซอร์ส, CI/CD, โครงสร้างพื้นฐานคอนเทนเนอร์ และการสังเกตการณ์ระบบเข้าด้วยกันเป็นวงจรภายในที่ราบรื่น ตั้งแต่การคอมมิตโค้ดไปจนถึงการทำงานจริงที่ตรวจสอบได้ องค์ประกอบสำคัญ ได้แก่ GitHub (ซอร์ส), GitHub การดำเนินการ (ไปป์ไลน์การสร้างและการปรับใช้), Azure Container Registry (ที่จัดเก็บอิมเมจ), Azure Container Apps (สภาพแวดล้อมทำงาน) และ Application Insights (การสังเกตการณ์ระบบ) การเปลี่ยนแปลงแต่ละครั้งจะเคลื่อนจากแล็ปท็อปของนักพัฒนาไปยังระบบจริงโดยอัตโนมัติภายในไม่กี่นาที พร้อมด่านตรวจสอบคุณภาพในทุกขั้นตอน

ขั้นตอนที่ 1: การควบคุมซอร์สและกลยุทธ์การแยกสาขา

จัดระเบียบโค้ดของคุณในที่เก็บ GitHub โดยใช้การพัฒนาแบบยึดทรังก์หรือกลยุทธ์การแยกสาขาแบบ GitFlow สำหรับไมโครเซอร์วิสส่วนใหญ่ การพัฒนาแบบยึดทรังก์ (แยกสาขาฟีเจอร์อายุสั้นแล้วผสานเข้ากับ main ทุกวัน) ช่วยลดความขัดแย้งในการผสานและทำให้ไปป์ไลน์เรียบง่าย ใช้กฎการป้องกันสาขากับ main เพื่อกำหนดให้ตรวจสอบคำขอดึงและผ่านการตรวจสอบ CI ก่อนผสานไฟล์ CODEOWNERS ช่วยให้มั่นใจว่าการเปลี่ยนแปลงบริการสำคัญต้องได้รับอนุมัติจากวิศวกรอาวุโสของทีมที่เกี่ยวข้อง

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

ขั้นตอนที่ 2: CI ด้วย GitHub การดำเนินการ

ไปป์ไลน์ CI จะทำงานกับคำขอดึงทุกครั้ง เวิร์กโฟลว์ทั่วไปคือ: ดึงโค้ด → กู้คืนการพึ่งพา → เรียกใช้การทดสอบหน่วย → เรียกใช้การทดสอบการผสานรวม → สร้างอิมเมจ Docker → ส่งไปยัง Azure Container Registry อิมเมจจะติดแท็กด้วยSHA ของคอมมิต git เพื่อให้ตรวจสอบย้อนกลับได้ ใช้การตรวจสอบสิทธิ์ที่อิง OIDC จาก GitHub การดำเนินการไปยัง Azure (ผ่านข้อมูลประจำตัวแบบสหพันธรัฐ) เพื่อหลีกเลี่ยงการจัดเก็บข้อมูลลับของผู้ให้บริการ Azure ใน GitHub ซึ่งเทียบเท่ากับข้อมูลประจำตัวที่มีการจัดการสำหรับไปป์ไลน์ 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 }}

ขั้นตอนที่ 3: CD ไปยังสภาพแวดล้อมเตรียมใช้งาน

หลังจากไปป์ไลน์ CI ทำงานสำเร็จเมื่อผสานเข้ากับ main แล้ว ไปป์ไลน์ CD จะปรับใช้กับสภาพแวดล้อมเตรียมใช้งานโดยอัตโนมัติ ไปป์ไลน์จะอัปเดตแท็กอิมเมจของ Container App เป็น SHA ที่สร้างขึ้นใหม่ รอให้รุ่นใหม่มีสถานะสมบูรณ์ และเรียกใช้การทดสอบควันกับ URL ของสภาพแวดล้อมเตรียมใช้งาน การทดสอบควันจะตรวจสอบว่าจุดปลายทาง API ที่สำคัญส่งการตอบสนองตามที่คาดไว้ หากการทดสอบควันไม่ผ่าน ไปป์ไลน์จะย้อนกลับโดยเปลี่ยนการรับส่งข้อมูลขาเข้ากลับไปยังรุ่นก่อนหน้าโดยไม่ต้องดำเนินการด้วยตนเอง

# 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

ขั้นตอนที่ 4: ด่านอนุมัติสำหรับระบบจริง

หลังจากตรวจสอบสภาพแวดล้อมเตรียมใช้งานแล้ว ไปป์ไลน์ CD จะหยุดที่ด่านอนุมัติ การป้องกันสภาพแวดล้อมของ GitHub การดำเนินการช่วยให้คุณกำหนดผู้ตรวจสอบที่จำเป็นสำหรับสภาพแวดล้อม production ได้ ไปป์ไลน์จะส่งการแจ้งเตือน Slack ไปยังวิศวกรเวรประจำที่ตรวจสอบผลการทดสอบของสภาพแวดล้อมเตรียมใช้งาน ความแตกต่างของโค้ด และเหตุการณ์ที่ยังไม่ปิด ก่อนอนุมัติ เมื่อได้รับอนุมัติเท่านั้น ไปป์ไลน์จึงจะดำเนินการปรับใช้ SHA ของอิมเมจเดียวกันไปยังระบบจริง ขั้นตอนที่มีมนุษย์ร่วมตรวจสอบนี้สำคัญอย่างยิ่งสำหรับบริการที่มีปริมาณการใช้งานสูงหรืออยู่ภายใต้การกำกับดูแล

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

ขั้นตอนที่ 5: การสังเกตการณ์ระบบจริง

เมื่อปรับใช้กับระบบจริงแล้ว Application Insights จะให้ข้อมูลเชิงลึกแบบเรียลไทม์ SDK ของ App Insights (หรือการวัดค่าด้วยเครื่องมืออัตโนมัติสำหรับสภาพแวดล้อมทำงานที่รองรับ) จะติดตาม: อัตราคำขอ อัตราความล้มเหลว และเวลาแฝง (สัญญาณสำคัญสามประการ), การเรียกใช้การพึ่งพา (ไปยังฐานข้อมูล Service Bus และ API อื่น ๆ) และข้อยกเว้นพร้อมร่องรอยสแตกทั้งหมด แผนผังแอปพลิเคชันจะแสดงภาพว่าบริการต่าง ๆ เรียกใช้กันอย่างไร และเน้นว่าการพึ่งพาใดมีส่วนทำให้เกิดความล้มเหลวหรือเวลาแฝงมากที่สุด

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

การเชื่อมโยงการปรับใช้กับร่องรอย

ใช้คำอธิบายประกอบของ Application Insights เพื่อทำเครื่องหมายเหตุการณ์การปรับใช้ในแผนภูมิเมตริก เมื่อสร้างคำอธิบายประกอบรุ่น (ผ่านการดำเนินการ azure/appinsights-annotation ของ GitHub การดำเนินการ) คำอธิบายประกอบนั้นจะปรากฏเป็นเส้นแนวตั้งบนแผนภูมิเมตริกของ App Insights ทั้งหมด ทำให้เห็นได้ทันทีว่าการเพิ่มขึ้นของเวลาแฝงหรืออัตราข้อผิดพลาดสัมพันธ์กับการปรับใช้ล่าสุดหรือไม่ ซึ่งช่วยลดเวลาเฉลี่ยในการวินิจฉัย (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 }}'

ย้อนกลับอัตโนมัติเมื่ออัตราข้อผิดพลาดเพิ่มสูงขึ้น

สำหรับไปป์ไลน์ที่มีความทนทานสูงที่สุด ให้ใช้การย้อนกลับอัตโนมัติ หลังการปรับใช้กับระบบจริง ไปป์ไลน์จะรอ 10 นาทีแล้วสอบถาม Application Insights เพื่อหาอัตราข้อผิดพลาด หากอัตราข้อผิดพลาดสูงกว่าเกณฑ์ที่กำหนดค่าได้ (เช่น >5%) ไปป์ไลน์จะย้อนกลับโดยอัตโนมัติด้วยการอัปเดตการรับส่งข้อมูลขาเข้าของ Container App ให้ชี้ไปยังรุ่นก่อนหน้า 100% รูปแบบการส่งมอบแบบค่อยเป็นค่อยไปนี้ช่วยลดขอบเขตผลกระทบของการปรับใช้ที่มีปัญหา และช่วยให้ทีมปรับใช้ได้อย่างมั่นใจ แม้เป็นการเปลี่ยนแปลงที่ซับซ้อนหรือมีความละเอียดอ่อน

# 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

ประสิทธิภาพการทำงานของนักพัฒนา: การพัฒนาในเครื่องด้วยตัวจำลอง

นักพัฒนาควรสามารถเรียกใช้และทดสอบสแตกทั้งหมดในเครื่องได้โดยไม่ต้องเชื่อมต่อกับทรัพยากร Azure ของระบบจริง ใช้Azure Storage Emulator (Azurite) สำหรับพื้นที่จัดเก็บบล็อบและคิวในเครื่อง Cosmos DB Emulator สำหรับการทดสอบฐานข้อมูลในเครื่อง และService Bus Emulator สำหรับการส่งข้อความในเครื่อง ตัวแปรสภาพแวดล้อม AZURE_ENVIRONMENT=local สามารถสลับ DefaultAzureCredential ให้ใช้สตริงการเชื่อมต่อที่ชี้ไปยังตัวจำลอง ขณะที่โค้ดเดียวกันใช้ข้อมูลประจำตัวที่มีการจัดการใน Azure Docker Compose จะจัดการการทำงานร่วมกันของการพึ่งพาในเครื่องทั้งหมดด้วยคำสั่ง 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'

ความปลอดภัยในเวิร์กโฟลว์ของนักพัฒนา

ผสานความปลอดภัยเข้ากับทุกขั้นตอนของเวิร์กโฟลว์นักพัฒนา: Dependabot สแกนหาการพึ่งพาที่มีช่องโหว่ในคำขอดึง; GitHub Advanced Security (การสแกนโค้ดด้วย CodeQL) ตรวจจับช่องโหว่ เช่น การแทรก SQL และข้อมูลลับที่เขียนตายตัว; Microsoft Defender for DevOps ผสานรวมกับ GitHub เพื่อแสดงคำแนะนำด้านความปลอดภัยของ Azure ควบคู่กับการเปลี่ยนแปลงโค้ด และการสแกนช่องโหว่ของ ACR Defender ตรวจสอบอิมเมจคอนเทนเนอร์เพื่อหาช่องโหว่ CVE ในชั้นระบบปฏิบัติการและชั้นแอปพลิเคชันหลังการส่งแต่ละครั้ง ผลการตรวจสอบความปลอดภัยจะปรากฏเป็นความคิดเห็นในคำขอดึง จึงได้รับการแก้ไขก่อนผสาน

นำทุกอย่างมารวมกัน

เวิร์กโฟลว์นักพัฒนาที่สมบูรณ์คือวงจรป้อนกลับอย่างต่อเนื่อง: นักพัฒนาคอมมิตโค้ด, CI สร้างและทดสอบอิมเมจคอนเทนเนอร์, ส่งอิมเมจไปยัง ACR โดยใช้ SHA ของคอมมิตเป็นแท็ก, CD ปรับใช้กับสภาพแวดล้อมเตรียมใช้งานและเรียกใช้การทดสอบควัน, มนุษย์อนุมัติการปรับใช้กับระบบจริง, ไปป์ไลน์ปรับใช้กับระบบจริงและสร้างคำอธิบายประกอบรุ่น และ Application Insights ตรวจสอบอัตราข้อผิดพลาดพร้อมย้อนกลับอัตโนมัติเมื่อเกินเกณฑ์ โครงสร้างพื้นฐานในรูปโค้ด (Bicep หรือ Terraform) ในที่เก็บเดียวกันช่วยให้มั่นใจว่าไปป์ไลน์, Container App และการกำหนดค่าการตรวจสอบทั้งหมดถูกควบคุมเวอร์ชันควบคู่กับโค้ดแอปพลิเคชัน

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด Microsoft Azure Fundamentals (AZ-900) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า เวิร์กโฟลว์นักพัฒนาแบบครบวงจร เชื่อมการควบคุมซอร์สของ GitHub, CI/CD ของ GitHub การดำเนินการ, Azure Container Registry, Container Apps และ Application Insights เข้าด้วยกัน, คำอธิบายประกอบรุ่นช่วยเชื่อมโยงการปรับใช้กับการเปลี่ยนแปลงของเมตริกเพื่อวินิจฉัยเหตุการณ์ได้รวดเร็วยิ่งขึ้น และการย้อนกลับอัตโนมัติที่อิงจากการสอบถามอัตราข้อผิดพลาดช่วยลดขอบเขตผลกระทบจากการปรับใช้ที่มีปัญหา ขั้นถัดไป เราจะเปลี่ยนไปสู่การเตรียมสอบด้วยการทบทวนแนวคิดคลาวด์และสถาปัตยกรรม Azure อย่างครอบคลุม

คำถามที่พบบ่อย

บทเรียน “เวิร์กโฟลว์นักพัฒนาแบบต้นจนจบ” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “เวิร์กโฟลว์นักพัฒนาแบบต้นจนจบ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “เวิร์กโฟลว์นักพัฒนาแบบต้นจนจบ”

เชื่อมต่อ GitHub Actions CI/CD, Azure Container Registry, Container Apps และ Application Insights เป็นวงจรการพัฒนาภายในที่สมบูรณ์ ตั้งแต่การส่งการเปลี่ยนแปลงจนถึงระบบจริงที่ตรวจสอบได้ คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “เวิร์กโฟลว์นักพัฒนาแบบต้นจนจบ” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม

ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

ข้อมูลประจำตัวที่จัดการเพื่อการยืนยันตัวตนแบบไร้รหัสผ่าน
Azure Service Bus สำหรับการส่งข้อความแบบแยกส่วน
Azure Container Apps
เวิร์กโฟลว์นักพัฒนาแบบต้นจนจบ

← กลับไปที่ Cloud & IT Cert Prep