Dev Service Versions

Dev service versions refers to deliberately pinning every dependency service's version within a development Compose file to match production as closely as practical, rather than relying on a mutable tag like latest that could drift unpredictably and undermine environment parity.

Why Pinning Matters Even for Local Dependency Services

A development database or cache running an unintentionally different version than production risks masking a version-specific behavior difference that would otherwise be caught locally.

services:
  db:
    image: postgres:latest

services:
  db:
    image: postgres:16.2

The second, explicitly pinned version provides a stable, known target that can be deliberately kept aligned with production's actual version, unlike the first, which could silently resolve to a different version over time.

Keeping Pinned Versions Aligned With Production Over Time

Updating a development service's pinned version specifically when production's corresponding version changes keeps both environments deliberately synchronized.

services:
  db:
    image: postgres:16.2

services:
  db:
    image: postgres:16.3

This kind of deliberate version bump, applied to development specifically because production was also updated, maintains the intended alignment between the two environments.

Documenting Why a Specific Version Was Chosen

A brief note alongside a pinned version, particularly if it intentionally lags behind the latest available release for a specific reason, helps future maintainers understand the reasoning rather than assuming the pin is simply outdated.

services:
  db:
    image: postgres:16.2  # matches production; do not bump without coordinating

Why Dev Service Versions Matter

Deliberately pinning and maintaining dependency service versions in development, specifically to track production's actual versions, is a focused but important practice for preserving genuine environment parity, rather than letting local dependency versions drift independently over time.