Modular Monolith CI/CD: Fast Builds & Test Pipelines

Answer-First: Large monoliths avoid slow CI/CD pipelines by implementing monorepo path-filtering, Go build caching, and selective test execution based on git diffs. Deploying a single-binary modular monolith enables atomic deployments where application code and schema migrations ship deterministically in a single commit release.

Pillar Architecture Guide: This article is part of the Architecting 21-Service E-commerce with Golang & DDD series and Composable E-Commerce Migration guide. Please refer to the original article for a detailed overview of the architecture.

Prerequisite: Before reading this part, please review Part 3: DDD Module Boundaries.

What You’ll Learn That AI Won’t Tell You:

• Go Build Tags & Bazel Caching: How to isolate integration tests and share Go compilation objects across CI runners.
• Sub-3-Minute CI Blueprint: How git diff path filtering and worker pools compress test pipeline execution times.
• Internal Interface Contract Testing: How to verify cross-module Go interfaces without external network mocks.
• Automated Kamal 2 / ECS Deployments: How single-container releases execute atomic database migrations safely before traffic cutover.

One of the biggest drivers pushing teams toward Microservices is the promise of “Independent Deployment.” In theory, team A can deploy service A without caring about team B. But reality is often much crueler: The existence of “Dependency Hell.”

If Service A changes its API payload, Service B is forced to update accordingly. The organization must design complex pipelines, use API contracts, and coordinate release schedules to avoid bringing down the system. Actual velocity doesn’t increase; it is bottlenecked by synchronization costs.

Conversely, the Modular Monolith uses the Atomic Deployments model, providing a much safer, cheaper, and more reliable Release management approach.

The sequence diagram below illustrates the atomic CI/CD pipeline execution flow, from git diff path filtering and cached compilation to container artifact generation:

sequenceDiagram
    autonumber
    participant Dev as Developer Pull Request
    participant Filter as Git Diff Path Filter
    participant GoBuild as Go Build Cache & Test Runner
    participant Deploy as Atomic Deployment Pipeline
    
    Dev->>Filter: Push Commit Hash (Git Diff)
    Filter->>GoBuild: Trigger Selective Test Suites (internal/billing)
    GoBuild->>GoBuild: Compile with $GOCACHE in parallel
    GoBuild-->>Deploy: Pass All Verification Checks
    Deploy->>Deploy: Atomic Single-Binary Container Push

1. What Are Atomic Deployments?

Answer-first: Atomic deployments release the entire application binary and database schema migrations in a single commit hash, eliminating cross-service API version mismatches and complex multi-repo rollback states.

Atomic Deployment means the application is released as a single block, at a single point in time. In a Modular Monolith, the application logic code and database structure definitions (Database Schema/Migrations) travel together in a single Commit Hash. When you deploy a new version, all modules are updated simultaneously.

• You never encounter the error: “Service A’s API version does not match Service B’s.”
• You don’t have to manage complex rollback scenarios: What happens if Service A deploys successfully but Service B fails and has to Rollback? In a Monolith, either everyone moves forward together, or everyone rolls back together. The system state is always consistent.

In addition, atomic deployments simplify zero-downtime rolling updates on Kubernetes. Because a single container image encapsulates the entire server logic, Kubernetes deployment controllers update pods deterministically without maintaining complex cross-service dependency graphs or version compatibility matrices.

2. Monorepo Build Isolation & Keeping CI Builds Under 3 Minutes

