Reputation: 1
I'm new to this but wondered there could be a standard practice that enables developers accessing the same database to work without getting affected while the schema changes, the model changes and the related code changes (in our MVC application) are happening (and being tested) using same database.
I guess we have to take a copy of the database where we could implement schema changes. How do we bring/import those changes into the database so others can see the new changes to the database.
Upvotes: 0
Views: 83
Reputation: 10014
If you are using Visual Studio and TFS for source control, you could include a database project in your solution: http://msdn.microsoft.com/en-us/library/xee70aty.aspx. This would allow you to use TFS for your database source control.
Another option is to use a database source control tool such as Redgate: http://www.red-gate.com/products/sql-development/sql-source-control/
Upvotes: 2
Reputation: 48522
Best practice dictates you have something roughly equivalent to a development DB, QA DB and Production DB. Even having a separate development DB can get a bit tricky if multiple developers are changing it and those changes conflict with what other developers expect the state of the schema to be.
Most of us at our company develop against local databases and then check those changes into source control on a regular basis. Each of the developers will then do a get latest on those changes and integrate them into their codebase etc.
Then the changes in source control are migrated to QA for testing and then to production.
By the way, we're using SSDT (Sql Server Development Tools) for our source control with TFS. Our database is in its own SSDT database project. You absolutely should be using some sort of version control for your database schema. After all, your database schema is source code too, just like your MVC code.
Upvotes: 1