Accelerating AEM as a Cloud Service development with Rapid Development Environments

Transcript

Okay, Karl, please feel free to start with your presentation. Thank you, Goran. So, yeah, then welcome everybody to our today’s talk about RDE or Rapid Development Environments. And Goran already introduced us, so I’m not going to do that again. But instead, I’m going to go into it right away. And really what I want to start out with to talk about is cloud development velocity in the context of AAM as a cloud service. And I guess most of you are actually users and customers of AAM as a cloud service. So you know how it works and the surroundings of it. Probably a lot of you even know how it used to be to develop for AAM before cloud service.

So the way you develop for cloud service nowadays really hasn’t changed that much from what happened before cloud service existed. In other words, while cloud services brought quite some new features and things are different now, the way it deploys, everything runs on Adobe’s cloud side and you have environments and all these things. There are lots of changes, lots of improvements, lots of features. But the development is, at least for the initial one, still the same. You have the local SDK and that’s fine. That’s what AAM was famous for, that you have a local instance running and you can iterate really quickly. You can deploy at runtime, you can make changes, you can update bundles, you can update scripts, whatever and you get feedback directly. It still works and it’s still a valid way to do it and the feedback is there within seconds whenever you make a change. Now, however, with the cloud in the picture, local development has started to be missing some parity. On the one hand, you have cloud-only features. On the one hand, these are add-ons that we provide. There are things like assets essentials and other things that you just don’t have, commerce integrations that you cannot easily reproduce with the local SDK. But also, even deeper down, assets processing, for example, in the cloud that uses a separate service which is not the same that you get in the local SDK. Then, yes, it’s an approximation of the process, but it’s just not the same. On top of that, if you use the local SDK, it is possible that you run out of sync with what you have in the cloud, mostly because the cloud tries to be always current. We might push updates and then your SDK doesn’t match anymore, but also in certain scenarios for your dev environments, you have to pick the update and things like that. In other words, you frequently have to download a new SDK, update your SDK, and that can be time-consuming and introduce problems too.

Really, while it’s still fine to develop with the SDK, it is missing some integration piece when it comes to the cloud service.

What you can do instead, obviously, is to use the so-called dev environments to validate your changes once you’re done. But it really constrains you to validating your changes in the end in the cloud because you have to run a pipeline, which takes quite some time, up to 30 minutes.

That’s not optimal for getting quick feedback about small changes. It’s really only something that you do when you think it should work and you want to validate that it actually does. It’s in part because there’s validation going on in the pipeline, but also because those dev environments are not necessarily really developer environments. They’re more testing environment kind of things. They’re really full-blown environments with clustering and all of this. It takes some time to provision and deploy into them.

That’s the world we had until recently. And that we did set out to find a solution to. And really, the end goal here is that we want to move development for AM as a cloud service more into the cloud. And the idea is that we introduce a new environment type and those environment types similar to what you have in dev environments. You can have several of them. You have to potentially have to buy extra ones if you want several. But in general, you will have at least some. And the big difference is there’s no pipeline or Git repository associated with them, but they support changes at one time. So similar to the local SDK, you can provision more fine-grained changes like configurations or individual bundles and even up to scripts directly to the environment. And it’s applied on top of what’s running there at one time.

Same goes for some other features like the Web Tier config and other things. So really, the idea is to speed up the feedback and development cycle here and allow you to test your stuff and develop your things in the cloud, which hopefully helps with validating new features and creating code much more quickly.

And the way this works is that, as I said, there’s no pipeline or Git. Instead, we introduce a new API to which you send your artifacts directly. It’s potentially possible that this will become a public API eventually. Right now, it’s just an API we use for the integration that we provide. And we provide the integration right now for the AIO command. Some of you might be familiar with it. It’s used often for cloud manager tasks as well. And you can have plugins to AIO. And we have such an AIO plugin for our environments. And then you get the AIO CLI and you can use that one to send the artifacts to us. And then, yes, so from there on out, RDEs really are environments just like Dev Stage Support, but somewhat more similar to Dev, I guess.

