[UPHPU] deploying content with database-driven CMS
Wade Preston Shearer
wadeshearer.lists at me.com
Tue Feb 15 20:24:47 MST 2011
Consider a web-based content management system such as Drupal or Wordpress. A system like this allows you to edit content that is updated immediately (live) after you save it. Because you might want to preview your changes before they are live, systems like this allow you to save new content as drafts and preview content before it is published. This works alright for adding or editing single pieces of content but otherwise fails. It is impossible stage and test the rollout multiple changes or multiple pieces of content. It gets even uglier when the new release is a combination of content types (pages, content blocks, menus, etc), as you have to manually go through the site publishing and/or updating each individual item. The chances for you to miss something increase and the site is—for a minute at least—not complete.
I'd like to improve this. I have come up with a few ideas but each still doesn't feel adequate. I would like to hear any suggestions on how other systems overcome these challenges or ideas you have. The solution is easy for a file-based website, as a simple rsync will deploy a new release in seconds. This issue is unique to database-drive content.
One solution is for the CMS to be on a staging server instead of the production server. Changes are made and are tested in anticipation for deployment. The staging database and files are then completely copied to the production server. The benefits to this is that you can edit in confidence that it is not live, you can have a true test—navigating the changes in context with the rest of the site, and all of the changes (the entire site) are deployed at the same time with a single command. The downsides to this is that it's a lot of overhead for small changes.
Another solution would be to edit on the production server but provide a scheduling tool that would allow you to bundle changes that should be released simultaneously. Small changes (such as a text edit on a single page) could be published independently and immediately, but if you were updating an entire section of a website, you could save the changes as drafts, and then add each of the items to a scheduled "launch" to have their status flags flipped by a script together, at a designated time. This works alright for new content, but requires complete duplication of content that is changing—even if it's only a single letter. It seems like a big waste to have entire duplicate copies of content even if you're only changing a few little things. Navigation is the most significant example of this.
A third solution is a combination of the two. The CMS exists only on staging but publishing would copy only the change to the production server. You would have the ability to immediately publish individual changes or bundle content to be published simultaneously. This seems like the best solution, but is the most complicated.
More information about the UPHPU