DevOps
Pipelines, environments, monitoring and rollbacks. We have shipped through Azure DevOps on regulated work and staged firmware across device fleets where a bad release reaches hardware you cannot walk up to.
Book a 30-minute scoping call See how we ship
If you deploy weekly without drama, you do not need us for this.
| How long from merge to live Minutes or days | Ask |
|---|---|
| Who is allowed to deploy One person, or the team | Ask |
| How do you roll back And has it been tried | Usually not |
| Who finds out first Monitoring, or a customer | Usually customer |
| What breaks staging Drift from production | Ask |
The honest question first
People rarely want DevOps. They want releases that stop hurting. Those are different problems with different fixes, and only some of them are ours.
Not a pipeline problem
A better pipeline makes these worse, faster. We will point at the real cause.
This we can fix
The last one is the sharpest. On device fleets we stage rollouts so a bad firmware release can be stopped partway.
Plain definitions
Both are worth understanding before you agree a scope, because both can be sold to you at any size.
Continuous integration means every change gets merged and tested automatically, so problems surface within minutes instead of on release day. Continuous delivery means the tested change can go to production on demand, by a button rather than by a person following a document.
The value is not speed for its own sake. It is that a small change is easy to reason about, and a release that happens weekly is far less frightening than one that happens quarterly.
It means your environments are described in files kept in version control, so staging and production get built from the same source instead of by memory. Change the file, review it like code, apply it.
It is worth it the moment you have more than one environment or more than one person deploying. Below that it is paperwork. The clearest symptom that you need it is staging behaving differently from production and nobody being able to say why.
What we set up
What people ask us for
Most engagements here are weeks rather than months, and they end with your team running it.
Our work
Case study, IoT platform
On the IoT Workz platform a release travels all the way to ESP32 devices installed at customer sites. We built over-the-air delivery as a staged rollout that can be paused, with Prometheus and Grafana watching the fleet, and the platform running on Docker and Kubernetes in the client's own infrastructure.
On client-side delivery we work in Azure DevOps, including on safety compliance software.
Technology
We use what your team already knows. Migrating you to our preferred tooling is a cost you would carry after we left.
Who does the work
Delivery machinery is only useful if the people who inherit it can change it. That constraint shapes how we build, and it is easier to hold across a team of twenty than across a rotating bench.
You interview whoever we put forward. Ask when they last rolled back a release in anger, and listen for whether the answer has details in it.
How we work
The models differ in one thing: how much of the management you hand over. Everything else, including who owns the code, is the same in all five.
Changing model later is normal. Augmentation into a dedicated team is the common direction, and the people stay.
Engineers join your team and work inside your process, your board and your code review.
A team that works only on your product, with a lead on our side running delivery.
A long-term engineering site under your standards, where we carry recruitment, HR, payroll and equipment.
04
One price for a scope that is genuinely settled, with the overrun carried by us.
Everything in the centre model, with the whole team moving into your own Vietnamese entity on an agreed date.
FAQs
Yes. Azure DevOps, GitHub Actions, GitLab. We use what your team already knows rather than migrating you to our preference.
Usually not at first. Most of the value is in a few weeks of setup, then a smaller ongoing arrangement. We will say when a full-time role is genuinely warranted.
Sometimes. Often the pipeline is fine and the application cannot be deployed twice safely. We will tell you which one you have.
Staged rollout with the ability to stop, plus monitoring of the fleet during release. Pushing to everything at once is how a fleet gets bricked.
Your team. Pipelines, definitions and runbooks are handed over, and we would rather train someone than become a dependency.
We can cover a period during and after launch. Long-term on-call belongs with the people who own the product.
Most of the value lands in three to six weeks of setup. A larger piece, where the application itself cannot be deployed safely twice and needs work before any pipeline helps, takes longer. Ongoing support afterwards is deliberately small. Which engagement model you pick decides how any of it is billed, and the models are set out above.
Four numbers, measured before and after. How long a change takes from merge to production, how often you release, what share of releases cause a problem, and how long it takes to recover when one does. We take a baseline in week one so the argument at the end is about evidence rather than impressions.
It is the practice of putting security checks inside the pipeline rather than at a gate before release. Dependency scanning, secret detection in commits, and the build failing when something known-vulnerable arrives. It is not a separate product or a separate engagement, and any supplier quoting it as one is selling you a rename.
What broke, how you found out, and how long it took to undo. Those three answers point straight at what to fix first.
Book a 30-minute scoping call Read what is not a pipeline problem
