ใช้ไปป์ไลน์ CI/CD

  • 12 นาที

จนถึงจุดนี้ทุกขั้นตอนในกระบวนการเป็นแบบแมนนวล สร้างโครงการเรียกใช้ SqlPackage ตรวจสอบรายงานการปรับใช้ ไปป์ไลน์ CI/CD จะเปลี่ยนลําดับนั้นให้เป็นสิ่งที่เกิดขึ้นโดยอัตโนมัติในทุกการคอมมิต ด้วยขั้นตอนเดียวกัน ในลําดับเดียวกัน ทุกครั้ง ไม่มีแฟล็กที่ถูกลืม ไม่มีการพิมพ์ผิดในสตริงการเชื่อมต่อ ไม่มี "มันทํางานบนเครื่องของฉัน"

ออกแบบโครงสร้างท่อ

ไปป์ไลน์ฐานข้อมูลส่วนใหญ่เป็นไปตามรูปแบบสองขั้นตอน:

  1. สร้าง: คอมไพล์โครงการฐานข้อมูล SQL และสร้าง .dacpac สิ่งประดิษฐ์
  2. ปรับใช้: เผยแพร่ไปยัง .dacpac ฐานข้อมูลเป้าหมาย โดยเคลื่อนผ่านสภาพแวดล้อม (การพัฒนา การจัดเตรียม การผลิต)

การสร้างครั้งเดียวและปรับใช้สิ่งประดิษฐ์เดียวกันทุกที่ช่วยขจัดปัญหา "ทํางานในการพัฒนา แตกในการผลิต" ที่ .dacpac ผ่านการตรวจสอบความถูกต้องในการแสดงละครเป็นไฟล์เดียวกับที่ปรับใช้กับการผลิต

ใช้ไปป์ไลน์ CI/CD ด้วย GitHub Actions

เวิร์กโฟลว์ GitHub Actions อยู่ใน .github/workflows/ และกําหนดไปป์ไลน์ของคุณเป็น YAML การดําเนินการจะ azure/sql-action จัดการ .dacpac การปรับใช้กับฐานข้อมูล Azure SQL

นี่คือเวิร์กโฟลว์ที่สร้างขึ้นจากทุกการผลักดัน main และปรับใช้กับการผลิต:

# .github/workflows/sql-deploy.yml
name: Build and Deploy SQL Project
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4

    - name: Build SQL project
      run: dotnet build ./Database.sqlproj -o ./output

    - name: Upload dacpac artifact
      uses: actions/upload-artifact@v4
      with:
        name: dacpac
        path: ./output/Database.dacpac

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: production
    steps:
    - name: Download dacpac artifact
      uses: actions/download-artifact@v4
      with:
        name: dacpac

    - name: Install SqlPackage
      run: dotnet tool install -g microsoft.sqlpackage

    - uses: azure/login@v2
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

    - uses: azure/sql-action@v2.3
      with:
        connection-string: ${{ secrets.AZURE_SQL_CONNECTION_STRING }}
        path: './Database.dacpac'
        action: 'publish'

📝 การสนับสนุน azure/sql-action.dacpac, .sqlproj, และ .sql สคริปต์ ทํางานร่วมกับการรับรองความถูกต้องของ SQL, Microsoft Entra ID และการรับรองความถูกต้องของบริการหลัก

ถ้าฐานข้อมูล Azure SQL ของคุณเปิดใช้งานกฎไฟร์วอลล์ IP ของตัวเรียกใช้ GitHub Actions จําเป็นต้องมีการเข้าถึง เมื่อคุณจับคู่ azure/login กับ azure/sql-actionการดําเนินการจะเพิ่มกฎไฟร์วอลล์ชั่วคราวสําหรับ IP ของนักวิ่งระหว่างการปรับใช้และลบออกในภายหลัง

ใช้ไปป์ไลน์ CI/CD ด้วย Azure DevOps

Azure DevOps จัดเตรียม SqlAzureDacpacDeployment งานสําหรับ .dacpac การปรับใช้ นี่คือไปป์ไลน์ที่เทียบเท่า:

# azure-pipelines.yml
trigger:
  - main

pool:
  vmImage: 'windows-latest'

steps:
- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    projects: './Database.sqlproj'
    arguments: '-o $(Build.ArtifactStagingDirectory)'

- task: PublishBuildArtifacts@1
  inputs:
    PathtoPublish: '$(Build.ArtifactStagingDirectory)/Database.dacpac'
    ArtifactName: 'dacpac'

- task: SqlAzureDacpacDeployment@1
  inputs:
    azureSubscription: 'your-service-connection'
    AuthenticationType: 'server'
    ServerName: 'your-server.database.windows.net'
    DatabaseName: 'your-database'
    SqlUsername: '$(SqlUser)'
    SqlPassword: '$(SqlPassword)'
    deployType: 'DacpacTask'
    DeploymentAction: 'Publish'
    DacpacFile: '$(Build.ArtifactStagingDirectory)/Database.dacpac'