So they have all the trimmings and are running in the cloud. But the big difference is you deploy directly to them.

And that really brings back the feedback cycle to seconds, at least in certain cases. I mean, it depends a little bit on what you upload and how quick your upload is and how much work we have to do to get it in. So it can be up to minutes, but certainly it’s much quicker than running a pipeline. And we will get into what exactly is different and what’s similar a little bit later. But we will look into it during this talk. And I guess for those that cannot really now picture already what it’s going to look like, we will start out with a quick demo now just to show you how the normal workflow goes and give you an idea how to use it. But we will have a more in-depth demo later and more introduction to what really is different in doing this talk. But for now, let’s start with a quick peek into what it looks like from David.

Thank you, Carl.

Yeah, and I’m just going to share.

All right.

OK. Yes, thanks. So, yeah, so my name is Dave Borschardt, and I’m just going to show you a real quick peek into, you know, what you can roughly do with RDE.

Just to give you an idea of what we’re talking about.

So for my demo, I’m assuming that I’m building an application that is about selling tree seedlings or other plants. So it’s a plant selling application built on AEM. And this page here is going to be part of it. Now, this page is actually running in AEM cloud services in an RDE environment, but it looks a little bit bare at the moment. I would like it to look a little bit nicer.

So for my application, I made it such that you can change the background color of these images using an OCI configuration. Now, OCI configurations can be used for many different things, but just for the demo, I used, you know, decided to use this for the background color. So I have a config file here where I set the background color to blue. Now, what I’m going to do next is I’m going to deploy just this file. I already have my current application deployed, but I’m just going to deploy just this file to my RDE environment. So that’s just that file. And then we can see how quickly we can actually do round trips in, you know, development, trying things out and seeing the result. So it starts with uploading the change and in the applying update now it does some validation, the same kind of validation that happens in the pipelines, at least partly, to make sure that, you know, the change will work. So that’s the change uploaded. Now I can go straight back to my page and see if the color was nice, if my change was a good change. Oh, I think it was a terrible change because blue doesn’t work great at all here. So let’s make another change to make it look better.

Maybe honeydew is a nicer color than blue. Save it again.

And we’ll basically install the same config file now changed into the RDE environment again.

And applying the update. A config file is one example of things you can upload. Natalia will show different types of artifacts later on. So you will see more of that in a later demo. So, okay, our honeydew change came in. And I think this looks a lot better.

And again, this was just a, you know, teaser to quickly show you what you can do with RDEs and how you can quickly turn around and make changes. And, yeah, Natalia will show you a lot more detail later on. And with that, I’m going to give it back to Karl for the continuation of the presentation. All right. Thank you. Let me try to wrap the screen again.

So, yeah, that’s really already a good example of how you will interact with source rapid development environments.

And let me now zoom in a little bit into what really are the differences between RDEs and the similarities here. So, as I said, I think a good maybe mental model of thinking about this is to compare it to the local SDK, right? Where you have an install folder. So, typically, you built your project locally. You built your bundles or things like that. And you put them into the install folder. But even better, and then it’s picked up by AAM and Sling processes it and installs the differences, right? That’s something that’s even closer. I don’t know how many people used it. But in Sling, we always used to have the, or still have, a Maven plugin integration, right? Where you can just say Sling deploy when you do your Maven build and it sends the individual artifact directly to a running AAM instance or Sling instance.

That was always convenient. And this is roughly the direction that we’re taking here. Just that, as I said, for now, we have the AIO command for that.

And as David showed, it’s reasonable straightforward to send an artifact to a running AAM RDE environment like that. So, really, the idea is you have the AIO command. It takes your locally built artifact.

Initially, you probably would deploy your complete package, right? Your all package. But once you did that and that is applied, you can start working with more fine-grained changes like, say, just the bundle that you changed or just the script that you changed to.

