DevOps by Default Blog

Container-First Development: Lessons from GOTRS


The latest GOTRS release focused on something that doesn’t make for exciting screenshots but matters enormously: trust in the development workflow.

The Problem

Every developer has a slightly different local environment. Different Go versions, different database clients, different shell configurations. One machine has PostgreSQL 14, another has 16. One uses Homebrew, another uses apt.

These differences create subtle bugs that only appear in CI or production. “Works on my machine” becomes the team motto. Debugging becomes archaeology - figuring out which environmental difference caused the failure.

Our Solution

We made every make target run inside a container. Whether you’re running make dev, make test, or make lint, you get the exact same environment as CI. The Makefile auto-detects Docker or Podman and respects SELinux contexts.

No locally installed Go required. No database clients needed. No “did you install staticcheck?” conversations.

We also added DB-less fallbacks - dashboards and ticket views render gracefully even when the database is unreachable. Not perfectly (you need data), but gracefully. Perfect for CI smoke tests.

The Benefits

If it passes locally, it passes in the pipeline. Full stop. No more “but CI has a different version” debugging sessions.

New contributors run make dev and have a working environment in minutes, not hours. No setup documentation to maintain. No onboarding gotchas.

Service outages became less scary. The UI keeps enough context for operators to understand what’s happening even when the database is down.

The investment in container-first development paid for itself within weeks. The initial setup time was recovered many times over in avoided debugging sessions.