RDE vs local

Hi @hpm- ,

With AEM as a Cloud Service (AEMaaCS), you have the option to leverage Remote Development Environments (RDEs) rather than local environments for your developers. Here’s an overview of the pros and cons of using RDEs compared to local environments, which should help you make a well-informed decision for your scrum team.

Pros of Using RDE in AEMaaCS

1. Consistent Cloud Alignment: RDEs are specifically configured to mirror the cloud setup, which ensures that the development environment is fully consistent with the production environment on AEMaaCS. This eliminates discrepancies in configuration or code deployment that might arise from local setups.

2. Simplified Maintenance: RDEs remove the need for local environment configuration and dependency management. Each developer works on the same cloud-based instance, meaning updates, environment configurations, and versioning are managed centrally, reducing local troubleshooting and setup time.

3. Team Collaboration: RDEs enable real-time collaboration. Multiple developers can work on the same environment simultaneously, seeing each other's changes and ensuring code sync across the team without needing to push updates to a version control system and then pull those changes locally.

4. Scalability and Resources: In cloud development environments, scaling resources on demand is easier. This is especially beneficial when running high-resource operations that might be limited on local machines, like batch content processing or heavy integration testing.

5. Reduced Local Machine Dependencies: Using RDEs reduces dependency on specific machine capabilities, OS configurations, or storage limitations, which is helpful for teams with varied hardware setups.

6. Version Control and Traceability: Cloud environments support better traceability in terms of environment versions, allowing rollbacks and creating a unified development history that’s accessible to everyone on the team.

Cons of Using RDE

1. Latency and Network Dependency: Cloud-based development can sometimes introduce latency, especially if team members are geographically distributed or have variable network speeds. This can make local testing and iterative development feel slower compared to a local setup.

2. Potential Resource Contention: Since RDEs are shared across developers, heavy workloads from one team member could impact others, depending on how the environment is configured and managed.

3. Limited Offline Access: RDEs require a continuous internet connection, which can be a disadvantage for developers who work in areas with unstable connectivity or need to work offline.

4. Debugging Complexity: Certain types of debugging or intensive local experimentation may be more challenging in an RDE. Local environments often provide more flexibility for developers who need to test and debug code changes outside of a centralized setup.

5. Performance Variability: In some cases, tasks performed in RDE may not be as responsive as on a local machine with dedicated resources, especially for intensive development tasks or local previews.

Recommended Considerations for Your Team

• Hybrid Approach: Many teams benefit from a hybrid model, where RDEs are used for quick deployment and unit testing before actually deploying code to DEV for QA testing in an environment closely aligned with production, while developers can also use local instances for rapid development and debugging tasks.

• Resource Allocation and Permissions: Ensure that your RDE is configured to provide adequate resources to each developer, and that access permissions are in place to prevent accidental changes to shared configurations.

• Tooling for RDE: A good DevOps setup that automates deployment, environment creation, and teardown processes can make RDE usage smoother, especially if your team uses continuous integration/continuous deployment (CI/CD) systems that sync well with AEMaaCS.

Overall, RDE can indeed be a viable and efficient option for a development team, especially for a cloud-aligned product like AEMaaCS.

However, on my several projects we didn't use RDE envs, because we were good to wait development pipeline completion (30-45 mins). During the very active development phase we disabled pipeline auto-run on every commit to develop branch. When we merge several tickets at once, we executed pipeline manually. Once active development phase is over, we enabled auto-deploy on every commit to develop branch. Here you can find scripts how to update your local instances: https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/aemaacs-what-s-the-best-way-to-upgrade-local-sdk-version/m-p/701948#M173805

So, we had the following setup:

• Local instances - for development team.
• Dev AEMaaCS instance - for Dev/QA testing
• Stage AEMaaCS instance - for Release/UAT testing
• Prod AEMaaCS instance - for Prod. 

Hi @hpm-,

my personal preference is definitely to have local developer environments. It is simpler and faster to test code locally. The only downside is that some features can be tested on a real AEMaaCS environment. But 95% of things can be done on local SDK. Also, RDEs are not free AFAIK.

Good luck,

Daniel

@hpm- If your local environment is an VDI that doesn't support Hyper V , then obviously RDE is much better as you dont have to worry about setting your dispatcher locally. Also, with local environment it is often difficult to test features that involve boundary systems.

More on RDEs - https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/developing/rapid-development-environments

@hpm- Did you find the suggestions helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!