Yeah. To not have to wait that long. But what happens then once that is uploaded, we do have a pre-processing step, which is in part similar to what happens in the cloud. If you look at the cloud pipeline, it first builds your things so that we don’t do that as you do locally. Whatever you have locally, you can deploy. But from there on out, we run some of the translations we do in the build image step. We separate your packages just like in the build image step and these things. So, that’s similar. Then eventually, we push the results. But we also run the analyzers that we run in the build image step over them. So, the benefit then is that we can potentially catch some problems early, similar to what happens in the pipeline, right? Where if the build image step fails with an analyzer failure, at least it saves you some time. We can do the same thing here and it keeps things consistent, right? So, you get the feedback directly to your command to the AIO console much quicker than actually deploying it. The prominent example, for example, is if you would try to deploy a bundle that doesn’t resolve, right? So, we can catch that early. We will tell you, well, this bundle is not resolving. We’re staging it so you can keep adding bundles until you have a valid resolution over the transitive dependencies. And only then, you will release it to the environment.

And again, we have a demo for this later on which goes in much more detail here. But ultimately, we assume you gave us something that we think is okay.

And then, we will provision it to the environment. And again, this is picked up at runtime by the instances.

And then, for the environment itself, the biggest difference probably, at least noticeable from the outside, is twofold. On the one hand, we only have one author and one publish. So, there is no clustering going on in these environments.

That has a downside that you don’t have high availability, obviously. And it limits the testing use cases somewhat.

In other words, it’s not necessarily the intent that you can do something like a law testing here or something like that. But other than that, it should be pretty similar. The port layout, at least, is the same. So, you have a publish that has a dispatcher in front and things like that. But the author runs on a segment store.

So, it’s not using Mongo. Again, if you really wanted to do something like a law testing or a leader selection, things like that, that wouldn’t be an ILD here. You have to do that against your dev environment still. But hopefully, otherwise, you don’t notice the difference too much because the rest we try to keep as consistent as possible.

The scripts are not precompiled. But other than that, we do the same things. And we also, for example, for mutable content, at least, we first install it on the author and then replicate it to the publish just like it would happen in the cloud, in a normal cloud dev environment. So, it’s very similar from the flow. We also keep the separation between immutable and mutable repository parts. So, in other words, apps and libs are still immutable here, at least as far as your code is concerned. So, if you have a bundle that tries to write to apps, for example, that wouldn’t work. But due to the parts, due to the segment store, but just in general, the way we did it, we can still update it at runtime. So, you can use RDE and the AIO command to provision things to apps.

So, if you, for example, want to update a script, you can just send it with the AIO command either directly, that’s possible too, or indirectly. In other words, wrapped in a content package. And when that gets applied, it will update the scripts and the apps as well. So, that’s, I guess, for the inside of the environment.

Again, we try to keep it consistent, the asset dispatcher on the publish, and we do invalidation just like it is in the dev environment. And the infrastructure around it is the same. So, you still get a CDN, you have all the possibilities to limit the access to the environment and things like that. For most use cases, it should give you a similar experience than it does for the dev environments.

So, at least, yeah, that’s the goal.

Obviously, this is brand new, and we’re still looking for feedback and also having to improve it here and there. So, maybe some things are missing, which we still have in the pipeline to support, but the goal really is that it should be as close as possible to a normal environment, at least behavior, from the behavior.

Right. So, I think that hopefully gives you an insight of what the differences are. I will look into the Q&A part two and see if I can answer questions if I missed something and we have a chance later on to get back to questions that you have for this.

But I think we should now first go to have a more in-depth demo to see how it really looks like when you do the day-to-day development for RDE and also how you can configure and set up this AIO plugin to work with RDEs. And for that, I would like to hand it over to Natalia.

Thank you, Carl.

OK, so let me grab the screen.

