How to use Rapid Development Environment

Learn how to use Rapid Development Environment (RDE) in AEM as a Cloud Service. Deploy code and content for faster development cycles of your near-final code to the RDE, from your favorite Integrated Development Environment (IDE).

Using AEM WKND Sites Project you learn how to deploy various AEM artifacts to the RDE by running AEM-RDE’s install command from your favorite IDE.

  • AEM code & content package (all, ui.apps) deployment
  • OSGi bundle and config file deployment
  • Apache and Dispatcher configs deployment as a zip file
  • Individual files like HTL, .content.xml (dialog XML) deployment
  • Review other RDE commands like status, reset and delete
Transcript
In this video, let’s learn how to use the AEM RDE plugin. With the setup of AIO CLI and plugins now complete, it’s time to deploy code and content to the RDE environment for faster development cycles. For demonstration purposes, we’ll be using AEM Weaken Guides repository cloned from the GitHub. And I have opened it in my VS Code IDE. You can use your own AEM project to try it out. Using the AIO AEM RDE install command, we can deploy the Weaken All package.
The upload time will depend on your internet speed and package size. Once the package is uploaded to the AEM cloud storage, the contents will be applied to the RDE environment by separating the mutable and immutable content. You will receive a brief response indicating success or failure. Note that for larger packages, there may be a delay between the upload completion response and when the content becomes available in the RDE environment. All right, let’s review the newly deployed Weaken site on the RDE.
Here, you can see the language master and country specific language sites are present.
We can offer the content and add or remove the components from the pages. And likewise, review and manage the assets, content fragments, experience fragments.
In summary, RDE is similar to any AEM cloud environment, just the deployment aspect is different.
Now, we are all set to use the AEM RDE plugin to deploy various artifacts like OAGI bundles, OAGI configurations, Apache or dispatcher configurations, or AEM packages to this RDE. First, we are going to pretend that we are working on a simple enhancement to the hello world component. We need to update the component dialogue to include a new description text field and render the authored content.
After making our code changes and verifying them locally, we can then deploy these changes to our RDE by running the install command and passing the location of our UI apps package as an argument.
As you can see, the newly deployed changes look good on the RDE and we are now ready for the next stage in our development process.
That’s correct. This was just a trivial change, but it’s helpful in demonstrating the Swift deployment and review process and it gives us confidence that our feature is ready to go. Before we dive into more deployment examples, let’s review the options available with the install command. You can do this by passing the minus, minus help flag.
With the minus S flag, you can target your installation to either the author or publish environment. If you want to install your changes on both environments, simply omit this option.
With the minus T flag, you can specify the type of deployment you want to perform. Please note that some types, content file and content XML require an additional minus P option to specify the destination JCR path in the AMRDE environment.
So now that you have a better understanding of these options, let’s use this knowledge to deploy various AM artifacts. We will try out each of the various install types to give you a comprehensive understanding of how to use the install command.
Let’s get started. When it comes to deploying changes in RDE, a common starting point is to build and install the all and dispatcher package. From there, you can incrementally install additional changes on top of that. In this example, we will show you how to deploy an OSGI bundle. An OSGI bundle contains Java code, such as an OSGI service or sling model. So first, you need to update the Java code in the core module of your AM project. You will build the core module using the maven command. This will put all the Java files into a jar artifact that can be installed. Finally, you can deploy the jar file using the command aio space am colon rde colon install and specifying the location of the jar file, which is located in the target folder of the core project. As you can see, the OSGI change is deployed successfully to the RDE. Now, let’s take a look at how to deploy OSGI configurations. First, update the desired OSGI configuration file in the AM projects ui.config module. These files typically use the .cfg.json extension. Next, deploy each individual OSGI configuration using the RDE plugins install command. It’s important to note that OSGI configuration files are stored in run mode specific folders in the ui.config project. But when you install individual OSGI configurations, we are the aio RDE CLI. They are deployed without this context. To install an OSGI configuration, only an author or published instance specify it with the minus s flag. If you want the OSGI configuration to be deployed on both, then omit the minus s flag. And a key call out, the RDE has its own run mode. So you can also deploy RDE specific OSGI config files. All right, let’s talk about deploying Apache and dispatcher configurations. It’s important to note that you cannot deploy individual config files, but instead, the entire dispatcher folder structure needs to be deployed in the form of a zip file. To do this, first, update the desired config file. For example, here I’m updating the cache control header in the vcan.vhost file. Then build the zip file by running mvn clean package inside the dispatcher module. Finally, deploy it to the RDE using the aio am colon RDE colon install command and specifying the location of the zip file. Before we wrap up the install commands, let’s see how you can deploy the individual files like hdl, dialogue XML, or even content files. For the hdl file, you have to specify the type as content file using the minus t flag and the destination path in the am using the minus p flag. This example shows hello world hdl file specific deployment. Similarly, for .content.xml files, such as dialogue or files from slash conf and slash content folders, specify the type as content-xml and the am destination path. Note that for the content file and content XML install types, the full am project or subproject doesn’t have to be rebuilt. Instead, changes to discrete files can be quickly and iteratively deployed to the RDE. This wraps up our demonstration of deploying to the rapid development environments using the am RDE plugins install command. Make sure to check out the am RDE plugin GitHub repository for any updates or additions. And for more information, consult the am as a cloud service documentation on the rapid development environment topic. All right, let’s take a look at the other RDE commands. First, there is the delete command. This command allows you to delete OSGI bundles and configurations from the RDE. It also supports the minus s and minus t flags for added granularity. Next, there is the status command. This command provides a list of the bundles and configurations that have been deployed to the RDE. The restart command restarts both the author and publish instances. And finally, the reset command resets the RDE back to its default state, removing your application code and content and leaving only the AM product code available, like a clean slate instance. That’s it, folks. These are the key RDE commands that will help you to keep the development momentum and give you confidence that your code and configuration changes are ready for handoff. This concludes how to use the am RDE plugin. Here are a few key call outs to keep in mind. Number one, ideally, only one developer should use the RDE at a given time. Verify this using the history and status command to ensure that you are not overwriting someone else’s work. Number two, it is also possible that multiple developers can use the same RDE by committing their code changes to a shared Git repository and frequently pulling from it, or using other collaboration methods like pair programming, development, or debugging sessions. Number three, upon task or feature completion, reset the RDE to its default state and communicate the status to the team. Number four, the number of RDEs you will use depend on your project state, development process, and budget. Consider having an RDE per developer, or per Scrum, or per two to four developers. These guidelines may help you effectively use the RDE and avoid dysfunction.

