Release often, and roll back when you need to
We build the automated path from code to production: every change is tested, released the same way every time and can be rolled back to the previous version.
Who it's for
For companies where every release is a tense event, scheduled for the evening or the weekend.
What it solves
- Releasing depends on one person working through a checklist by hand.
- A faulty version reaches production because the tests never ran.
- Going back to the previous version takes hours, and nobody is sure how.
- Changes pile up for weeks, and every release becomes a big gamble.
What we do
- Continuous integration
- On every change, the code is built, tested and checked before it joins the main branch.
- Quality gates
- Tests, security checks and review are mandatory; if anything fails, the release stops.
- A single artefact
- The image tested in staging is the same one that goes to production, signed and traceable.
- Gradual rollout
- Where the system allows, the new version takes part of the traffic before taking all of it.
- Rolling back
- One documented, rehearsed command returns production to the last stable version.
- Database migrations
- Database changes written to work alongside the previous version during the switch.
What you get
- An integration and delivery pipeline running in your company's repository
- Blocking rules for tests, security checks and review
- A rollback runbook, rehearsed with your team
- A record of every release: what changed, who approved it and when
- Documentation for your team to maintain and adjust the pipeline
How we do it
Assessment
How code reaches production today, step by step, and where it gets stuck.
Continuous integration
Automatic builds and tests on every change, with results visible to the team.
Automated delivery
Staging and production along the same path, with approval where needed.
Rollback rehearsal
A version is rolled back on purpose, to prove the way back works.
Handover
Your team starts releasing on its own, with the documentation to hand.
Technology examples
- GitHub Actions
- GitLab CI
- Argo CD
- Docker
- Trivy
- Cosign
Related services
FAQ
How often can we release?
It depends on the tests you have and on how the system and the team work. The aim is for releasing to become routine rather than an event booked in advance.
Who approves a release to production?
Whoever your company decides. The pipeline can require a person's approval before production, and each approval is recorded with a name and a time.
What if we have no automated tests at all?
We start with the flows that hurt most when they break and expand from there. That work belongs to automated testing.
Doesn't releasing more often increase the risk?
Usually not. A small change is easier to test, understand and undo than a large batch built up over weeks.
Write to Balkan
Talk to us about your project