What I want from a CMS: Part 1

I'm starting a new series of blogs which cover the aspects of the ideal CMS from my point of view (a .NET web developer).

The goal of this blog series is to identify the core needs of developers when working with CMS solutions to deliver client websites, and, with any luck, identify CMS solutions which match these requirements.

Part 1 : Structure Change Management

What does this mean?

First, let's quickly go over the workflow for developers when they're asked to add a field or page to a site using a typical multi-purpose CMS

1. Load the CMS as an administrator on the dev's local machine.
2. Configure the page/document/whatever to add the field that the client wants, such as:
   • Configure primary attributes (name, data type, validation).
   • Configure default values (if even possible).
   • Configure relationships to other pages/documents/whatever.
3. Save some data in the CMS to test the new field.
4. Make any necessary code changes to get the new field to populate on the business models.
5. Make any necessary changes to the front end code to make the field show to users.
6. Test it.
7. Check-in the code changes and deploy it to the development site.
8. Apply the configuration changes to the CMS on the development environment, redoing:
   • Configure primary attributes (name, data type, validation).
   • Configure default values (if even possible).
   • Configure relationships to other pages/documents/whatever.
9. Populate the field in the dev CMS and test the data on the dev site.
10. Repeat steps 7 to 9 for each environment that the changes have to be migrated to.

So based on this workflow you can now see that Strucutre Change Management is the process of managing changes to the CMS structure through multiple environments, something which developers have to do very often during the course of any project.

Why is structure change management important?

Some content management systems make changing their structure fairly easy as they only look at the way a database is set up, so managing changes between environments is as 'easy' as synchronising two database schemas.

However, most multi-purpose and 'flexible' content management systems utilise a 'data as structure' approach to maintain high flexibility which, unfortunately, kills the ability to easily and reliably migrate structure changes from one environment to another.

As a client or non-developer you probably don't care how long it takes or how hard it is for developers to deploy changes to a particular CMS, but you should. If a developer can roll out changes to a particular CMS quickly, easily, and with a very low fault rate, it improves the ability of your business to react to change and do so with a high level of confidence.. not to mention it will be a lot cheaper!

What are the key qualities of good structure change management?

Single Environment: The structure can be deployed at the same time as the website that relies on it

Automated: The structure can be deployed automatically as part of the same build & deployment pipeline that the site uses

Robust: There's no chance that the structure will not be updated when deployed to the target environment

Can be rolled back: In the case of accidental deployment, structure changes should be able to be rolled back in the same way as website changes

To my knowledge, there is no CMS change management solution which ticks all of these boxes.

How could it be better?

Pure database-driven content management systems are relatively straight forward to manage structure changes with because of the previously mentioned method of comparing two database schemas using tools.. but in reality there is still usually a total disconnect between what's in the database and what's in the CMS because database changes are very rarely version-controlled in the same way (and at the same time) as the code changes that utilise them. This only leads to mismatched versions of the database and code bases which only serve to increase the potential fault rate of migrating changes between environments.. and no-one wants that!

Custom scenarios

Depending on the CMS in use, they may have custom tools to allow the migration of changes between environments. Umbraco has a plugin called Courier which is meant to handle the synch of structure changes, however it's not able to be automated and not ~100% reliable in my experience.

A better alternative?

I think one of the better ways to handle structure change management is to drive the CMS structure from code. This solves many problems since updating the structure of the CMS is as easy as deploying the latest code base, something which would need to happen anyway. Of course, the CMS has to be built in a way to allow itself to be configured in such a way, which few (if any) are, unfortunately.

What's next?

Next part in the series is on CMS Extensibility. Yay!