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!
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
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
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.
Depending on the industry, you may find:
Majority of the customers use the Option-2.
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
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?
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
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!
> In other words, authoring content in prod, pushing to stage for UAT, and then taking any corrections into prod and pushing down to stage?
My 2 cents: PROD and Stage are 2 different types of environments, and their role differs mostly in these aspects:
(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.)
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.
@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!
Views
Likes
Replies