DocumentationAEM as a Cloud ServiceUser Guide

Rapid Development Environments rapid-development-environments

Last update: Mon Jan 22 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

To deploy changes, current Cloud Development environments require the use of a process that employs extensive code security and quality rules called a CI/CD pipeline. For situations where quick and iterative changes are needed, Adobe has introduced Rapid Development Environments (RDEs for short).

RDEs allow developers to swiftly deploy and review changes, minimizing the amount of time needed to test features that are proven to work on a local development environment.

Once the changes have been tested in an RDE, they can be deployed to a regular Cloud Development environment through the Cloud Manager pipeline.

https://video.tv.adobe.com/v/3415582/?quality=12&learn=on

You can see additional videos demonstrating how to set it up, how to use it, and the development life cycle using RDE.

Introduction introduction

RDEs can be used for code, content, and Apache or Dispatcher configurations. Unlike regular Cloud Development environments, developers can use local command-line tools to sync code built locally to an RDE.

Every program is provisioned with an RDE. If there are Sandbox accounts, they are hibernated after a few hours of non-use.

Upon creation, RDEs are set to the most recently available Adobe Experience Manager (AEM) version. An RDE reset, which can be performed using Cloud Manager, cycles the RDE and set it to the most recently available AEM version.

Typically, an RDE would be used by a single developer at a given time, for testing and debugging a specific feature. When the development session is done, the RDE can be reset into a default state for the next usage.

Additional RDEs may be licensed for Production (non-sandbox) programs.

Enabling RDE in a Program enabling-rde-in-a-program

Follow these steps so you can use Cloud Manager to create an RDE for your program.

  1. Log into Cloud Manager at my.cloudmanager.adobe.com and select the appropriate organization.

  2. Click the program to which you want to add an RDE to show its details.

  3. From the Program Overview page, click Add Environment on the Environments card to add an environment.

    Environments card

    • The Add Environment option is also available on the Environments tab.

      Environments tab

    • The Add Environment option may be disabled due to lack of permissions or depending on the licensed resources.

  4. In the Add environment dialog that appears:

    • Select Rapid Development under the Select environment type heading.
      • The number of available/used environments is displayed in parentheses behind the environment type.
    • Provide a Name for the environment.
    • Provide an optional Description for the environment.
    • Select a Cloud Region.

    Add environment dialog

  5. Click Save to add the specified environment.

The Overview screen now displays your new environment in the Environments card.

Upon creation, RDEs are set to the most recently available AEM version. An RDE reset, which can also be performed using Cloud Manager, cycles the RDE and set it to the most recently available AEM version.

For more information about using Cloud Manager to create environments, manage who has access to them, and assign custom domains, see the Cloud Manager documentation.

Installing the RDE Command-Line Tools installing-the-rde-command-line-tools

After you have added an RDE for your program using Cloud Manager, you can interact with it by setting up the command-line tools as described in the following steps:

IMPORTANT
Make sure you have the latest version of Node and NPM installed for Adobe I/O CLI and related plugins to work properly.

  1. Install the Adobe I/O CLI tools according by following the procedure here.

  2. Install the Adobe I/O CLI tools cloud manager plugin, and configure them as described here.

  3. Install the Adobe I/O CLI tools AEM RDE plugin by running these commands:

    code language-none 
    aio plugins:install @adobe/aio-cli-plugin-aem-rde
aio plugins:update

  4. Configure the cloud manager plugin for your organization ID:

    aio config:set cloudmanager_orgid 4E03EQC05D34GL1A0B49421C@AdobeOrg

    and replace the alphanumeric string with your own organization ID, which can be looked up using the strategy here.

  5. Next, configure your program id:

    aio config:set cloudmanager_programid 12345

  6. Then, configure the environment id the RDE is going to be attached to:

    aio config:set cloudmanager_environmentid 123456

  7. After you are done configuring the plugin, login by performing

    aio login

    The response on a successful login should resemble the output below, but you can ignore the values that are displayed.

    code language-none 
    ...
