Bluebricks Git Repository Guide

This document outlines Bluebricks' best practices for using Git repositories as the primary driver for infrastructure modifications.

Since workflows vary between teams and serve different goals, the recommended Bluebricks workflow emphasizes key capabilities needed to manage infrastructure at scale, including:

• Version Control & Change Management – Ensuring traceability and rollback capabilities.

• Collaboration & Review Processes – Leveraging Git-based approvals for controlled deployments.

• Automation & CI/CD Integration – Enforcing consistency through automated pipelines.

• Security & Compliance – Embedding policies and audits within infrastructure changes.

Core Principles

Bluebricks Git best practices follow three core principles:

1. Separation of Concerns – Maintain distinct directories for business logic ("Blueprints"), reusable components ("Artifacts"), and designed ("live") configurations.

2. Industry Standards – Use declarative file formats to simplify infrastructure management while ensuring Git as the source of truth and GitOps compatibility.

Separation of Concerns

Bluebricks emphasizes Separation of Concerns (SoC) in infrastructure development, enabling independent development of each distinct part of the code while ensuring unified execution. This approach enhances flexibility, leading to advanced automation and streamlined operations.

SoC aligns with 2 out of the 5 SOLID principles (SRP and ISP), helping to prevent tight coupling and reducing the blast radius in case of errors.

By following SoC, code is easier to update and extend, workflows scale efficiently, and repetitive cloud tasks can be automated earlier in the development cycle.

This results in greater resilience, efficiency, and scalability in cloud infrastructure management.

Bluebricks Development Life Cycles

To ensure Due to Separation of Concerns (SoC), Bluebricks recommends maintaining two distinct life cycles for infrastructure code management:

1. Code Lifecycle – Manages reusable infrastructure components (e.g., Blueprints and Artifacts) sourced from any Infrastructure-as-Code (IaC) language such as Terraform, Helm, OpenTofu, CloudFormation, and more.

2. Configuration Lifecycle – Manages the values provided to Blueprints and Artifacts for a specific environment.

Preserving the two life cycles enhances scalability and reusability.

• For example, a VPC module can be reused across different environments (e.g., staging, production) without modifying other resources.

• Teams can standardize best practices across multiple deployments without duplicating code.

It also increases Security and Compliance:

• Security policies can be defined at the code level, preventing configurations from introducing vulnerabilities during deployment.

• Security and compliance scans can be performed once at the code level, ensuring a secure infrastructure while reducing the need for repetitive scans.

Lastly, it facilitates collaboration and unlocks workflow bottlenecks; In DevOps, platform engineering, and SRE teams, different groups often manage different aspects of infrastructure. SoC ensures clear boundaries, making it easier for teams to collaborate without stepping on each other’s changes.

Bricks Action

Bricks Action is a GitHub Action implementation that enforces Bluebricks' Separation of Concerns (SoC) concept for infrastructure management.

Bricks Action aligns with the discussed Code and Configuration Lifecycles and is responsible for the following actions:

Code Lifecycle

1. Updating Artifact and Blueprint versions

2. Resolving dependencies and updating versioning accordingly

3. Publishing the updated Artifact and Blueprint

Configuration Lifecycle

1. Initiate deployments over pull requests or merges

Getting Started with Bricks Action

Follow these steps to set up your Git-based workflow with Bricks Action:

1. Create Repository Folder Structure Following Bluebricks Guide

2. Configure your first Github Action Workflow using Bricks Action

3. Setup Workflow for Blueprints and Artifacts Update Automation

4. Shift-Left Blueprint Deployment using Github Workflows