Answer-first: Monolith CI builds achieve sub-3-minute execution by isolating test execution via Go build tags (//go:build integration), leveraging Bazel / Go $GOCACHE object layers, and mapping AST package dependency graphs to run tests strictly for modified domain directories.

Monorepo build times degrade exponentially if left unmanaged. A test suite taking 3 minutes for 5 developers ballooning to 45 minutes for 50 developers destroys developer feedback loops and causes PR queue congestion.

A. Go Build Tags & Test Suite Isolation

To prevent heavy database or network integration tests from slowing down rapid unit test feedback, we isolate test suites using Go build tags:

//go:build integration

package billing_test

import "testing"

func TestBillingDatabaseMigration_Integration(t *testing.T) {
	// Heavy integration test logic requiring live PostgreSQL instance
}

Running go test ./... executes only fast unit tests in seconds. Integration suites run conditionally when the -tags=integration flag is explicitly passed by CI runners.

B. Bazel AST Dependency Graphing & Content Caching

For massive monorepos, build tools like Bazel (with rules_go) map the Abstract Syntax Tree (AST) import graph into a directed acyclic graph (DAG):

$$\text{Affected Packages} = \text{TargetPackage} \cup \text{TransitiveDependents}(\text{TargetPackage})$$

Bazel stores compiled package outputs in content-addressable remote caches. If internal/inventory code has not changed and its dependencies are unchanged, Bazel instantly retrieves pre-built test binaries from cache, skipping re-compilation entirely.

C. The 4-Pillar Blueprint for Sub-3-Minute CI Pipelines

1. Path-Filter Triggers: Use Git diffs (git diff origin/main...HEAD) to execute tests only for packages modified in the pull request.
2. Persistent Compiler Caching: Mount Go $GOCACHE and $GOPATH/pkg/mod persistent volume layers across CI runner invocations.
3. Parallel Test Matrix: Divide independent module package suites across parallel worker jobs using sync.WaitGroup runners.
4. Dependency Pre-Fetching: Warm CI base runner images with pre-downloaded Go module dependencies.

3. Internal Module Interface Contract Testing & Shopify Lessons

Answer-first: Internal contract testing validates Go interface compliance between modules at compile-time and runtime without external network mocks, while automated merge queues maintain main branch stability under high engineering throughput.

Internal Module Contract Testing

In a microservice architecture, contract testing requires external tooling like Pact. In a Modular Monolith, internal interface contract testing is performed via Go compile-time type assertions and table-driven unit suites:

package billing_test

// Compile-time interface compliance assertion
var _ billing.Service = (*billing.ModuleImpl)(nil)

func TestBillingModule_ContractInvariants(t *testing.T) {
	// Verify internal API contract behavior without network overhead
}

Shopify CI Optimization Lessons (Buildkite & Merge Queues)

Shopify maintains developer velocity across thousands of engineers using three primary mechanisms:

1. Selective Testing via Packwerk: Calculates affected internal packs and runs unit tests strictly for modified packages.
2. Parallel Buildkite Node Pools: Distributes test batches dynamically to ensure worker node runs finish under 90 seconds.
3. Automated Merge Queues: Batches approved PRs into speculative integration commits, preventing main branch race conditions.

4. Go Parallel Test Execution & Pipeline Automation Script

Answer-first: A production Go test automation script uses goroutine worker pools and exec.CommandContext deadlines to execute selective package test suites concurrently, maintaining rapid CI feedback loops.

The following Go automation script demonstrates concurrent package testing across internal domain directories using sync.WaitGroup worker pools:

package main

import (
	"context"
	"fmt"
	"os/exec"
	"path/filepath"
	"sync"
	"time"
)

type TestTask struct {
	PackagePath string
	Module      string
}

type TestResult struct {
	PackagePath string
	Duration    time.Duration
	Err         error
}

// RunSelectiveTests parallelizes Go module testing based on git diff targets
func RunSelectiveTests(ctx context.Context, modules []string) ([]TestResult, time.Duration) {
	start := time.Now()
	tasks := make(chan TestTask, len(modules))
	results := make(chan TestResult, len(modules))

	var wg sync.WaitGroup
	workers := 4 // Concurrency level

	for w := 0; w < workers; w++ {
		wg.Add(1)
		go func(workerID int) {
			defer wg.Done()
			for task := range tasks {
				t0 := time.Now()
				cmd := exec.CommandContext(ctx, "go", "test", "-v", task.PackagePath)
				out, err := cmd.CombinedOutput()
				_ = out // Suppress unused output variable

				results <- TestResult{
					PackagePath: task.PackagePath,
					Duration:    time.Since(t0),
					Err:         err,
				}
			}
		}(w)
	}

	for _, mod := range modules {
		pkgPath := filepath.Join("./internal", mod, "...")
		tasks <- TestTask{PackagePath: pkgPath, Module: mod}
	}
	close(tasks)

	wg.Wait()
	close(results)

	var resList []TestResult
	for res := range results {
		resList = append(resList, res)
	}

	return resList, time.Since(start)
}

func main() {
	ctx, cancel := context.WithTimeout(context.Background(), 2*time.Minute)
	defer cancel()

	changedModules := []string{"billing", "orders"}
	fmt.Println("Running selective Go test suite for modified modules...")

	results, elapsed := RunSelectiveTests(ctx, changedModules)
	fmt.Printf("Completed test execution in %v across %d packages\n", elapsed, len(results))

	for _, r := range results {
		if r.Err != nil {
			fmt.Printf("FAIL: %s (%v)\n", r.PackagePath, r.Duration)
		} else {
			fmt.Printf("PASS: %s (%v)\n", r.PackagePath, r.Duration)
		}
	}
}

5. Optimized GitHub Actions Pipeline for Selective Module Testing

Answer-first: GitHub Actions workflows combine path-filtering triggers (dorny/paths-filter) with persistent Go $GOCACHE layers (actions/setup-go), running module tests conditionally and cutting pipeline execution times to under 10 seconds.

Running tests across a massive monolith on every commit wastes compute time. The configuration below demonstrates a full production GitHub Actions pipeline that uses Git diffs to detect changed module directories and leverages Go $GOCACHE layer caching:

name: Monolith Selective CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  detect-changes:
    runs-on: ubuntu-latest
    outputs:
      modules: ${{ steps.filter.outputs.changes }}
    steps:
      - uses: actions/checkout@v4
      - uses: dorny/paths-filter@v3
        id: filter
        with:
          filters: |
            billing: 'internal/billing/**'
            inventory: 'internal/inventory/**'
            orders: 'internal/orders/**'

  test:
    needs: detect-changes
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: '1.22'
          cache: true

      - name: Test Billing Module
        if: ${{ needs.detect-changes.outputs.modules == 'true' && contains(needs.detect-changes.outputs.modules, 'billing') }}
        run: go test -v -race ./internal/billing/...

      - name: Test Inventory Module
        if: ${{ needs.detect-changes.outputs.modules == 'true' && contains(needs.detect-changes.outputs.modules, 'inventory') }}
        run: go test -v -race ./internal/inventory/...

      - name: Test Orders Module
        if: ${{ needs.detect-changes.outputs.modules == 'true' && contains(needs.detect-changes.outputs.modules, 'orders') }}
        run: go test -v -race ./internal/orders/...

Build Caching Strategy in Production Pipelines

To maximize speed, we leverage Go’s compilation cache. The actions/setup-go action caches the $GOCACHE directory, ensuring third-party dependencies are compiled only once, reducing test run times from minutes to under 10 seconds.

Single Container Automated Deployment Pipeline (Kamal 2 / ECS)

Deploying a single compiled container binary simplifies release pipelines by unifying database migrations and service updates into an atomic deployment step. The Kamal 2 pipeline configuration below executes isolated pre-deploy migration hooks before rolling out the application image.

# Kamal 2 deploy.yml configuration snippet for single-binary container
service: my-modular-monolith
image: registry.example.com/my-modular-monolith

servers:
  web:
    - 192.168.1.10
    - 192.168.1.11

# Pre-deploy hooks execute database schema migrations automatically
hooks:
  pre-deploy: |
    docker run --rm --net=host registry.example.com/my-modular-monolith:latest ./migrate -path ./db/migrations up

For observability in single-process monoliths, check out Part 5: Observability in Memory.

Frequently Asked Questions (FAQ)

Answer-first: This FAQ addresses key questions on atomic deployment benefits, selective test execution via Git diffs, Go $GOCACHE acceleration, and merge queue strategies.

Navigation & Next Steps

Answer-first: Proceed to Part 5 for in-memory observability or examine related guides on load balancing, API gateways, and zero-downtime Kubernetes deployments.

• Previous Part: Part 3: DDD Module Boundaries
• Next Part: Continue to Part 5: Observability in Memory
• Related Guides: Modular Monolith Architecture and Zero Downtime K8s Deployments

Need help optimizing your CI/CD pipelines for a modular monolith? Get in touch or hire our DevOps & platform engineers for pipeline acceleration consulting.