You are currently in:
1. Org: <no org selected>
2. Project: <no project selected>
3. Workspace: <no workspace selected>

    This step requires you to be a member of the Cloud Manager Developer - Cloud Service Product Profile. See this page for more details.

    Alternatively, you can confirm that you have this developer role if you can log in to the developer console by running this command:

    aio cloudmanager:environment:open-developer-console

    note tip
    TIP
    If you see the Warning: cloudmanager:list-programs is not a aio command. error, you must install the aio-cli-plugin-cloudmanager by running the command below:
    code language-none 
    aio plugins:install @adobe/aio-cli-plugin-cloudmanager

  8. Verify that the login was completed successfully by running

    aio cloudmanager:list-programs

    This should list all programs under your configured organization.

For more information and demonstration, watch the video tutorial how to set up an RDE (06:24).

Using RDE while Developing a New Feature using-rde-while-developing-a-new-feature

Adobe recommends the following workflow for developing a new feature:

  • When an intermediate milestone is reached and successfully validated locally with the AEM as a Cloud Service SDK, commit the code to a git feature branch. The branch should not be part of the main line yet, although committing to git is optional. What constitutes an “intermediate milestone” varies based on team habits. Examples include a few new lines of code, half a day of work, or completing a subfeature.

  • Reset the RDE if it has been used by another feature and you want to reset it to a default state. Reset takes a few minutes and all existing content and code is deleted. You can use the RDE status command to confirm the RDE is ready. The RDE comes back up with the most recent AEM release version.

    note important
    IMPORTANT
    If your staging and production environments are not receiving automatic AEM release updates and are behind the most recent AEM release version, the code running on the RDE may not match how the code functions on staging and production. In that case, it is especially important to perform thorough testing of the code on staging before deploying it to production.

  • Using the RDE command-line interface, sync local code to the RDE. Options include installing a content package, a specific bundle, an OSGI configuration file, a content file, and a zip file of an Apache/Dispatcher configuration. Referencing a remote content package is also possible. See RDE Command-Line Tools for more information. You can use the status command to validate that the deployment was successful. Optionally, use Package Manager to install content packages.

  • Test the code in the RDE. Author and Publish URLs are available in Cloud Manager.

  • If the code does not behave as expected, use standard debugging techniques to understand the problem and make the appropriate changes. Without committing the code modifications to git (since they haven’t been validated), use the local CLI to sync the code to the RDE. Keep iterating until the issue is resolved.

  • Once the code behaves as expected, commit the code to the git feature branch.

  • Code synced to RDE does not use a Cloud Manager pipeline so now you should use a Cloud Manager non-production pipeline to deploy the git feature branch to the Cloud Development environment. This validates that the code passes the Cloud Manager quality gates and lets you be confident the code is later successfully deployed using the Cloud Manager production pipeline.

  • Repeat the steps above for each intermediate milestone until all code for the feature is ready, and runs well on both the RDE and the Cloud Development environment.

  • Deploy the code to production by way of the Cloud Manager production pipeline.

Using RDE to Debug an Existing Feature use-rde-to-debug-an-existing-feature

The workflow is similar to developing a new feature. The difference is that the code being synced to RDE would reflect the git label of whatever was pushed to the environment where the issue has been found. In addition, it may be useful to deploy content matching the upstream environment. This can be achieved through exporting and importing of content packages.

Multiple Developers Collaborating on the Same RDE multiple-developers-collaborating-on-the-same-rde

An RDE supports a single project at a time. Since code is synced from a local development environment to the RDE environment, it is most natural for one developer to be using it on their own at a given time.

However, with careful coordination, it is possible for more than one developer to validate a specific feature or debug a specific issue. The key is that each developer keeps their local projects in sync so code changes made by a particular developer are absorbed by the other developers, otherwise one developer might inadvertently overwrite the other’s code. The recommended strategy is for each developer to commit their changes to a shared git branch before syncing to the RDE, so that the other developers pull the changes before making their own changes.

RDE Command Line Tools Commands rde-cli-commands

Help/General Information help

  • For a list of commands, type:

    aio aem:rde

  • For detailed help for a command, type:

    aio aem rde <command> --help

Deploying to RDE deploying-to-rde

