Juggling content from environment to environment is quite frankly a pain in the butt. PROD back to QA, QA back to DEV, DEV back to my personal CQ instance. The need to be concerned with overwriting content along the way. QA people will have their environment setup for regression testing, new testing, etc. Developers will have their tests and POC's setup on their own environments and DEV. You sometimes need to move content from QA to your local to test something that's broken on QA.

Sound like a big hairy mess? Well, lemme give you the clippers.

What I have done is create each environment with their own "sites". DEV will have a site: /content/DEV. QA will have a site: /content/QA, and may very well have sub-sites: UAT, REGRESSION, etc... capitalization optional of course. Within DEV each developer will have their own branch beneath that: FrankZappa, EdgarVarese, JohnCage, ElizabethFraser, you get the skinny.

I would suggest that content can be promoted backwards but never forward.  Think about the implications of that.  Each content is the master oif its own domain.  I have no business modifying content in the QA branch locally, and then installing it back onto QA.

This way I can get content from anywhere, and not have to worry too much about overwriting content I have been building up locally.  This may require that I use multiple packages to move the DEV content back to my local to ensure that I dont overwrite my own MJK "site".  But the structure outlined above will facilitate and enable easy moving of content with a much smaller amount of worries.

The next thing I have done to further make my content life more manageable is to automate the demotion of content from QA and DEV back to my local.  Using the CLI interface I have written a shell script that handles moving predefined packages from the corresponding environment back to my personal CQ instance.  I could use some replication agent black magic, but I don't want the Exceptions polluting the logs when the respective servers can't connect to my CQ instance.

The next thing I have planned, is to remove the need for prebuilt packages altogether and do the following:

  • on the fly create a new package with the appropriate content paths
  • build the package
  • download the package
  • delete the package from the CQ instance
  • upload the package to my CQ instance
  • install the package on my CQ instance
  • optionally delete the package from my CQ instance

This way the packages I use for my convenience are not polluting the package space on the respective servers.

Hope this helps you keep your content demotions from getting out of hand.