Previous Next

Jivespace Community Blog

Currently Being Moderated
Nick Hill

The Benefits of an Upgrade Framework

Posted by Nick Hill on Jul 19, 2007 5:01:00 PM

We have always been committed to making the user experience as painless as possible. Our goal has always been to create products that are incredibly easy to setup and administer; however, we went without developing an upgrade framework for some time.

 

Why did we wait until now? Well, because upgrades are generally viewed as a "one time" thing and we always had more demanding feature requests.  When we embarked on building Clearspace however, we knew from the start that building an upgrade framework would be a valuable investment, and help us reach the goal of making upgrades painless for both our existing and our rapidly growing customer base.

 

We knew that we needed a tool that did more than execute simple SQL scripts. We knew that it needed to be as robust as our setup tool. That means that it needed to be secure by requiring a system administrator to authenticate, concise by prompting the user that an upgrade needs to take place, and informative by alerting the user if a task has failed for any reason and providing them with the ability to manually perform that task.

 

  

 

 

You know that feeling when you get something free? Whether it is a free Ipod with your new Macbook Pro, or simply a free sample at Costco, it's a good feeling. Having developed this upgrade framework with the mindset of making our customer's lives easier, we quickly found many other benefits of having developed an upgrade framework:

 

Improves the user experience by allowing painless automated upgrades.

 

Customers no longer have to pour through documentation and gain access to their database administrators to execute scripts. The system will automatically determine which version is installed and perform all necessary upgrade tasks. Customers will be more willing to upgrade to new releases, which will result in reduced support costs and increased revenues.

 

Enhances the development process

 

How many times have you updated from version control and no longer been able to start up the application because of some changes made by another developer? How many times have you been working on a project when you receive an email from one of your team members saying that table xyz has been changed and all the developers need to execute some script? This unnecessary frustration and cost of development is solved with the upgrade framework and helps to decrease the cost of development.

 

Manages exact changes between versions

 

As a developer, I generally can not remember all the changes I made last week, let alone last month.  Unless you are highly disciplined and you keep notes of every major change you have made, you will likely miss something when it comes time to worry about upgrades. By writing an upgrade task when you make a change, you are effectively documenting your changes and will be ready to go when it is time to release.

 

Allows for demo servers to be up running during development

 

Having a demo server up for the company to use during development is beneficial in many ways. It allows your company to 'eat its own dog food' and test the functionality and usability of an application months before the beta process. However, managing the state of a demo server during development can be a daunting task. Not if you have an automated upgrade framework. Day to day changes will be picked up and your demo server will always be the latest and greatest.

 

 

Lowers the support burden for new releases and upgrade

 

When upgrades go smoothly, the cost of upgrading is lowered for both the customer and the company.

 

Improves the productivity of the Professional Services Department

 

Having previously worked in our professional services department, I know first hand how managing various projects can be difficult. Having an upgrade framework facilitates the process of making customizations to the core product. Not to mention two years down the road when the customer wants to upgrade the core product and keep their customizations.

 

 

Enables plugins to provide their own upgrade path.

 

Similar to customizations made by the professional services department, having the ability to provide automated plugin specific upgrade paths is insanely powerful.

 

For any of you looking to justify investing in an upgrade framework, it has been our experience that an upgrade framework will benefit everyone involved, and will pay for itself in a matter of weeks. In fact, I would go so far as to say that developing an automated upgrade framework is as essential a practice for enterprise applications as unit testing.



Jul 20, 2007 8:30 AM reuben.brown reuben.brown    says:

When going from version 1.1.1 to 1.3 I was forced to upgrade to 1.2 and still had to do some custom tweeking of the SQL manually.  I like the idea of an upgrade tool, but find that it should be able to handle some version skipping if needed.  You already have the upgrade information from the previous version so I would think it is not too hard to include the upgrade tools to ensure that if a user skips a version or two, that the upgrade would still work.
Jul 20, 2007 8:46 AM Nick Hill Nick Hill    says in response to reuben.brown:

The upgrade framework is designed to detect the version that you were running, and compare it with the new version you have installed. It will run all the tasks between your previous version and your new version. A user running Clearspace 1.0.0 can upgrade to Clearspace 1.3 in the exact same manner as a user running 1.2 would upgrade to 1.3. The only difference is that there will be more tasks that need to run for the 1.0.0 upgrade.
Jul 20, 2007 8:49 AM reuben.brown reuben.brown    says in response to Nick Hill:

It seemed odd that it would not work w/o displaying an error on the first task and not be aware of the indexes from the version I was using.  You guys do great work and I like what you are doing very much.  Keep it up.
Jul 20, 2007 9:15 AM Nick Hill Nick Hill    says in response to reuben.brown:

Thanks Reuben. There is a task in the 1.3 upgrade that is somewhat error prone. I'm not sure if you are interested, but since this is a developer community, I'll take the time to explain it a bit.

 

For 1.3, we wanted to make Clearspace OpenSQL Compliant. One of the (many) tasks in doing so requires that all index names be less than 18 characters. What the task does is drop all of the possible old index names, and then create all of the new indexes.

 

The problem is that in most databases, if you try to drop an index that doesn't exist, it throws a SQLException. Because there is no way for us to determine the reason for the SQLException, and simply no-op, we assume the worst (that the index does exist and some other exception caused the failure) and report it to the user. In most cases, the end result is the same, failing to drop and index that already doesn't exist. It kind of comes down to a design decision. Do we swallow the exception and continue the upgrade, without interruption to the user, or do we always report the exception and let the user determine the steps to take. We chose the latter, but in doing so did our best to provide the user with all the necessary information. What went wrong, and what still needs to be done. When the user fixes the failed task, the framework should kick back in and execute all remaining tasks.

 

Like any framework, there will always be shortcomings and issues to iron out, but our goal is to standardize the upgrade process and to make it as simple as possible for our customers. All the other stuff mentioned above is simply a nice bonus!
Jul 20, 2007 9:22 AM reuben.brown reuben.brown    says in response to Nick Hill:

I completely understand that decision and support the display of the error to the user.  The only thing I would like to see is an option when that error comes up to be able to create the new indexes and continue on from that screen.  That way if the indexes that you expected to remove are missing/miss-named you can create the new indexes and have the system work.
Jul 20, 2007 9:28 AM Nick Hill Nick Hill    says in response to reuben.brown:

I might be misunderstanding you, so please correct me if I am wrong, but I think we have what you are asking for. If it was missed, we might need to call it out more in the UI. I'll admit, that the big red box can be quite distracting If you look at the screenshots up above in the blog post, you can see what it looks like when an error occurs. There are two buttons on the buttom, retry the task, or do it manually. If you click on Manual, it will take you to a page with instructions on exactly what needs to be done by you (next screenshot). Once you perform the tasks outlines in the instructions page (in this case, dropping and adding the indexes manually), there is a Finished button that will take you back to the list of tasks, marking the failed task complete and continuing with the rest of the upgrade tasks.

 

Is there additional functionality you are looking for in the instructions page?
Jul 20, 2007 12:33 PM reuben.brown reuben.brown    says in response to Nick Hill:

I would like to see a variant of the manual task that would let me mark which lines to execute for me so I can more easily debug what went wrong, or just skip the failing parts.  Part of where this was difficult was using the internal database that comes w/ Clearspace.  If I could mark the the drop commands to be skipped, or just a few of them, then I could see which lines are bad when I re-tried the task.

Actions

Popular Blog Posts