0Pricing
Azure Fundamentals · บทเรียน

การสร้าง CI Pipeline ด้วย Azure Pipelines

กำหนด YAML pipeline ที่ทริกเกอร์เมื่อมีคำขอดึงข้อมูล เรียกใช้การทดสอบหน่วย และสร้างอาร์ติแฟกต์การสร้าง จากนั้นตรวจสอบผลการทดสอบและความครอบคลุมโค้ดในพอร์ทัล

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

การผสานรวมอย่างต่อเนื่องคืออะไร

การผสานรวมอย่างต่อเนื่อง (CI) คือแนวปฏิบัติในการผสานการเปลี่ยนแปลงโค้ดเข้ากับสาขาที่ใช้ร่วมกันบ่อย ๆ โดยการผสานแต่ละครั้งจะเรียกใช้การสร้างและการทดสอบโดยอัตโนมัติ เป้าหมายคือการตรวจพบความล้มเหลวในการผสานรวมตั้งแต่เนิ่น ๆ ก่อนที่ปัญหาจะสะสมจนกลายเป็นปัญหาใหญ่ที่แก้ไขได้ยาก ไปป์ไลน์ CI ที่ดีจะสร้างโค้ด เรียกใช้การทดสอบหน่วย วัดความครอบคลุมของโค้ด ดำเนินการวิเคราะห์แบบสถิต และสร้างอาร์ติแฟกต์ที่พร้อมนำไปใช้งานได้ภายในไม่กี่นาที Azure Pipelines ให้กลไกอัตโนมัติสำหรับแนวปฏิบัตินี้

โครงสร้างไปป์ไลน์ YAML

ไปป์ไลน์ CI ของ Azure Pipelines กำหนดไว้ในไฟล์ azure-pipelines.yml ที่รากของที่เก็บของคุณ ไฟล์ YAML ระบุทริกเกอร์ (จะเรียกใช้เมื่อใด) พูล (จะใช้เอเจนต์ประเภทใด) และลำดับชั้นของระยะ งาน และขั้นตอน โดยค่าเริ่มต้น ระยะจะทำงานตามลำดับ งานภายในระยะจะทำงานแบบขนานตามค่าเริ่มต้น และขั้นตอนภายในงานจะทำงานตามลำดับ โครงสร้างนี้ช่วยให้คุณควบคุมลำดับการทำงานของไปป์ไลน์ได้อย่างละเอียด

