RedGate ReadyRoll is wonderful DB versioning tool which works like a charm. But the only one drawback - price.
I've researched what to use and found DBUp, Envolve... These tools are good but:
Doesn't have ability to define Up and Down scripts to be able apply and rollback migrations
Apply migration based on name ordering and not creation time. It's not big issue because developers could give the name based on the time but...
These tools doesn't allow to do development in different branches when developers uses not shared DB but their own and change DB schema separately. How to handle the issues when Team Lead have to switch between branches or when QA have to test feature before it goes to master - it's open question for me.
Using SSDT - as a case but it makes live very difficult if need do something with a DATA and not only with schema. What can be done very simple if use migration-based approach - becomes really big issue when try to do it with state-based one.
Can somebody suggest some tool for DB versioning with migration-based approach which can work with .NET stack and been free or paid but cheaper than RedGate?
Thanks
P.S.
What if use Entity Framework only for migrations? Without entities, etc. Create DB Context and do everything just to create migration files which has Up/Down and then write there scripts or define sql file to apply up/down migration changes. The only question - it's snapshots. How it will works with it.
Have somebody used this approach?
ReadyRoll also comes in a Core Edition, which is a free
entitlement if you also own a Visual Studio Enterprise license. I
admit this information isn't too helpful if you have VS Community or
Professional.
I'm updating this answer because Redgate no longer supports ReadyRoll Core edition. Instead Redgate's supported migrations tech is Flyway migrations, which comes with a free community edition.
We have decided to use EF Code First migrations to do what we need. If compare it with DbUp - EF Code First migrations contains Down script which allows us rollback DB to any target migration script.
Yes, it's not alternative for ReadyRoll and I have to accept that there are no any similar product which is surprised for me.
But it does what we need and after more than 1 month of usage I can say - it fit for our needs.
Because we we use EF Code First only for migrations scripts there is no issue with Team Collaboration described here because snapshot is always the same if your context doesn't have any entities.
Related
OK, here we go, after reading a couple of related questions, I haven't ended into a real productive solution for my thoughts.
Thoughts:
As we all developers creating applications, then these apps going into production, the client after couple of days demands additional features.
Great! you open your database through Server Explorer, create tables, add columns, maybe changing datatypes and then updating your model from database, nice it works everything OK!
Now you release the project with your way (InstallShield, InstallAware, VS Setup Project...).
You could e.g. have a schema compare tool, get the script, try it (it's working) and then add it to "InstallShield" or another installer supports this job!
I have been searching though if there is a way for entity framework to realize the changes, or if there is an out of the box way to update the schema based on your model???
In general is there Entity Framework 4 Schema Change support?
Thank you.
You never open Server Explorer to modify your schema, thats where it all falls apart. You always write an upgrade script and then apply the upgrade script to the client site. See Version Control and your Database. Or you store the project as a VS DB project and apply a vsdbcmd based upgrade of the on-site data based on your .schema file, but with this approach you give up a lot of control and it can ruin your day if you have large tables.
As for modeling tools schema upgrade support capabilities: they are quite well behind of the VSDB upgrade capabilities, and personally I find the explicit upgrade script based far superior and more flexible than any of the diff based tools (EF, VSDB, SQL Compare etc).
How do you manage your sql server database build/deploy/migrate for visual studio projects?
We have a product that includes a reasonable database part (~100 tables, ~500 procs/functions/views), so we need to be able to deploy new databases of the current version as well as upgrade older databases up to the current version. Currently we maintain separate scripts for creation of new databases and migration between versions. Clearly not ideal, but how is anyone else dealing with this?
This is complicated for us by having many customers who each have their own db instance, rather than say just having dev/test/live instances on our own web servers, but the processes around managing dev/test/live for others must be similar.
UPDATE: I'd prefer not to use any proprietary products like RedGate's (although I have always heard they're really good and will look into that as a solution).
We use Red-Gate SQLCompare and SQLDataCompare to handle this. The idea is simple. Both compare products let you maintain a complete image of the schema or data from selected tables (e.g. configuration tables) as scripts. You can then compare any database to the scripts and get a change script. We keep the scripts in our Mercurial source control and tag (label) each release. Support can then go get the script for any version and use the Redgate tools to either create from scratch or upgrade.
Redgate also has an API product that allows you to do the compare function from your code. For example, this would allow you to have an automatic upgrade function in your installer or in the product itself. We often use this for our hosted web apps as it allows us to more fully automate the rollout process. In our case, we have an MSBuild task that support can execute to do an automatic rollout and upgrade. If you distribute to third-parties, you have to pay a small additional license fee for each distribution that includes the API.
Redgate also has a tool that automatically packages a database install or upgrade. We don't use that one as we have found that the compare against scripts for a version gives us more flexibility.
The Redgate tools also help us in development because they make it trivial to source control the schema and configuration data in a very granular way (each database object can be placed in its own file)
The question was asked before SSDT projects appeared, but that's definitely the way I'd go nowadays, along with hand-crafting migration scripts for structural db changes where there is data that would be affected.
There's also the MS VSTS method (2008 description here), anyone got a good article on doing this with 2010 and the pros/cons of using these tools?
I'd like to have all DB DDL code under CVS.
We are using Subversion for our .NET code but all database code remains still unversioned.
All we know is how important DB logic can be. I've googled but I've found only few (expensive tools). I believe there exists other (cheaper) solution(s).
What approach do you advise to follow? What tools are most appropriate?
SQL Server 2005, VS 2008 TS, TSVN
UPDATE
Our coding scenario is that developers cannot access to PROD DB directly. It is changed only by scripts (so this is not a problem)
I'm mostly interested in the DEV environment where all of developers have full access.
So it happens that a developer overwrite USP previously changed by another.
I'd like to have the possibility to restore lost version / compare USPs revisions etc.
UPDATE-2
To create deployment script we are using Red-Gate SQL Compare.
Works perfectly - so deployment scripts are not a case.
If you haven't already read it, Martin Fowler's article Evolutionary Database Design is a great place to start.
The article is hard to summarize, but it describes how his team dealt with database versioning in a rapidly changing development process. They created their own tools to facilitate things: scripts to bring users up to the current master, to copy any version of the schema so users could debug one another's working copies, etc..
For a solid low-tech solution, I've found it helpful to keep two kinds of DDL scripts in source control:
A master version that can create the database objects from scratch.
'Version upgrade' scripts for each development iteration.
They're redundant to a degree, but extremely useful (particularly when it comes to deployment).
If you haven't already looked at the Visual Studio Database Edition GDR (a.k.a. "Data Dude"), you should definitely download it and try it out:
http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en
Among other things, the GDR will facilitate team development by making it easy for each developer to maintain their own local copy of a database, version scripts, create deployment scripts to move a database schema to a new version, and even support database rollback.
It's free if you are using team system developer edition. Check it out.
If you are using Visual Studio Team Suite or Visual Studio Developer Edition, you are entitled to a copy of Visual Studio Database Professional. This is designed to do exactly what you describe, and much more. We use it to manage our database schema (code).
Randy
We use Subversion for all our database code as well. Since nothing is allowed to go to Prod unless it is in a script, there seems to be no porblem with getting people to put all the scripts into subversion. We tend to write alter table scripts to change tables with existing data and then recreate the whole table structure in case we need to create a new database from scratch (we often have the same database structure on multiple servers as some of our clients are very large and do not want their data accidentally available to the competition and so pay for separate servers and therefore may need to create the whole database again with no data.) For objects that don't directly store data we drop the orginal object and recreate it with a create statement. Each project has it's own home inthe repository and each database does too, so the script may be in more than one place to facilitate deployment.
But the real key is that no one can load to Prod without a script. We don't give our devs direct rights to prod, so they have no problem doing things in scripts as opposed to using SSMS.
I wrote SMOscript which generates a CREATE script for each object in a database.
Use this tool to generate into a directory covered by CVS, and update your repository.
Finally I found this tool and approach extremely useful and very easy to introduce
(at least at the beginning - where no versioning solution on the place):
http://www.codeproject.com/KB/database/SQLScripter.aspx
You can run it out of the box.
For final solution I'd incline to GDR.
This also sounds interesting:
Freeware:
http://dbsourcetools.codeplex.com/
http://www.codeproject.com/KB/database/ScriptDB4Svn.aspx
http://www.codeproject.com/KB/database/SQLScripter.aspx
http://blog.boxedbits.com/archives/133
Commercial:
http://www.nobhillsoft.com/Randolph.aspx
You should use Management Studio (SSMS) and place the .sql under source control, possibly separate schema objects under folders.
Hope this helps
See if Wizardby fits your needs.
Interested if anyone has used VSTS Database Edition extensively and, if so, which features did you find the most useful over the standard Visual Studio database projects?
What are the most compelling features as opposed to alternative schema management options or tools like RedGate's SqlCompare etc?
Edit: Microsoft just released the RTM version of Database Edition (GDR) which adds support for SQL Server 2008 - link is here. I've previously blogged (briefly) about it here.
Has anyone had a chance to do any real work with the GDR? It looks like there are some real enhancements including refactoring support. I'd be really interested to hear if people are using it with SQL Server 2008...
Download From: [http://www.microsoft.com/downloads/details.aspx?FamilyID=bb3ad767-5f69-4db9-b1c9-8f55759846ed&displaylang=en]
We use the database edition functionality of Team Suite on Stack Overflow. As Vaibhav said, mostly it is useful because it gives you a one-click way to reverse engineer a database into source control, and keep it up to date.
Note that it also has decent Data and Schema compare tools as well. You can compare projects to physical databases and vice-versa. This makes it pretty easy to keep your database up to date, no matter where you make changes -- in the filesystem database project, or in the physical database itself.
If you compare it to tool like RedGates, that are specifically taylored for SQL Server, the benefits are that if you have the proper MSDN subscription you do not have to spend more money for other tools (but keep in mind that RedGate tools are much more mature) and it covers some points (like regression tests and unit tests at the DB level) that other tools do not cover and it make so in a integrate manner with other testing tool of VSTS, so that you can record results in Team System.
Compared to a tool like Embarcadero ErStudio (my solution of choice) it misses the cross database features, and this is a big problem, at least for me.
If you are a "all Microsoft" shop with the proper MSDN subscription it could be worth spending time on it.
We are currently using the GDR 2008 projects for managing our entire database development and deployment on a greenfield system. We use a TFS build script to call out to the MSBuild task for deploying the databases along with executing the data generation plans for pre populating the testing environment with data.
The key with the data generation plans was finding the build task to use which is :
TaskName="DataGeneratorTask"
AssemblyName="Microsoft.Data.Schema.Tasks, Version=9.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
All of this gdr project work has been unbelievably helpful and I think it is well worth the learning curve to get to know these project types. The value they provide is astronomical in productivity and visibility.
It allows us all to view the entire system in a single visual studio solution along with allowing us to start with a clean slate of our system at any point in time with either a click of the deploy command or a custom build configuration.
This blog
will help with getting the TFSBuild script to run if you're interested.
The VSDB test integration is so painful to configure that we abandoned it, and that's the only thing it's got that Red-Gate doesn't.
Red-Gate's tool is miles more useful. It does live DB and scripts in folders, but also has "snapshots." The aspect of Red-Gate SQL Compare that gives it the win is its Snapshot ability and the fact that your license allows you to deploy their assemblies and use them to perform database maintenance at customer run-time.
It has made upgrades in the COTS application that I develop a breeze. A Snapshot is a binary schema representation. You can package them as resources in an assembly, then use the snapshot in a customer run-time schema compare to bring an existing database up to the current rev.
Probably the best advantages are around being able to version control individual DB schema objects (which you could do with the older "Database Projects"), but have the power to "build"/deploy the project and convert those individual scripts into a complete database.
The ability to import scripts and have the Wizard covert individual schema items into separate files is very handy if you've inherited a DB schema.
Given that recently the licensing model changed, it makes it even more enticing because it's included with the Developer edition SKU. It also provised support for "Database Unit Tests" which might be useful.
From the 2008 GDR, I understand that they now support SQL Server 2008.
You can do database versioning for one. That is useful.
The other thing that is really useful is the ability to define type of seed data for testing. Through this Visual Studio will populate the database with random data and this is great for testing purposes.
There are other benefits as well of course.
It is always useful to put everything under the same source control, so your data-dude can be shelving, checking in, compare with history, and even resolve workitems and bugs using the same tools that other team members are using.
Also to be able to have one versionning mechanism across the whole application, in other words, it doesn't make sense to say that my source control has all the versions of my project while your database can't fit with any of these old versions, unless you take a backup or a snapshot of the database with each build.
I am looking for something to integrate to my CI workflow.
I've heard of dbdeploy but I'm looking for something else. The reason I don't like dbdeploy is I don't want to install java on my server.
I would prefer of course that the solution doesn't involve stringing some shell scripts together.
Here is a feature comparison between
Flyway
Liquibase
c5-db-migration
dbdeploy
mybatis
MIGRATEdb
migrate4j
dbmaintain
AutoPatch
It's not a tool, but Ambler and Sadalage's book, Refactoring Databases: Evolutionary Database Design is quite good.
Redgate will probably do everything you need. Expensive though.
EDIT - Specifically: http://www.red-gate.com/products/sql-development/readyroll/
You mentioned that you like dbDeploy and the fact that you do not want to install java on your server. Are you aware of the .NET port of this tool?
I used this recently with a team and we were very happy with it. In our case we were targeting SQL 2000, but it could easily be configured to run against other DB platforms, including MySQL. Of course it will require you to have the .NET Framework installed on the server... if that's an acceptable prerequisite vs. the java runtime.
for those people who are interested in liquibase, but don’t like xml migrations.
Take a look at groovy-liquibase, a plugin that supports groovy migrations
Liquibase is great in structure, but misses with xml migrations. This plugin solves that problem
Possible it's not your case, but if you decide to use Java take a look at liquibase
Yep, Redgate is magic. And Not that expenssive for what it provides.
Try Agile DBRIRE for Continuous Integration workflow. It's easy to set and allows to generate test db from Dev DB. Also it allows to generate incremental DB updates for Staging and Production. The tool can compare DEV and Staging/Production DB and generate metadata and data update SQL scripts. The tool is free.
Visual Studio Team system (database edition) does some refactoring.
I read the Refactoring databases book. I think it's helpful.
But in software dev, you build tests so that you are safe refactoring. They don't touch on tests in the Refactoring Databases book, which was my big disappointment with it.
I think those tools are very good, but for my purpose I have written a custom own. The main reason for this was because of I'm working on a SQL Server Compact 3.5 database, so none of the listed tools worked.
Of course it isn't as powerful as the tools from Redgate but you get the most important features very quick.
It's able to rename all kinds of database objects and migrating columns to other tables and create a diff script for 2 databases.
An important part of Refactoring Databases is the migrations part.
A .NET migrations solution that does not require EF or Java is Rob Reynold's Roundhouse
Might be worth checking out.