There you go. So, let’s start. You can see here I have Node 18 version and I don’t have the AIO CLI installed. But if we go to the public documentation, we can just follow the steps to install the AIO CLI and this will take a little.

So, basically here I just chose Node 18 because, well, it is, I think, the most recent version of Node with LTS.

Also, because you will see some warnings. You can skip if Node those warnings.

They are just saying, well, they are not compatible with Node 18, but I can say it works because actually this demo has been done with the Node 18.

And also in the public documentation, I’m going to take advantage to let you know that you can also find a lot of information about RDE. So, there you have the warnings that I told you.

So, this would be almost done. Those are the warnings and let’s see if the AIO tooling was installed correctly. There you go. OK, cool. So, let’s go back to the public docs and the next step should be to go to install the Cloud Manager plugin.

So, we just copy and paste the command. This is not the main plugin that we are going to use, but it is helpful to have it installed because some commands are helpful for the development as well. OK, done. And then the most important one, we install the RDE plugin.

So, this will also take a little.

All right, done. So, now actually let’s double check that the RDE plugin is installed correctly. OK, there you go. And now, well, we have the AIO tool installed, but we need to set up the authentication and to point to the Cloud Manager organization. In my case, it is this one and to the program ID and the environment ID. I’ll show you later in another wrap-up demo about how to get the organization ID. So, don’t worry about that. And you can see I specify the local flag. That is because actually it created a .AIO file in my local folder with the pointing to the program ID and environment ID that I put. This allows us to switch between environments very quickly because actually now I’m going to log in. You can use the no open flag if you want to. I’ll explain later. In my case, I’m just going to throw the output to a file to avoid displaying the token. But sometimes if you have the login cache, then it will open this URL and it will automatically log in. You will not see this organization selected. So, if you use the no open flag and then you open the link in an incognito window, you start over.

OK, so now I’m looking. So, I should be able to see the status of my RDE environment, which I already have up and running. So, there you go. The environment is ready and I don’t have anything installed. Let’s go to the public docs and we can see here that we can install a lot of things.

In this case, we’re going to install the weekend, but let’s double check also the things that we have in the AIO tool. So, we can install a bundle, a config, a content package, which is what we’re going to do, and a dispatcher config, a lot of things. In our case, let’s go for the weekend package, the weekend content package. Actually, this is a, let’s say, pretty huge package. So, it’s going to take a little.

But in the meantime, I’ll explain to you a little about what is happening behind the scenes.

Well, you could see in the previous diagram that my workmates saw to you that the first step is that we upload the package or the file or the input that you are giving us to the cloud. So, actually, that is what happened in the uploading step and it depends on the internet connection that everyone has. And the second thing is, well, you are seeing the applying update is we are running analyzers and we are processing the package to be installed in AM. So, now it is in this step. Okay. Now, it should be installed. But let’s go back to the documentation because we installed the content package, but we are still missing the dispatcher configuration for the weekend. So, in my case, I just have downloaded the dispatcher config from the weekend GitHub project. I have it here.

And I’m going to install it in my RDA environment.

It is the install command the same, but you can specify the type as I saw it to you previously. Let’s actually double check again the types. In this case, you could specify the dispatcher config, but if you don’t do it, we try always to infer the type. In my case, you can see I didn’t specify and it’s going to work. But if you see, you know, that we are not catching up properly the type that you are specifying for any reason, you can just go ahead and put it yourself. So, all right. That was quick. So, you can see now, no issues found and the syntax is okay. So, the dispatcher configuration is done.

The new thing. Let’s double check the status of the environment again before it was empty. And let’s see what is going on now. Environment is ready and we have the bundles and the configurations from the weekend. All of this happened, well, you can see here, we have the published weekend content. And also, you can see that we didn’t specify to put it in the publish or author. That is because by default, we deployed in both. So, here in the author, it will also be installed the weekend package.

Let’s double check. It is also here.

