This last year I had a focus to get more involved in Open Source (OSS). The year before I had been involved a little by submitting a patch here and there, but 2009 was a big year for me in OSS. I now manage 4 open source projects that have solved a need for me and others. Coming up on the end of the year it was important for me to get some final touches into at least two projects to finish out the year.
UppercuT (UC), for those of you who have never heard of it, is an automated build tool that uses conventions to build your code. That means that you can have a professional build for most projects out of the box within 3 minutes! You drop it into a project, update a simple configuration and you’re done. It is also extendable (to the point of steps being completely replaced) so it’s very powerful. The goals we had for UC when we started it are that it’s insanely easy to use, easy to upgrade your builds, and easy to extend. It has met all of those goals and has some features that other build tools do not have (versioning out of the box and templating for configurations, documents, sql, deployment files, etc to name a couple). Check it out at http://projectuppercut.org.
So what milestone did we finish for UC? When the project started, there were plans for support for multiple types of source control for versioning the assemblies. We supported Subversion (SVN) from the beginning, but the priority for other types was lower. I’m pleased to announce that in the last two months we’ve added both TFS and GIT. The GIT one is a little more interesting. It follows what is suggested for versioning by Chris Ortman, GitFu and in the Git documentation. We also go the extra mile to show the SHA1 as well so you could theoretically get to that version.
How easy is it to do versioning with Git? Assuming you have a git repository, you crack open the configuration and change your source control to git:
If you’ve used UppercuT in the past or have been dying to try it out, set a goal to look at the latest verion this year before February.
RoundhousE (RH), for those of you who have not heard of it, is a database migrations tool that uses SQL Scripts. RH is kind of like Tarantino. We had originally wanted to contribute our ideas to Tarantino, but some of the goals for the two didn’t line up nicely so RoundhousE was born. RoundhousE runs update scripts (the goal is DDL/DML only), but it also looks for other scripts in other folders (like functions, views, and sprocs). The reasoning for the separation is so that versioning and seeing version history is much cleaner in source control. RH also versions databases the way you want. We prefer to version our databases based on source control, but it is extendable to be versioned in any way (or not at all). RH has an MSBuild task, a NAnt task, but most importantly, a command line console (rh.exe). Everything is configurable (including the version and scripts run tables). Check it out at http://projectroundhouse.org. RH has quite an extensive roadmap for where it is going (we are moving it to be a total migration package, not just a migration runner).
So what milestone did we finish for RH? Making RH environment aware so you can execute environment specific scripts. Why would you want to do that? What if you wanted to insert a bunch of test data into your database but didn’t want that to get into production? What if you want to run the output of templated scripts for granting permissions to different users in different environments?
Here I have a set of permissions scripts. Notice they are environment specific.
Notice also that they have two things. They have “.ENV.” in the name to let RH know they are environment scripts. Then they also have the name of the specific environment (LOCAL, TEST) they should be run in. By the way, If you use UC and templating, you only maintain one file in source control and the file per environment is generated at build time (I digress). So we have some environment files and now I run RH to migrate my database.
We can see from the log notes below that it only runs the LOCAL environment script in the LOCAL environment.
LOCAL.GrantRobDataReaderDataWriterPermissions.ENV.sql is an environment file. We are in the LOCAL environment. This will run based on this check.
Running LOCAL.GrantRobDataReaderDataWriterPermissions.ENV.sql on (local) - TestRoundhousE.
TEST.GrantRobDataReaderDataWriterPermissions.ENV.sql is an environment file. We are in the LOCAL environment. This will NOT run based on this check.
And to be sure, we look in the database:
If you’ve looked at RoundhousE in the past or haven’t yet looked at it, it’s worth downloading and running the sample to see what it can do.
By the way, you’ve probably noticed that have a definite theme with our developer automation tool suite (WarmuP, UppercuT, RoundhousE, DropkicK, HeadlocK, and SidePOP). We are still not solid on the library name, but pretty close. Each of the tools are designed to be enjoyable to use and free. We respond to inquiries and fix problems quickly. Once we have a name for the library, we may offer enterprise support for those that would require that.