CM as a Publishing Target

I have a new client who has an existing Sitecore instance with three environments: DEV, UAT and PROD. The DEV environment has a publishing target of the UAT CM (not CD). And the UAT environment has a publishing target of the DEV CM (not CD). As a result, content can be overwritten (and has) in each environment at any time. Additionally, versions are wiped out in the target environment whenever items are published.

Can anyone think of a use-case where this setup would be a good idea. Or can anyone point me to a blog or documentation where anyone would recommend using this sort of set up. I am having a hard time convincing them this is bad practice without some backup. I can't find documentation because it seems obvious to me that no one would ever want this type of setup.

Please let me know if I'm wrong.

5 Replies

  • You are right, it is not a good idea to publish to a master database.
  • I have worked on asimilar instance, where the customer wanted to setup the publishing targets to different sitecore instance.

    In My case, we had the below setup
    PROD (CM) -> UAT (CM)
    UAT(CM) -> DEV (CM)

    This helped in migrating the content from PROD to testing environments to verify and reproduce (if any) the issues.

    Coming back to the issue of item overriding, the publishing targets can be restricted to a specific users ( e.g. sitecore developer or admin) who needs this kind of content migration with proper authority and backup.

    Hope this helps!!
  • In reply to Deepak Jena:

    Thanks Deepak for the comment. The problem we've run into is that content has been overwritten in one or more environments as content is moved from one environment to the next, up and down the chain. We've also lost all history of an item because publishing wipes out all previous versions of the item.

    In our case, we aren't just refreshing data from a higher environment to a lower environment. We are encouraged to enter production content into either environment and then publish from that environment up or down (DEV to UAT or UAT back to DEV). If human factors come into play, inevitably content updates made in DEV are overwritten by content updates in UAT and vice versa.

    The problem has been that both environments are considered valid areas to enter production content. And I cannot seem to convince them that there should be a single source of truth.
  • In reply to Lauren Hightower:

    You are absolutely correct Lauren, this sounds like a very valid problem scenario with a problematic solution.

    With most projects I've worked with, critical development pieces are source-controlled, ensuring that they can be deployed and replicated in any environment. These would include core templates, solution items, etc. that are not expected to be changed by authors.

    However, it seems like there is a problem in the workflow if content being built by authors needs to be published between different content management areas. It would be worth digging into why these items have to come 'down' and why they need to go 'up' between environments. There are many reasons why a 'single source of truth' is not possible, but until you start peeling back they "why" layers it will be hard to solve.

    Some common scenarios I know of where this type of workflow starts out:

    1. Developers are building pages, not just solution items, that will be part of final production usage. These need to flow upwards through Dev->UAT->PROD as part of delivery cycle.
    2. Developers and testers need to check production content against new upgrades/features before launching to production. This tends to require a flow downwards from PROD -> DEV (or PROD -> UAT)
    3. New templates or components have been built that are not in production, so the new pages that require these components need to be built in a lower-environment (where the component is) and migrated up. Sometimes this looks like UAT->PROD as authors work with the new functionality, try it out, and find issues. They tend not to want to rebuild the page again in production after the deploy, so they need to push their items.

    These are all valid workflows, but using publishing to solve it leads to problems (as you found out).
  • In reply to Sitecore St-Cyr:

    Thanks so much Jason. So much appreciate the thoughtful response.