Release a change without crossing your fingers.
Who it is for
For companies and public bodies with applications or portals that change often, and where a release today depends on one person, a list of steps and picking the right hour.
The problem
Releasing is scary. It happens on a Friday afternoon or in the middle of the night, by hand, following steps only one person knows. If something breaks, nobody knows how to go back. So releases are rare, and each one carries too many changes at once.
How we solve it
We automate the whole path. Every change goes through automatic tests and a pre-production environment like the real one. Only what has been tested reaches production, when a person approves it. And if something goes wrong, it is rolled back to the previous version.
What it includes
Automatic tests
On every change. If they fail, the change does not move forward.
Pre-production
An environment like the real one where you see the change before it goes live.
A person's approval
Nothing reaches production unless someone decides it.
Rollback
The previous version is kept and can be recovered.
Security updates
Proposed every night by a bot and reviewed by a person.
Record
What was released, when and who approved it.
How we work
We start by looking at how you release today and by writing those steps as code. We set up pre-production and the tests, and do the first releases with you. From then on, changes go out small and often. You decide who approves the step to production.
What we measure
Deployments made, failed deployments and rollbacks, time from a change being ready to being in production, and how old pending updates are.
Cases
A public body: every change to its portal goes through tests and pre-production before it is released.
How it is built
Continuous integration and deployment with GitLab CI. The path of a change is written in the repository: build, tests, quality and security analysis, deployment to pre-production and promotion to production.
Going to production takes a minimum of 80 % test coverage and 0 open issues in SonarQube. Static security analysis covers all the code and every change is checked against known vulnerability databases: if a new finding appears, the integration stops.
In container-based projects, what goes live is exactly the image that was tested in pre-production, identified by its digest, and not a new build. The previous version is kept and can be restored. Promotion to production is a manual step: a person triggers it.
Every night a bot (Renovate) reviews the dependencies and proposes updates, which a person reviews before they are applied. Deployment secrets live in a secrets manager and are handed over at run time; they are not in the repository. Before production, every change is also reviewed by four agents (security, accessibility, quality and functionality) and a person.
Frequently asked questions
What happens if a deployment goes wrong?
It is rolled back to the previous version, which is kept. The cause is then investigated calmly, with the service running.
Who decides that something goes to production?
A person, always. The tests say whether a change can be released; when it is released is decided by whoever you choose.
Does the service have to stop for a release?
It depends on the application. We look at it in the initial inventory and, if downtime is needed, we agree the moment with you.
Can you automate deployments for an application that already exists?
Yes. We start by writing as code the steps that are done by hand today and by adding the tests that are missing.
Also in Managed systems
Backups
Encrypted and tested: we actually restore them, not just copy.
Monitoring
Error and availability monitoring, with the fix already prepared.
The next step
Tell us how you work today and we will tell you where to start.