• Internet
• 06.06.2018
• EN

oshyn Blog: Content Lifecycle vs. Code Lifecycle

One concept that begs for clarification when we implement Content Management Systems (CMS) is the difference between a company's Code Lifecycle and their Content Lifecycle.  I've seen many development organizations who are about to purchase a CMS--attempt to figure out how this new CMS will work in their existing application code development process.  Enterprises have robust and sophisticated ways of managing their Code Lifecycle.  They are tuned to their organization’s unique needs that are built on industry best practices refined over many years.  They use tools such as:  Version Control repositories, IDEs, Unit Testing, Bug Tracking tools, Release Configuration and Management  tools, more recently Continuous Integration concepts--have taken hold and are using Automated Code Quality tools like: checkstyle, pmd, cpd, cobertura.

Along with these tools, most likely procedures have been put in place to minimize risk and maximize change control success.  Things happen on off-hours, rollback procedures are identified and tested--hot backups are available.

This is the environment we are walking into with our NEW tool for managing content.

The Content Lifecycle looks much different.  Most tools follow a basic pattern:

• Content is thought out by business owners 
• It's added in via the tool 
• It is submitted by the author and goes through workflows of varying complexity 
• It's published or scheduled for publication at a particular date/time 

The trick for us (CMS Implementers) is to figure out a way to make these two co-exist. 

There are three places where we need to be aware of the interrelationships:

• Template development is sort of like code development
• Mixing dynamic code and content on the same page
• Getting your content and your code in the same spot, so when an end user requests a page, it all renders and works successfully

I'll take each one separately:
 

#1 - Templates

Every CMS will have a different idea of what a template is.  Some will be files on a file system.  Some will store it them in a database.  Some will be code that you are completely familiar with like XML, .NET or Java or Freemarker tags.  Some will have their own proprietary development language.  Some basic principles that must be applied to our template development are:

• They must be version controlled.  We need to be able to see versions of them so we can roll back to different versions 
• They must be "releasable".  We need to move them from environment to environment so we can continue to develop and enhance them 

 Ideally, we'd be able to create unit and regression tests for them and have tools that we can run to ensure code quality, but b/c they differ so greatly by vendor, standardization isn't really high on the vendor's priority list.  Typically though, if we are clever, we can find ways to do the above two minimum steps to make template development more stable and repeatable.
 

#2 - Fusing Dynamic Code and Content

We could spend a lot of time on strategies for doing this based on all the different CMS.  Each CMS will have a different "Best Practice" for doing this.  However, here are some principles for determining the right model to set up:

• Does it restrict or hinder the Code Lifecycle described above in any way?  These processes are put in place for a very good reason so we need to make sure they remain in tact for any real functional development we are doing 
• Even though the CMS vendor claims to "manage" code, the likelihood that they do it correctly or in line w/ the Code Lifecycle is very slim.  Your best bet is to rethink how you are managing your code even IF the vendor claims to manage it.  Issues with this are: 
  • This is just not their area of expertise.  They are experts in Content Lifecycle management.  I've NEVER seen a CMS that does the Code Lifecycle well.  The BEST we can hope for is that it plays nicely with existing Code Lifecycles and doesn't put an undue burden on developers.   
  • If they do try to manage it, they probably only manage HALF/PART of it:  i.e. they will manage Tags in the HTML or ASPX or JSP, but they won't manage Jars/DLLs/Dependant Libraries or resource files or any of the other artifacts we typically create during application development 
  • If your CMS manages code, your code promotion process is slightly messed up 
  • Putting this type of burden/change on your Code Lifecycle usually means you will be LESS likely to use/leverage managed content within your applications.  Developers and Project Managers will be less likely to think it is less work and less risk to use a CMS to manage content within their Applications. 
• Try to keep them as separate as possible.  Reducing dependencies is the best way to minimize intrusion on existing Code Lifecycles and maximize the use of the CMS's provided Content Lifecycle.  This means using clever ways to include dynamic code.  If your CMS let's you right JSP, make sure the JSP is minimal and just an entry point for functionality and quickly drop down into Java code.  You can templatize the "entry points" to make them more like presentation or template code while your deeper business logic is lower level in the page (this is a typical code development strategy anyway). 
• While it is tempting to use content workflow and content security and content version control for code, DON'T DO IT.  It's not built to do that and you'll eventually wish you were using standard code development tools 

#3 - Getting everything to the same destination

Again, you might be tempted to use the CMS's ability to publish to different servers as your mechanism for deploying your code, but DON'T DO IT.  The best advice I can provide is, if you do a good job of #1 and #2, the answer to #3 should become obvious.  If you don't, the answer to #3 will be convoluted.  You need to find some way to plug back in to the normal Code Lifecycle.

The biggest favor you can do yourself is to think of how you will achieve these things with your CMS implementation before you start development.  Prototype and test your solution to ensure that your theories work.  You can quickly code yourself into a hole where you are either stuck with a terrible Code development process or faced with redoing or moving large pieces of your application (yes, this is experience speaking).

Let me know your thoughts and strategies with different CMS!

Source: Content lifecycle vs. Code lifecycle

© copyright 2011 by oshyn