Introduction
Entity Framework is a well-known technology in the ORM domain for the .NET world.
Note: Object Relational Mapping, this is the part between data persistence unit and some more “high level” code.
When you start a new entity framework project you have a few different ways to do it, one of which being “code first”. It means our code will drive the SQL Schema evolution (which simplifies a lot of things and allows you to focus on business and not technical implementation).
When you chose this approach you have a few methods to run the update of your schema:
Nuget or DNS console, a developer has to do it manually during deployment
Auto Migration, entity framework will update the database automatically at runtime when the application starts if it finds differences. This is really useful for small projects but it brings some bad sides: performances are degraded during application startup, you’re not in control anymore of “when” the update is going to happen.
Because we’re developers and really lazy people , because we want to avoid errors, oversights, save time to everybody, we’re going to automate the process while keeping it under control.
Following examples will be for DNX projects but classic .NET projects are really similar, just the commands change a little bit.
Note: this post assumes you’ve followed something similar to that article in setting up your dbcontext
https://docs.efproject.net/en/latest/platforms/aspnetcore/new-db.html
Build or release process?
In our case we’re using Visual Studio Team Services software industry for our software developments. Some of the provided services are build services and release management services.
In our case we have a real decoupling between our build and our release processes.
Build process is responsible for:
Transforming source code to deliverables (compilation, transpilation…)
Transmitting additional release artifacts (scripts)
Run unit tests
Release management process is responsible for:
Deploying deliverables to target environments
Data migration
Environments setup and configuration
…
Which explains why it makes sense in our case to put the database update process in our release process. Depending on how you set up your continuous delivery process it may differ a little bit and you may have to adapt examples.
Configuring definitions in VSTS
Script that will run the update
The first thing we’re going to want to add to our “code” is a script which will tell DNX to run the database update and a configuration source file which will allow to configure the db context.
It’s your lucky day because I’ve already done that for you, here are my gists
https://gist.github.com/baywet/9931ba2f45043dba9bdb
https://gist.github.com/baywet/ad41ccb8ad0bb12184ae
Getting the sources and the scripts
What must be understood is that DNX will use the source code and build it live in order to run the database update, I’m not aware of any way to do that from an already compiled DNX library (really just a nuget) available now.
What it means is we’ll need the sources to do the entity framework database update. Source that are already at hand if you’re doing that in the build process. In our case thought we’re updating the database schema from the release process. So you’ll need to bring your sources with your build artifacts.
To do so edit your build process and in “copy files” add two lines:
src\** for sources (our sources are in the folder src, which is a standard for DNX projects)
*.ps1 to bring the script we just added
Updating the schema during deployment
Last step is to update your deployment process to tell it to run the entity framework database update. To do so just add a powershell step and configure it to run the script we just added.
As argument give it the connection script you want to use for the database to be updated.
Conclusion
As you can see it’s pretty easy to automate and master the database update of an entity framework code first project with a release pipeline. And that with or without DNX involved.
I hope this post will save you guys time and deployments issues.