CodeProjectWhen you are taking Code First Entity Framework route, having a proper migration plan becomes a crucial point. The migration process must be decided at an early stage to avoid road blocks down the road.
- Are you starting a new project using the code first approach?
- You have an existing project where you want to reverse engineer your database to use code first?
- Do you want to get rid of maintaining those sql script and handle the changes via your code?
Then this article will help you planning the right Entity Framework migration strategy for your project. Before we start comparing the Automatic and Code Based approach, lets know them a little better.
What are code first migrations anyways?
When you are developing your application, your models change frequently and you need to constantly maintain the sync between your database and model. In case you have a developed application which is live on production, you still will be making changes to your models, may be not that frequent, but changes are always required.
As a developer you always need to be careful about synchronizing between your model and database. This can be handled by maintaining SQL scripts, but a more elegant and seamless approach is to use Migrations. This way you only need to worry about your code changes and the database changes are taken care by Entity Framework itself.
Now, you still need to be careful about the way you choose to implement these migrations. A small overlook or mistake in your strategy can cost your time and cause you trouble in the long run. There are two approaches to implement migrations in Entity Framework, Automatic and Code Based.
In this approach you just need to turn on automatic migrations and the rest is magic. Every time your application runs, your database schema is checked against the model and updated. For implementation you can go through this MSDN article. Now, the magic has its limitations. When you are giving all control to the framework, the limitations of the automation becomes yours. However, this does not means this is not supposed to be used. This approach works very well in certain scenario which we will cover later in the article. Lets see some of the features this approach cannot offer.
- Column renames cannot be handled.
- Indexes and Constraints cannot be added.
- You cannot add a not null column with specific values.
- You cannot switch between migrations as automatic migrations are forward only.
- Cannot update Stored Procedures if you wanted to.
If any of the above points make you nervous about handling those migration changes then do not worry. There is another approach called code based migrations, which gives you a higher level of control over your migration.
Code Based Migrations
This approach gives you complete control over your migrations by providing migration class for each migration you create. These migration classes contain Up and Down methods to apply and revert migrations. Each time you apply a migration, the migration history captures the model and adds a new row for the same. In this approach you can add columns with default value, add indexes and constraints, switch between migrations, run SQL queries and many more. Detailed guidelines to implement this can be found in this link.
How to manage migrations in a team environment?
When working in a team depending on the version control system you use, you need to plan out a process to handle migrations done by different members of the team. You may face many challenges related to conflicts, merge issues, migration history mismatch, etc. But these can be avoided by having a solid workflow for your team. Michael Perry in his Pluralsight course explains very well how to manage migrations in large teams.
For each team member, the process for creating the migrations would be same.
- First you make the changes to your models and mapping configurations.
- Add the migration. Check the generated migration class.
- Delete and rectify the migration if something went wrong.
- Reiterate the process until you have a correct migration in place.
- Update the database and share the migration with the team.
Once you are happy with your migration changes, you need to share it with your team. In an ideal development environment setting, each team member must be working with a separate copy of the database on different branches. Sharing a database to apply migrations would not be a very good idea as there might be different changes coming from developers into same database.
After making the changes, you need to update your branch with the working branch. If there are no migrations added, you are good to go. Push the changes and your teammates can pull them and apply the migration to their databases.
Now, in your update if you found that there were migrations added by other developers, then you need to abort the remove your migration. Make sure your database is updated with the revert as well.
Now, update your branch again to get the migration of other developers and then add your own migration on top of it. This will maintain the correct sequence in the migration history table.
While writing software, the choices you take at the early stage decides how maintainable and sustainable your project will be. So, analyze your project scenario and make the correct choice by making an informed decision. Do let me know which migration technique you used in your project and why.