-
Notifications
You must be signed in to change notification settings - Fork 245
Features
#Features of RoundhousE
This describes both advantages of RH and disadvantages. You should understand both it's strengths and weaknesses to understand if RH is something you can use in your organization.
RH subscribes to the idea of convention over configuration, which means you can pass the migrator very few configuration options to get it to work (rh.exe /d dbname), but pass as many options as necessary to meet your conventions. Say you don’t like the tables or folder names that RH uses, you can override those to whatever you want. See ConfigurationOptions.
RH versions the database how you want it versioned. You can supply it with a DLL path for it to pull the file version from. You can give it an XML file and XPath, or you can use the highest script number in the up folder. You can also just use a sequence based (non-global) form of passive versioning. See Versioning.
RH believes in low maintenance and keeping good clean history in your source control. This means that you don’t lump everything into one folder, you put your anytime scripts (views/functions/stored procedures/etc) into their own folders and track history as you go. RH is smart enough to only run these if they are new/different from the current existing scripts in the database.
RH has three modes of operation. Normal, DropCreate, and Restore. Notice none of those are Create like you may see in other migrators. If the intent in the end is to have a database ready to go, why would you want to have to make a step to specify that you want to create the database? RH is smart enough to realize that the database doesn’t exist and it creates it (unless you pass a switch explicitly telling it not to). Normal is just the migration as it is. DropCreate is used during development when you want to continually change the same scripts prior to production. Restore is used when you switch to maintenance mode and want to change the same maintenance script. See RoundhousEModes.
RH is environment aware, which means you can have environment specific scripts. If you have scripts or permissions scripts that are different for each environment you can give them a special name. See EnvironmentScripts.
RH is an easy to start using on legacy databases. You just take your old DDL/DML scripts and move them into a special folder that RH will only evaluate/run when it is creating a database (say on a new developers machine). You can arrange existing scripts into RH default folders or point RH to the existing folder types. RH splits scripts with the GO batch terminator in them.
RH speeds up your development process. You can use RH with NHibernate to refresh your database without leaving Visual Studio! Entity Framework and FluentMigrator are planned for this feature as well. See RoundhouseRefreshDatabaseFNH.
RH runs on just the .NET framework. This means you don’t need SMO installed like some other migrators require.
You can just download the bits of RoundhousE and start using it. No installation necessary.
It costs you nothing to use, the license is developer friendly (Apache 2.0). So you can use it with confidence at your place of business without worry that you haven't met some agreement.
Find a bug? Fix it and submit a path. Or let us know on the issues list. You want to discuss something about dk? Drop us a line on the mailing list
RH was originally built to meet the needs of SOx for the contributors. We found no other free tool at the time that could answer SOx auditing questions in the same way that RH can. When RH runs, it keeps track of exactly what was run in both the database and on the file system. It provides a log during execution and saves that log on the file system for later retrieval by auditors.
RH has many conventions, but the developers realize that not everyone is in the same situation. Therefore RH can meld to your expectations.
RH is set up to make DBAs life easier as well. If you have thousands of stored procedures, views, functions, you don't want to wait for a tool to run them all. RH only runs the files that have changed since the last time it ran. There is an override switch for this in case this doesn't meet your conventions.
RH does not support the concept of going down in migrations (yet). To get around this idea, you can take backups (if you can do backups) of your database and then run the migrator. If things go wrong, you can just restore the backup. One thing we have also done in the past was to fix the bad script and rerun the migrator, moving Up.
Since RH is useful in every environment along the way, having the ability to test your scripts over and over again really reduces the possibility for errors and a necessity for down. That said, it does happen, and knowing what RH will/will not support is important.
RH is not a code migrator (yet). If you are looking for a code migrator, there are quite a few good tools out there, including FluentMigrator and Mig#, and Entity Framework Code Migrations.
RH only migrates to the latest version set of the sql scripts you are giving it at run time. If you are using the output of a build or source, you can get to specific versions by deploying an older build.
RH does not have a GUI tool (yet). All of it's runs are done with the executable or some run you kick off with the embeddable DLL.