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
main
branch to your local. -
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 adevelop
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:
-
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.