This section describes using the RDE CLI for deploying, installing, or updating bundles, OSGI configurations, content packages, individual content files, and Apache or Dispatcher configurations.

The general usage pattern is aio aem:rde:install <artifact>.

You can find some examples below:

Deploying a Content Package

aio aem:rde:install sample.demo.ui.apps.all-1.0.0-SNAPSHOT.zip

The response for a successful deployment resembles the following:

...
#1: deploy completed for content-package sample.demo.ui.apps.all-1.0.0-SNAPSHOT.zip on author,publish - done by 9E072FC75D54FE1A2B49431C@AdobeID at 2022-09-13T11:32:06.229Z

Optionally, you can reference a remote repository:

aio aem:rde:install -t content-package "https://repo1.maven.org/maven2/com/adobe/aem/guides/aem-guides-wknd.all/2.1.0/aem-guides-wknd.all-2.1.0.zip"

By default, artifacts are deployed to both author and publish tiers, but the “-s” flag can be used to target a specific tier.

Any AEM package can be deployed, such as packages with code, content, or a container package (also called the “all” package).

IMPORTANT
The Dispatcher configuration for the WKND project is not deployed by way of the above content-package installation. Deploy it separately following the “Deploying an Apache/Dispatcher Configuration” steps.

Deploying an OSGI Configuration

aio aem:rde:install com.adobe.granite.demo.MyServlet.cfg.json

Where the response for a successful deployment resembles the following:

...
#2: deploy completed for osgi-config com.adobe.granite.demo.MyServlet.cfg.json on author,publish - done by 9E0725C05D54FE1A0B49431C@AdobeID at 2022-09-13T11:54:36.390Z

Deploying a Bundle

To deploy a bundle, use:

aio aem:rde:install ~/.m2/repository/org/apache/felix/org.apache.felix.gogo.jline/1.1.8/org.apache.felix.gogo.jline-1.1.8.jar

Where the response for a successful deployment resembles the following:

...
#3: deploy staged for osgi-bundle org.apache.felix.gogo.jline-1.1.8.jar on author,publish - done by 9E0725C05D53BE1A0B49431C@AdobeID at 2022-09-14T07:54:28.882Z

Deploying a Content File

To deploy a content file, use:

aio aem:rde:install world.txt -p /apps/hello.txt

Where the response for a successful deployment resembles the following:

..
#4: deploy completed for content-file world.txt on author,publish - done by 9E0729C05C54FE1A0B49431C@AdobeID at 2022-09-14T07:49:30.644Z

Deploying an Apache/Dispatcher Configuration

The entire folder structure must be in the form of a zip file for this type of configuration.

From the dispatcher module of an AEM project, you can zip the Dispatcher configuration by running the below maven command:

mvn clean package

Or using the below zip command from the src directory of the dispatcher module:

zip -y -r dispatcher.zip .

Then deploy the configuration by this command:

aio aem:rde:install target/aem-guides-wknd.dispatcher.cloud-X.X.X-SNAPSHOT.zip

TIP
The above command assumes you are deploying the WKND project’s Dispatcher configurations. Make sure to replace the X.X.X with the corresponding WKND project version number or your project-specific version number when deploying your project’s Dispatcher configuration.
NOTE
RDE supports “Flexible mode” Dispatcher configuration, but not “Legacy mode” Dispatcher configuration. See Dispatcher documentation for information about the two modes. You can also consult the documentation on migrating to Flexible mode, if you have not done so already.

A successful deployment generates a response that resembles the following:

..
#5 deploy completed for dispatcher-config dispatcher.zip on author,publish - done by 9E0735C05T54FE1A0B49431C@AdobeID at 2022-10-03T10:26:31.286Z
Logs:
  Cloud manager validator 2.0.49
  2022/10/03 10:26:37 No issues found
  Syntax OK

Code deployed to RDE does not undergo a Cloud Manager pipeline and its associated quality gates. However, the code does go through some analysis, which reports the errors, as illustrated in the code sample below:

