Do you really use Source Control? I’m not talking merely about having some code in a version control system. I’m talking about using source control as an efficient tool in your daily work. As a huge fan of the Joel Test I’ve put together my own 6 point test of source control usage:
The Anders Source Control Test
Is all of your code under source control?
Do you commit all of your changes, having your local copy and the repository completely in sync?
Is your source repository the master version of all code?
Do you know exactly what code revision that was used to build every single copy of the software deployed in production?
Can you make a bug fix to an old release and deploy it, without having to upgrade to the latest version?
Are all developers in the team comfortable with occasionally reverting all their working copy changes?
If you get 6 points you are definitely using source control. 5 points might do, but 4 or lower means that you are not using source control right.
In the Adding Indexes with EF Migrations post I showed how to add indexes to a database created by EF Code First with a separate migration step. When using code-based migrations to add a table, there is another, better way to add indexes, if it is done together with the table. If you’ve read my Type Safe SelectList Factory post you know my feelings about code that contains class or property names as strings. I was considering writing a similar post about indexes in EF Migrations until I found out that there is a built in index creation, using lambdas.
In my series exploring EF Migrations it is time to look into updates to tables. In this post I’ll make a simple update of a table by adding a column to it. Expanding on the example from the previous posts in this series a TopSpeed column is added to the cars table. Before doing the actual update there’s another thing I want to change. When working in a team I don’t think that automatic migrations give control enough. Using them would cause the developers to end up with different migration order for their databases, yet another migration order for the user test environment and finally another migration order in the production environment. I think that it is better to be strict and use manual migrations. So first I’ll disable the automatic migrations that I enabled previously and then go on and add the new column.
Most business applications use a database. Creating the database in the first place is the easy part. Continously evolving the database schema during development when multiple team members are doing changes in various parts of the database is one of the hard parts. The really hard part is to be able to upgrade – or revert back to – a specific version of the schema when needed.
In the first post in this series I created a basic database with the EF Code First features. One of the things I couldn’t do there was creating an index, so in this post I will look into adding an index to my database through EF Migrations in Entity Framework 4.3.