We deploy fine by hand. What does this actually buy us?

Three things you cannot buy separately. Releases stop depending on one person being awake and at their laptop. Every deploy becomes identical, so a bad release is a code problem rather than a mystery about which step somebody skipped. And you get a rollback that takes about as long as a coffee, which is what turns a Friday afternoon fix from a risk into a routine.

We have almost no automated tests. Is a pipeline still worth it?

Yes, and it is often the thing that finally makes tests worth writing. A pipeline with a build stage, a linter and a deploy that can be reversed already removes most manual release risk. The test gate is then something you grow into, and once it exists the pipeline is what makes it matter — a failing test that nobody is forced to look at changes nothing.

How long does a deploy take once this is in place?

For a typical web application, a few minutes from merge to live, most of it spent building and running tests rather than deploying. Very large test suites or heavy container builds take longer, and part of the work is caching dependencies and layers so that the pipeline does not spend ten minutes reinstalling the same packages on every run.

Which tool will you use?

Usually whatever is closest to where your code already lives — GitHub Actions for GitHub, GitLab CI for GitLab. Both are capable enough for the overwhelming majority of applications and neither adds a system your team has to learn separately. If you already run Jenkins or something else that works, we would rather improve it than replace it.

Where do our secrets live once this is automated?

In the pipeline's own encrypted secret store or a dedicated secrets manager, injected at run time, never in the repository and never printed into build output. Part of the handover is checking that no key appears in a log, because a secret that has been written into a build log has to be treated as leaked and rotated.

What about database migrations?

They are the part that makes automated deploys risky if ignored, so they get their own step and their own rule — migrations must be backwards compatible with the currently running code. That way the new schema is in place before the new code needs it, and a rollback of the application does not leave the database ahead of it in a state the old version cannot read.

Cloud, DevOps & Infrastructure

An automated build, test and deploy pipeline

Releases that run from a commit rather than from one person's terminal — built once, tested before it ships, and reversible in a couple of minutes.

From: $800–$8,000
Typical time: 1–4 weeks
Usually bought by: Dev teams

What this actually solves

The honest version of most deployment processes is a person, a terminal and a memory. They connect to the server, pull the latest code, run a build, restart the service and watch the site for a minute. It works. It works right up until that person is on a plane, or ill, or has left, and then nobody else in the company can safely ship a one-line fix.

The second cost is subtler and shows up as fear. When releasing is manual, releasing is risky, so releases get batched. Three weeks of changes go out at once, something breaks, and now there is no way to tell which of forty commits caused it. That is the real reason teams stop deploying on Fridays — not because Friday is dangerous, but because their releases are too big and their way back is undefined. A pipeline attacks both at once. Small releases become cheap, so they happen more often, so when one breaks the suspect list is short.

The third thing it fixes is quieter. Manual deploys drift. Somebody sets an environment variable on the server during an incident and never records it. Somebody builds from a local branch at midnight. Six months later the running system does not correspond exactly to any commit in the repository, and nobody can rebuild it. A pipeline that builds once, tags the artefact with the commit it came from and ships that artefact makes the running system traceable to a line of code again.

How the pipeline gets built

Watch a real release and write down every step. Including the ones nobody mentions - the cache that gets cleared, the migration that is run by hand, the service that has to be restarted in a particular order, the file that is copied because it is not in the repository. This list is the specification, and it is usually longer than anyone expects. Half a day to two days.
Build once, and tag the artefact with the commit. A reproducible build producing a container image or a versioned bundle, pushed to a registry, tagged with the commit hash rather than a moving label. Dependencies and layers cached so the pipeline is fast enough that people actually wait for it. Two to four days.
Add the gate, then prove the gate works. Tests, linting and a build check wired so a failure genuinely stops the deploy. Then we break something on purpose — a deliberately failing test on a scratch branch — and confirm the pipeline goes red and refuses to ship. An untested gate is decoration. One to three days.
Automate the deploy, and the way back with it. Secrets pulled from the pipeline's encrypted store or a secrets manager at run time. Database migrations as their own step, written to stay compatible with the code currently running. Deployment to staging first where one exists, production gated behind an approval where you want one. The previous artefact stays in the registry so reverting is a redeploy of a known-good tag rather than a rebuild from an old branch. Two to five days.
Rehearse a rollback and hand over the runbook. We ship a change, then roll it back on your staging environment while you watch, and time it. The runbook says what to do when the pipeline itself fails, who can approve a production deploy, and how to ship when the provider is having a bad day. One day.

