DevOps covers the processes, methods and communication required to:
DevOps aims to avoid problems such as:
An Adobe Experience Manager (AEM) deployment usually consists of multiple environments, used for different purposes on different levels:
The production environment must have at least one author and one publish environment.
It is recommended that all other environments also consist of an author and publish environment to reflect the production environment and enable early testing.
The developers are responsible for developing and customizing the proposed project (be it website, mobile applications, DAM implementation, etc), with all the required functionality. They:
The configuration of the development environment can be dependent on various factors, though it is usually comprised of:
Depending on the scale of your system, the development environment can have both author and publish instances.
This environment is used by the quality assurance team to comprehensively test your new system; both design and function. It should have both author and publish environments, with suitable content, and provide all necessary services to enable a complete suite of tests.
The staging environment should be a mirror of the production environment - configuration, code and content:
The production environment consists of the environments needed to actually author and publish your implementation.
A production environment consists of at least one author instance and one publish instance:
Depending on the scale of the project, it often consists of several author and/or publish instances. At a lower level, the repository may be clustered to several instances as well.
Author instances are usually located behind the internal firewall. This is the environment where you, and your colleagues, will perform authoring tasks, such as:
Content that was activated is packaged and placed in the author environment’s replication queue. The replication process then transports that content to the publish environment.
In order to reverse-replicate data generated in a publish environment back to the author environment, a replication listener in the author environment will poll the publish environment and retrieve such content from the publish environment’s reverse-replication outbox.
A publish environment is usually located in the Demilitarized Zone (DMZ). This is the environment where visitors will access your content (for example, via a website or in the form of a mobile application) and interact with it; be it public, or within your intranet. A publish environment:
The publish environment generates your content dynamically in real-time and the content can be personalized for each individual user.
Code should always be propagated from bottom to top:
The code (e.g. customized web application functionality and design templates) is usually transferred by exporting and importing packages between the different content repositories. Where meaningful, this replication can be configured as an automatic process.
AEM projects often trigger code deployment:
Content being created for production should always be authored on the production author instance.
Content should not follow code moving from lower environments to higher ones, as having authors create content on local machines or lower environments and then moving it to the production environment is not a good practice and likely to introduce errors and inconsistencies.
Production content should be moved from the production environment to the staging environment to ensure that the staging environment provides an efficient and accurate testing environment.
This does not mean that staging content needs to be continually synchronized with production, regular updates are sufficient, but especially before testing a new iteration of code. Content on the QA and development environments does not need to be updated as frequently, it should just be a good representation of the production content.
Content can transferred: