What changes for you
A release stops being an event your team braces for and becomes an ordinary part of the week.
In many teams, the release is the riskiest moment of the month. Changes pile up because each release costs an evening and some courage. The bigger the pile, the harder it is to say which change caused a problem, so the next release is put off a little longer. A feature that was finished in the first week waits for the last one. Customers who asked for it hear “soon” more than once.
The way out is not braver release nights. It is smaller releases. A release that carries one or two changes is easy to read, easy to talk about and easy to put right. When releases are small, there is no reason to save changes up, and the queue of waiting features shrinks.
Zefana can carry the work for you: you set the direction, and finished changes arrive in your own repository for your approval. Those changes go out in small releases instead of one large one at the end of the month. Your product keeps moving forward, week after week.
Three abilities sit underneath this, each on its own page. When a release misbehaves after it goes out, your users get the previous version back: see releases that put themselves back. The fix then follows without anyone filing a ticket: see broken releases repaired. And a new version goes live without a maintenance page: see releases your users never notice.
What you decide
You decide what ships. Nothing reaches your users without your approval.
You decide how often you want to release. “Every week” is a goal you set, not a pace we promise, and you may want more or less than that. You also decide which changes your customers hear about. A release can carry a feature you want to announce on a day you pick, or a small repair nobody needs to read about.
You decide what comes first. A small release gives you more chances to change your mind, because the next one is never far away.
What you see along the way
You see a steady stream of small changes instead of a large bundle once a month.
Each change arrives in your repository with a plain explanation of what it does, so you and your team can read it before it goes out. When a release misbehaves, your users get the previous version back, and the fix arrives as a change you can read like any other. The question at the end of the week is no longer “did the release go well?” but “what shipped?”.
An example from our own work
ClickDeeper is our own product, and it releases often. ClickDeeper shipped more than a thousand releases in three months.
That figure describes ClickDeeper and nothing else. It is not a rate we promise for your product. What it shows is that a release can be routine rather than a night to dread.
What it costs you in time
Mostly the time to approve changes as they arrive, and a short word when the order of work should change. Nobody on your side has to stay up for a release.
What it does not do
It does not mean nothing ever goes wrong. Releases still misbehave sometimes; what changes is how big they are and who has to carry the problem. Going back to the previous version also does not reverse changes to stored data, as the page on going back explains.
If you want to stop
The code we build for you is yours. Every change made until then is already in your repository, and your team can release it themselves in whatever rhythm suits them.
Starting small
It starts with a conversation, with no obligation. Bring the feature that has waited longest for a release, and we will talk about getting it out.
