Several blogs, including ours, have shared some introductory posts on how to structure an UrbanCode plugin. I decided to take these a step forward and actually build one for a reasonably well-known tool. I chose Liquibase as my guinea pig for several reasons. First, because it was outside the typical code mover scenarios – I am extremely passionate about moving the DevOps discussion forward from the too-typical “app and OS” issues. Second, I happen to know several of the people involved with Liquibase here in Austin. And Third, I felt Liquibase would be a good example of a good toolchain citizen as I have begun discussing on my personal blog.
I am not going to get deep into the use of Liquibase. That is well documented and, while the issues Liquibase addresses are only now getting the attention they deserve, the tool itself has been around for a while and is pretty well understood by folks who have been out in front of things a bit. So, my goals with this were to provide basic automation of core database tasks. I want to be able to bring the database under management, generate documentation for the database, and then perform update / rollback tasks on the database.
Translating that into Liquibase commands, that equates to:
Given that set of goals, the first step is to lay out the project. In the interests of keeping the effort simple, I decided to do at least this first version of the plugin as a simple command line wrapper. That way I get value quickly while still gaining the benefits of process integration and abstracting my users from lengthy command lines with many arguments. My plugin project therefore ended up needing the 3 XML files (info.xml, plugin.xml, and upgrade.xml) and 6 Groovy scripts – one for each of the Liquibase commands I wanted to capture in this first effort. These 9 files all went into a single directory and eventually a single ZIP file.
In the next couple of posts, I’ll flesh out the contents of these files.