Okay. There you go. You can see here, we have the weekend package. And let’s see. Let me go and open the path of a file because I’m going to prepare also a very quick and also done, let’s say, change that I want to show you. Because actually, it’s just to show you that you don’t need to now change the entire content package and, you know, push the entire content package. Imagine that you want to change, let’s say, the footer, right? Here I have just prepared, I want to change my footer. That is not present in the weekend. So, I don’t need to build and push the entire content package again. You can just deploy this single content file.

So, actually, we just need to call the install command, put the long path where my file is. And we’re going to specify the path where the file is going to end up in AM. So, we just run this command.

This will be pretty, pretty quick because it is a small file.

All right. It is done. So, now if we go back to the author and we refresh, we go here. We cannot see here, but let’s click on edit.

And let’s see that our change to the footer is present here.

Right. Let’s wait.

Let’s go to the bottom.

There you go. I want to change my footer. The change is there. So, this was like a quick change, but, you know, there are tons of possibilities that you can do. Even more, we can go to the repository browser, which you can access via the developer console. So, let’s open the developer console.

And let’s log in. And in the repository browser, we should be able to see the file that we just modified. And the change will appear there. This is also helpful while developing. So, okay. If we go to content, we navigate under the tree to find a file.

Right. It is on the side.

The footer. Let me write it a little bit more.

Okay. In the root and container, we’re close. And we can see that the file is there. The root and container, we’re close. There you go. Okay. I want to change my footer. You can see the text is modified here.

So, this was just, again, one of the tons of examples that we could show you. I mean, you can just modify whatever piece you want from the content package. And you don’t need to build and push it again.

Okay. Let me stop sharing and share again the presentation. All right. That was the demo.

But even more, I mean, because you could see that we have always an RDE up and running prepared. And we didn’t show you how to create one or how it would be done.

It is going to be quite simple. I’ll show you in a wrap-up demo again. But just to some pointers, this is just a new environment type. I mean, it is the same as when you create a new development environment or a new stage or production environment. You now can select rapid development environment. Okay. So, that is the same. It’s just a new item that you’ll see in the list.

We mentioned this, the reset operation. This is actually quite useful, at least for development. Because if you reset your environment, you can just leave it in a vanilla state as it was before. This means we will upgrade to the latest AM version. So, the same as if you create a new one, right? It will appear into the latest AM version available.

And we will wipe out all the installed content. Everything you did into the R, the environment in terms of content or code that you installed, it’s going to be wiped out.

The environment variables, the CDN configuration, all the rest that you configured that is going to be kept. I mean, only what you installed, right? And besides that, also to highlight here, although it is less important, that this is the same as we had for Sandbox’s programs. I mean, if you have a dev, stage, production, or RDE environments in a Sandbox program, they will be hibernated if they are not used after some time. But again, this is the same for dev, stage, and production programs. RDEs are not hibernated in production programs. But beyond that, what about the enablement? I mean, because some of you might already be using this or not. So, the thing is, the production rollout is in progress. Actually, the plan is to complete the rollout this week.

So, this will be done by the end of this week. And all of you should have this enabled in your organizations. By default, and most of you might wonder how many are the environments you will have. Well, we will give you some for free. Actually, we will give you one for free per Sandbox program. And also for free, one per solution applied into a production program. But besides that, if you want to get more, you can just buy extra credits. You just need to reach out to your account executives. You just need to reach out to your account executive and you’ll get more.

The more you want, you’ll have it. So, now that I have just showed you some pointers, let me again stop sharing and start the quick wrap-up demo.

Okay.

So, before I forget, let me show you the first of all how to get your organization ID because I mentioned it to you. This is the org ID that you can use to set up the AIO tooling and to refer to your organization. Besides that, I was also, I want to also show you that here I’m in a Sandbox program and I can just click on Wrap It Up and create a new environment. I have some of them prepared already. You can see here in a production program, I’m running three. And you can see here the reset button. This is the Cloud Manager UI, but we can also go to the terminal and see here, for instance, let me double check that I’m in the right environment.