สําหรับตัวแทน Linux หรือควบคุมกระบวนการได้มากกว่า ให้ติดตั้งและใช้ SqlPackage โดยตรง:

steps:
- script: dotnet tool install --global microsoft.sqlpackage
  displayName: 'Install SqlPackage'

- script: |
    sqlpackage /Action:Publish \
      /SourceFile:$(Build.ArtifactStagingDirectory)/Database.dacpac \
      /TargetConnectionString:"$(ConnectionString)"
  displayName: 'Deploy database'

ไม่ว่าคุณจะใช้ GitHub Actions หรือ Azure DevOps ไปป์ไลน์ทั้งสองต้องการข้อมูลประจําตัวเพื่อเชื่อมต่อกับฐานข้อมูลของคุณ ขั้นตอนต่อไปคือการตรวจสอบให้แน่ใจว่าข้อมูลประจําตัวเหล่านั้นไม่อยู่ในไฟล์ YAML ของคุณ

สตริงการเชื่อมต่อที่ฮาร์ดโค้ดในไฟล์ YAML เป็นการละเมิดที่รอให้เกิดขึ้น ทั้ง GitHub Actions และ Azure DevOps มีกลไกในการจัดเก็บและแทรกข้อมูลลับในขณะรันไทม์โดยไม่ต้องเปิดเผยในการควบคุมแหล่งที่มา

ที่เก็บ GitHub และความลับของสภาพแวดล้อม

จัดเก็บค่าที่ละเอียดอ่อนเป็นข้อมูลลับของที่เก็บหรือข้อมูลลับของสภาพแวดล้อม ในที่เก็บ GitHub ของคุณบน github.com:

  1. เลือกการตั้งค่า >ข้อมูลลับและตัวแปร>การดําเนินการ
  2. เลือก ข้อมูลลับของที่เก็บข้อมูลใหม่
  3. เพิ่มชื่อ (เช่น AZURE_SQL_CONNECTION_STRING) และค่า

อ้างอิงข้อมูลลับในเวิร์กโฟลว์ ${{ secrets.SECRET_NAME }}ของคุณด้วย ข้อมูลลับของสภาพแวดล้อมมีขอบเขตตามสภาพแวดล้อมการปรับใช้เฉพาะ ดังนั้นข้อมูลประจําตัวการผลิตจึงสามารถเข้าถึงได้เฉพาะงานที่กําหนดเป้าหมายการผลิตเท่านั้น

การรับรองความถูกต้องของบริการหลักและ OpenID Connect

ยังดีกว่า ข้ามรหัสผ่านไปเลย OpenID Connect (OIDC) พร้อม azure/login การรับรองความถูกต้องโดยใช้ข้อมูลประจําตัวแบบรวมศูนย์ โดยไม่มีข้อมูลลับไคลเอ็นต์ที่จัดเก็บไว้ที่ใดก็ได้ คุณต้องมีค่าสามค่า:

  • AZURE_CLIENT_ID: รหัสแอปพลิเคชัน (ไคลเอ็นต์) ของบริการหลัก
  • AZURE_TENANT_ID: รหัสผู้เช่า Microsoft Entra ID ของคุณ
  • AZURE_SUBSCRIPTION_ID: รหัสการสมัครใช้งาน Azure ของคุณ

บริการหลักรับรองความถูกต้องผ่านข้อมูลประจําตัวแบบรวมศูนย์ ดังนั้นจึงไม่มีรหัสผ่านให้หมุนเวียนหรือรั่วไหล

การรวม Azure Key Vault

สําหรับการจัดการข้อมูลลับแบบรวมศูนย์ ให้จัดเก็บสตริงการเชื่อมต่อและข้อมูลประจําตัวใน Azure Key Vault และให้ไปป์ไลน์ของคุณดึงข้อมูลเหล่านั้นในเวลาปรับใช้ ใน Azure DevOps งาน Azure Key Vault จะดึงข้อมูลลับลงในตัวแปรไปป์ไลน์ ใน GitHub Actions ให้ใช้ azure/login ตามด้วยคําสั่ง Azure CLI เพื่ออ่านจากห้องนิรภัย

สำคัญ

หมุนเวียนข้อมูลประจําตัวฐานข้อมูลอย่างสม่ําเสมอ Azure Key Vault สามารถรวมเข้ากับ Azure Functions เพื่อหมุนเวียนข้อมูลลับโดยอัตโนมัติ ซึ่งช่วยลดความเสี่ยงของข้อมูลประจําตัวที่ถูกบุกรุก

ใช้การควบคุมไปป์ไลน์การปรับใช้

ไปป์ไลน์ที่ปรับใช้กับการผลิตในทุกการผลักดันโดยไม่มีขั้นตอนการตรวจสอบมีความเสี่ยงต่อการเปลี่ยนแปลงฐานข้อมูล คุณต้องมีการควบคุมที่ป้องกันไม่ให้การเปลี่ยนแปลงที่ยังไม่ได้ตรวจสอบไปถึงการใช้งานจริง

