Could anyone please explain the technical differences between locally installed AEM Cloud SDK and the AEM Rapid Development Environment
Thank you,
Kashif
Solved! Go to Solution.
Views
Replies
Total Likes
As such its difficult to point out the differences between the two. Some of the functionalities working on local sdk might not work on RDE.
So its better to follow AEM Cloud Development guidelines. Few of the things that I have seen :
1) Processing Profile : This can also be set up on local sdk but by default its not present.
2) System user : You can create system user through crx/explorer and map to user mapper in local sdk where as for RDE this isnt available you need to use repo init script.
3) Custom namespace : This can be done through crx/explorer in local sdk but need config changes for RDE.
So its better to test out changes in RDE before deploying to Dev and higher environment.
Hi, you can find here good resources explaining in detail the differences:
Hope this helps
Esteban,
Thank you for your response. I wanted to know the differences between Cloud SDK that is installed by developers on their local machines vs the RDE.
Appreciate anyone listing the differences between AEM Cloud SDK and the RDE.
thank you,
Kashif
By investing time in watching the video, you can independently grasp the distinctions instead of relying on my recollections off the top of my head
Esteban,
I have watched these two before posting the question. Wanted to know any in depth answer from the community which is not captured in the documentation.
Thank you,
Kashif
AEM Cloud SDK is local jar file which can be used for local development but it doesn't come up with all the capabilities of cloud so some of the functionalities may differ when you deploy to dev, stage or prod. Example Processing profiles are not available in local sdk
Where as RDE (Rapid Development Environment) 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. It is like a sandbox environment similar to dev but here you don't need to worry about code quality or test coverage issues. You can use command line tools to deploy code.
Use Adobe/aio-cli tool to deploy code from your local to RDE environment.
So in short if you have a RDE environment configured you can deploy your code before commit to test it out.
Varun,
Appreciate the answer. You mentioned processing profiles are not available in the Cloud SDK. That's what I want to know more about. The features differences between these two.
Thank you,
Kashif
As such its difficult to point out the differences between the two. Some of the functionalities working on local sdk might not work on RDE.
So its better to follow AEM Cloud Development guidelines. Few of the things that I have seen :
1) Processing Profile : This can also be set up on local sdk but by default its not present.
2) System user : You can create system user through crx/explorer and map to user mapper in local sdk where as for RDE this isnt available you need to use repo init script.
3) Custom namespace : This can be done through crx/explorer in local sdk but need config changes for RDE.
So its better to test out changes in RDE before deploying to Dev and higher environment.
Features wise local SDK and RDE may or may not be the same, RDE is to deploy changes as quickly as possible and review in cloud environment which were proved to work on local SDK ( only if both the aem versions are same). RDEs are mostly set to the latest available AEM version which may be the case for your DEV/STAGE and PROD environment.
For RDE dev need to setup node and npm for Adobe I/O and plugins but for local SDK that is not needed.
RDE is bind to a program but local SDK is program agnostic and completely available at local as per AEM version.
Once RDE command line tools are setup dev can sync up code, content package, bundle or any specific OSGI config, dispatcher/apache config etc.
In RDE you get a cloud-like environment but need not to use CM pipeline to follow all the CM build steps and deployment time which vary from 30 mins to 3-4 hours (depends on code, repo and index size).
Regards