I’m going to log in again, just to double check.

This will be automatically logging because it is cached, as I told you before.

And now let’s double check again the options or the commands that we have for the Rb plugin.

You can see there the reset one. So, we can just call the reset command and voila, the environment is being reset. So, now if we go to the Cloud Manager UI and refresh, we should see the environment marked as resetting.

This will take some minutes and then it will be done.

There you go. The environment is resetting.

You can see I have more. I mean, this one, we’ll see that this one is, the reset is not enabled. So, it will be once it is done. But for the others, you can reset them.

Okay. And you can add more. Here, actually, you can see that in this example, we have used 11 from 22 credits that we have available in this organization.

All right. So, that was all I wanted to share. So, back to you, Carl.

Thank you, Natalia.

Yes. So, hopefully, that gave a better overview about what you can do with RDEs on the one hand, how it works with the AIO plugin and the integration with Cloud Manager and hooking everything up, but also how you can create RDEs for yourself and what you need to do there. I saw quite some questions around these topics. So, I guess some of them, we tried to answer directly online and others have been answered, hopefully, by the demo here.

So, let me summarize this a little bit again and try to take at least some of the questions into account. So, as you can see, the RDE environments really are meant, not necessarily at this point, to completely replace the local SDK.

That’s certainly something for the future to consider. But right now, and there was a question about this, too, it really augments your setup where you do the local development with an environment where you can more quickly test out things. So, typically, you would probably still have the SDK around to do the bulk of the development, especially when you need the buggers attached and things like that. But once you’re going into experimenting how this works in a setup as a publish and a dispatcher and a remote URL space and or need integrations with the other things in the cloud, that’s where it comes in handy to have RDEs. Also, they potentially lend themselves well for running tests against them in the cloud for integration tests or something like this. There were some questions about integrations with other built tooling. And we certainly are open.

And we know that, for example, even the AIO plugin still needs improvement. But we also want to look into better integration with other tooling and potentially IDEs and things like that. So that’s hopefully not the end that we have here. Also, it would be interesting to see what you can do on GitHub and other Jenkins and CircleCI and whatever integrations for actions to use RDEs directly.

So there hopefully will be more coming soon in that area. The AIO plugin itself is on GitHub. So if you, I think Conrad already found that. So we certainly are open for suggestions there, too. So feel free to provide feedback there and create issues if you have ideas. We still want to develop it further. But in a nutshell, the hope really is that RDE environments will save you a lot of time and speed up the development for you, mostly because they allow you to get feedback much quicker and you don’t have to do your development with the dev environment, but really can use dev environments for the final testing. And yeah, as I said, maybe more expensive things like law testing and things like that. That’s where the dev environment really is used for. But for the in-between, from the actual development locally to the dev environment, we hope that RDEs can be used. I think if I’m not mistaken, they should now be available for most organizations. If not right now, today, then during the next couple of days, I think they will be available in general.

I see that quite some questions around that still. So yes, I think RDEs will be available for sandboxes. So as Natalia said, each sandbox gets the possibility to have an RDE. It’s just like a sandbox normally has dev stage part, and then now it can have an RDE. And in addition, I think each program will get one RDE. And then if you want more, you have to talk with your account executive to see what that means.

Hi, Carl. I’d quickly like to jump in here.

Thanks for your presentation and demo. Awesome. Thank you, Carl, Natalia, and David. I just quickly wanted to mention to the audience that I would like you to complete our ending poll. I will post it into the general chat.

This is also general questions and anonymous and also quite brief. But we foster a strong feedback culture, and that’s why we would like to get some information from you.

And yeah, let’s continue with the Q&A. I will quickly read out the questions to our presenters.

