There’s a new type of environment known as a Rapid Development Environment (RDE) with Adobe’s Cloud Service. This environment was specifically made with developers in mind to accelerate code deployments and other development activities in Cloud Service. We’ve had a chance to use the RDE to better understand its capabilities, strengths, and gaps.
Pipelines in an AEMaaCS program are often executing and busy during high development activity, which is one of the main reasons for using an RDE. If a developer isn’t using an RDE and needs to validate that their code will work in Cloud Service, they may experience delays waiting on the traditional pipelines.
With an RDE, the developer can deploy within minutes or less, greatly accelerating the development workflow. Compare this scenario to the traditional CI/CD pipeline which can take hours or longer due to additional code security and quality checks.
Where the RDE Resides in a Program and the Deployment Lifecycle
The RDE is generally available as an environment on a per-program basis. Depending on the size of the team and anticipated activity within a program, additional RDEs can also be provisioned, however, this may come at an additional licensing cost from Adobe.
Creating an Rapid Development Environment
The RDE can be provisioned with a Program via Cloud Manager in AEM as a Cloud Service. In the Environments view, select “Add Environment” and then choose the RDE from the environment type. Provide a name and the region for where the RDE is to be provisioned.
Once the RDE creation is completed, it’s available as a blank-slate environment. Note that the RDE will have an author and publish environment segment. This is different from a standard environment, which also includes a preview environment.
Deploying to RDEs
The RDE can be deployed via automation in tools like Jenkins or from a developer’s local workstation using Adobe’s command-line interface.
The command-line interface is one of the easiest ways to deploy content to the RDE, also known as Adobe I/O Runtime Extensible CLI (or aio CLI for short.) In this simple example, a content package is deployed with the aio aem:rde:install command.
Similar commands can be executed for deploying content files, dispatcher configurations, OSGi configurations, and bundles.
Note: Follow the instructions provided by Adobe on this page to configure your environment for deploying to the RDE(s).
There are many commands available to use with the RDE including login, installation, deletion of bundles and packages, status, and even resetting or restarting the RDE. Detailed instructions on the commands can be found on the Adobe GitHub page.
If you’re planning to deploy to the RDE from an internal build mechanism such as Jenkins, then there are a few additional considerations to account for. Jenkins does not support the use of aio CLI. This means an environment will need to be created such as an AWS EC2 instance so that aio CLI can be installed and used.
Resetting an RDE
There will be times, particularly when the purpose of an RDE changes, that it may need to be reset. Resetting an RDE simply means bringing the environment back to a state of no content or code installed. This is essentially the same as recreating the RDE, which may also be an option. As mentioned earlier, the RDE can be reset as well using the aio CLI command. For more options and details on resetting the RDE for your program, review Adobe’s documentation on Experience League on this page.
Multiple Developer Scenarios
As with any development team, there will be a need for developers to collaborate on their development activities in a shared environment. As such, the need for each developer to have the RDE as a deployment target will come about. But if only one RDE is allowed or in use, then the development team will need to coordinate their code changes so that the features being worked on don’t interfere or overwrite each other. The recommended approach here is to commit code changes to a shared git branch before deploying to the RDE. This ensures that developers on the team will have the appropriate changes done by other developers.
Appropriate Use Cases
The RDE is certainly a nice addition to a program in AEM as a Cloud Service. We love that it allows for quick deployments to a cloud-based environment for quick validation and accelerating the developer workflow. That said, it makes sense to focus on feature development that is intended to work on Cloud Service environments. Things that can be easily developed like templates, components, workflows, sling models, or other functionality are better suited for the developer’s local environment.
Here are four considerations before moving forward with using the RDE.
- Not all Forms development features are available in the RDE, such as configuring the Document of Record (DoR) for an Adaptive Form.
- The RDE lacks a preview environment, unlike other environments in a Program.
- Each developer does not automatically have an RDE provisioned and, depending on the team size, additional RDEs would need to be licensed and purchased from Adobe.
- There are other various pieces of functionality that may not work as other Cloud Environments, such as support for viewing and debugging front-end code deployed via a CM Front-End Pipeline. See the Adobe documentation page that describes some of these differences between the RDE and other environments.
Wrap-Up and Further Reading
Rapid Development Environments provided for AEM as a Cloud Service programs are a great addition to the suite of tools available to improve the development workflow. One of our favorite features is the ability to deploy dispatcher configurations. This can save a lot of time for developers. Particularly, when the configured pipelines for other environments are more rigid and don’t allow for quick deployments to test out Apache functionality.
Check out more of our AEM as a Cloud Service development and deployment-related blogs for more help making informed decisions for your own implementations.
Thank you for reading!