$ aio aem:rde:install ~/.m2/repository/org/apache/felix/org.apache.felix.gogo.jline/1.1.8/org.apache.felix.gogo.jline-1.1.8.jar
...
#19: deploy staged for osgi-bundle org.apache.felix.gogo.jline-1.1.8.jar on author,publish - done by 9E0725C05D74FR1A0B49431C@AdobeID at 2022-09-14T07:54:28.882Z
Logs:
The analyser found the following errors for author :
[requirements-capabilities] com.adobe.aem.temp:org.apache.felix.gogo.jline:1.1.8: Artifact com.adobe.aem.temp:org.apache.felix.gogo.jline:1.1.8 requires [org.apache.felix.gogo.jline/1.1.8] org.apache.felix.gogo; filter:="(&(org.apache.felix.gogo=command.implementation)(version>=1.0.0)(!(version>=2.0.0)))"; effective:=active in start level 20 but no artifact is providing a matching capability in this start level.
[api-regions-exportsimports] com.adobe.aem.temp:org.apache.felix.gogo.jline:1.1.8: Bundle org.apache.felix.gogo.jline:1.1.8 is importing package(s) [org.jline.builtins, org.jline.utils, org.apache.felix.service.command, org.apache.felix.service.threadio, org.jline.terminal, org.jline.reader, org.apache.felix.gogo.runtime, org.jline.reader.impl] in start level 20 but no bundle is exporting these for that start level.
The analyser found the following errors for publish :
[requirements-capabilities] com.adobe.aem.temp:org.apache.felix.gogo.jline:1.1.8: Artifact com.adobe.aem.temp:org.apache.felix.gogo.jline:1.1.8 requires [org.apache.felix.gogo.jline/1.1.8] org.apache.felix.gogo; filter:="(&(org.apache.felix.gogo=command.implementation)(version>=1.0.0)(!(version>=2.0.0)))"; effective:=active in start level 20 but no artifact is providing a matching capability in this start level.
[api-regions-exportsimports] com.adobe.aem.temp:org.apache.felix.gogo.jline:1.1.8: Bundle org.apache.felix.gogo.jline:1.1.8 is importing package(s) [org.jline.builtins, org.jline.utils, org.apache.felix.service.command, org.apache.felix.service.threadio, org.jline.terminal, org.jline.reader, org.apache.felix.gogo.runtime, org.jline.reader.impl] in start level 20 but no bundle is exporting these for that start level.

The above code sample illustrates the behavior if a bundle does not resolve. In which case, it is “staged” and is only installed if its requirements (missing imports, in this case) are satisfied through the installation of other code.

Deploying front-end code bsed on site themes and site templates

NOTE
This feature is not yet GA, but can be used by early adopters. Please reach out to aemcs-rde-support@adobe.com to try it out and provide feedback.

RDEs support front-end code based on site themes and site templates. With RDEs, this is done using a command line directive to deploy front-end packages, rather than the Cloud Manager Front-End Pipeline used for other environment types.

As usual, build your front-end package using npm:

npm run build

It should generate a dist/ folder, so your front-end package folder should contain a package.json file and dist folder:

ls ./path-to-frontend-pkg-folder/
...
dist
package.json

Now you are ready to deploy the front-end package to the RDE by pointing to the front-end package folder:

aio aem:rde:install -t frontend ./path-to-frontend-pkg-folder/
...
#1: deploy completed for frontend frontend-pipeline.zip on author,publish - done by ... at 2024-01-18T15:33:22.898Z
Logs:
> Deployed artifact wknd-1.0.0-1705592008-26e7ec1a
> with workspace hash 692021864642a20d6d298044a927d66c0d9cf2adf42d4cca0c800a378ac3f8d3

Alternatively, you can zip the package.json file and dist folder and deploy that zip file:

zip -r frontend-pkg.zip ./path-to-frontend-pkg-folder/dist ./path-to-frontend-pkg-folder/package.json

aio aem:rde:install -t frontend frontend-pkg.zip
...
#1: deploy completed for frontend frontend-pipeline.zip on author,publish - done by ... at 2024-01-18T15:33:22.898Z
Logs:
> Deployed artifact wknd-1.0.0-1705592008-26e7ec1a
> with workspace hash 692021864642a20d6d298044a927d66c0d9cf2adf42d4cca0c800a378ac3f8d3
NOTE
The naming of the files in the front-end package must adhere to the following naming conventions:
  • “dist” folder, for the npm build output package folder
  • “package.json” file, for the npm dependencies package

