AEM - Content as Code | Community
Skip to main content
C
contentguy
Level 1
March 31, 2026
Solved

AEM - Content as Code

  • March 31, 2026
  • 3 replies
  • 73 views

Are there recommendations/best practices to manage content as code.

One of the team I work with mentioned this as their problem statement “Our code gets deployed through Cloud Manager but our QA cannot test anything yet nor can automated regression tests be triggered through Continuous Test Pipelines because they have to wait until content is authored.”

The human element in the process feels like a huge bottle neck in the process as it is hindering immediate feedback loop.

I am trying to understand what strategies other enterprises who use AEM have implemented in their SDLC process.

For example in a sprint, if the code and content are planned to be delivered together, cant the content creators(BA/Business) be ready with the content that go in with the fragments that get deployed as part of code 

Best answer by AmitVishwakarma

Hi ​@contentguy 

You're basically describing the classic "content as code" gap in AEM: code is fully automated through Cloud Manager, but content depends on manual authoring, so QA and regression pipelines block.

A few patterns most enterprises use to fix this:

1. Treat seed/test content as code

Create a dedicated Maven module (often ui.content or ui.tests-content) that contains:

  • Representative pages, templates and policies
  • Sample Content Fragments / Experience Fragments
  • Test users, tags, configurations needed by automated tests

This module lives in Git and is deployed via Cloud Manager to dev/QA with every build, so:

  • QA + automated pipelines always have known content immediately after deploy
  • Tests don't depend on authors finishing their work

On prod, you usually either don't deploy this module, or deploy only a safe subset.

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/developing/aem-project-content-package-structure

 

2. Separate immutable code and mutable runtime content

Model things roughly like this:

  • Code / definitions as code
    • Components, dialogs, Sling Models, OSGi configs (/apps)
    • Content Fragment Models, templates, policies, configs (/conf)
  • Runtime content authored by business
    • Pages, CF instances, XF instances, assets (/content, /content/dam)

Best practice is:

  • Keep models and structure in Git so they are part of the build.
  • For testing, also create "reference" CF/XF instances in the content module.
  • Let authors create business variants from those reference items, without breaking tests.

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/deploying/overview

3. Make automated tests depend only on versioned content

For regression / CI:

4. Use Content Copy for realistic data (not for tests)

When you need realistic scenarios (e.g., prod-like data in QA), use Cloud Manager's Content Copy:

5. Adjust sprint planning for content

Process-wise, teams that do this well usually:

  • Design content models and sample content one sprint ahead of implementation.
  • Expect every feature to ship with "ready for automation" content in Git.
  • Let business authors refine that content later, instead of blocking pipelines on it.

That's the essence: ship testable content in Git with the code, and treat real authored content as a separate, mutable layer. This removes the human bottleneck from pipelines while still keeping authors in control of the actual experience.

3 replies

rk_pandian
rk_pandian
Level 4
March 31, 2026

Hello ​@contentguy! Please see my response below:

  1. You can have limited content as code (maybe until folder level) but not everything, because that alone defeats the purpose of codebase
  2. Some companies have content authoring team who does the authoring once deployment is done
  3. If you dont have a specific authoring team but have CRX access in lower servers, you can install basic content packages for QA from your local. The same can be synced to higher servers via automation - package installation would be the easiest one.
  4. Other way is, you can ship your components with content during deployment. This can be done via _cq_template.xml or default properties for dialog values. Again it is recommended to have only limited content here. Ex: 1 out of 5 cards can be shipped via default values.
  5. For fragments - if the fragments data can be authored in a structured way and placed in a file / cloud location, then you can write a utility to read it, parse it and create fragments. This is very similar to product importers. This can be automated as well (via jobs with CRON or via workflows etc)

Hope this helps!

 

Regards,

Ramkumar

VishalKa5
VishalKa5
Level 6
April 1, 2026

Hi ​@contentguy ,
 

AEM – Content as Code

  • Treat content like code
    Store structured content (like fragments) in Git and manage versions, so it can be tracked and deployed like application code.
  • Use Content/Experience Fragments
    Create reusable and structured content blocks, which reduce dependency on page-level authoring.
  • Deploy content with code
    Use content packages in Cloud Manager pipelines to ensure content is available immediately after deployment.
  • Avoid manual authoring dependency
    Pre-create required pages and content so QA doesn’t have to wait for authors after deployment.
  • Automate content creation
    Use scripts, APIs, or tools to generate test content automatically and save manual effort.
  • Work in parallel
    Content teams (BA/Business) should prepare content during the sprint alongside development, not after it.
  • Use mock/sample content
    Provide dummy or placeholder content to enable early testing before final content is ready.
  • Enable continuous testing
    Include content and test data setup in pipelines so automated tests can run immediately.

    Thanks
AmitVishwakarma
Community Advisor
AmitVishwakarmaCommunity AdvisorAccepted solution
Community Advisor
April 1, 2026

Hi ​@contentguy 

You're basically describing the classic "content as code" gap in AEM: code is fully automated through Cloud Manager, but content depends on manual authoring, so QA and regression pipelines block.

A few patterns most enterprises use to fix this:

1. Treat seed/test content as code

Create a dedicated Maven module (often ui.content or ui.tests-content) that contains:

  • Representative pages, templates and policies
  • Sample Content Fragments / Experience Fragments
  • Test users, tags, configurations needed by automated tests

This module lives in Git and is deployed via Cloud Manager to dev/QA with every build, so:

  • QA + automated pipelines always have known content immediately after deploy
  • Tests don't depend on authors finishing their work

On prod, you usually either don't deploy this module, or deploy only a safe subset.

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/developing/aem-project-content-package-structure

 

2. Separate immutable code and mutable runtime content

Model things roughly like this:

  • Code / definitions as code
    • Components, dialogs, Sling Models, OSGi configs (/apps)
    • Content Fragment Models, templates, policies, configs (/conf)
  • Runtime content authored by business
    • Pages, CF instances, XF instances, assets (/content, /content/dam)

Best practice is:

  • Keep models and structure in Git so they are part of the build.
  • For testing, also create "reference" CF/XF instances in the content module.
  • Let authors create business variants from those reference items, without breaking tests.

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/deploying/overview

3. Make automated tests depend only on versioned content

For regression / CI:

4. Use Content Copy for realistic data (not for tests)

When you need realistic scenarios (e.g., prod-like data in QA), use Cloud Manager's Content Copy:

5. Adjust sprint planning for content

Process-wise, teams that do this well usually:

  • Design content models and sample content one sprint ahead of implementation.
  • Expect every feature to ship with "ready for automation" content in Git.
  • Let business authors refine that content later, instead of blocking pipelines on it.

That's the essence: ship testable content in Git with the code, and treat real authored content as a separate, mutable layer. This removes the human bottleneck from pipelines while still keeping authors in control of the actual experience.

Amit Vishwakarma - Adobe Commerce Champion 2025 | 16x Adobe certified | 4x Adobe SME
    Terms & ConditionsAccessibility statement

    Loading footer...