4

In Web 8 we have the new Topology Manager and have a Live and Staging Topology with a Live purpose and Staging purpose. We'd like to be able to keep the state of where items are published after the DB restore from Production to Dev.

When restoring the Production DB into Dev DB, is it possible to use Topology Manager and change the Topology to point to the Dev environment? And, do we still know where the items are published? Would we need to use 1 TopologyManager database for all environments?

If we have a 'Dev' name in Dev and 'Staging' and 'Live' in Production, how would we handle this after the DB refresh?

Also, we have template code that uses the Publication Target name, and this might be a challenge in the usage of Live and Staging?

Improve this question
2
  • Just to clarify, Robert: Are you saying that you want the publish state that you currently have in dev to remain after the db restore? So the publish state would reflect the currently published assets in Dev?
    – Dominic Cronin
    Aug 10, 2016 at 7:47
  • Yes, I would want the publish state of items in Dev to remain after I restored the Production DB.
    – robrtc
    Aug 11, 2016 at 7:38

2 Answers 2

Reset to default
6

Note that publish state is not stored in Topology Manager, but in Content Manager. So, publish state is automatically copied if you restore the CM DB across environments.

As Bart mentions, this can be considered "cheating", though, because it's likely that the publish state won't reflect reality after such an action.

You should not use Topology Manager across environments; the idea is that the information stored in Topology Manager is environment-specific so should not be shared; having this infrastructure-related info in TTM is actually supposed to facilitate cross-environment CM DB ports.

The 'Dev', 'Staging' and 'Live' you mention sound like Target Type Purposes (of two Business Process Types). You can have these two BPTs in your CM DB. In Production, you will use 'Staging/Live' and in Dev you will switch to 'Dev' (switching BPT will be an explicit action after the CM DB restore).

Improve this answer
1
  • Thanks Rick. I was hoping that the publish state was connected with items being published to a CD Environment from the TopologyManager, and this environment is unique across all my infrastructure, and therefore I would have one source to know where everything has ever been published to. I now understand the functionality is the same as previous versions and I would need to run a post-restore script to set the 'published to' correctly, or re-publish all items to the Dev system.
    – robrtc
    Aug 11, 2016 at 7:40
4

Isn't it a bit strange to want to keep the publishing status when restoring items from one environment to another, where the actual publish status can certainly be different? Items published to a target on Production, will not be published on Development.

This is also why the Topology Manager is maintained in a different database, so that your topologies are not moved over when you sync the CM database through a backup/restore on your DTAP.

It sounds a bit to me that you are trying to be lazy, when you need a valid publishing status on Dev, after restoring a production database, you should simply publish all those items to your targets on Dev. Using the same Topology Manager database for both environments sounds a bit risky, possibly allowing you to publish to Production from your Dev environment.

Improve this answer
2
  • Sorry Bart, I think you misunderstood my question. I was hoping / thinking that publish state was connected with TopologyManager items, and this might be able to be 'restored' next to my CM DB. In the past I have re-published items to the targets, but it is much less ideal because it places more load on the publisher and in large environments takes hours or days to do a full re-publish.
    – robrtc
    Aug 11, 2016 at 7:42
  • @robrtc publish state belongs to an item, so is part of the CM database, and connected to TTM via the target. But when you restore a database from production to dev, you have a different topology and different targets, thus your items will not have a valid publish status anymore. I understand your way of thinking, assuming the URI of the item which was there on dev, is the same as it was on production, but the simple fact is, an item could have been updated on prodyction, and thus its publish state is not valid on dev, since those are different targets.
    – Bart Koopman
    Aug 11, 2016 at 7:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.