中文
devexamples
← Workflows

阅读中文版本

Devcontainer Parity Workflow

Define a devcontainer that matches CI tool versions, mount caches for speed, document ports and services, and verify a clean clone builds inside it.

intermediate~120 mindxcontainersonboarding

Objective

Give every developer a reproducible environment that matches CI so onboarding and "works on my machine" issues disappear.

Environment

  • A Dev Container spec and compatible editor
  • Docker for the container runtime

Steps

1. Pin tool versions in the devcontainer

Pin tool versions in the devcontainer to match CI.

Expected state: Local and CI run the same toolchain.

2. Include supporting services such as databases

Include supporting services such as databases via compose.

Expected state: Dependencies are available locally.

3. Mount caches for package managers

Mount caches for package managers to keep startup fast.

Expected state: Rebuilds are not painful.

4. Verify a clean clone builds

Verify a clean clone builds and tests inside the container.

Expected state: Parity is proven.

Decision points

One container or docker compose?

  • Compose with services
  • Single container

Compose when the app needs a database or queue; a single container otherwise.

Mount source or copy it?

  • Bind mount
  • Copy

Bind mount for fast edit loops; copy is more reproducible but slower to iterate.

Expected outcome

A devcontainer that reproduces the CI toolchain and services, verified by building and testing a clean clone inside it.

Verification

Confirm a fresh clone runs the build and test commands inside the container with the same versions CI uses.

Cleanup

Document the container usage and any host prerequisites.

Overview

Give every developer a reproducible environment that matches CI so onboarding and “works on my machine” issues disappear. Confirm a fresh clone runs the build and test commands inside the container with the same versions CI uses.

Steps

  1. Pin tool versions in the devcontainer to match CI. Expected state: Local and CI run the same toolchain.
  2. Include supporting services such as databases via compose. Expected state: Dependencies are available locally.
  3. Mount caches for package managers to keep startup fast. Expected state: Rebuilds are not painful.
  4. Verify a clean clone builds and tests inside the container. Expected state: Parity is proven.
{
  "image": "mcr.microsoft.com/devcontainers/typescript-node:22",
  "features": { "ghcr.io/devcontainers/features/docker-in-docker:2": {} },
  "postCreateCommand": "pnpm install"
}

Verification

  • A devcontainer that reproduces the CI toolchain and services, verified by building and testing a clean clone inside it.

Decision points

  • One container or docker compose? Options: Compose with services; Single container. Recommended: Compose when the app needs a database or queue; a single container otherwise.
  • Mount source or copy it? Options: Bind mount; Copy. Recommended: Bind mount for fast edit loops; copy is more reproducible but slower to iterate.