Git Setup & Branching Strategy

Understanding AEM Cloud Environments

AEM as a Cloud Service typically comes with three types of environments:

  1. Rapid Development Environment (RDE)

    • Used by individual developers to push code directly from their local machines.

    • No CI/CD pipeline is involved.

  2. Development Environments

    • Number depends on your license.

    • For example:

      • One environment for integration testing.

      • One for system integration testing (SIT).

      • Another for performance testing.

    • You can have multiple development environments based on licensing.

  3. Production + Stage (Combined)

    • A single CI/CD pipeline handles both.

    • When you define this environment, you can label one as “prod” and the other as “stage,” but they are managed under a single pipeline.

In a basic license setup, you typically get:

  • 1 Rapid Development Environment

  • 1 Development Environment

  • 1 Stage

  • 1 Production


Setting Up Git in AEM Cloud Manager

When you create a new program in AEM Cloud Manager:

  • Navigate to the Pipeline section.

  • If no pipeline is set up, you’ll see an option to Manage Git.

  • Clicking on “Manage Git” gives you:

    • AEM Git Repository URL

    • Username

    • Password

This Git repository is automatically generated by AEM Cloud. You can use the credentials to clone the repo locally and push/pull code. However, in practice, organizations usually maintain their own Git repository.


AEM Git vs. Organizational Git

Organizations prefer using their own Git repositories because:

  • CI/CD pipelines run custom automated test scripts.

  • Linting tools like SonarQube are integrated.

  • Security and unit test validations are performed before merging.

At the same time, AEM Cloud requires code to go through its pipeline. AEM validates:

  • Minimum 50% unit test coverage before deployment.

  • Other mandatory checks via its own CI/CD process.

Thus, you end up with two Git repositories:

  1. Organizational Git – For development and internal validations.

  2. AEM Git – For deploying to AEM environments.


Branching Strategy

Here’s how to sync both Git systems and set up branches:

  1. Clone AEM Git main branch to your local.

  2. Push this to your organizational Git’s main branch.

    • This initializes your org Git with AEM’s baseline code.

From there:

  • Create a release branch and a develop branch in your org Git.

  • Developers create feature branches from develop for new work.

  • Feature branches are merged into develop after pull requests (PRs).

  • You can use RDE for unit testing after merging all feature branches into develop.

Using RDE for Testing

RDE is ideal for testing merged code without interfering with the single development environment meant for SIT.

Developers:

  • Checkout their feature branch.

  • Push changes.

  • Merge to develop after review.

  • Deploy to RDE manually using AIO CLI commands.

Syncing Code from Organizational Git to AEM Git

To sync code from your organizational Git (e.g., Bitbucket, GitHub) to Adobe’s AEM Git:

  1. Use a DevOps system user account:
    Make sure to use a service/DevOps user that has push access to your AEM Git repository. This ensures stability and avoids credential rotation issues.

  2. Authenticate using HTTPS with user ID & password:
    Use the AEM Git URL with HTTPS (not SSH). When prompted for authentication, use:

    • Username: DevOps user ID

    • Password: Your Adobe Developer Console token or password set for that user

  3. Git Remote Setup:
    You can set the AEM Git as a second remote in your local or pipeline repo

  4. Automate with CI/CD (Optional):
    For enterprise setups, configure your CI/CD pipeline (e.g., Jenkins or Bitbucket Pipelines) to sync code automatically using stored credentials or secrets vault integration.