DevOps covers the processes, methods and communication required to:
- Ease the deployment of your software across the various environments.
- Simplify the collaboration between the development, testing and deployment teams.
DevOps aims to avoid problems such as:
- Manual errors.
- Forgotten elements; for example, files, configuration details.
- Discrepancies; for example, between a developer's local environment and other environments.
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:
- develop and customize the necessary elements; for example, templates, components, workflows, applications
- realize the design
- develop the necessary services and scripts to implement the required functionality
The configuration of the development environment can be dependent on various factors, though it is usually comprised of:
- An integrated development system with version control to provide an integrated code-base. This is used to merge and consolidate code from the individual development environments used by each developer.
- A personal environment for each developer; usually resident on their local machine. At apppropriate intervals the code is synchronized with the version control system
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:
- It is used to test the scripts used to implement the actual deployment.
- It can be used for final tests (design, functionality and interfaces) before deploying to the production environments.
- Although it is not always possible to have the staging environment identical to the production environment, it should be as close as possible to enable performance and load testing.
Code should always be propagated from bottom to top:
- code is initially developed on the local and then integrated development environments
- followed by thorough testing on the QA environment(s)
- then tested again on the staging environments
- only then should code be deployed to the production environments
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:
- Automatically: for transfer to the development and QA environments.
- Manually: deployments to the staging and production environments are done in a more controlled manner, often manual; though automation is possible if required.
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:
- Between the different environments - by exporting and importing packages.
- Between different instances - by directly replicating ( AEM replication ) the content (using a HTTP, or HTTPS, connection).