reducing devops overhead for hybrid product models: the tier·dev approach
most of the devops pain in a hybrid (open-source + saas) product is self-inflicted: it comes from building, testing, and releasing two diverging code lines. collapse the lines into one repo with per-tier flag config and the overhead falls out — one ci pipeline, one test suite, one release process, with the tier name as a build parameter.
where the overhead actually lives
audit a week of work on a two-branch product and the waste is rarely one big thing. it's the bugfix that needed two prs and two reviews. the ci matrix that runs everything twice. the release checklist with a 'sync the enterprise branch' step that one person knows how to do. the incident where saas was fine but the community edition shipped a regression nobody backported.
each cost looks small; together they're a part-time job nobody hired for. and unlike feature work, this overhead scales with the divergence between editions — it gets worse every quarter you let the branches drift.
the collapse: one pipeline, parameterized
with tiers as flag config, the pipeline simplifies structurally, not cosmetically.
- ci builds main once, then produces per-tier artifacts by setting PRODUCT_TIER and reading the committed tiers.json — no duplicate compile-and-test of a second line.
- tests run against the superset build, plus a thin smoke suite per tier that asserts flag wiring (saas shows the pro dashboard, open-source doesn't).
- releases tag one commit. 'what went out to each edition' is the tag plus that edition's config block — auditable in the diff.
- on-call triage starts from one codebase. a bug is either in shared code (fix lands everywhere) or in a flag value (fix is a config change).
what the tier·dev layer adds
you can hand-maintain tiers.json — early teams do. what tier·dev adds is the bookkeeping that hand-maintenance loses at around ten flags: a matrix view of every flag across every tier, descriptions so flags stay legible, normalization so names stay consistent, and regenerated json/yaml/code snippets so the committed config never drifts from the source of truth.
because the output is a plain committed file, adopting tier·dev adds zero runtime dependencies and removing it is a non-event — the last generated config keeps working forever. devops overhead should only ever go down.
see this on your own repo
tier·dev turns the open-source / saas difference into per-tier feature flags — one repo, generated config, no sdk.
faq
- we already pay for a ci farm — is duplicate building really expensive?
- the compute is the cheap part. the expensive parts are the second review, the second failure mode, and the human sync step. those don't show on the ci bill, but they show in cycle time.
- does this work with docker-based releases?
- cleanly — build one image and bake the tier config in at build time, or mount it at deploy time. either way the dockerfile stops needing per-edition variants.
- what's the migration path from an existing enterprise branch?
- merge the branch back behind flags one feature at a time: pick a divergent feature, wrap it in a flag, port it to main, delete it from the branch. teams typically retire the branch in a few sprints without a feature freeze.