Content Update Deployment Strategy

[liam_rigby]

Hi, have a basic question about deployment of content changes to a publicly accessible website that I'm struggling to find an answer to.

Our use case is as follows:

1. Content change request sent to digital team.
2. Digital make the changes requested on a preproduction environment (perhaps production author instance), includes text/media/document/navigation changes
3. Changes are accessible to wider business via intranet only for testing and approval (target should be website that appears identical to production website, e.g. staging.companyname.com)
4. Digital activates any changed pages to production publish instance
5. Changes are accessible to general public

This seems like a fairly standard content deployment setup. Can someone please confirm if/how this is done within AEM?

Thanks.

[smacdonald2008]

This looks like a good use case to solve using AEM workfliws. I will post back with more details tomorrow. Off hand, you want to look at using content approval workflow and once approced, a publish workflow. 

[Opkar_Gill]

Hi Liam,

the general recommendation is to do all your previewing on the author instance in "preview mode". If anyone wishes to just view the page for reviewing they could be given read access.

However, all changes from all authors will be seen in this use case, you wouldn't see specific changes in isolation. If you did wish to see just specific changes, without other authors changes being reflected in the site/section you wish to preview, you could consider launches[0].

In standard preview mode and with launches, you are always previewing in the author instance. I have come across clients where they wish to see the changes as they would appear in the production publish instance, they felt the preview mode was not a true reflection or there were integrations only available in the publish instance or there were different permissions/security aspects that needed to be tested, that could only be tested on a publish instance.

Whatever the reason, in this case, you could (given you have an extra licence) create a another prod publish instance, as a preview publish instance. With this "preview" publish instance you could have two approaches:

1. Create a new UI action to publish to a preview server, when the page has been reviewed and approved on the preview server, the author uses the publish to prod action, to push it live.

2. Create a workflow that replicates the page to the preview server when you have finished authoring, after reviewing the change on the publish server, the user would come back and complete the workflow step, the next step being replicate to the live production publish instance. If the user rejected the change, the workflow would complete without replicating the page, with perhaps an email notification sent to the authoring group.

The preview server option is obviously a lot more complex as you require an extra instance and need to setup the actions to the send the content to the preview server. Only the business can decide if the extra cost and complexity is worth the effort or, if using preview mode or launches is enough.

Regards,

Opkar

[0]https://docs.adobe.com/docs/en/aem/6-2/author/site-page-features/launches.html

[liam_rigby]

Hi Opkar,

Thanks for the reply.

To expand on our setup, we have two separate instances of AEM. One as a UAT type instance where changes published are accessible via a domain separate from our main website. Ideally I'd like changes on the UAT instance, once tested, to be able to automatically publish to the prod publish instance. Currently this can only be done manually, and as a result the UAT instance is rarely used. Is this the scenario you are talking about with regards to the extra license in your post?

Thanks for the help.

[Opkar_Gill]

Hi Liam,

in both of my scenarios, the content is sent from primary author to preview author, and this is one way. Then if the content is visually approved on the preview author instance, the author logs onto the primary author, from where content is sent to the publish instance. 

In the scenario you are describing the flow seems to be primary author -> preview author -> prod publish which is not a recommended approach.

Regards,

Opkar

[liam_rigby]

Hi Opkar,

Apologies if I'm getting slightly lost in the terminology.

The workflow I'm after would be UAT author -> UAT publish -> Prod author -> Prod publish

Where changes made in UAT publish can be automatically pushed to prod author and scheduled for prod deployment.

In this case, we would have UAT and Prod setup to be identical from a content perspective, but publish to a different domain.

[Jitendra_S_Toma]

Hi Liam,

If I understood whole discussion correctly. Opkar has suggested the same thing only difference is that you want to push content to prod author via UAT publish and Opkar is suggesting that do the same from UAT author via workflow. And the reason is that when some changes are done at UAT Publish, it means changes were done on UAT author too. So why can't push content to prod author from UAT author to prod author rather than from UAT publish.

I also see the one case where it would not be wrong if you could push content from UAT Author to Prod author and then scheduled to Prod deployment. because you want to make sure content which is approved & signoff from UAT publish should be propagated to prod author. And I think this is also a valid use case but this can be handled if we use approval process in the workflow. No one can push content directly without signed off.

A few follow-up question before suggesting any approach.

1. Does content editor team never make any changes on prod author directly and every content on UAT would be same as Prod author?
2. What if page content modified on prod author & UAT publish, which would be the final content? Would you allow content to be overwritten in prod author?

--Jitendra

[Opkar_Gill]

Liam Rigby wrote...

Hi Opkar,

Apologies if I'm getting slightly lost in the terminology.

The workflow I'm after would be UAT author -> UAT publish -> Prod author -> Prod publish

Where changes made in UAT publish can be automatically pushed to prod author and scheduled for prod deployment.

In this case, we would have UAT and Prod setup to be identical from a content perspective, but publish to a different domain.

Hi Liam,

the only way of working tested is using a single environment for creating, previewing and publishing content. It is not recommended to use two environments in the way you describe. As Jitendra pointed out there will be a lot of issues with this approach and I am not aware of any customers using your proposed approach.

Regards,

Opkar

[liam_rigby]

Hi Jitendra,

UAT Author -> Prod Author is a valid use case for what I am describing (though per Opkar's responses sounds like it might not be the recommended approach).

Essentially we have a dedicated team that makes all of the content changes but due to stringent legal requirements on the content we publish we need to be certain that it is accurate. Giving staff read access to AEM is an option but given the number and the training that would be required this isn't ideal for us at this stage. As we already have a UAT environment setup that publishes to a preproduction domain I was hoping it could be used for exactly that, with a job that would automate any of the content we changed on UAT to the prod instance, after approval and performance testing on the preproduction domain (though it sounds like the above can be achieved with an additional publish server per Opkar's initial response that I misinterpreted).

If using UAT in this way is not the recommended approach, what is the use case for it? We currently use it as a bit of a playground, hence I was hoping to repurpose it as above if it was a valid approach (doesn't appear to be that way).

Appreciate the help on these queries.

[Jörg_Hoh · Accepted solution]

Hi,

I see the whole process you want to take very dangerous. If you perform your changes on UAT and get all the approvals there, then you must be 110% sure that you move all your changes and only *your* changes to PROD to activate it there. AEM is not built in such a way and the standard content "development" process used by most of the projects is not using this approach as well.

Instead you should take Opkars approach and and create a "preview publish" and run all approval processes through a single workflow using workflow packages. Then you can be sure that all changes on preview publish get on live publish as well. There is some work to do, but it's not that hard to from a coding/architecture point of view, and the efforts are overseeable.

Of course the easiest approach would be to avoid the preview publish completely and use the preview functionality only.  And I recommend to everybody to stay with this wherever possible (and to be honest, this approach is ok for many businesses, if you give them a 30 minute how-to video plus the proper links where they get directly into the preview mode on the right page).

Jörg

[liam_rigby]

Makes sense.

Thanks for the help guys.