กฎการป้องกันสภาพแวดล้อม

ทั้ง GitHub และ Azure DevOps รองรับ สภาพแวดล้อมที่มี กฎการป้องกันที่เกตการปรับใช้:

  • ผู้ตรวจสอบที่จําเป็น: สมาชิกในทีมอย่างน้อยหนึ่งคนต้องอนุมัติก่อนที่งานการปรับใช้จะทํางาน ใน GitHub ให้กําหนดการตั้งค่านี้ภายใต้>กฎการป้องกันสภาพแวดล้อมการตั้งค่า>
  • ตัวจับเวลารอ: เพิ่มความล่าช้าระหว่างการอนุมัติและการดําเนินการ ทําให้ทีมมีหน้าต่างในการพิจารณาใหม่
  • สาขาการปรับใช้: จํากัดสาขาที่สามารถกําหนดเป้าหมายสภาพแวดล้อมได้ ตัวอย่างเช่น ปรับใช้กับการผลิตเท่านั้นmain

นโยบายสาขา

นโยบายสาขาปกป้องสาขาหลักของคุณและทําหน้าที่เป็นด่านแรกของการป้องกัน ใน Azure DevOps ให้กําหนดค่า:

  • จํานวนผู้ตรวจทานขั้นต่ํา สําหรับคําขอดึงข้อมูล
  • การตรวจสอบความถูกต้องของบิลด์ ซึ่งเรียกใช้บิลด์โปรเจ็กต์ SQL เป็นการตรวจสอบ PR ก่อนการผสาน
  • การแก้ไขความคิดเห็น โดยกําหนดให้ต้องแก้ไขความคิดเห็นในการทบทวนทั้งหมด
  • รวมผู้ตรวจทานโดยอัตโนมัติ ดังนั้นบุคคลที่เฉพาะเจาะจงจะถูกเพิ่มลงใน PR ที่สัมผัสไฟล์ฐานข้อมูล

GitHub ให้การป้องกันที่คล้ายคลึงกันผ่านกฎหรือชุดกฎการป้องกันสาขา

เจ้าของโค้ด

CODEOWNERSไฟล์ (GitHub) หรือนโยบายผู้ตรวจทานที่รวมไว้โดยอัตโนมัติ (Azure DevOps) ทําให้แน่ใจว่าบุคคลที่เหมาะสมจะตรวจสอบการเปลี่ยนแปลงฐานข้อมูล ไม่มีไฟล์ SQL ใดถูกรวมเข้าด้วยกันโดยที่ทีมฐานข้อมูลไม่เห็น:

# .github/CODEOWNERS
/Database/ @db-team
*.sql @db-team @dba-lead

กฎนี้กําหนดให้สมาชิกของ Pull db-team Request ตรวจสอบคําขอดึงข้อมูลใดๆ ที่ปรับเปลี่ยนไฟล์ SQL หรือโฟลเดอร์โครงการฐานข้อมูล

การตรวจสอบการควบคุมสาขา

ใน Azure DevOps การตรวจสอบการควบคุมสาขา ในการเชื่อมต่อบริการจะล็อกไปป์ไลน์ที่สามารถเข้าถึงข้อมูลประจําตัวการผลิตได้ เฉพาะไปป์ไลน์ที่ทํางานในบริบทของ main การเข้าถึง แม้ว่าจะมีคนปรับเปลี่ยนไปป์ไลน์บนสาขาคุณลักษณะเพื่อกําหนดเป้าหมายการผลิต แต่การเชื่อมต่อบริการจะปฏิเสธคําขอ

ประเด็นสําคัญ

ใช้ azure/sql-action (GitHub Actions) หรือ SqlAzureDacpacDeployment (Azure DevOps) เพื่อปรับใช้ .dacpac ไฟล์จากไปป์ไลน์ CI/CD ของคุณ จัดเก็บสตริงการเชื่อมต่อและข้อมูลประจําตัวเป็นข้อมูลลับของที่เก็บ ข้อมูลลับของสภาพแวดล้อม หรือใน Azure Key Vault และอย่าฮาร์ดโค้ดในไฟล์ YAML หากต้องการตรวจสอบสิทธิ์โดยไม่ต้องจัดเก็บรหัสผ่าน ให้ใช้ OpenID Connect (OIDC) กับข้อมูลประจําตัวแบบรวมศูนย์ ปรับใช้การผลิตแบบเกตด้วยกฎการปกป้องสภาพแวดล้อม ผู้ตรวจสอบที่จําเป็น และข้อจํากัดของสาขาการปรับใช้ ใช้ CODEOWNERS แฟ้มหรือผู้ตรวจทานที่รวมไว้โดยอัตโนมัติเพื่อให้แน่ใจว่าบุคคลที่เหมาะสมจะตรวจทานการเปลี่ยนแปลงฐานข้อมูล