So a question from Arun Kumar. With Adobe Cloud Manager doing the project builds, do we still need a separate build to push in Nexus repo or it’s optional or Nexus repo configuration is required for non-Adobe cloud setup? I’ve seen that question, and I’m not sure how to answer it. I’m sorry. I’m not 100% sure.

OK, no problem. So note that we have a contextual thread where we can interact with the audience post session, and also the audience can interact with us. We can take up this question and post it, the answer there after the session. So you have to have time to look into that. I wanted to quickly jump the queue because there’s one question I’ve seen which I want to answer.

I think from Thomas, how would you work with those if your whole frontend is sitting in a separate repo is deployed using frontend pipelines? And I assume this question is about frontend pipeline support. And yes, right now the RDE does not support the frontend pipeline separation, so you cannot send that to us yet, but that’s planned. So hopefully soon we will support frontend pipeline. Deployments too.

Thank you, Carl.

Next question is Adobe going to support AM as a cloud service SDK in another cloud like Azure and AWS? I’m not sure that this is on topic.

I don’t know the answer to that.

Yeah, we’ll pick it up post session as well. And the contextual thread.

Next question, can we validate the local code against the cloud manager rule sets? So we had a similar question which I answered already, which is around the… So we run in the pre-processing, we do run the analyzers that we run in the build image. So there is some of the quality gates that we have in the normal pipeline. We do actually give you feedback about, but this one I would assume is the actual rules that run during the build step from the pipeline, which is different. And no, we don’t look at those in the RDE.

Thank you, Carl. Next question, is this now available on all Adobe cloud programs to add one per program? Is there any licensing that need to be procured? Yeah, I think I tried to answer that one already and Natalia had it in there. I think it should be available. If not right now today, then it should be soon. So it’s in the progress of being enabled for everybody, I believe.

Okay, thank you. Okay, thank you. Next question around compliance. Do I need a whitelisting if I’m behind the client VPN such that AIO still upload the packages? I think we have to potentially follow up on this one offline.

You need to be able to reach the Adobe cloud. So if that is part of the whitelisting you already have, then yes, it should be fine. Otherwise, you might need to whitelist something, yes.

All right, thank you. Next question, can we update the local cloud SDK using the AIO commands or do we have to manually download the latest SDK from software distribution? How do we ensure the local SDK and RDE have same cloud SDK release? Yeah, there’s no solution for that.

Just like you’re not having much support for keeping your normal cloud release in sync with your SDK, you have the same here. But maybe we didn’t go into that part right now. Right now the idea is, you’ve seen in the demo that you can reset RDE environments. When you do that, you will potentially get on the latest version of AAM.

Right now we don’t have real support for saying that you run different releases on RDEs. You will be on the latest one and if you want to save your SDK in sync, you have to download it.

All right, thank you. Also, there’s a question, I’ll read it out and then go to the next question as we can combine those. Can you say something about front-end pipelines versus RDEs? And the next question is, how would you work with those if your whole front-end is sitting in a separate repo slash is deploying using FE pipelines? Maybe you can combine the answer to this. Yes, I already cherry picked that question a little bit. That was the one I cherry picked. Front-end pipeline support is planned. It hopefully will be there soon. Right now we don’t support that you send us the result of front-end pipeline build.

But the idea is that it works similar to the rest. Basically, you just will build your front-end pipeline package locally, zip it up and send it to us with the AIO command and then it will be deployed.

But right now that’s not there yet. So if you really have the separation between front-end and the front-end pipeline, you have to wait a little bit.

Thanks for your elaboration, Carl.

Next question is, we see that we have four RDEs in our program. Does that mean we can use all the four and don’t worry about the cost? I ask this because Natalia mentioned that only one RDE will be provisioned per program.

Well, perhaps I can take this one.

It is not one per program. It is one per solution that you are using in a program. So if you have, for instance, assets in the form solutions, then you can have two in a production program. So this depends. And also it depends on the credits that you have.

Perhaps you have more and you can apply all of them in the same program. I mean, there is no limitation.

