Cloud & delivery / Capability
CI/CD pipelines.
Automated builds, tests and deployments, so every release follows the same checked path.
Review your release process
When to bring us in
Sound familiar?
- Releasing takes half a day and a checklist only one person knows.
- Tests exist, but nobody runs them before deploying.
- When a release goes wrong, getting back to the last version is guesswork.
The cost of leaving it
Releases depend on one person’s laptop and memory, so they happen less often and carry more change. A broken build reaches production because a step was skipped under pressure.
Why us
What we bring to ci/cd pipelines.
Infrastructure kept in code
Our own products run on AWS with infrastructure defined in Terraform, so environments can be reviewed and rebuilt.
Data kept apart by design
In SoulCare, each care provider has its own PostgreSQL database rather than sharing tables with everyone else.
Accounts set up in your name
Cloud accounts and databases are yours from the first day, not something to transfer at the end.
What the work includes
Every change takes the same route to production.
We automate the steps between a merged change and a running release: build, test, package and deploy. Checks that matter run on every change, and slow ones run where they are worth the wait. Production deployments can require approval, and a failed release can be rolled back without improvising.
Build and test automation
Every change built and tested automatically, with results visible on the pull request.
Deployment pipelines
Repeatable deployments to each environment, including mobile and web where needed.
Secrets and approvals
Credentials kept out of code, and production releases gated by the right people.
Rollback
A tested way to return to the previous release quickly when something fails.
Use cases
Projects we take on.
Automating a manual release
A release that relies on one person’s checklist turned into a pipeline anyone on the team can run.
Mobile builds and submissions
iOS and Android builds signed and uploaded to the stores from a pipeline instead of a developer’s machine.
Safer database migrations
Schema changes run as a deliberate pipeline step, with a backup taken and the result checked before traffic moves.
What you get
Outputs you can review.
- Pipeline configuration in version control
- Automated test and quality checks
- Deployment to each environment
- Secrets management setup
- Rollback procedure
- Release documentation
Technologies we use for this
Where it matters
- Health & social care Where each care provider has its own database and access rules, environments, backups and schema changes have to be managed per provider.
- Medical education A training app on the app stores and the web needs one pipeline that ships every platform from the same tested commit.
- Fintech & professional services Infrastructure changes need review and a record of who approved them; version-controlled code and pipeline approvals give you both.
Where AI helps
Useful, on a short leash.
Explaining failed builds
Summarise why a pipeline failed from its logs, so the developer starts from a likely cause.
AI workflow automation ↗Testing AI features on every release
Run a fixed set of real examples against any AI feature in the pipeline, and stop the release if quality drops.
AI evaluation & testing ↗
Where it stops: Whether a release goes out depends on tests and a person’s approval, not on a model’s opinion of the change.
What’s changing
Shifts to plan for.
June 2026
Amazon Linux 2 reaches end of life
Amazon Linux 2 reached end of life on 30 June 2026. Lambda runtimes built on it, such as Python 3.10 and 3.11 and older Java, get limited patches until their own deprecation dates.
April 2026
Lambda deprecates Node.js 20
Lambda stopped patching the nodejs20.x runtime on 30 April 2026. Creating functions on it is blocked from 29 July 2027 and updating them from 31 August 2027.
April 2026
MySQL 8.0 reaches end of life
Oracle moved MySQL 8.0 to Sustaining Support, so Oracle no longer releases security fixes for it. Oracle recommends moving to MySQL 8.4 LTS or 9.7 LTS.
Process
How the work runs.
Write down today’s release
We record every manual step as it happens now, including the ones people forget to mention.
Automate the build
Builds and tests run on each pull request, so a broken change is caught before it is merged.
Add environments in order
Staging deployments are automated first, and production follows once staging has run cleanly for a while.
Rehearse a rollback
We roll a release back on purpose to prove the route works before anyone needs it.
Cost
What shapes the estimate.
Test coverage today
A pipeline is only as useful as its checks, and writing missing tests adds work.
Applications and targets
Each application, environment and platform needs its own pipeline steps.
Approval rules
Sign-off from several people, or an audit trail for regulators, means extra gated steps.
Ways to work together
A first, fixed stage
Discovery, a prototype or a technical review with agreed outputs, so the next decision is made with something concrete in hand.
Delivery in phases
The build split into releases, each with a scope you review and approve before it starts.
Ongoing engineering
An agreed scope for support and improvements after launch, with response expectations written down.
Common questions
Before you get in touch.
Can you work with the CI tool we already use?
Usually, yes. We review what you have and improve it where that makes sense, rather than moving tools for the sake of it.
Can pipelines handle mobile app releases?
Yes. Mobile pipelines can build, sign and submit iOS and Android apps, with store review still part of the release process.
What affects the effort?
The number of applications and environments, existing test coverage, how releases are approved and any mobile or database migration steps.
Further reading
- A database for every pull request: preview environments that work How to give each pull request its own database branch, with safe data, tested migrations and automatic clean-up.
- Terraform from day one: infrastructure as code that lasts How to start with Terraform in the first environment, so infrastructure stays reviewable and a new team can take it over.