Search for a command to run...
A practical guide to embracing "Release Early, Release Often" to ship faster, learn sooner, and build better software.
Software Engineer x Data Engineer - I make the world a better place to live with software that enables data-driven decision-making
No comments yet. Be the first to comment.
In this series, I will explore practices, reflections, and lessons learned that shape how we collaborate, improve processes, and build better ways of working. [Series cover photo by Leone Venter on Unsplash]
What is the difference between the DoR and the DoD
Optimize context budgets and eliminate prompt bloat by decoupling skill discovery triggers from execution details.
Why fanning out OAuth introspection inside your VPC creates a distributed bottleneck - and how to keep internal auth fast.
How Model Context Protocol and Agent Communication Protocol shape the AI stack.
A practical follow-up on turning agent instructions into focused, testable workflows.
How to reduce context size, improve reasoning, and build more predictable AI coding workflows
There’s a lot of teams that thinks about themselves as “agile”, they do have JIRA, they do the standups, but if we look closely at their release cycle it says otherwise.
They can plan sprints, push to main and then they… wait. They wait for the QA - a week. Then for the UAT testing phase - another week. Then for the Release Window.
By the time the feature hits production, everyone forgot why it was built.
Slow releases kill developer momentum and delay the only thing that matters - feedback from real users.
RERO - Realease Early, Release Often - isn’t about deploying half-baked code. It’s abt shortening the feedback loop between code and reality.
Release Early → push features to production as soon as they’re functional, not perfect
Realease Often → make deployment a non-event; something you do daily, not quarterly (or monthly)
The goal isn’t speed for the sake of speed.
The goal is learning faster than your competition.
Every release is a feedback opportunity. EVery deployment tests your delivery pipeline, your observability, and your assumptions.
The more often you release:
the smaller your changes are → they’re easier to debug (this is uber important part!)
the faster you catch the regression (if any) → you lower the risk
the quicker you learn what users actually want → profit (better ROI)
RERO shifts focus from “perfect features” to conrtinuos improvement.
Define What “Release Ready” Means:
Agree as a team what “good enough for release” means
Use your Definition of Done as the gate - not “it feels ready” (lol):
code reviewed
tests passing (CI)
feature flag enabled
rollback plan ready
Use Feature Flags:
Don’t wait until a feature is “fully complete”
Wrap it in a flag and ship it dark:
if feature.IsEnabled("new_flow") {
newFlow();
} else {
oldFlow();
}
Automate Everything:
if your deployment requires a 10-step manual guid, you’ll never release often
Automate GH Actions, GL CI or wahtever you’re using - the key is zero (or minimal) friction deploys
Release Small, Release Confident:
Trunk based development helps
No more long-lived branches that rot for weeks - merge daily
Small commits = fast reviews = fewer conflicts = faster learning
Monitor and Rollback
RERO without monitoring is chaos
Make sure you can:
detect failures quickly (metrics, logs, alerts)
rollback instantly (blue/green or versioned deploys)
“We’ll release when QA approves” → Integrate QA into the pipeline. Use automated regression tests.
“Our users can’t handle frequent updates” → Use progressive rollouts: 5%, 25%, 100% (canary releases)
“We’re afraid of breaking production” → Build trust in rollback and observability.
“We don’t have time for this” → You don’t have time not to. Every delay costs learning.
It’s not just about speed - it’s about smoother flow. Velocity isn’t measured by lines of code - it’s measured by how fast you learn and adapt.
“Release Early, Release Often” is more than a slogan - it’s a mindset shift. It replaces fear with feedback and perfectionism with progress.
The faster you ship, the faster you learn. The faster you learn, the better you build.
Cheers!
RERO: https://en.wikipedia.org/wiki/Release_early,_release_often
Trunk Based Development: https://trunkbaseddevelopment.com/
B/G deployment: https://en.wikipedia.org/wiki/Blue%E2%80%93green_deployment
Canary Release: https://martinfowler.com/bliki/CanaryRelease.html