CI/CD Strategies

Continuous Integration and Continuous Deployment (CI/CD) for micro frontends must support independent pipelines while enabling efficient builds and thorough testing. This page covers per-application pipelines, monorepo CI strategies, pipeline stages, testing approaches, and how to handle shared infrastructure and dependency updates.

Per-Application CI/CD Pipelines

Each micro frontend should have its own pipeline. When a team pushes changes to their micro frontend, only that pipeline runs. Other teams’ pipelines are unaffected. This supports independent deployments and keeps feedback loops fast.

Pipeline Triggers

Pipelines run when:

Code is pushed to the main branch (or release branch)
A pull request is opened or updated
A tag is pushed (for release workflows)

Path-based triggers are essential in monorepos: only trigger the checkout pipeline when files under packages/checkout/ change. This avoids unnecessary builds and keeps pipelines fast.

Pipeline Outputs

Each pipeline produces:

Build artifacts — Bundled JavaScript, CSS, and any static assets
Test results — Unit tests, integration tests, coverage reports
Deployable package — Ready for CDN upload or container build

Artifacts are versioned (e.g., with git SHA or semantic version) so deployments are reproducible.

Monorepo CI Strategies

Many organizations use a monorepo for micro frontends. The challenge: when one micro frontend changes, you should not rebuild everything. Affected-based builds solve this.

Affected-Based Builds (Only Build What Changed)

Tools like Nx, Turborepo, and Lerna compute the dependency graph and determine which packages are affected by a given change. If only packages/search/ changed, only the search pipeline runs. If a shared library changed, all dependents run.

Benefits:

Faster CI — No redundant builds
Clear ownership — Each team’s changes trigger only their pipeline
Dependency awareness — Shared code changes propagate correctly

Implementation:

# Example: Nx affected commands
nx affected:build --base=main
nx affected:test --base=main

The --base parameter identifies the comparison point (e.g., the branch point or last successful main build).

Caching

Cache build outputs and dependencies. If inputs have not changed, restore from cache instead of rebuilding. Modern CI systems (GitHub Actions, GitLab CI, etc.) support caching. Monorepo tools often include built-in caching.

Pipeline Stages for Micro Frontends

A typical pipeline has these stages:

1. Lint, Test, Build per MF

Lint — ESLint, Prettier, type checking (TypeScript)
Unit tests — Jest, Vitest, etc. Run in parallel when possible
Build — Produce production bundles. Fail if build fails.

These stages run within the boundaries of a single micro frontend. No cross-MF coordination yet.

2. Integration Testing

After individual builds succeed, run integration tests:

Contract tests — Verify that micro frontend interfaces (props, events, APIs) match between producers and consumers. See versioning for contract testing details.
Visual regression — Capture screenshots of the composed application. Compare against baselines. Detect unintended UI changes.
E2E tests — Run end-to-end tests against the full composed application. Use sparingly—they are slow and brittle—but they catch integration issues.

3. Deployment Automation

Deploy to staging first
Run smoke tests
Deploy to production (manual approval or automated)
Invalidate caches, update version manifests, notify monitoring

Testing Strategies in CI

Unit Tests Within Each MF

Each micro frontend has its own unit tests. They run in isolation and validate component logic, utilities, and business rules. Fast and numerous—these are the first line of defense.

Contract Testing Between MFs

Micro frontends expose interfaces to each other. Contract testing ensures:

Producers publish a contract (e.g., Pact, OpenAPI)
Consumers verify they can use that contract
CI runs contract tests when either producer or consumer changes

If a producer changes its interface without updating the contract, consumer tests fail. Prevents integration breakage at deployment time.

Integration Testing at the Shell Level

The shell loads and composes micro frontends. Integration tests verify:

The shell can load each micro frontend
Routing works across boundaries
Shared state (e.g., authentication) propagates correctly
No JavaScript errors during composition

These tests run against a built, composed application—either in a test environment or a container.

Visual Regression Testing

Tools like Percy, Chromatic, or Playwright screenshots capture the UI. On each change, compare against baseline images. Flag visual diffs for review. Catches layout bugs, CSS regressions, and unintended style changes.

Visual regression is expensive (storage, computation). Use it for critical flows or sample pages rather than exhaustive coverage.

E2E Testing Across the Composed Application

Full end-to-end tests (Cypress, Playwright) exercise user journeys across multiple micro frontends. They validate the complete system but are slow and require a running environment. Run them on a subset of changes—e.g., main branch or before production deploy—rather than on every PR.

Shared CI Infrastructure

Reusable Pipeline Templates

Define pipeline templates once; each micro frontend uses them with minimal configuration. Example:

# Shared template
micro-frontend-pipeline:
  stages: [lint, test, build, deploy]
  variables:
    BUILD_OUTPUT: dist/

# Per-MF usage
checkout:
  extends: micro-frontend-pipeline
  variables:
    PACKAGE: checkout

Reduces duplication and ensures consistency across pipelines.

Shared Dependency Updates

When a shared dependency (e.g., design system, utility library) is updated, all consuming micro frontends may need to be rebuilt and tested. Strategies:

Automated dependency updates — Dependabot, Renovate create PRs. CI runs on those PRs. Teams review and merge.
Batch update workflow — Periodically update all dependents. Run full integration test suite. Fix any breakages.
Version pinning — Pin to specific versions until you are ready to upgrade. Upgrade in a coordinated window.

Summary

CI/CD for micro frontends requires:

Per-application pipelines so each team deploys independently
Affected-based builds in monorepos to avoid redundant work
Pipeline stages: lint → test → build → integration test → deploy
Testing layers: unit, contract, integration, visual regression, E2E
Shared templates for consistency
Planned handling of shared dependency updates

For deployment patterns and rollout strategies, see independent deployments. For version management and contract compatibility, see versioning.

Go Deeper in the Book

This topic is covered in depth in Chapter 8 of Micro Frontends Architecture for Scalable Applications, with detailed examples, diagrams, and production-ready patterns.