ofver – automating repository-based software installations

In a nutshell, ofver is a very simple library/tool to simplify software deployment management on agile environments. ofver helps you to create and maintain installation and upgrade code (scripts) for your applications (regardless of the type of application), making it easy to evolve deployments from one version to another, allowing you to customizing small sections of the default work-flow, if required, with a minimal effort.

Project is located in Google code, under ofver project: http://code.google.com/p/ofver/

In this sense, ofver is meant to be used in what one may call “repository-based deployments”, in which instead of using packages or other software distribution channels, the development software repository is indeed used (e.g. in a stable branch).

Having said that, this is by no-means a post trying to discuss on whether it is better to use this or that deployment strategy.We all love package-based software distributions, but ofver is generally meant to be used when this approach, for whatever reason, does not fit, and a more rapid deployment strategy is in need.

The concept

One deployment strategy sometimes used nowadays is to deploy applications from a copy of the repository, usually using a stable or production branch. However placing the code is often not enough, as it remains things like installation of dependencies, installation and migration of the database schemas, file management duties…

Fortunately, some development environments do provide some or even most of this functionality (Capistrano in RoR [1], Fabric [2], Chef [3]…), however not all of them do, and in addition usually they have to be used in the context of this particular  technology/framework.

The idea behind ofver is very simple; try to fill this gap for the cases in which neither packaging is the selected choice nor the development environment or frameworks does provide such features on its own.

The main features offered by the library/tool are currently:

  • Create a simple set of scripts that automate the generic tasks of installation and upgrade procedures. In this sense, installation code can be seen as part of the development, growing with the code.
  • Application framework/programming language agnostic. This is why primary tools are used, such as shell scripts.
  • Simplifying the task of creating version aware installation/upgrade specific  work-flows, maximizing code re-usage from default or generic installation/upgrade work-flows.
  • Allow ofver code to live in the same branch as the application code, or in an external source (e.g. in an external branch, repository or even under a HTTP server).
  • Allowing transactional support for roll-back mechanisms.
  • Logging.

ofver tool

ofver tool/library source code is very lightweight and simple, and is splitted between the code of ofver on its own, and the code specific to the installation and upgrade worflow of the targeted application. The first level tree has the following directories and files:

  • common : containing the set of libraries used
  • log : directory used to store log files of each execution
  • ofver : executable
  • repo : file containing commands to upgrade ofver code during upgrades procedures.
  • rescue : directory used to store the backups.
  • settings : settings file
  • versions : versions folder is containing the scripts specific to the applciation which wants to be mantained by ofver

For more details regarding this and other technical aspects you can take a look at the Demo.

ofver has currently two main commands install and upgrade (implementation of other commands, like for instance remove is trivial with the current structure).  With the following pre-defined(minimal) workflows:

This basic structure of ofver should not be altered, but use customization over above workflows by using modules instead. The important aspect of all this is that all of this pieces which we can call modules, can indeed be particularized for specific versions/version jump. Example: install module can be specifically overwritten for version 1.1 by only putting a file under versions/1.1/install/install and put the code in it.

The same happens with the upgrade procedure, in which you can even specify “from”, “to” or “from and to” versions, and particularize the workflow for it.

Moreover, and this is probably one of the most attracting features, within the modules themselves, using ofver loadModule routine one can particularize even smaller pieces of the workflow, as right figure is showing.

Authorship and related links

ofver was originally created as a tool for deploying the Ofelia Control Framework software, developed within WP5 of OFELIA FP7 project, and is being actively developed by i2CAT.

Project site: http://code.google.com/p/ofver/
Tutorial: http://code.google.com/p/ofver/wiki/Demo

Contact { marc.sune | leonardo.bergesio } @ i2cat.net for further information.

References

[0] http://code.google.com/p/ofver/
[1] https://github.com/capistrano/
[2] http://docs.fabfile.org
[3] https://github.com/opscode/chef

This entry was posted in Software. Bookmark the permalink.