What moves the price

How many environments there are. One production target is straightforward. Development, staging, production and a per-branch preview environment is four sets of configuration, four sets of secrets and four sets of failure modes.

What is on the other end. Deploying to a single machine running a systemd service is quick and reliable to automate. Deploying to a container platform or a Kubernetes cluster brings image builds, registry authentication, rollout strategies and health checks, and that is a materially longer piece of work.

Whether a test suite already exists. A pipeline can be wired to an existing suite in days. If the tests have to be written, or if the suite is slow and flaky enough that people have learned to ignore it, that is its own project and we will quote it separately rather than bury it in this one.

What usually goes wrong

The image is tagged latest and rollback quietly becomes impossible. Every build overwrites the same label, so the artefact that was running an hour ago no longer exists anywhere. When you need to go back, the only option is rebuilding an old commit and hoping the dependencies resolve to the same versions they did last week. Tagging every build with its commit hash costs nothing and is the difference between a two-minute rollback and an afternoon.

Secrets end up in the build log. A debugging line that prints the environment, a verbose deployment command, a configuration dump on failure — and the key is now sitting in plain text in a log that a good number of people can read. Automated scanners find exposed keys in public repositories within minutes of them appearing, and a key in a log has to be treated as compromised and rotated, not quietly ignored.

The pipeline is green because nothing can make it red. Tests that were never actually invoked, a step ending in a fallback that swallows the failure, a linter warning-only by default. The team gains total confidence in a check that has never once stopped anything. This is why we deliberately break the build before handover — a gate you have not watched fail is not a gate.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

We deploy fine by hand. What does this actually buy us?: Three things you cannot buy separately. Releases stop depending on one person being awake and at their laptop. Every deploy becomes identical, so a bad release is a code problem rather than a mystery about which step somebody skipped. And you get a rollback that takes about as long as a coffee, which is what turns a Friday afternoon fix from a risk into a routine.
We have almost no automated tests. Is a pipeline still worth it?: Yes, and it is often the thing that finally makes tests worth writing. A pipeline with a build stage, a linter and a deploy that can be reversed already removes most manual release risk. The test gate is then something you grow into, and once it exists the pipeline is what makes it matter — a failing test that nobody is forced to look at changes nothing.
How long does a deploy take once this is in place?: For a typical web application, a few minutes from merge to live, most of it spent building and running tests rather than deploying. Very large test suites or heavy container builds take longer, and part of the work is caching dependencies and layers so that the pipeline does not spend ten minutes reinstalling the same packages on every run.
Which tool will you use?: Usually whatever is closest to where your code already lives — GitHub Actions for GitHub, GitLab CI for GitLab. Both are capable enough for the overwhelming majority of applications and neither adds a system your team has to learn separately. If you already run Jenkins or something else that works, we would rather improve it than replace it.
Where do our secrets live once this is automated?: In the pipeline's own encrypted secret store or a dedicated secrets manager, injected at run time, never in the repository and never printed into build output. Part of the handover is checking that no key appears in a log, because a secret that has been written into a build log has to be treated as leaked and rotated.
What about database migrations?: They are the part that makes automated deploys risky if ignored, so they get their own step and their own rule — migrations must be backwards compatible with the currently running code. That way the new schema is in place before the new code needs it, and a rollback of the application does not leave the database ahead of it in a state the old version cannot read.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about CI/CD pipeline setup All Cloud, DevOps & Infrastructure services