微服务架构下EF Core迁移独立CI/CD流水线搭建咨询

Hey there! Let's walk through setting up a standalone CI/CD pipeline for Entity Framework Core migrations, tailored to your current setup with Azure DevOps (formerly VSTS), separate Git repos for your API and database projects, and existing independent pipelines.

1. Prep Your Database Project #

First, confirm your EF Core database project (the one holding your DbContext and migration files) is fully independent:

• It should compile successfully with just dotnet build (no dependencies on your API project code).
• If you share any domain models between API and DB projects, package those as a separate NuGet library so the DB project can reference it without tying to the API repo.

2. CI Pipeline: Validate & Package Migrations #

The CI stage focuses on ensuring your migration code is valid, and prepping artifacts for deployment. Here's how to set it up in Azure DevOps:

• Pull Code: Configure your pipeline to pull directly from your EF Core database project's Git repo.
• Install Correct .NET SDK: Match the SDK version to your EF Core release (e.g., EF Core 6 uses .NET 6 SDK):

  - task: UseDotNet@2
    inputs:
      packageType: 'sdk'
      version: '6.x' # Swap for your EF Core-compatible SDK version
  

• Build the Project: Verify the code compiles without errors:

  - script: dotnet build --configuration Release
    displayName: 'Build EF Core Migration Project'
  

• Generate Idempotent Migration Script (Recommended): Create a reusable SQL script that can safely run multiple times—critical for production safety:

  - script: dotnet ef migrations script --idempotent --output migration.sql --configuration Release
    displayName: 'Generate Idempotent Migration Script'
    env:
      ConnectionStrings__Default: 'Server=.;Database=TempTestDb;Trusted_Connection=True;' # Use a temp DB for validation
  

• Publish Artifacts: Save the migration script or a packaged tool for the CD stage:

  - task: PublishBuildArtifacts@1
    inputs:
      PathtoPublish: 'migration.sql'
      ArtifactName: 'migration-script'
      publishLocation: 'Container'
  

3. CD Pipeline: Apply Migrations to Target Environments #

The CD stage deploys migrations to your dev/test/prod databases—prioritize safety and environment isolation here:

• Download CI Artifacts: Pull the migration script or tool from your CI pipeline:

  - task: DownloadBuildArtifacts@0
    inputs:
      buildType: 'current'
      downloadType: 'single'
      artifactName: 'migration-script'
      downloadPath: '$(System.ArtifactsDirectory)'
  

• Choose a Deployment Method:

  Option 1: Run Migrations Directly with dotnet ef #

  Use this for dev/test environments where you want quick, automated deployments. Store sensitive connection strings in Azure DevOps variable groups (never hardcode!):

  - script: |
      dotnet tool install --global dotnet-ef
      dotnet ef database update --configuration Release --project ./YourMigrationProject.csproj
    displayName: 'Apply EF Core Migrations'
    env:
      ConnectionStrings__Default: '$(TargetDbConnectionString)' # Pull from encrypted variable group
  

  Option 2: Execute Pre-Generated SQL Script (Best for Production) #

  For production, use this method to let your team audit the script before deployment. Use Azure's built-in SQL deployment task:

  - task: SqlAzureDacpacDeployment@1
    inputs:
      azureSubscription: 'YourAzureSubscriptionName'
      ServerName: 'your-sql-server.database.windows.net'
      DatabaseName: 'YourProductionDb'
      SqlUsername: '$(DbAdminUsername)'
      SqlPassword: '$(DbAdminPassword)'
      deployType: 'SqlTask'
      SqlFile: '$(System.ArtifactsDirectory)/migration-script/migration.sql'
  

• Add Environment Approvals: For production, mandatory manual approval ensures someone reviews the migration before it runs—add this in Azure DevOps's pipeline environment settings.

4. Optional: Integrate with Your API Pipeline #

If you want API deployments to sync with migrations:

• Set your migration pipeline as a pre-deployment condition for your API's corresponding environment (e.g., migration must deploy to test before API deploys to test).
• Use Azure DevOps release triggers to auto-start your API pipeline once migrations successfully deploy to a target environment.

5. Critical Best Practices #

• Sensitive Data Security: Store all connection strings, DB credentials in Azure DevOps encrypted variable groups—never commit them to Git.
• Environment Isolation: Use separate databases for dev/test/prod, with unique variable groups for each environment.
• Rollback Plan: Always back up databases before production migrations, and keep rollback scripts handy (you can generate a rollback script with dotnet ef migrations script <PreviousMigration> <LatestMigration>).
• Logging & Monitoring: Add tasks to log migration output to Azure Monitor, so you can quickly troubleshoot failed deployments.

内容的提问来源于stack exchange，提问作者Maxmanzero