تنفيذ خطوط أنابيب CI/CD

مكتمل

حتى هذه اللحظة، كانت كل خطوة في العملية يدوية. ابن المشروع، شغل SqlPackage، تحقق من تقرير النشر. خط أنابيب CI/CD يحول هذا التسلسل إلى شيء يحدث تلقائيا في كل التزام، بنفس الخطوات، وبنفس الترتيب، في كل مرة. لا علامات منسية، ولا أخطاء إملائية في سلاسل الاتصال، ولا "نجح على جهازي."

تصميم هيكل خط الأنابيب

تتبع معظم خطوط أنابيب قواعد البيانات نمطا من مرحلتين:

1. البناء: تجميع مشروع قاعدة بيانات SQL وإنتاج الأداة .dacpac الأثرية.
2. نشر: انشر ذلك .dacpac لقواعد البيانات المستهدفة، مع التنقل عبر البيئات (التطوير، المرحلة، الإنتاج).

البناء مرة واحدة ونشر نفس القطعة الأثرية في كل مكان يقضي على مشكلة "يعمل في التطوير، يتوقف في الإنتاج". الملف .dacpac الذي اجتاز التحقق في مرحلة المراحل هو نفس الملف الذي يتم نشره في الإنتاج.

تنفيذ خط أنابيب CI/CD باستخدام GitHub Actions

تعيش سير عمل GitHub Actions في .github/workflows/ خط الأنابيب الخاص بك وتعرف خط الأنابيب الخاص بك ك YAML. يتولى .dacpac الإجراء azure/sql-action النشر إلى قاعدة بيانات 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، ومصادقة المبادئ الأساسية للخدمة.

إذا كانت قاعدة بيانات 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'

لعملاء لينكس أو التحكم الأكبر في العملية، قم بتثبيت واستخدام 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. حدد Settings>Secrets and variables>Actions.
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 في الإنتاج.

نهج الفروع

سياسات الفروع تحمي فرعك الرئيسي وتعمل كخط الدفاع الأول. In Azure DevOps, configure:

• الحد الأدنى لعدد المراجعين لطلبات السحب.
• التحقق من البناء، الذي يشغل بناء مشروع SQL كفحص PR قبل الدمج.
• حل التعليقات، يتطلب معالجة جميع تعليقات المراجعة.
• يتم تضمين مراجعين تلقائيا، بحيث يتم إضافة أشخاص محددين إلى الPRs التي تلمس ملفات قاعدة البيانات.

يوفر GitHub حماية مماثلة من خلال قواعد حماية الفروع أو مجموعات القواعد.

ملاك الرمز

CODEOWNERS الملف (GitHub) أو سياسة المراجعين المشمولين تلقائيا (Azure DevOps) يضمن أن الأشخاص المناسبين يراجعون تغييرات قاعدة البيانات. لا يتم دمج أي ملف SQL دون أن يراه فريق قاعدة البيانات:

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

تتطلب هذه القاعدة من أعضاء ال " db-team Pull" مراجعة أي طلب سحب يعدل ملفات SQL أو مجلد مشروع قاعدة البيانات.

فحوصات التحكم في الفروع

في Azure DevOps، يقوم فحص التحكم في الفروع على اتصالات الخدمة بتحديد أي خطوط الأنابيب يمكنها الوصول إلى بيانات اعتماد الإنتاج. فقط خطوط الأنابيب التي تعمل في سياق main الحصول على الوصول. حتى إذا قام شخص ما بتعديل خط أنابيب في فرع ميزة ليستهدف الإنتاج، فإن اتصال الخدمة يرفض الطلب.

النقاط الموجزة الأساسية

استخدم azure/sql-action (GitHub Actions) أو SqlAzureDacpacDeployment (Azure DevOps) لنشر .dacpac الملفات من خط أنابيب CI/CD الخاص بك. تخزين سلاسل الاتصال وبيانات الاعتماد كأسرار مستودع، أو أسرار البيئة، أو في Azure Key Vault، ولا تقوم أبدا بترميزها بشكل ثابت في ملفات YAML. للمصادقة دون تخزين كلمات المرور، استخدم OpenID Connect (OIDC) مع بيانات اعتماد اتحادية. نشر الإنتاج عبر البوابات مع قواعد حماية البيئة، والمراجعين المطلوبين، وقيود فروع النشر. استخدم CODEOWNERS الملفات أو المراجعين المدرجين تلقائيا لضمان مراجعة الأشخاص المناسبين لتغييرات قاعدة البيانات.