Lessons
Git Setup & Branching Strategy
Understanding AEM Cloud Environments
AEM as a Cloud Service typically comes with three types of environments:
-
Rapid Development Environment (RDE)
-
Used by individual developers to push code directly from their local machines.
-
No CI/CD pipeline is involved.
-
-
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.
-
-
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:
-
Organizational Git – For development and internal validations.
-
AEM Git – For deploying to AEM environments.
Branching Strategy
Here’s how to sync both Git systems and set up branches:
-
Clone AEM Git
mainbranch to your local. -
Push this to your organizational Git’s
mainbranch.-
This initializes your org Git with AEM’s baseline code.
-
From there:
-
Create a
releasebranch and adevelopbranch in your org Git. -
Developers create feature branches from
developfor new work. -
Feature branches are merged into
developafter 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
developafter 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:
-
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. -
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
-
-
Git Remote Setup:
You can set the AEM Git as a second remote in your local or pipeline repo - 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.