ÃÛ¶¹ÊÓƵ

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.