# azure-pipelines.yml skeleton
trigger:
  branches:
    include:
    - main
    - 'feature/*'
  paths:
    exclude:
    - docs/**
    - '*.md'

pool:
  vmImage: ubuntu-latest

variables:
  buildConfiguration: Release
  nodeVersion: '18.x'

stages:
- stage: CI
  displayName: 'Build and Test'
  jobs:
  - job: Build
    displayName: 'Build Application'
    steps: []

การกำหนดค่าทริกเกอร์

Azure Pipelines รองรับทริกเกอร์หลายประเภท ทริกเกอร์สาขาจะเรียกใช้ไปป์ไลน์เมื่อมีการพุชโค้ดไปยังสาขาที่ระบุ ทริกเกอร์คำขอดึง (ทริกเกอร์ PR) จะทำงานเมื่อมีการเปิดหรืออัปเดต PR ที่มุ่งไปยังสาขาเป้าหมาย ซึ่งจำเป็นสำหรับการตรวจสอบโค้ดก่อนผสานรวม ทริกเกอร์ตามกำหนดเวลาจะทำงานตามเวลาที่กำหนด (เช่น การสร้างในแต่ละคืน) ทริกเกอร์ไปป์ไลน์จะเชื่อมโยงไปป์ไลน์เข้าด้วยกัน ระบุ trigger: none เพื่อปิดการทำงานอัตโนมัติและอนุญาตให้เรียกใช้ด้วยตนเองเท่านั้น

# Branch trigger
trigger:
  branches:
    include: [main, develop]

# Pull request trigger
pr:
  branches:
    include: [main]
  autoCancel: true  # Cancel previous runs when PR is updated

# Scheduled trigger (nightly build at 02:00 UTC)
schedules:
- cron: '0 2 * * *'
  displayName: 'Nightly Build'
  branches:
    include: [main]
  always: true  # Run even if no new commits

ขั้นตอน: สคริปต์และงาน

ขั้นตอนของไปป์ไลน์มีทั้งสคริปต์ (คำสั่ง bash หรือ PowerShell) หรืองาน (หน่วยที่สร้างไว้ล่วงหน้าและกำหนดพารามิเตอร์ได้จาก Azure DevOps marketplace) งานอย่าง NodeTool@0, DotNetCoreCLI@2 และ Maven@3 จะรวมการดำเนินการสร้างทั่วไปไว้ ใช้ displayName กับทุกขั้นตอนเพื่อให้บันทึกของไปป์ไลน์อ่านได้ง่าย แต่ละขั้นตอนจะทำงานตามลำดับ และไปป์ไลน์จะล้มเหลวหากขั้นตอนใดจบลงด้วยรหัสที่ไม่ใช่ศูนย์ เว้นแต่คุณจะตั้งค่า continueOnError: true

steps:
- task: NodeTool@0
  displayName: 'Install Node.js 18'
  inputs:
    versionSpec: '18.x'

- script: npm ci
  displayName: 'Install dependencies (clean install)'

- script: npm run lint
  displayName: 'Run ESLint'

- script: npm run build
  displayName: 'Build production bundle'

- script: npm test -- --ci --coverage
  displayName: 'Run unit tests with coverage'

การเผยแพร่ผลการทดสอบ

หลังจากเรียกใช้การทดสอบแล้ว ให้เผยแพร่ผลลัพธ์ไปยัง Azure DevOps โดยใช้งาน PublishTestResults Azure Pipelines จะแยกวิเคราะห์ไฟล์ผลลัพธ์รูปแบบ JUnit, NUnit, XUnit หรือ VSTest และแสดงจำนวนที่ผ่านหรือไม่ผ่าน ระยะเวลาการทดสอบ และรายละเอียดการทดสอบแต่ละรายการในส่วนติดต่อผู้ใช้ของการเรียกใช้ไปป์ไลน์ ระบบจะติดตามประวัติการทดสอบตามเวลา เพื่อให้คุณตรวจพบการทดสอบที่ไม่เสถียรและการถดถอยได้ นี่เป็นสิ่งสำคัญสำหรับการมองเห็นคุณภาพโค้ดทั่วทั้งทีม

# Example: Node.js project with Jest tests
steps:
- script: npm test -- --ci --reporters=jest-junit
  displayName: 'Run tests with JUnit reporter'
  env:
    JEST_JUNIT_OUTPUT_DIR: '$(Agent.TempDirectory)/test-results'

- task: PublishTestResults@2
  displayName: 'Publish test results'
  inputs:
    testResultsFormat: JUnit
    testResultsFiles: '$(Agent.TempDirectory)/test-results/**/*.xml'
  condition: succeededOrFailed()  # Publish even if tests fail

การเผยแพร่ความครอบคลุมของโค้ด

เผยแพร่รายงานความครอบคลุมของโค้ด เพื่อให้ Azure Pipelines แสดงเปอร์เซ็นต์และแนวโน้มความครอบคลุมในส่วนติดต่อผู้ใช้ของไปป์ไลน์ งาน PublishCodeCoverageResults รองรับรายงานรูปแบบ Cobertura หรือ JaCoCo ใช้ร่วมกับด่านความครอบคลุมของสาขา โดยกำหนดเกณฑ์ความครอบคลุมขั้นต่ำและทำให้การสร้างล้มเหลวหากความครอบคลุมลดลงต่ำกว่าเกณฑ์ แนวโน้มความครอบคลุมช่วยระบุช่วงที่มีการเพิ่มโค้ดใหม่โดยไม่มีการทดสอบที่สอดคล้องกัน

# Jest + coverage
- script: npm test -- --ci --coverage --coverageReporters=cobertura
  displayName: 'Run tests with coverage'

- task: PublishCodeCoverageResults@1
  displayName: 'Publish code coverage'
  inputs:
    codeCoverageTool: Cobertura
    summaryFileLocation: '$(System.DefaultWorkingDirectory)/coverage/cobertura-coverage.xml'
    reportDirectory: '$(System.DefaultWorkingDirectory)/coverage'

ตัวแปรไปป์ไลน์และกลุ่มตัวแปร

