Authoring in Stage vs Prod?

[NicholeVe]

Hi all, 

We are using AEM cloud version 6.5 and author in stage, publish and then package pages, assets and other elements individually, package all of these and push them to the AEM prod environment. 

I'm just curious, for others using cloud, do you author in stage? Directly in prod? Do you use packaging? I am trying to determine the most efficient path to taking advantage of cloud features vs freezing moments in time in stage for experimentation. 

Thanks in advance!

[EstebanBustamante]

Hi, 

Here are my two cents: Although your Stage environment should ideally be a copy of Prod, this isn't always the case. Therefore, authoring directly in Stage is not always recommended. However, there are certain conditions where this approach can be viable.

In general, it's not considered good practice to promote content from lower environments to Production due to the potential for human errors. For those on AMS, interaction with the Package Manager in Production is typically not allowed unless explicitly approved by Adobe through an exception process. Similarly, AEMaaCS lacks a clear method to move content from lower environments to Production, suggesting that the preferred approach is to author in Production and then propagate content downwards.

Regarding content freeze scenarios, in my opinion, these should not occur frequently. If they do, it may be necessary to revisit the timing of these freezes within your deployment and development cycle. Another strategy to mitigate content freezes is to limit them to specific paths, hence you can create content outside the content freeze area. Lastly, consider using Launches, which can be helpful in such scenarios as well.

Hope this helps.

[aanchal-sikka]

@NicholeVe 

Depending on the industry, you may find:

1. Content created in Stage and promoted to Production
2. Content created on Production and Stage used for UAT.

Majority of the customers use the Option-2.

• This allows Dev activities to continue in Dev, while Stage is used for UAT/Trainings etc.
• This is also a recommended set up from Adobe, until you need Option-1 for specific reasons.
• You might no longer need Content Freeze windows.

[Hemalatha · Accepted solution]

Hi @NicholeVe,

You can freeze your code changes till stage and move it as either package deployment / pipeline deployment to Production as per your practice. While when dealing with content, it is best to have the content authored in Prod, reviewed by an approver in Prod author Preview and then the changes getting published to Live Pages. You should set up a process guideline to author content in prod with necessary restrictions, workflow and moving that content down the line to keep things synced across environments.

You can always sysnc Stage in line with Prod content so that it is easy to replicate prodcution issues easily.  Hope this helps.

Regards,

Hemalatha C

[NicholeVe]

Thank you, Hemalatha! This is what I'm thinking to propose at my organization (author and review in prod then publish live.) One follow up question- what do people use stage environment for (if at all) in those cases?

[Hemalatha]

Hi @NicholeVe ,

Typical use cases for Stage environment,

- A Production like environment which needs to be in sync with prodcution all the time to debug, replicate and fix any P1 issues in live environment

- Stage can be used as an environment for User Acceptance Testing by Business Users before rolling out any new features to Prod to get feedbacks & Optimize further

- Stage can be used by content authors to test any new features, preview changes before they move to actual Production site if needed

- In general Stage should be as same Hardware specification as prod to conduct load testing for the Site performance optimization

Hope this helps.

Regards,

Hema

[NicholeVe]

Thank you Hema! Last clarifying question:

"Stage can be used by content authors to test any new features, preview changes before they move to actual Production site if needed"

Is there any downside to following this logic but authoring in prod first? In other words, authoring content in prod, pushing to stage for UAT, and then taking any corrections into prod and pushing down to stage?

Currently we author in stage, UAT in stage and then push to prod but it sounds like we could simply author in prod and that may help with currency of content and not having to package things to get them from stage to prod.

Thanks for all of your help!

[Jörg_Hoh]

> In other words, authoring content in prod, pushing to stage for UAT, and then taking any corrections into prod and pushing down to stage?

[Jörg_Hoh]

My 2 cents: PROD and Stage are 2 different types of environments, and their role differs mostly in these aspects:

• A PROD environment  usually has a much higher SLA and you have monitoring and active alerting & incident handling for it. That's different from stage. When your content creation process uses the Stage env as an integral part of it, you need the same amount of SLA and monitoring for it. That means from an operational point of view your Stage env should be considered as an additional PROD environment. It's critical for content creation & maintenance.
• The roles of Stage and PROD typically relates to code lifecycle; you do your final validation and testing on a Stage environment, before you deploy it to PROD. If both environments are critical to your content production, you cannot use Stage for that final release validation role anymore, you need to do this on a different environment.
• The content livecycle is different, and should not be required to validate it the same way as you need to validate code; it's easier to change, and it should be straight forward to change content without the need to do another deployment.

(In the context of AEM as a Cloud Service you are encouraged not to use your Stage environment as an integral part of the content creation process; IIRC for Stage there is no SLA, and also the alerting standards are much different on Stage than on PROD environments.)

[vishnuunnikrishnan]

The practice utilized in our projects involves using Production environment for content population activities. If the case of Multi-language site, the translation process is also carried out in production environment. 

Staging environment serves as a replica of prod (often without the full actual content) and is maintained for UAT and functional testing, while the content validation is conducted on the prod environment.

[kautuk_sahni]

@NicholeVe Did you find the suggestions from users helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!