Use Pipeline with Different Branch | Community
Skip to main content
herohell
herohell
November 6, 2025
Solved

Use Pipeline with Different Branch

  • November 6, 2025
  • 4 replies
  • 238 views

Hello Everyone,

 

I am trying to integrate the Adobe Cloud Manager APIs with external Pipeline Platform. The idea is that I have some restrictions and governance I need to do this externally and from there instruct the Adobe CI/CD to manage the pipeline like starting it, stoping, and so on.

 

One of my requirements is that I need to define the pipeline as normal and then use this pipeline with different branches. Let's say we have a non-production pipeline with type CodeQuality. Developer A needs to run the pipeline from hist feature branch X and Developer B needs as well to run in-parallel the pipeline from feature branch Y. How can I achieve this dynamically using the Cloud Manager APIs?. I thought that I can do a PATCH for the pipeline to change the branch as needed but then I realized that this will not be right solution due to race conditions between parallel pipelines.

 

I would like to hear from you more.

 

Thanks.

Best answer by BrianKasingli

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.

4 replies

tatvam
tatvam
Level 2
November 6, 2025

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

    BrianKasingli
    Community Advisor and Adobe Champion
    BrianKasingliCommunity Advisor and Adobe ChampionAccepted solution
    Community Advisor and Adobe Champion
    November 7, 2025

    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.

      giuseppebaglio
      giuseppebaglio
      Level 10
      November 7, 2025

      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

       

       

       
        M
        manikandan90
        Level 2
        November 10, 2025

        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 

          Terms & ConditionsAccessibility statement

          Loading footer...