Thanks, Natalia. Thanks, Natalia.

Next question, how quick are the pipeline executions for the RDE environments? I assume they are going to be different than non-prod pipelines that deploy to dev.

I guess I can take this one because it is really quick. There are no pipeline executions in RDE.

Cool. Stop. Nice. Thank you. Next question, do we need Docker for local setup dispatcher for AEM cloud? I tried to answer this already.

It depends a little bit. I mean, if you want to locally test your dispatcher, you need it. But if you just want to try it out with RDE, no. I mean, the idea is you basically zip up the dispatcher folder, which happens during the Maven build anyway, so it produces a zip and you upload that zip, as Natalia I think showed in the demo, for the weekend dispatcher zip and it will be applied in RDE. So you don’t need Docker for that.

Let me also add a comment here. In order to be able to use dispatcher via RDEs, you need to use dispatcher in flexible mode. Yes.

Thanks. Next question, in the future, will it be possible to do content backflow on the RDE environment? So is it possible to transfer content from test or prod environment to RDE environment? Yes, I believe that’s the idea. There’s a content backflow feature coming and that should also be enabled for RDEs.

Thank you.

Next question is also in the future, will it be possible to update RDE versions without losing content? We certainly have that as an item on the roadmap.

Right now, I’m not sure how quickly we will get to it, but it is a requested feature. Let me put it like this.

All right. But really, for now, it is a requested feature. It would make sense and we will look into it, I think. But the use case right now really assumes that you do some development, eventually just reset and start from scratch again if you have a new task. But I can see that it would be useful to also be able to keep the content in that step. So it is at least under consideration.

And the next question…

I’m sorry, this got scattered now.

Where was I? Okay, there we go. Can the developer set debug logging using RDE? Right now, you can change what you log the normal way. Since you can change conflicts and things like that via the AIO command by sending new conflicts, you could change the conflicts for AM. You can get to the logs via the Cloud Manager plugin, which has the possibility to stream the logs from the author of the publish. So in that sense, you could enable some debug logging. It’s not super convenient, I believe, but it should be possible. We also, and again, I cannot make any promises here, but we at least hope that we will be able to provide some improved feedback mechanisms here for the AIO plugin to, for example, make it possible to get more fine-grained debug. Log streams directly from the RDE environments. But right now, it’s basically what you get with the Cloud Manager plugin to stream the logs and what you can change with the conflicts in AM.

All right, thank you, Carl. So we’re done answering questions in the Q&A tab.

Actually, I see that… Actually, I see that…

I want to take this opportunity also to apologize for the issues we had with frozen screens you might have experienced. So this is due to this platform. I’m sorry this happened to you.

And now let’s go on with Q&A. We have two more minutes left. Will there be any possibility to do remote… Oh, we got this already.

I think.

I’m not quite sure if this got answered all the way. Will there be any possibility to do remote debugging of the AM application on RDE? Maybe this is the biggest feature priority gap in comparison to local dev. I think you answered that mostly.

Carl? Yes. I mean, right now, there’s no way to attach a debugger now.

All right.

Okay.

Another question is, what are the plugins as we need to download for RDE? I thought I answered that already in the chat box, but maybe still there. As far as I know, they mean the AIO plugins. You only really need the RDE plugin, but the Cloud Manager plugin is useful as well. So the documentation recommends to download the Cloud Manager plugin as well. But you only really need the RDE one.

All right. Thank you very much. Okay. Great. And with that, I would slowly like to complete the session. Please do fill out our ending poll. We appreciate your feedback and it will help to improve our future sessions. Also to include topics you are interested in and also regarding the RDE in general. So please do complete this ending poll. Also check out the Adobe Summit happening in Las Vegas on March 21st through 23rd. And with that, I would like to thank you all for your attention and for your interest. And have a nice day or evening. Thank you and bye-bye.

Thank you. Bye.