Entries Tagged 'BundleWorks' ↓

After a bit of a break to meet some client deadlines, I’d like to continue the series The Five Principles of Software Deployment. This entry discusses the fourth principle in that series: Releases should be easy to do and undo.

Doing a software release can be as simple as installing a new version of a single component on a single machine, or it can involve upgrading multiple components across multiple machines along with configuration and database changes. Undoing a software release, i.e. rolling back if the newly released software doesn’t work properly, can be a challenging, if not impossible, task.

This blog entry provides tips on how to make your software releases easier to do and undo.

Know your environments

The most important part of a software release is knowing your environments. You should be able to answer the following questions:

• What versions of the software (if any) are running in the target environments?
• Are the correct versions of all dependencies installed in the target environments?
• What OS versions are running on the machines and is the release compatible with these versions?

If you keep your environments consistent, it is easier to answer these questions.

Have proper backups

This point is especially important for being able to undo a release. You should ensure backups for the application itself, its configuration, any runtime files produced by the application, and any databases used by the application. Be skeptical of regular backups that are performed. I’ve seen cases where these backups were not being done properly or could not be restored. It is better to take a snapshot of all components at the time of release.

Document all release steps

Good documentation is essential to a good software release. Even if a release is completely automated, it is important to document the changes that will take place. This documentation must also include rollback steps. In a perfect world, rollback steps would not be necessary, but the world of software development is far from perfect.

Here are some of the things to include in release documentation:

1. List of machines included in the release.
2. List of components, with versions, to be released on each machine.
3. All steps necessary to do the release.
4. For larger releases, an hour-by-hour plan with time estimates and checkpoints
5. All steps necessary to undo the release.
6. List of tests to be performed to verify the release.
7. List of people who need to sign off on the release.
8. List of emergency contact names and phone numbers.

Automate the release to an appropriate level

Automation can help avoid human error during a release. I’m a big fan of automation. But there are some important points to remember about automation:

• Any code that automates a release is still code. This automation code must be tested thoroughly, including all use cases - installation, upgrade, and rollback.
• Automation is not a substitute for good documentation or for understanding exactly what will happen during a release. Blind reliance on automation can make diagnosing problems more difficult during a release.
• There is always a trade-off between the benefits gained from automation and the time spent to automate. An example would be writing and testing sophisticated database rollback code when a simple database dump and restore would do as well.

Test the release

You should have a staging environment where release steps can be tested before the final production release. Also, you should get someone else to test the release. Having another person follow your release steps is a great way to make sure that the release is documented properly.

Use BundleWorks

This tip is a shameless plug for our BundleWorks product. BundleWorks has features that help to make software releases easier to do and undo, including:

• Allowing multiple versions of an application to co-exist. This allows you to keep older versions around while you upgrading to newer versions, making it easier to roll back.
• Allowing multiple environments to co-exist on the same machine. This allows you to easily set up a staging environment for testing a release.
• Application management functions which allow you to see what versions are installed where.
• Standard hooks and a library of functions to help automate installing, upgrading, and rolling back applications.

If you want to give BundleWorks a try, you can download the latest version.

The last of the The Five Principles of Software Deployment, Failures should be obvious, will be covered in the next blog entry. Stay tuned.

The old saying goes “Necessity is the mother of invention.” This saying was proved true yesterday.

I was contacted by a developer eager to use our BundleWorks product to help manage their build and deployment process. There was one problem - they built their application on Windows and deployed to AIX. The deployment part wasn’t a problem since BundleWorks supports a variety of UNIX-based platforms, including AIX. But the Windows version of BundleWorks is not ready yet.

A thought came to me. A BundleWorks bundle is simply a set of directories and files in well-defined locations, very similar to a Java jar or war archive. With the proper changes to their current ant build script, this developer could produce a BundleWorks bundle without needing BundleWorks on their Windows machine.

The developer needed to make the following changes accomplish this:

1. Create BundleWorks action scripts to install and run their java application. These scripts ended up being a handful of lines long since they were able to rely on BundleWorks built-in functions.
2. Change their ant build.xml file to arrange their build output to match the layout of a BundleWorks bundle.
3. Use the ant echo task to write out a BundleWorks info file.
4. Use the ant zip task to create an archive for deployment.

Note that these steps are normally performed by the BundleWorks bundle command, so when BundleWorks is available for Windows, the developer’s ant script becomes simpler.

The developer made these changes, built a BundleWorks bundle for their application, and successfully deployed it to their AIX staging environment. Next week, they will deploy the application into their production environment.

The developer said they were eager to use BundleWorks to replace an error-prone upgrade process. Previously, they would deploy upgrades by manually copying new jar files to replace old ones, and they sometimes ran into trouble doing this. Using BundleWorks, the upgrade process became clean and safe, with an option to roll back if necessary.

The net result: one happy developer.

Yesterday I needed to set up a test installation of the Drupal content management platform for an upcoming project. It was only natural that I used our BundleWorks product to set up this Drupal test environment.

One of the main features of BundleWorks is that it allows you to create multiple independent environments on a single server and run multiple versions of an application in these environments. For now, I was only running one version of Drupal within a single environment, but I will eventually need to have Drupal (perhaps different versions) running in multiple environments for development and staging.

Drupal is written in PHP and is usually run with the Apache web server and MySQL database server. These three technologies make up the A-M-P in the LAMP technology stack (with Linux being the L).

BundleWorks supports LAMP technologies out of the box. It has “bundlers” specifically for creating Apache and MySQL bundles. It also has a bundler that can create bundles from source, which I used to create a PHP bundle. BundleWorks supports a variety of Linux versions, including the Ubuntu server that I use here.

I’ve posted the complete experience inside the BundleWorks forums for anyone interested in the details, but by the time I was done, I was able to run my Drupal test environment using the following commands:

use cms
mysqlserver start
apache start


I was also in a position to very easily create additional, independent Drupal environments on the same server. In the end, the effort to set up Drupal with BundleWorks was well worth it.

Welcome to the Sauers Technologies blog.

At Sauers Technologies, we are passionate about software development. We have a particular interest in tools to help build, test, deploy, and maintain software. In fact, we have written one of these tools ourselves. It is called BundleWorks, and we are just now releasing it as a public beta.

This blog will not just be about BundleWorks, however. It will cover a wide range of software development topics. We have experienced a lot in our years in the business, and we hope to be able to share some of this experience.

Over the next couple of weeks, we will kick off the blog with a set of entries entitled The Five Principles of Software Development. These entries will present some basic principles of software deployment learned over the years, sometimes the hard way.