จัดเก็บการกำหนดค่าไปป์ไลน์ในตัวแปรที่กำหนดไว้ในระดับไปป์ไลน์ ระยะ หรืองานใน YAML สำหรับค่าที่มีความละเอียดอ่อน (คีย์ API และรหัสผ่าน) ให้ใช้ตัวแปรลับ โดยตั้งค่าในไลบรารีไปป์ไลน์ (ส่วนติดต่อผู้ใช้) หรือกลุ่มตัวแปร แล้วอ้างอิงใน YAML กลุ่มตัวแปรคือชุดตัวแปรที่นำกลับมาใช้ได้และใช้ร่วมกันระหว่างหลายไปป์ไลน์ เชื่อมโยงกลุ่มตัวแปรกับ Azure Key Vault เพื่อซิงค์ข้อมูลลับจาก Key Vault เข้าสู่ตัวแปรไปป์ไลน์โดยอัตโนมัติ

# Reference a variable group in a pipeline
variables:
- group: 'Production-Secrets'  # Linked to Azure Key Vault
- name: buildConfiguration
  value: Release

# Use a variable
steps:
- script: echo 'Building $(buildConfiguration) configuration'
- script: az webapp deploy --src-path drop.zip
  env:
    AZURE_SUBSCRIPTION_ID: $(AZURE_SUBSCRIPTION_ID)  # From Key Vault
    APP_API_KEY: $(APP_API_KEY)  # Secret, not printed in logs

อาร์ติแฟกต์: การจัดแพ็กเกจเอาต์พุตจากการสร้าง

หลังจากการสร้างสำเร็จ ให้จัดแพ็กเกจเอาต์พุตเป็นอาร์ติแฟกต์ไปป์ไลน์ เพื่อให้ระยะถัดไป (เช่น การนำไปใช้งาน) เข้าถึงได้ ใช้ PublishPipelineArtifact เพื่ออัปโหลดไฟล์จากเอเจนต์การสร้างไปยังที่จัดเก็บอาร์ติแฟกต์ของ Azure DevOps ในระยะหรืองานถัดไป ใช้ DownloadPipelineArtifact เพื่อเรียกอาร์ติแฟกต์กลับมา วิธีนี้แยกงานการสร้างออกจากงานการนำไปใช้งาน ซึ่งสามารถทำงานบนเอเจนต์อื่นหรือในระยะอื่นได้

# Publish build artifact
- task: PublishPipelineArtifact@1
  displayName: 'Publish build artifact'
  inputs:
    targetPath: '$(System.DefaultWorkingDirectory)/dist'
    artifactName: webapp-drop
    publishLocation: pipeline

# In a later deployment job, download the artifact
- task: DownloadPipelineArtifact@2
  inputs:
    artifactName: webapp-drop
    targetPath: '$(Pipeline.Workspace)/drop'

- script: ls -la $(Pipeline.Workspace)/drop

งานแบบขนานเพื่อการสร้างที่เร็วขึ้น

เรียกใช้งานที่ไม่ขึ้นต่อกันแบบขนานโดยกำหนดงานหลายรายการภายในระยะ ตัวอย่างเช่น เรียกใช้การทดสอบหน่วยและการสแกนความปลอดภัยพร้อมกันแทนการทำตามลำดับ งานแบบขนานต้องใช้เวลาการสร้างแยกกัน แต่สามารถลดระยะเวลารวมของไปป์ไลน์ได้อย่างมาก ใช้คุณสมบัติ dependsOn เพื่อให้งานรอให้งานอื่นอย่างน้อยหนึ่งงานเสร็จก่อนเริ่มทำงาน ซึ่งจะสร้างกราฟการขึ้นต่อกันภายในระยะ

stages:
- stage: CI
  jobs:
  - job: UnitTests
    displayName: 'Run unit tests'
    steps:
    - script: npm test

  - job: LintAndSecurity
    displayName: 'Lint and security scan'
    steps:
    - script: npm run lint
    - script: npm audit --audit-level=high

  - job: BuildArtifact
    displayName: 'Build and publish artifact'
    dependsOn: [UnitTests, LintAndSecurity]
    condition: succeeded('UnitTests') and succeeded('LintAndSecurity')
    steps:
    - script: npm run build

การตรวจสอบการสร้างด้วยนโยบายสาขา

