I’m excited to write this one, it’s always lovely to talk about great success stories, and this might be our most successful one so far.
I’ve always believed that the best DevOps work isn’t measured by the infrastructure you build, but by how much faster the people around you can move because of it. We just love to enable people to deliver fast, with confidence and quality.
The Starting Point
There’s a specific kind of anxiety that comes with manual deployments. You’ve been holding back features all week. It’s Friday afternoon. Everyone’s quietly hoping nothing breaks over the weekend. The deployment itself takes longer than it should, because you’re doing it by hand, and because the stakes feel high enough that you double-check everything twice.
That was how we found our client when we first started working with them. Their
team was shipping roughly 37 PRs per month, not bad for a team of 5
engineers, but they were fighting their own tools the whole way. Deployments
were manual, every Friday. The main Elixir app was running on Heroku, and
master wasn’t even the source of truth. Infrastructure lived in the AWS
console, everything was done via ClickOps. They had a CloudFormation template
for multi-tenancy, and connecting to a running BEAM node via IEx wasn’t even
possible because they weren’t using releases. Secrets were managed… creatively.
If you’ve ever been in a team where deploying feels like defusing a bomb, you know the vibe. Every release carried risk, and that risk slowed everything down.
In two months, we changed all of that.
Starting With the Right Foundation
The first thing we tackled was packaging. The main Elixir application wasn’t using releases, which meant no clean configuration model, no proper startup scripts, and no way to connect a remote IEx session to a running BEAM node in production. That last point sounds like a minor inconvenience, but it isn’t. Releases are the foundation that everything else sits on: containerisation, reproducible deployments, and any future work around clustering. Getting this right first meant everything we built on top of it would actually hold.
From there, we Dockerised the service and built CI/CD pipelines from scratch using GitHub Actions. We created a proper AWS staging environment, set up SOPS for secrets management, and moved the main Elixir app off Heroku entirely into ECS. Then we ran the production cutover.
During this period, Ellie and I contributed nearly half of all merged PRs across the whole team, 47%. Not because the existing team wasn’t capable, but because there was so much automation that needed doing and until the tooling was in place, the team wasn’t able to move faster. We’ve always been pretty intense when it comes to shipping, which honestly just comes with the territory.
What Good CI/CD Actually Looks Like in Practice
A good CI/CD pipeline is one that makes you work faster, and makes deployments feel like second nature.
We automated the packaging of the Elixir application into a release and containerised it. This gave us a consistent, reproducible build process that could be run anywhere and meant that changes could be easily tested and verified.
An important step was adding database migration validation directly in CI, so a broken migration would fail the pipeline before it ever reached production. If you’ve ever had a deployment roll back because a migration didn’t account for the existing schema, you know how much time this saves and how much confidence it adds. Engineers could merge with certainty that if CI passed, the migration was safe.
Once the Elixir app was being deployed regularly, we implemented a CD pipeline for a second service, their React front-end, giving the team the same deployment confidence across their whole stack.
CD pipelines are not only for application changes. We built continuous delivery for Terraform alongside the application pipelines, so infrastructure changes went through the same review and automation process as code. A proposed Terraform change would generate a plan, posted to the PR for review. Infrastructure changes stopped feeling like a separate, riskier class of work.
One thing that is essential to all CI pipelines: keep the time down. A CI run that takes 20 minutes is a CI run that people start ignoring. So we parallelised the pipeline to keep the feedback loop tight, because fast feedback is what keeps people engaged and the pipeline valuable.
Something I always love about effective CI/CD is that a new engineer who joins the team can ship to production on their second day. That’s not an accident. It’s what good tooling makes possible. New engineers hitting the ground running used to require months of accumulated context about how deployments worked and what could go wrong. Now the pipeline handles that, and they can focus on the product.
The Numbers
The numbers tell the story:
| Metric | Before | After | Change |
|---|---|---|---|
| Existing team merged PRs/month | 37.3 | 75.6 | +103% |
| BEAMOps merged PRs/month | - | 31.6 | - |
| Total merged PRs/month | 37.3 | 107.3 | +187% |
The existing team more than doubled their own output. Yes, they also grew the team during that period, but new hires only ramp up fast when the tooling is there to support them. When deploying is easy, when you can trust your CI, when you can see what’s happening in production, everyone just ships more.
And that is the thing I care about most. Anyone can build a CI pipeline. The hard part is building the right one at the right time so that 10 other engineers can stop worrying about deployments and focus on the product.
The Lesson
Every engagement reinforces the same lesson: the biggest productivity gains come from removing friction, not adding features.
A team doesn’t need more engineers. It needs the right foundation and CI/CD that actually works. That is the thing that determines whether your team ships in small, safe steps or large, stressful batches. It determines whether Friday afternoon feels calm or tense. Done well, it becomes invisible. Engineers open a PR, it gets reviewed, it merges, it ships, with no drama, no manual steps, no “who’s handling the deployment this week?”
When you give a good team the right tools, they don’t just keep up, they accelerate.
If your team is still doing manual deployments, or your CI pipeline is slow enough that people have started treating it as optional, we’ve been there. This is what we do, we deliver.
📬 Email us at info@beamops.co.uk 📅 Or book a free 30-minute call, we’d love to hear what you’re working on.