Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

Replicate content from non-prod publish to prod - author

Avatar

Level 3

What could be the issues in replicating content from non prod publish to prod author directly? We have a scenario where client want to set up some approval workflow where all approval happens in non prod but post approval content is directly moved to prod author. Hence wanted to understand is there an issue doing so?

1 Accepted Solution

Avatar

Correct answer by
Level 3

What i could figure out is that Automating the content WF from lower env to prod is not a recommended option because of below issue that can potentially happen.

    1. Content being over written in PROD due to multiple authors working at the same time which also makes it difficult to revert to original content in case of error.
    2. Difficult to handle a scenario where 2 author worked on different content type where go live dates needs to be managed separately. In such scenario automated publishing to prod will make it difficult to manage such governance in content Go Live.
    3. Un-required / Incorrect content being pushed to prod.

 

Happy to hear other POVs.

 

Thanks

Anika

View solution in original post

6 Replies

Avatar

Community Advisor

There won't be an issue. Have all your content ready and approved in a non-prod environment say "stage".
once approved by the client, take a content package with proper filters and install it in prod author.

please maintain versions of your package so as to revert if wanted.

 

Avatar

Level 3

Thanks but what i mean is automate the content movement instead of manual package installation..

Avatar

Correct answer by
Level 3

What i could figure out is that Automating the content WF from lower env to prod is not a recommended option because of below issue that can potentially happen.

    1. Content being over written in PROD due to multiple authors working at the same time which also makes it difficult to revert to original content in case of error.
    2. Difficult to handle a scenario where 2 author worked on different content type where go live dates needs to be managed separately. In such scenario automated publishing to prod will make it difficult to manage such governance in content Go Live.
    3. Un-required / Incorrect content being pushed to prod.

 

Happy to hear other POVs.

 

Thanks

Anika

Avatar

Employee Advisor

This is violating AEM best practices.

 

  1. What's the role of the PROD authors in your setup? PROD authoring environments are the area where the approval will happen. 
  2. In your setup the Stage environment is a shadow PROD environment. Because if stage is not there, you cannot activate content to PROD. Also think of things like audit data etc which you have to preserve on PROD.
  3. The code on Stage/Shadow PROD and PROD must be consistent and compatible.

 

Don't do that!

 

 

Avatar

Level 3

Yeah i agree with you its against AEM best practice but client is pushing to have this feature else questioning the capability of AEM as a product because such feature is available in team site.

So customer do not want to use Prod author for authoring at all. Hence using iso-prod env to author content and post approval want to push content to prod author. We are trying replication agent route where post approval from workflow itself, we are sending that specific content to a separate replication agent which will just replicate the content to prod author from iso-prod author.

Since that new replication agent is bound to a user same "replication_prod-user" and we have disabled it to be used by default, so that other content doesn't use that replication agent. Do you still see this to be an issue?

 

Thanks

Anika

Avatar

Employee Advisor

I don't think that it's a good approach to violate best practices and recommendations of a product just to "ease" the migration. I fear that you never get rid of these workarounds and this will cause more pain on the long run. If the customer is questioning AEM for this decision, I think it is the task of the development team leads to explain it to the customer. If this is not possible I would recommend to get in touch with Adobe to get support in this discussion.

 

From a development point of view your approach is not a real problem, and most likely it will work quite flawlessly. It just causes major pain in the operation. And prepare for questions when you raise support cases where this aspect is uncovered.