เชื่อมโยงไปป์ไลน์ CI ของคุณกับนโยบายสาขาใน Azure Repos เพื่อให้ทำงานโดยอัตโนมัติในฐานะการตรวจสอบความถูกต้องของการสร้างบนคำขอดึงที่มุ่งไปยัง main ระบบจะบล็อกการผสานรวมจนกว่าไปป์ไลน์จะผ่าน รวมการตรวจสอบหลายรายการเข้าด้วยกัน ได้แก่ ไปป์ไลน์ CI ต้องสำเร็จ ผู้ตรวจสอบอย่างน้อย 2 คนต้องอนุมัติ ความคิดเห็นทั้งหมดต้องได้รับการแก้ไข และต้องมีรายการงานที่เชื่อมโยงอยู่ วิธีนี้สร้างด่านคุณภาพที่ทำให้ไม่สามารถผสานโค้ดที่เสียหายเข้ากับสาขาหลักได้

# Add build validation via CLI
az repos policy build create \
  --blocking true \
  --branch main \
  --branch-match-type exact \
  --build-definition-id <pipeline-id> \
  --display-name 'CI Build Validation' \
  --enabled true \
  --project MyProject \
  --repository-id <repo-id> \
  --queue-on-source-update-only true \
  --manual-queue-only false \
  --valid-duration 720  # Pipeline result expires after 12 hours

การอ่านผลการเรียกใช้ไปป์ไลน์

หลังจากการเรียกใช้ไปป์ไลน์เสร็จสิ้น ให้ตรวจสอบผลลัพธ์ในพอร์ทัล Azure DevOps แท็บ Summary แสดงผลผ่านหรือไม่ผ่านโดยรวมและเวลา แท็บ Tests แสดงผลการทดสอบทั้งหมดพร้อมการกรองตามผลลัพธ์ แท็บ Code Coverage แสดงเปอร์เซ็นต์ความครอบคลุมและเน้นบรรทัดที่ไม่มีความครอบคลุม คลิกงานใดก็ได้เพื่อดูเอาต์พุตบันทึกทีละขั้นตอน ไปป์ไลน์ที่ล้มเหลวจะแสดงขั้นตอนที่ล้มเหลวโดยเน้นด้วยสีแดง พร้อมเอาต์พุตข้อผิดพลาดทั้งหมดเพื่อวิเคราะห์ได้อย่างรวดเร็ว

# View pipeline run results via CLI
az pipelines runs list \
  --pipeline-ids <pipeline-id> \
  --project MyProject \
  --query '[].{id:id, status:status, result:result, startTime:startTime}' \
  -o table

# View logs from a specific run
az pipelines runs logs list \
  --run-id <run-id> \
  --project MyProject

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

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

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า Azure Pipelines YAML กำหนดไปป์ไลน์ CI ด้วยระยะ งาน และขั้นตอนสำหรับการสร้าง การทดสอบ และการสร้างอาร์ติแฟกต์ ทริกเกอร์ PR และนโยบายสาขาบังคับใช้ด่านคุณภาพที่บล็อกการผสานโค้ดที่เสียหาย และงาน PublishTestResults และ PublishCodeCoverageResults ทำให้คุณภาพการทดสอบมองเห็นได้ทั่วทั้งทีม ต่อไปเราจะสำรวจการนำไปใช้งานอย่างต่อเนื่องใน Azure

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

บทเรียน “การสร้าง CI Pipeline ด้วย Azure Pipelines” ฟรีหรือไม่

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

คุณจะเรียนรู้อะไรในบทเรียน “การสร้าง CI Pipeline ด้วย Azure Pipelines”

กำหนด YAML pipeline ที่ทริกเกอร์เมื่อมีคำขอดึงข้อมูล เรียกใช้การทดสอบหน่วย และสร้างอาร์ติแฟกต์การสร้าง จากนั้นตรวจสอบผลการทดสอบและความครอบคลุมโค้ดในพอร์ทัล คุณปฏิบัติ Azure Fundamentals ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Azure Fundamentals หรือไม่

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

บทเรียน “การสร้าง CI Pipeline ด้วย Azure Pipelines” ใช้เวลานานแค่ไหน

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

ฉันเขียนและรันโค้ดในบทเรียน Azure Fundamentals นี้ได้ไหม

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

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

  1. ภาพรวมบริการ Azure DevOps
  2. การสร้าง CI Pipeline ด้วย Azure Pipelines
  3. การปรับใช้อย่างต่อเนื่องไปยัง Azure
  4. GitHub Actions บน Azure
← กลับไปที่ Azure Fundamentals