CODEWITHSUNDEEP
postgresqlazureazure-devopsazure-pipelinesef-core-3.1
Ferran R.
Ferran R.

Reputation: 194

Updating postgreSQL DB through EFCore migrations in Azure DevOps

In Azure DevOps, the way I used to update the SQL Server Database was with Entity Framework Core, using two tasks:

  1. In my Build Pipeline: This task that generated a sql script with my db migrations.
  2. In the Release Pipeline: This task to update the database using this script.

The thing is, now that I'm using a PostgreSQL database, I can't find an easy and clean way to update the database in the same way. I've seen there's another task for MySQL that does exactly the same my release pipeline task did with SQL Server, but nothing for PostgreSQL.

So I thought I could basically execute dotnet ef update database (with its proper options set) in the pipeline, but I was wondering if there's actually a way to keep updating the database in a smooth way as I did before.

Upvotes: 5

Views: 2613

Answers (1)

Ferran R.
Ferran R.

Reputation: 194

I finally got to fix it.

There are two solutions I found to fix the issue.

  1. First, there's a common fix for all the databases that support Entity Framework Migrations:
    • Using a .NET Core Task, we'll have to install the dotnet ef tool: The task would look like this:

Intalling dotnet ef tools

And this would be the YAML (in case you want to use it in out of the release pipeline):

 - task: DotNetCoreCLI@2
  displayName: 'dotnet custom'
  inputs:
    command: custom
    custom: tool
    arguments: 'install --global dotnet-ef --version 3.1.4 --ignore-failed-sources'
  • And once we have the required tools installed, with a CMD or a Bash Task, we'll have to execute a script like this:
dotnet ef database update -c <DBCONTEXT> -p <PROJECT> -s <STARTUP_PROJECT> -v --no-build

You just have to add the flag -c in case you have more than one context in your project (sometimes the other DbContexts can come from some nugget packages).

Notice I added the flag --no-build since I already built the project in the build pipeline to follow good practices.

  1. The other option (and the one I finally used), it's been to use this task that basically does the same process, with the difference that it does it by using your already compiled .dll files, so you won't have to copy the entire project to make the migrations work. The setup of the task, although you have to fill many inputs, it's pretty straightforward, and it's supposed to work with other Databases as well.

However, if I had to use SQL Server or MySQL I would use a migrations script, since the process it's much easier (you just need to generate a .sql script and then it's the only file required for deploying the migrations).

Upvotes: 5

Related Questions