Use Pipeline with Different Branch

An approach to achieve this would be:

Developer 1 - branch X

Developer 2 - branch Y

Code Quality Pipeline

branch - code-quality

Trigger - on change

Developer 1 - merges branch X to code-quality

Developer 2 merges branch Y to code-quality

Okay. You are asking for an on-demand environment (ODE) for AEMaaCS engineers. Natively, AEMaaCS does not have ODEs. I've seen similar concerns like this before, but here's how I’ve seen AEM projects handle it successfully without needing an ODE:

1. Each developer works on their own branch locally and ensures their code passes linting, tests, and quality checks before opening a pull request (PR).

2. The PR is reviewed by a technical lead.

3. Once approved and merged into the shared `development` branch, a GitHub Action automatically triggers, which:
- Runs a sanity pipeline (your own internal checks),
- Pushes the code to AEMaaCS’s remote Git repository,
- Then triggers the Adobe Cloud Manager pipeline (usually non-prod).

This avoids any race conditions. Everyone feeds into the same stable pipeline branch (development), but only after their code has been reviewed and validated locally and by the team. It keeps things simple, clean, and CI-friendly. And from the AEMaaCS development environment, the developer can review their code on that environment; with all other configurations & features all integrated into a single environment.

Summary:
You don’t need an ODE to support parallel feature development. With a proper local workflow and a well-defined CI gatekeeping process, teams can safely and efficiently deliver into Cloud Manager from a controlled, shared branch. Also you can check out RDE (Rapid Development Environment) https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/developing/rapid-development-environments RDEs let developers swiftly deploy and review changes, minimizing the amount of time needed to test features that are proven to work in a local development environment. Once the changes have been tested in an RDE, they can be deployed to a regular Cloud Development environment through the Cloud Manager pipeline. Dev environments and Rapid Dev environments should be limited to development, error analysis, and functional tests, and are not designed to process high workloads, nor large amounts of content.

hi @herohell,

a pipeline is fundamentally configured to monitor and deploy from a single Git branch at a time. While you can edit the branch configuration via API or UI, this creates the exact concurrency issues you've identified.

IMHO, you could consider using Rapid Development Environments (RDEs). These environments are specifically designed to address the need for multiple developers to test code from different feature branches without going through the full CI/CD pipeline. Here are some key points about RDEs:

• Each RDE is typically used by a single developer at a time for testing and debugging specific features​

• Developers can deploy directly from their local environment using command-line tools without pipeline execution​

• RDEs support quick iterative testing of code that's been validated locally but needs cloud environment verification

The topic of pure parallelism among developers is not easy to solve, though. Here is the Adobe POV "Multiple developers collaborating on the same RDE":

 Official Documentation

• Rapid Development Environments Guide: RDEs for AEM as a Cloud Service​

• How to Use RDEs: RDE Deployment and Usage​

Hello @herohell, 

You're correct that using a PATCH request to change the Git branch on a single pipeline introduces race conditions. Since Cloud Manager pipelines are tied to a single branch at a time, switching branches dynamically for parallel executions can cause conflicts, especially when multiple developers trigger runs simultaneously.

Recommended strategy: Use single pipeline

• Create the non-production pipeline manually in cloud manager
• Use the Cloud Manager API to dynamically switch the branch via PATCH before triggering execution. 

To avoid race condition

• Build a queue or locking mechanism in your external CI/CD platform like Jenkins. 
• Ensure only one branch update and execution happens a a time.
• Wait for the pipeline execution to complete before switching to the next branch.

with the above approach, it limits the parallel execution. If the parallel execution is critical, merge the feature branch into fixed temporary branchs and run the shared pipeline