Prerequisite

Clone the WKND Sites project and open it in your favorite IDE to deploy the AEM artifacts onto the RDE.

$ git clone git@github.com:adobe/aem-guides-wknd.git

Then, build and deploy it to the local AEM-SDK by running the following maven command.

$ cd aem-guides-wknd/
$ mvn clean package

Deploy AEM artifacts using the AEM-RDE plugin

Using the aem:rde:install command, let’s deploy various AEM artifacts.

Deploy all and dispatcher packages

A common starting point is to first deploy the all and dispatcher packages by running the following commands.

# Install the 'all' package
$ aio aem:rde:install all/target/aem-guides-wknd.all-2.1.3-SNAPSHOT.zip

# Install the 'dispatcher' zip
$ aio aem:rde:install dispatcher/target/aem-guides-wknd.dispatcher.cloud-2.1.3-SNAPSHOT.zip

Upon successful deployments, verify the WKND site on both the author and publish services. You should be able to add, and edit the content on the WKND site pages and publish it.

Enhance and deploy a component

Let’s enhance the Hello World Component and deploy it to the RDE.

  1. Open the dialog XML (.content.xml) file from ui.apps/src/main/content/jcr_root/apps/wknd/components/helloworld/_cq_dialog/ folder

  2. Add the Description text field after the existing Text dialog field

    code language-xml
    ...
    <description
        jcr:primaryType="nt:unstructured"
        sling:resourceType="granite/ui/components/coral/foundation/form/textfield"
        fieldLabel="Description"
        name="./description"/>
    ...
    
  3. Open the helloworld.html file from ui.apps/src/main/content/jcr_root/apps/wknd/components/helloworld folder

  4. Render the Description property after the existing <div> element of the Text property.

    code language-html
    ...
    <div class="cmp-helloworld__item" data-sly-test="${properties.description}">
        <p class="cmp-helloworld__item-label">Description property:</p>
        <pre class="cmp-helloworld__item-output" data-cmp-hook-helloworld="property">${properties.description}</pre>
    </div>
    ...
    
  5. Verify the changes on local AEM-SDK by performing the maven build or syncing individual files.

  6. Deploy the changes to the RDE via ui.apps package or by deploying the individual Dialog and HTL files.

    code language-shell
    # Using 'ui.apps' package
    $ cd ui.apps
    $ mvn clean package
    $ aio aem:rde:install target/aem-guides-wknd.ui.apps-2.1.3-SNAPSHOT.zip
    
    # Or by deploying the individual HTL and Dialog XML
    
    # HTL file
    $ aio aem:rde:install ui.apps/src/main/content/jcr_root/apps/wknd/components/helloworld/helloworld.html -t content-file -p /apps/wknd/components/helloworld/helloworld.html
    
    # Dialog XML
    $ aio aem:rde:install ui.apps/src/main/content/jcr_root/apps/wknd/components/helloworld/_cq_dialog/.content.xml -t content-xml -p /apps/wknd/components/helloworld/_cq_dialog/.content.xml
    
  7. Verify changes on the RDE by adding or editing the Hello World Component on a WKND site page.