Checking the Status of the RDE checking-rde-status

You can use the RDE CLI to check if the environment is ready to be deployed to, as what deployments have been made by way of the RDE plug-in.

Running:

aio aem:rde:status

Returns the following:

Info for cm-p12345-e987654
Environment: Ready
- Bundles Author:
 com.adobe.granite.sample.demo-1.0.0.SNAPSHOT
- Bundles Publish:
 com.adobe.granite.sample.demo-1.0.0.SNAPSHOT
- Configurations Author:
 com.adobe.granite.demo.MyServlet
- Configurations Publish:
 com.adobe.granite.demo.MyServlet

If the command returns a note about instances deploying, you can still go ahead and perform the next update, but your last one might not yet be visible on the instance.

Show Deployment History show-deployment-history

You can check the history of deployments made to the RDE by running:

aio aem:rde:history

Which returns a response in the form of:

#1: deploy completed for content-package aem-guides-wknd.all-2.1.0.zip on author,publish - done by 029039A55D4DE16A0A494025@AdobeID at 2022-09-12T14:41:55.393Z

Deleting from RDE deleting-from-rde

You can delete configurations and bundles that have previously been deployed to RDE by way of the CLI tooling. Use the status command for a list of what can be deleted, which includes the bsn for bundles and pid for configs to reference in the delete command.

For example, if com.adobe.granite.demo.MyServlet.cfg.json has been installed, the bsn is just com.adobe.granite.demo.MyServlet, without the cfg.json suffix.

Deletion of content packages or content files is not supported. To remove them, the RDE should be reset, which returns it to a default state.

See the example below for more details:

aio aem:rde:delete com.adobe.granite.csrf.impl.CSRFFilter
#13: delete completed for osgi-config com.adobe.granite.csrf.impl.CSRFFilter on author - done by karl at 2022-09-12T22:01:01.955Z
#14: delete completed for osgi-config com.adobe.granite.csrf.impl.CSRFFilter on publish - done by karl at 2022-09-12T22:01:12.979Z

For more information and demonstration, see the video tutorial how to use RDE commands (10:01).

Reset reset-rde

Resetting the RDE removes all custom code, configurations, and content from both the author and publish instances. This reset is useful, for example, if the RDE has been used to test a specific feature and you want to reset it to a default state so you can test a different feature.

A reset sets the RDE to the most recently available AEM version.

You can use Cloud Manager to reset your RDE by following the below steps:

  1. Log into Cloud Manager at my.cloudmanager.adobe.com and select the appropriate organization.

  2. Click the program for which you want to reset the RDE.

  3. From the Overview page, click the Environments tab at the top of the screen.

    Environments tab

    • Alternatively, click the Show All button on the Environments card to jump directly to the Environments tab.

      Show all option

  4. The Environments window opens and lists all environments for the program.

    The environments tab

  5. Click the ellipsis button of the RDE that you want to reset, and then select Reset.

    View environment details

  6. Confirm that you want to reset the RDE by clicking Reset in the dialog.

    Confirm reset

  7. Cloud Manager confirms by way of a banner notification that the reset process started.

    Reset banner notification

Once the RDE reset process is started, it usually takes a few minutes to complete and return the environment to its default state. The status of the reset process can be viewed at any time in the Status column of the Environments card or in the Environments window.

RDE reset status

You can also reset the RDE using the ellipsis button directly from the Environments card on the Overview page.

Reset RDE from Environments card

For more information about how to use Cloud Manager to manage your environments, see the Cloud Manager documentation.

Run Modes runmodes

RDE-specific OSGI configuration can be applied by using suffixes on the folder name, like in the examples below:

  • config.rde
  • config.author.rde
  • config.publish.rde

See the run mode documentation for general information about run modes.

NOTE
RDE OSGI configuration is unique in that it inherits the values of any OSGI properties declared by the bundle’s dev run mode.

