Developer Workflows, Dev Containers, Inner Loop Optimization, Compose-Based Labs, and Local Parity: Concepts, Architecture, and Mental Model

1. The practical problem: fast development can still hide state

A containerized developer workflow can remove “install this exact compiler and database on every laptop” from onboarding, but it can also move hidden state into bind mounts, Desktop file sharing, anonymous tool downloads, editor extensions, named volumes, forwarded ports, and implicit credentials. The goal is not to hide those boundaries. The goal is to make them explicit, versioned, inspectable, and disposable.

Chapter 36 made the release artifact immutable. Chapter 37 applies the same discipline to the inner loop: record the source revision, define the developer environment, keep caches and secrets separate from source, and still build production through its own controlled target.

2. Mental model: development is a dataflow, not just a container

flowchart TD
  A[Source workspace + exact revision] --> B[Dev Container / Compose definition]
  B --> C[Developer container + supporting services]
  A --> D[Bind mount or Compose Watch sync]
  D --> C
  C --> E[Tests, tools, hot reload]
  C --> F[Named cache / generated state]
  E --> G[Evidence: versions, UID/GID, ports, test results]
  A --> H[Production Dockerfile target]
  H --> I[Immutable production image]
  G --> J[Parity-gap record]
  I --> J
            

The source workspace is the human-edited truth. A Dev Container or Compose definition describes how tools/services are created. A bind mount or Watch rule determines how edits cross the host/container boundary. Tests and tools run in the developer container, while caches and generated files need an intentional home. Production is a separate build boundary: it consumes reviewed source and build inputs rather than inheriting a long-lived developer container filesystem.

3. State domains to record before changing anything

4. Dev Container Spec versus Compose

The Development Container Specification is development metadata. It can reference an image, Dockerfile, or Compose service and add concepts such as a workspace folder, remoteUser, tool/editor customizations, lifecycle hooks, Features, and forwarded ports. Compose describes container services, networks, volumes, builds, health, and development Watch rules. They can complement each other: Compose can own the multi-service runtime while devcontainer.json tells compatible development tools which service is the interactive workspace.

5. Bind mount versus Watch/sync

6. Why non-root still matters in development

A development container that runs every tool as root often leaves root-owned artifacts on native Linux bind mounts and grants unnecessary authority inside the container. Prefer an explicit non-root user whose writable directories are known. On native Linux, numeric UID/GID alignment can improve bind-mounted ownership. Docker Desktop inserts a VM/file-sharing layer, so do not assume host numeric ownership behaves exactly like native Linux.

7. Caches are performance state, not source state

Dependency caches can make the inner loop dramatically faster, but they should not be committed to source or mistaken for reproducible build evidence. Put package-manager caches in a named volume or explicit cache directory, scope them to the project/toolchain, and be able to delete only that cache when diagnosing corruption. Databases also generally belong in named volumes rather than large Desktop bind mounts.

8. Ports: published runtime port versus development forwarding

A Compose ports entry publishes a host socket through Docker networking. A Dev Container forwardPorts request is metadata interpreted by a supporting development tool and can behave differently across implementations. Record which mechanism exposes the service, the bound interface, and who can reach it. Development convenience must not silently become production exposure policy.

9. Features and tool versions are supply-chain inputs

Dev Container Features are convenient reusable installation units, but they are still external code and artifacts. Use reviewed publishers, constrain versions, retain the generated lockfile where supported, and update deliberately. “Feature major version 2” is a human-friendly request; the resolved digest in a lockfile is stronger evidence of what was actually installed.

10. Production parity means controlled differences

11. Read-only preflight

docker context show
docker version
docker compose version
docker buildx version
docker info --format 'os={{.OperatingSystem}} driver={{.Driver}} cgroup={{.CgroupVersion}}'
git rev-parse HEAD 2>/dev/null || true
git status --short 2>/dev/null || true
docker compose config 2>/dev/null || true

Run inspection against the intended project only. Do not clean images, volumes, or caches because an onboarding check looks unfamiliar.

12. Chapter evidence contract

For every lab, retain the source revision, Compose/devcontainer definitions, resolved base-image identity when practical, container user, workspace mount/sync mechanism, tool versions, cache names, local port exposure, test result, production image digest/ID, and a short list of known dev-versus-production differences.

Knowledge check

Official references and version notes

• Docker Docs — Use Compose Watch — current Watch workflow, sync/rebuild behavior, ownership guidance, and command forms.
• Docker Docs — Compose Develop Specification — develop.watch, actions, paths, targets, ignore/include, and version gates.
• Docker Docs — Docker Desktop settings — host/VM file sharing and resource behavior.
• Docker Docs — Synchronized file shares — optional Desktop acceleration for large repositories and its constraints.
• Docker Docs — Sharing local files — bind-mount semantics and host-side effects.
• Development Containers Specification — open development-container specification and reference ecosystem.
• Dev Container Spec — Overview — devcontainer.json as development metadata layered onto container technologies.
• Dev Container Spec — Dockerfile and Compose guide — using Dockerfile/Compose as the underlying environment definition.
• Dev Container Spec — Supporting tools and services — support boundaries for properties such as remoteUser and forwardPorts.
• Dev Container Features index — current Feature registry and versioned references.
• Dev Container Spec — Feature updates and lockfiles — resolved Feature identities and lockfile maintenance.
• Docker Docs — Multi-stage builds — keep development tooling out of the production target.
• Docker Engine 29 release notes — current Engine-era context used by this course.