Review the install command options

In the above individual file deployment command example, the -t and -p flags are used to indicate the type and destination of the JCR path respectively. Let’s review the available install command options by running the following command.

$ aio aem:rde:install --help

The flags are self-explanatory, the -s flag is useful to target the deployment just to the author or publish services. Use the -t flag when deploying the content-file or content-xml files along with the -p flag to specify the destination JCR path in the AEM RDE environment.

Deploy OSGi bundle

To learn how to deploy the OSGi bundle, let’s enhance the HelloWorldModel Java™ class and deploy it to the RDE.

  1. Open the HelloWorldModel.java file from core/src/main/java/com/adobe/aem/guides/wknd/core/models folder

  2. Update the init() method as below:

    code language-java
    ...
    message = "Hello World!\n"
        + "Resource type is: " + resourceType + "\n"
        + "Current page is:  " + currentPagePath + "\n"
        + "Changes deployed via RDE, lets try faster dev cycles";
    ...
    
  3. Verify the changes on local AEM-SDK by deploying the core bundle via maven command

  4. Deploy the changes to the RDE by running the following command

    code language-shell
    $ cd core
    $ mvn clean package
    $ aio aem:rde:install target/aem-guides-wknd.core-2.1.3-SNAPSHOT.jar
    
  5. Verify changes on the RDE by adding or editing the Hello World Component on a WKND site page.

Deploy OSGi configuration

You can deploy the individual config files or complete config package, for example:

# Deploy individual config file
$ aio aem:rde:install ui.config/src/main/content/jcr_root/apps/wknd/osgiconfig/config/org.apache.sling.commons.log.LogManager.factory.config~wknd.cfg.json

# Or deploy the complete config package
$ cd ui.config
$ mvn clean package
$ aio aem:rde:install target/aem-guides-wknd.ui.config-2.1.3-SNAPSHOT.zip
TIP
To install an OSGi configuration only on an author or publish instance, use the -s flag.

Deploy Apache or Dispatcher configuration

The Apache or Dispatcher config files cannot be deployed individually, but the entire Dispatcher folder structure needs to be deployed in the form of a ZIP file.

  1. Make a desired change in the config file of the dispatcher module, for demo purposes, update the dispatcher/src/conf.d/available_vhosts/wknd.vhost to cache the html files only for 60 seconds.

    code language-none
    ...
    <LocationMatch "^/content/.*\.html$">
        Header unset Cache-Control
        Header always set Cache-Control "max-age=60,stale-while-revalidate=60" "expr=%{REQUEST_STATUS} < 400"
        Header always set Surrogate-Control "stale-while-revalidate=43200,stale-if-error=43200" "expr=%{REQUEST_STATUS} < 400"
        Header set Age 0
    </LocationMatch>
    ...
    
  2. Verify the changes locally, see Run Dispatcher locally for more details.

  3. Deploy the changes to the RDE by running the following command:

    code language-shell
    $ cd dispatcher
    $ mvn clean install
    $ aio aem:rde:install target/aem-guides-wknd.dispatcher.cloud-2.1.3-SNAPSHOT.zip
    
  4. Verify changes on the RDE

Additional AEM RDE plugin commands

Let’s review the additional AEM RDE plugin commands to manage, and interact with the RDE from your local machine.

$ aio aem:rde --help
Interact with RapidDev Environments.

USAGE
$ aio aem rde COMMAND

COMMANDS
aem rde delete   Delete bundles and configs from the current rde.
aem rde history  Get a list of the updates done to the current rde.
aem rde install  Install/update bundles, configs, and content-packages.
aem rde reset    Reset the RDE
aem rde restart  Restart the author and publish of an RDE
aem rde status   Get a list of the bundles and configs deployed to the current rde.

Using the above commands your RDE can be managed from your favorite IDE for faster development/deployment life cycle.

Next Step

Learn about the development/deployment life cycle using RDE to deliver features with speed.

Additional resources

RDE commands documentation

Adobe I/O Runtime CLI Plugin for interactions with AEM Rapid Development Environments

AEM Project setup

recommendation-more-help
4859a77c-7971-4ac9-8f5c-4260823c6f69