Topology Type naming to facilitate database restores back through environments

Question

I'm currently working on an upgrade from Tridion 2013 SP1 to SDL Web 8.5.

As part of the upgrade, we're implementing publishing using Topology Manager.

I'm in the process of defining the Topology Manager configuration. This includes details for Business Process Types, Target Types, Topologies, etc.

As well as ensuring that this works in each of the DTAP environments, I also want to make sure that future database restores back through environments are as straightforward as possible.

The client has a lot of published content. Therefore, in the past, we have backed-up and restored the Broker databases (which contain all of the content) as well as the Content Manager database and this has worked fine.

Similarly, in the new system, we'd like to avoid having to republish all of the content again following a database refresh as this could take days.

As with Tridion 2013 SP1, it appears that the details of which items are published where are stored in the PUBLISH_STATES table within the Content Manager database, with references to the items (Pages, etc.), along with the Target Type that they're published to.

However, it appears that in SDL Web 8, there is now a reference from the Target Type to the Publication's Business Process Type...

... which in turn references the Topology Type (which is defined within Topology Manager, rather than the Content Manager database).

Given that this reference to the Topology Type is stored within the Content Manager database and will come back as part of the database restore, my thinking is that keeping the name of the Topology Type (along with the Purposes) consistent across all environments will ensure that this publishing status is correct back in the earlier environments. Q1. Is this a correct assumption?

Also, Production, Acceptance and Test all have Staging and Live Purposes. However, Development only has Staging. Presumably, we can just run the normal database script (with permission from Support) to prevent items from showing as published to 'Live' in the Development environment. Q2. Is that still a valid approach in Web 8.5?

Q3. Is there anything further I need to consider?

---

Update (3rd July 2017): With regards to my third question (anything further to consider), it may be worth mentioning that I also need to consider the Publication to Web Application Mappings within Topology Manager, to double-check that these are still correct following the database restore. There are a small number of new Publications making their way through environments, so these will need to be recreated and their Mappings recreated. I will also need to delete the old mappings before doing the database restore.

Answer 1

A1. Indeed, to support porting/restoring the CM DB as a whole across DTAP environments, you should ensure that each environment has the same set of Topology Types (IDs) defined.

You don't need to have actual Topologies of all those Types in each environment (e.g. you may not have a Staging/Live Topology in Dev). In this case, you may want to switch the Business Process Type used in your Publications after porting.

For example, you only have a Staging env. in Development and Staging and Live in Production. It makes sense to use a "Development" (Staging only) BPT in Development and a "Staging/Live" BPT in Production.

After you ported your Production CM DB to Development, your Publications will be using the "Staging/Live" BPT. This should work in Development too, but publishing to "Live" will never resolve anything (because you don't have a "Live" environment in Development). You may want to switch your Publications on Development to the "Development" BPT, but that means you should have that BPT defined in Production too (unless you want to add the BPT each time after porting the CM DB).

A2. As Dominic mentioned, please use the decommissioning functionality in the public API instead of DB-level operations.