Previous Next

Jivespace Community Blog

July 19, 2007
Nick Hill

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.

7 Comments Permalink
Nick Hill

Unfortunately wiki documents and discussions can only be created in a single specific space. The primary reason is that each space has its own set of permissions, allowed content types, etc. With that goal in mind, the logic around creating and viewing content living in multiple spaces could be counterintuitive.

 

But this problem is the ideal use case for tags. Think of a space as a folder on your operating system. It can have sub-spaces (nested folders) and some files (wiki docs and discussions). Each file must live in one and only one parent folder. We are all very comfortable with this paradigm, but the drawbacks become self-evident in time.

 

Let's take a simple example. I want to organize all of my recipes, so I create a folder (space) called recipes. Now what? Do I create more sub folders based of the type of food, such as Italian, Chinese, Indian, Mexican, etc. Or do I create sub folders for breakfast, lunch, dinner, and dessert? How do I classify an Italian dessert then?

 

The solution to this problem, at least in Clearspace, is to use tags and tag groups. So wiki documents and discussions must live in one and only one space; however, they can be tagged with any keywords you might use to look for them. You can then browse the content by tags, regardless of which space the content was created in. Tags will transcend this typical folder-tree structure that we are all used to, and provide a means to find relevant content regardless of where it is created.

 

Also, we went a step further and created tag groups. A tag group is nothing more than a named collection of tags. The primary benefit of a tag group is that it groups your content virtually. A wiki document or discussion is not created in a tag group,

but will be associated with one or more tag groups if it is associated with tags in the tag groups. If a discussions morphs into something entirely different in time, you can change its tags to change the tag groups it can be found in.

 

So when would you use a sub-space as opposed to a tag group? A good rule of thumb is to think about people as opposed to content. If you simply need need a way to organize content, use a tag group. If instead you need to capture permissions for specific users, limit available content types, and so on, then you should create a sub-space.

 

Here is an example of both:

 

Space: Product Development

Sub-spaces: Clearspace, Forums, Openfire, Spark

 

The preceding sub-spaces are some of our different products, and they would be sub-spaces because there are different teams with different permissions for each.

 

Space: Clearspace

Tag groups: Release Plan, Weekly Status, Documentation, Features

 

The preceding are tag groups because they are simple containers of content; they do not need all the extra complexity a sub-space provides. As mentioned above, it is entirely possible to create a document or discussion that can be found in both Documentation and Features simply by tagging your content with the appropriate tags, say "documentation" and "features."

8 Comments Permalink Tags: clearspace, clearspacex, organization

Actions

Popular Blog Posts