RDEs are distinct from other environments in that content can be installed in an install.rde folder (or install.author.rde or install.publish.rde) under /apps. This lets you commit content to git and deliver it to the RDE using the command-line tooling.

Populating with Content populating-content

When an RDE is reset, all content is removed and so if desired, explicit action must be taken to add content. As a best practice, consider assembling a set of content to be used as test content for validating or debugging features in the RDE. There are several possible strategies for populating the RDE with that content:

  1. Sync the content package explicitly to the RDE using the command-line tooling

  2. Place and commit the sample content in git inside an install.rde folder under /apps and then sync the overarching content package to the RDE using the command-line tooling.

  3. Use the content copy tool to copy a defined content set from prod, stage, or dev environments, or from another RDE.

  4. Use Package Manager

You are limited to 1 GB when syncing content packages.

Logging logging

Log levels can be set by modifying OSGi configurations. Check the documentation for more information.

How are RDEs Different from Cloud Development Environments? how-are-rds-different-from-cloud-development-environments

While the RDE is in many ways similar to a Cloud Development Environment, there are some minor architectural differences to allow for quick syncing of code. The mechanism for getting code to RDE is different – for RDEs, one syncs code from a local development environment, while for Cloud Development Environments, one deploys code by way of Cloud Manager.

For these reasons, it is recommended that after validating code on an RDE environment, you should deploy the code to a Cloud Development Environment using the non-production pipeline. Finally, test the code before deploying with the production pipeline.

Also note the following considerations:

  • RDEs do not include a preview tier
  • RDEs do not currently support the prerelease channel.
  • While RDE support for viewing and debugging front-end code based on site themes and site templates deployed is not yet GA-ready, it can be used by early adopters. Please reach out to aemcs-rde-support@adobe.com to try it out and provide feedback.

How many RDEs do I need? how-many-rds-do-i-need

An RDE is available for each licensed solution and Adobe also offers additional RDEs, which can be licensed for Production (non-sandbox) programs.

The number of RDEs needed depends on the make-up and processes of an organization. The most flexible model is where an organization purchases a dedicated RDE for each one of their AEM Cloud Service developers. In this model, each developer can test their code on the RDE without coordinating with other team members around whether an RDE environment is available.

At the other extreme, a team with a single RDE may use internal processes to coordinate which developers can use the environment at a given time. This can possibly be whenever a developer has hit an intermediate feature milestone and is ready to validate in a Cloud environment where they can quickly make the changes they need.

An in-between model is one where an organization purchases several RDEs so there is a greater likelihood of an unused RDE being available. One strategy could be to allocate an RDE per scrum team or major feature. Internal processes may be used to coordinate usage of the environments.

How a AEM Forms Cloud Service Rapid Development Environment (RDE) is different from other environments? how-are-forms-rds-different-from-cloud-development-environments

Forms developers can use AEM Forms Cloud Service Rapid Development Environment to quickly develop Adaptive Forms, Workflows, and customizations like customizing core components, integrations with third-party systems, and more. The AEM Forms Cloud Service Rapid Development Environment (RDE) has no support for Communication APIs. It also has not support for features and capabilities that require Document of Record, like generating a Document of Record on submission of an Adaptive Form. The below listed AEM Forms features are not available on a Rapid Development Environment (RDE):

  • Configuring a Document of Record for an Adaptive Form
  • Generating a Document of Record on submission of an Adaptive Form or with a Workflow step
  • Send Document of Record as an attachment with Email Submit action or with Email step in a Workflow
  • Using Adobe Sign in an Adaptive Form or in a Workflow step
  • Communication APIs
NOTE
There is no difference between the UI of Rapid Development Environment (RDE) and other Cloud Service environments for Forms. All Document of Record related options, like selecting a document of record template for an adaptive form, continues to appear in the UI. These environments have no Communication APIs and Document of Record capabilities to test such options. So, when you choose any option that requires Communication APIs or Document of Record capabilities, no action is performed, and an error message is displayed.

RDE tutorial

To learn about RDE in AEM as a Cloud Service, see the video tutorial that demonstrates how to set it up, how to use it, and the development life cycle (01:25).

recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab