Vladimir Sarić wrote this on February 27, 2013

Bringing life to your old Rails application, part 2

In Part 1 of this post we outlined the importance of good communication, a good development environment and automated tests. In this part we will build on those fundamentals and list the steps we take when improving the application.

Since the application is now covered with automated tests, we can safely and with confidence begin to change and add to its code base.

Upgrade

Before adding new features, we first need to upgrade application’s core elements.

The first of those core elements is, of course, Ruby. Upgrading Ruby isn’t too difficult and doesn’t take too much time, but the performance improvements can be significant. For example, Ruby 1.9 performs much better than Ruby 1.8. All of the potential incompatibilities, with the current application code, will become evident once automated tests are run. Those same tests can then serve as a guide to resolving the incompatibilities.

The second core element is Rails. When upgrading to a major version there are usually a number of good guides and in some cases even tools to help with the upgrade process. One of those tools is the rails-upgrade plugin which runs checks for obvious upgrade points on the path from Rails 2 to Rails 3. Just like with Ruby, the automated tests serve to indicate what has been broken with the upgrade and to guide the developer to potential fixes.

Since a standard Rails application uses a number of libraries, that is, Ruby gems, it’s not uncommon that those gems are not compatible with new versions of Ruby or Rails, and also require an upgrade. If the gems in question are well established, they are normally kept in line with newer versions of Ruby and Rails. If that’s not the case, there are usually a good number of alternatives. Because of this, before deciding on which gem to use, it’s always a good idea to see if the gem is being maintained regularly. After an upgrade or two, one really begins to appreciate judicious use of gems. Of course, sometimes it’s just simpler to roll your own solution.

One thing to remember, when performing an upgrade, is to try, if possible, to upgrade the application in parts. And as soon one part is upgraded, to deploy to the staging server, where stakeholders can see the progress and, if they wish, do some manual testing.

Add new value

After adding automated tests to have confidence to change the code, and upgrading core elements to ensure security and performance, it’s finally time to add new value to the application. Often this means both implementing new features and performing a visual redesign. We follow our process, where we continuously discuss goals, prioritize tasks, design first and write test-driven code.

Prepare users

It’s always a good idea to inform existing users what’s happening to the application. If the changes, both functional and design, are being deploy gradually letting users know might not be crucial, but it’s still good manners. Also, when users are aware that changes are being made for the better and that good things are coming, they might not be so frustrated when they encounter an error as a result of a change.

One way to inform the users is to post to the application’s blog. Even though having a blog has become a standard, we still see many applications that don’t have one or at least its quality is low. Depending on stakeholders’ requirements, the blog can either be custom made, that is, developed as a part of the application, or it can use a 3rd party service, that is, a blog on one of the popular blog hosting platforms. In either case, the blog has to look good and it’s design should resemble the application’s design as much as possible. More importantly, the information on the blog has to be relevant and kept up to date.

An application should also maintain an email newsletter. Newsletters are also a perfect tool for informing users of impending changes. Usually, a newsletter shouldn’t be sent more than once a month, as not to spam users, but it might be acceptable to send to it more often when the application is undergoing major changes. Again, depending on stakeholders’ requirements, the newsletter system can be a part of the application, but we suggest using a 3rd party service for this. There are a number of good services offering quality email newsletter solutions, which can also track the results.

Another method to consider, for informing users, is the use of application wide real time updates. These are especially useful and effective when a change requires some user action. Again, one has to be careful not to spam.

Backup

Before deploying new features to production, it’s important to have a good backup system. Last thing in the world we want is to lose existing user’s data.

Creating a database backup is a simple task, but the process should be automated as much as possible. The backup should be performed at least every few hours and before every database-altering deployment. One tool that we absolutely love for this task is the Backup gem.

Backup has built-in support for various databases, storage protocols/services, syncers, compressors, encryptors and notifiers which you can mix and match.

An application might also have data that isn’t in the database, like images, sound files, pdf documents… This data should probably already be hosted on a 3rd party service, which has it’s own backup system, but if that’s not the case, the application should itself have an adequate backup solution. For example, images can be backed up every few hours to Amazon’s S3.

Remember that you can’t be sure that your backup is good and working untill you’ve done / simulated a full recovery from it at least once.

Deploy to production

Since the application now has a backup system and the users have been made aware of coming changes, it’s finally time to deploy to production.

If the application in question is few years old, this could be the perfect time to update server’s hardware. The good thing is, that the new server can be set up, using the same script we used for setting up the development environment, while the old one is still running. Once the new server’s environment is set up, the database has been imported and all of the assets have been copied, all that is left to do is to update the DNS records. This way, the transition will be smooth and if something goes amiss, we still have the old server up and running.