CI/CD in New Zealand
A deployment pipeline is the cheapest reliability a software team can buy, and the clearest sign of whether releasing is currently a routine or an event.
$20k+
Typical project value
2 min
To post a project
What do you need built?
Start here and add detail as you go.
Free - No obligation - Your details stay private
What people usually mean by ci/cd
CI/CD means every change is built and tested automatically, and getting it into production is a button rather than a procedure. It is bought after a bad release, or when someone notices that only one person knows how to deploy. The work is modest and the difference it makes is not.
A first pipeline
Build, test and deploy one application from a commit, with a staging environment and a way back. Usually a fortnight and the highest return here.
Pipelines plus environments
Environments defined as code so staging genuinely matches production, and can be rebuilt rather than remembered.
Several applications on one pattern
Shared pipelines and conventions across a portfolio, so a new service starts with the plumbing already decided.
What it costs
Indicative ranges from projects posted here. Use them to sense-check a quote, not to budget precisely.
One application
Automated build, test and deploy, staging, rollback and documentation.
$10k – $25k
Pipeline and environments
The above with infrastructure as code, secrets management and environment parity.
$25k – $70k
Portfolio
Shared pipelines, templates and conventions across several applications and teams.
$70k+
Questions worth asking a provider
·How long does a release take today, and how long once you are done?
·Can you demonstrate a rollback, including database changes?
·Which tests run in the pipeline, and what happens when one is flaky?
·Where will secrets live, and who can read them?
·Can our own team change the pipeline without you?
Common questions
How much does a CI/CD pipeline cost in New Zealand?
Automating build, test and deployment for one application, with a staging environment, rollback and documentation, is $10,000 to $25,000. Adding infrastructure as code, environment parity and secrets management is $25,000 to $70,000. Standardising across several applications starts around $70,000. Pipeline runner costs are usually tens of dollars a month.
We are a small team. Is it worth it?
Yes, and small teams get more from it than large ones. In most small businesses exactly one person can deploy, and everyone has quietly agreed not to think about what happens when they are on leave. A pipeline anyone can run removes a genuine business risk, and it makes releases small and frequent — which is the single largest reduction in release risk available to anyone.
What if we have no tests?
Start anyway. A pipeline that builds, checks the code compiles, runs whatever checks exist and deploys consistently is already worth having — most release failures are process mistakes rather than logic bugs. Then add tests around the parts where a failure costs money. A firm that says you must write a full test suite before any pipeline can exist is proposing a much larger project than you asked for.
What is the most commonly missing piece?
A tested rollback. Most teams can deploy and assume they could undo it, then discover during an incident that the database migration only runs forwards. Ask every firm to demonstrate a rollback rather than describe one, and ask specifically what happens to schema changes. The answer separates people who have run production systems from people who have configured pipelines.
Which tool should we use?
Whichever is closest to where your code already lives. GitHub Actions if you are on GitHub, GitLab CI if you are on GitLab, Azure Pipelines if you are a Microsoft business. All are capable and the choice matters far less than whether the pipeline is understandable and whether your own team can change it. Be wary of a proposal built around a tool only the consultant knows.
CI/CD projects open right now
Titles and categories are public. Full briefs, budgets, regions and buyer detail are visible to approved providers only.
Updated daily
No open projects in this category right now. New briefs are posted every week.
Write down how you release today
Before anyone quotes, describe the current process honestly. It is the cheapest specification available and it makes every quote comparable.
- How many steps, and are they written down anywhere?
- How long does it take, start to finish?
- Who can do it? If the answer is one name, that is the finding.
- When did you last release, and when did a release last go wrong?
- What happened that time, and how long until it was back?
Then ask each firm what those numbers will be when they are finished. A proposal that cannot answer in those terms is selling tools. One that says "three hours and one person who knows how becomes eight minutes any developer can run" is selling an outcome.
Small and frequent beats large and careful
The instinct when releases are frightening is to release less often and test more before each one. It makes things worse.
A quarterly release contains three months of changes, so when something breaks nobody knows which change did it, and rolling back means losing everything. A daily release contains one change, and the cause is obvious.
This is the actual benefit of a pipeline. Not the automation itself, but that automation makes small releases cheap enough to do, and small releases are what reduce risk.
Demand a demonstrated rollback
Most teams can deploy. Far fewer have tested going back, and the discovery usually happens during an incident at an inconvenient hour.
Ask each firm to show a rollback rather than describe one, then ask three follow-ups:
- How long does it take?
- Can anyone on the team do it, or only you?
- What happens to database changes?
That last one is the important one. A schema migration that only runs forwards makes rollback a fiction. It is why experienced teams stage schema changes — add the column, backfill it, switch the code, remove the old one — so that yesterday's code still works against today's database.
Start even if you have no tests
A common and unhelpful answer is that a pipeline is pointless without a test suite. It is not.
A pipeline that builds the application, confirms it compiles, runs whatever checks exist and deploys the same way every time already removes most release failures — because most release failures are somebody skipping a step, not a logic bug.
Then add tests where they pay: around the calculations that involve money, the integrations that touch other systems, and the paths a customer takes to give you money. Not everywhere.
A firm insisting on full coverage before any pipeline exists is proposing a much larger project than the one you asked about.
Handle flaky tests deliberately
A test that fails one run in twenty for no reason is worse than no test, because within a fortnight the team is re-running the pipeline on red and has stopped reading the result.
Ask what the policy is. A workable one: a flaky test is quarantined immediately, a ticket is raised, and it either gets fixed or deleted within a sprint. What you cannot have is a pipeline everyone ignores.
Environments should match
"It worked on staging" usually means staging has different configuration, different data, or a setting somebody changed by hand two years ago.
Infrastructure as code — Terraform, Bicep, CDK — puts the environments in files you own, so they genuinely match and can be rebuilt rather than reconstructed from memory. Ask for the repository as a deliverable; it is also what makes changing consultant possible.
Ask where the secrets are going
As part of any pipeline work, ask where production credentials live today. Common answers include a file in the repository, a shared spreadsheet, and one developer's laptop.
They belong in the pipeline's own secrets store or a dedicated secrets manager, scoped per environment, with a record of what was accessed and a way to rotate without a redeploy. It is usually a quick fix during work that is happening anyway.
Make sure your team can change it
A pipeline only the consultant understands is a dependency you did not intend to buy. Ask:
- Is the pipeline definition in our repository, in a format our developers can read?
- Can we add a step without you?
- What documentation do we get, and does it cover what to do when a deployment fails at 5pm?
- Is anything here specific to a tool only you use?
Comparing five quotes
Read for:
- Who asked how long a release takes today?
- Who committed to numbers for afterwards?
- Who demonstrated a rollback including database changes?
- Who chose a tool close to where your code already lives?
- Who described what your team can change without them?
Describe how you release now, who can do it, what broke most recently, and what you run on. Firms who do this work will ask about your last bad release before they ask about your stack.
Related services
Not quite what you are after? These are the briefs most often confused with ci/cd.
Get up to 5 quotes for your ci/cd project
You choose who may contact you. Free to use, no obligation.