Skip to content

CI/CD Concept

The ACAI CI/CD Concept defines the architecture of ACAI’s AWS Landing Zone automation framework. It standardizes how Terraform code, configurations, and orchestration are separated across repositories to ensure scalability, compliance, and maintainability across your AWS Organization.

Repository Concept

The ACAI Repository Concept establishes a clear separation between infrastructure code, environment configuration, and deployment orchestration.
This structure promotes modularity, security, and scalability in AWS Landing Zone automation.

A full scale deployment you can see in the ACAI AWS Lab.

Core Repository Types

There are three main repository types:

  • Settings Repository
  • Feature Repository
  • Pipeline Repository

REPO_CONCEPT

Settings Repositories (Environment-Specific)

Define environment-specific parameters and serve as the single source of truth for organizational deployment configurations.

Characteristics

  • Shared across all pipeline repositories within the same environment
  • Centralized, version-controlled configuration
  • Enables change tracking and rollback

Examples

  • Sample-Repository
  • Organizational unit structure
  • Primary and secondary AWS regions
  • Security parameters
  • Service Control Policies (Guardrails)
  • Account baselining specifications

Feature Repositories (Environment-Agnostic)

Contain reusable, parameterized Terraform modules that work across environments without modification.

Characteristics

  • No hardcoded environment values
  • Configurable through variables and inputs
  • Versioned, tested, and reusable components

Examples

Pipeline Repositories (Orchestration Layer)

Orchestrate the deployment by combining Settings and Feature repositories.
These repositories define environment access, Terraform backend configuration, and deployment logic.

Characteristics

  • Defines Terraform providers and backends
  • Implements orchestration and workflow logic
  • Controls integration between settings and features

Example (Azure DevOps)

pipeline-core-{pipeline-name}/
├── azure-pipelines-templates/
│   ├── 10_terraform_preparation.yaml
│   └── 20_terraform_approval_apply.yaml
├── terraform/
│   ├── backend.tf
│   ├── context.tf
│   ├── main.tf
│   ├── providers.tf
│   └── variables.tf
└── azure-pipelines.yaml

Key Benefits

Separation of Concerns

  • Configuration isolated from implementation
  • Environment details do not pollute reusable code
  • Clear ownership boundaries
  • Separation of duties between configuration, development, and deployment teams

Security & Compliance

  • Environment data contained within settings repositories
  • Pipelines enforce environment access and approval control
  • OIDC authentication eliminates long-lived credentials
  • Least-privilege access minimizes risk

Scalability & Reusability

  • Shared feature modules across projects
  • New environments created simply by adding settings repositories
  • Modular design supports incremental rollout

Version Control & Testing

  • Independent versioning for each repository type
  • Isolated testing of feature modules
  • Validation and compliance checks for settings
  • Module version pinning ensures reproducible results

ACAI Repository Workflow

This workflow illustrates how repositories interact during an AWS Landing Zone deployment:

sequenceDiagram
    participant ACAI as ACAI<br/>(Solution Provider)
    participant FR as Feature Repo<br/>(ACAI ACF Modules)
    participant Customer as Customer Team
    participant SR as Settings Repo<br/>(Environment Config)
    participant PR as Pipeline Repo<br/>(Orchestration)
    participant PL as CI/CD Pipeline<br/>(Azure DevOps/GitHub)
    participant AWS as AWS Environment<br/>(Landing Zone)

    Note over ACAI,AWS: ACAI CI/CD Workflow

    ACAI->>FR: 1. Publish/update ACF modules (versioned releases)
    FR->>FR: 2. Validate & test modules

    Note over Customer,PR: Customer Configuration

    Customer->>SR: 3. Define environment settings (OUs, regions, policies)
    Customer->>PR: 4. Reference module versions from FR

    Note over PL,AWS: Customer Deployment Execution

    Customer->>PL: 5. Trigger pipeline
    PL->>SR: 6. Pull environment settings
    PL->>FR: 7. Pull feature modules
    PL->>PL: 8. Merge settings + features (Terraform plan)
    PL->>Customer: 9. Display plan for approval
    Customer->>PL: 10. Approve deployment
    PL->>AWS: 11. Apply infrastructure (OIDC)
    AWS->>PL: 12. Return deployment status

AWS Organization Release Concept

To ensure safe, repeatable deployments, ACAI recommends structuring AWS Organizations into multiple stages, e.g.:

  • Pre-Production → Production
  • Development → Test → Production

RELEASE_CONCEPT

Core Principles

Feature Modules

  • Environment-agnostic, single codebase for all stages
  • Parameterized via inputs; no hardcoded values
  • Versioned with semantic tags (e.g., v1.4.2) and commit SHA pinning

Settings

  • Environment-specific, versioned repositories
  • Promotion via tagged releases—not direct edits

Isolated AWS Organizations

  • Dev/Test: fast iteration and automated applies
  • Pre-Prod: production-like testing with manual approval gates
  • Prod: immutable artifact promotion and strict approvals