Implementarea pipeline-urilor CI/CD

Până în acel moment, fiecare pas al procesului era manual. Construiește proiectul, rulează SqlPackage, verifică raportul de implementare. Un pipeline CI/CD transformă acea secvență într-un lucru care se întâmplă automat la fiecare commit, cu aceiași pași, în aceeași ordine, de fiecare dată. Niciun steag uitat, nicio greșeală de tastare în șirurile de conexiune, niciun "a funcționat pe mașina mea".

Proiectează structura conductei

Majoritatea pipeline-urilor de baze de date urmează un model în două etape:

1. Build: compilează proiectul bazei de date SQL și produce .dacpac artefactul.
2. Implementează: publică asta .dacpac în bazele de date țintă, deplasându-se prin medii (dezvoltare, staging, producție).

Construirea o singură dată și implementarea aceluiași artefact peste tot elimină problema "funcționează în dezvoltare, se întrerupe în producție". Cel .dacpac care a trecut validarea în staging este același fișier care este implementat în producție.

Implementează un pipeline CI/CD cu acțiuni GitHub

Fluxurile de lucru GitHub Actions există și .github/workflows/ definesc pipeline-ul tău ca YAML. Acțiunea azure/sql-action gestionează .dacpac implementarea în baza de date Azure SQL.

Iată un flux de lucru care se bazează pe fiecare push către main și îl implementează în producție:

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

📝 Suporturile azure/sql-action.dacpac, .sqlproj, și .sql scripturile. Funcționează cu autentificare SQL, Microsoft Entra ID și autentificare principal de serviciu.

Dacă baza ta de date Azure SQL are reguli de firewall activate, IP-ul runner-ului GitHub Actions are nevoie de acces. Când te asociezi azure/login cu azure/sql-action, acțiunea adaugă o regulă temporară de firewall pentru IP-ul runner-ului în timpul implementării și o elimină ulterior.

Implementează un pipeline CI/CD cu Azure DevOps

Azure DevOps asigură sarcina SqlAzureDacpacDeployment pentru .dacpac implementare. Iată pipeline-ul echivalent:

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

Pentru agenți Linux sau mai mult control asupra procesului, instalează și folosește direct 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'

Indiferent dacă folosești GitHub Actions sau Azure DevOps, ambele pipeline-uri au nevoie de acreditări pentru a se conecta la baza ta de date. Următorul pas este să te asiguri că acele acreditări nu ajung în fișierele tale YAML.

Un șir de conexiune codificat fix într-un fișier YAML este o breșă care așteaptă să se întâmple. Atât GitHub Actions, cât și Azure DevOps oferă mecanisme de stocare și injectare a secretelor la rulare fără a le expune în controlul versiunilor.

Depozitul GitHub și secretele mediului

Stochează valorile sensibile ca secrete de depozit sau secrete de mediu. În depozitul tău GitHub pe github.com:

1. Selectați Setări>Secrete și variabile>Acțiuni.
2. Selectați Secret depozit nou.
3. Adaugă un nume (ca AZURE_SQL_CONNECTION_STRING) și valoarea.

Referinează secretele din fluxul tău de lucru cu ${{ secrets.SECRET_NAME }}. Secretele mediului sunt limitate pentru medii specifice de implementare, astfel încât acreditările de producție sunt accesibile doar pentru joburile care vizează producția.

Principalul de serviciu și autentificarea OpenID Connect

Și mai bine, sari complet peste parole. OpenID Connect (OIDC) cu azure/login autentificații folosind credențiale federate, fără niciun secret client stocat nicăieri. Ai nevoie de trei valori:

• AZURE_CLIENT_ID: ID-ul aplicației (client) al principalului serviciului.
• AZURE_TENANT_ID: ID-ul tău de chirian Microsoft Entra.
• AZURE_SUBSCRIPTION_ID: ID-ul tău de abonament Azure.

Principalul serviciului se autentifică prin credențiale federate, deci nu există parolă pentru rotire sau scurgere.

Integrarea azure Key Vault

Pentru gestionarea centralizată a secretelor, stochează șirurile de conexiune și acreditările în Azure Key Vault și lasă pipeline-ul să le extragă la momentul implementării. În Azure DevOps, sarcina Azure Key Vault preia secretele în variabile pipeline. În GitHub Actions, folosește azure/login comenzi CLI urmate de Azure pentru a citi din vault.

Implementarea controalelor pipeline-ului de implementare

Un pipeline care se implementează în producție la fiecare push fără pas de revizuire este riscant pentru modificări ale bazei de date. Ai nevoie de controale care să prevină ca modificările nerevizuite să ajungă în producție.

Reguli de protecție a mediului

Atât GitHub, cât și Azure DevOps suportă medii cu reguli de protecție care blochează implementările:

• Evaluatori obligatorii: unul sau mai mulți membri ai echipei trebuie să aprobe înainte ca jobul de implementare să fie rulat. În GitHub, configurează această setare sub Setări>Reguli de protecțiea mediilor>.
• Cronometră de așteptare: adaugă o întârziere între aprobare și execuție, oferind echipei o fereastră de reconsiderare.
• Ramuri de implementare: restricționează care ramuri pot viza un mediu. De exemplu, se implementează doar main în producție.

Politici ale filialelor

Politicile de ramură protejează ramura principală și servesc drept prima linie de apărare. In Azure DevOps, configure:

• Număr minim de recenzori pentru pull request-uri.
• Validarea build-ului, care rulează build-ul proiectului SQL ca o verificare PR înainte de fuziune.
• Rezolvarea comentariilor, cerând ca toate comentariile de recenzie să fie abordate.
• A inclus automat recenzorii, astfel încât anumite persoane să fie adăugate în PR-uri care ating fișierele bazei de date.

GitHub oferă protecții similare prin reguli sau seturi de reguli de protecție a ramurilor.

Proprietari de cod

Un fișier (GitHub) sau o politică a recenzorilor inclusă automat (Azure DevOps) se asigură că persoanele potrivite revizuiesc CODEOWNERS modificările bazei de date. Niciun fișier SQL nu este combinat fără ca echipa de baze de date să-l vadă:

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

Această regulă cere membrilor să db-team revizuiască orice pull request care modifică fișierele SQL sau folderul proiectului bazei de date.

Verificări de control al ramurii

În Azure DevOps, o verificare a controlului ramurilor pe conexiunile de servicii blochează care pipeline-uri pot accesa credențialele de producție. Doar pipeline-urile care rulează în contextul main obținerii accesului. Chiar dacă cineva modifică o conductă pe o ramură de funcționalitate pentru a ținti producția, conexiunea de serviciu refuză cererea.

Principalele concluzii

Folosește azure/sql-action (GitHub Actions) sau SqlAzureDacpacDeployment (Azure DevOps) pentru a implementa .dacpac fișiere din pipeline-ul tău CI/CD. Stochează șirurile de conexiune și credențialele ca secrete de depozit, secrete de mediu sau în Azure Key Vault și niciodată să nu le programezi fix în fișiere YAML. Pentru a te autentifica fără a stoca parole, folosește OpenID Connect (OIDC) cu credențiale federate. Poartă implementările de producție cu reguli de protecție a mediului, evaluatori obligatorii și restricții de ramuri de implementare. Folosește CODEOWNERS fișiere sau recenzori incluși automat pentru a te asigura că persoanele potrivite revizuiesc modificările bazei de date.