- Production environment - for the business practitioners
- Stage environment : performance and quality tests before changes to the application are pushed to the production
- Development environment - developers to implement AEM applications
- Demonstration environment : Training , demos, pocs etc - is simplified to a single author node, all others having min 2 author nodes
- AEM Cloud Sites Service
- AEM Cloud Assets Service
- Code repository (Git) 1
- Baseline image (Sites or Assets) 1
- Stage and production environment set (1:1) 0 or 1
- Non-production environments (development or demonstration) 0 to N
- Pipeline for each environment 0 or 1
**Note:* The author tier will contain all Sites and Assets functionality for all programs, but the Assets programs will not have a publish tier by default
Both author and publish tiers always accessed via a load balancer. But publish tier, a Continuous Delivery Network (CDN) is always available.
The method of author to publish replication has upgraded now. AEM as a Cloud Service Sling Content Distribution which allows one to distribute Sling resources between different Sling instances.{The API works at path level and the distribution agents basically enable distribution of specific paths between instances.}This uses a pipeline service run on Adobe I/O, which is external to AEM.
- Custom workflows that push content to replication agents of preview servers for example.
- Customization to replication agents to transform content
- Using Reverse Replication to bring content from publish back to author
Pattern
<service>.<environment_type>
Fr eg: author.dev or publish.prod
The supported runmode configurations in AEM as a cloud service are:
- config ( The default, applies to all AEM Services )
- config.author ( Applies to all AEM Author service )
- config.author.dev ( Applies to AEM Dev Author service )
- config.author.stage ( Applies to AEM Staging Author service )
- config.author.prod ( Applies to AEM Production Author service )
- config.publish ( Applies to AEM Publish service )
- config.publish.dev ( Applies to AEM Dev Publish service )
- config.publish.stage ( Applies to AEM Staging Publish service )
- config.publish.prod ( Applies to AEM Production Publish service )
- config.dev (*Applies to AEM Dev services)
- config.stage (*Applies to AEM Staging services)
- config.prod (*Applies to AEM Production services)
** OSGI configuration that has the most matching runmodes is used.
For local development:
The following artifacts are made available to the developers:
- The AEM as a Cloud Service QuickStart: a .jar based, standalone installer of the latest AEM code base, with the same functional and API surface.
- The AEM as a Cloud Service Dispatcher SDK: an image-based process for testing and validating Dispatcher configurations locally
[* The quickstart is a simple author environment where the majority of the extensions can be developed and tested - does not allow for all AEM Sites and AEM Assets functionalities]
- AEM as a Cloud Service - The cloud-native way of leveraging the AEM applications
- AEM Image - A deployable artifact that contains the AEM product code together with the customer code.
- Golden Master - The AEM publish tier.
- Orchestration Engine - AEM as a Cloud Service uses an orchestration engine to ensure that all author and publish services are scaling as and when needed.
- Asset microservices - Cloud-based digital asset processing services that cater to various asset processing use cases, such as rendition generation, PDF processions, subasset handling, text extraction etc.
Cloud Manager currently defines four roles for users which govern the availability of specific features:
- Business Owner - defining KPIs, approving production deployments
- Program Manager - team setup, review status
- Deployment Manager - execute stage/production deployments
- Developer - Develops and tests custom application code , do git operations
* There is a role 'Content Author' who does not interact with Cloud Manager. May use Cloud Manager Program Switcher (having navigated from Experience Cloud) to access AEM
> Planning
Access cloud service readiness - determine areas that will require refactoring to be compatible with AEM as a Cloud Service.(Source code Vs deprecated features, New path structure w.r.t AEM as cloud). Then estimate the plan.
Review resource planning - identify resources, create a team, and map out roles and responsibilities
Establish KPIs - Define KPIs to help your team focus on what matters the most.
> Execution
- onboad -familiarize & deploy the code to cloud service
- Integrate - the Git and deploy the code, content transfer, code refactor( Use tools where ever possible For eg: Asset Workflow Migration Tool, Dispatcher Converter, Modernization Tools. )
- Configure - user roles and other things on Admin console of cloud manager
> Post Go-Love
clean-up of temporary files,
review best practices for continuous development
manage logs
- Developer Console
- CRX/DE Lite
- Managing Logs
SDK is comprised of the following artifacts
- Quickstart Jar - The AEM runtime
- Java API Jar - all allowed Java APIs that can be used to develop against AEM as as Cloud Service(Previously known as Uber Jar)
- Javadoc Jar - The javadocs for the above JAR
- Dispatcher Tools - set of tools used to develop against Dispatcher locally
Below given customer owned the configuration
- Ad-hoc Task Purge
- Workflow Purge
- Project Purge
- /apps and /libs are considered immutable areas of AEM as they cannot be changed (create, update, delete) after AEM starts (i.e. at runtime). Any attempt to change an immutable area at runtime will fail.
- Everything else in the repository, /content , /conf , /var , /home , /etc , /oak:index , /system , /tmp , etc. are all mutable areas, meaning they can be changed at runtime.
- Oak indexes are mutable at run time
- * /oak:index configurations are part of the Code Package and not part of the Content Package