WordPress CI/CD and DevOps
Your code lives in Git, and new versions go live without downtime.
mainLivea3f9c21- Code checks
- PHPStan
- PHP_CodeSniffer
- Tests
- PHPUnit · 214 tests
- Build
- composer install
- npm run build
- Staging
- staging.client.no
- Playwright · 18 flows
- Production
- client.no
- Total time
- 3 min 55 s
- Downtime
- 0 s
- Previous release
- Ready to roll back
Releasing WordPress codewithout uploading files by hand
With CI/CD, code is tested automatically before it goes live on your site. Many WordPress sites are still updated by someone uploading files over FTP straight to the live site, with no test and no copy of the old version. If one file is wrong, the checkout on an online shop can stop working, and there's no easy way back. Manual checklists get skipped when people are busy, so we let the tests run automatically on every change.
pxl-tripletexIn reviewLivefinal readonly class CreditNoteSync{public function __construct(private TripletexClient $tripletex,) {}public function handle(WC_Order_Refund $refund): void{$this->tripletex->creditNotes()->create(CreditNote::fromRefund($refund),);}}
- PHPStan, level 9
- Pest46 tests
- Migration on staging
- Screenshot test32 pages
We also take over sites where only one developer knew how changes were released, and that developer has left. Nobody knows for certain which plugin versions are running, because there's no log to check. Without that overview, it's hard to say what a new change might affect.
The setup uses standard tools. The code lives in the version control system Git, every change a developer submits starts automated tests, and the release itself runs the same steps each time. It's useful as soon as two developers work on the same site. It's part of the standard setup in our enterprise WordPress development, so it doesn't come as an extra.
- Releases in a normal week across our clients
- 30+
- From submitting a change to it being tested and live
- <15min
- Downtime for visitors when we release
- 0s
- From spotting an error to the previous version running
- <5min
What a WordPress CI/CD pipeline is made of
The tools vary from project to project. The principle is that code that fails its tests doesn't get released.
Everything in Git
The theme and every custom plugin live in version control with their full history. You can see who changed a file last autumn and why, even when nobody remembers.
WordPress managed with Composer
Composer is a tool that keeps track of which versions of WordPress and plugins the site uses. We set it up following the Bedrock model, with locked versions, so a new environment matches the live site. Small differences between environments are a common cause of bugs that are hard to track down.
Automated tests
Automated code checks and unit tests (PHPUnit) run every time a change is submitted. The testing tool Playwright then goes through the site in a real browser, filling in forms and logging in, before the change reaches visitors.
A test environment that copies the site
The test environment (staging) is a copy of the site where changes are tested before they're published. It runs the same PHP version and database as the live site, so bugs show up there and can be fixed before customers see them.
Two versions side by side
The old and new versions run at the same time while the new one is checked automatically. Traffic moves across when every check has passed, and it can move back just as quickly if the new version throws errors.
Monitoring and alerts
We measure response times and error counts before and after every release. If the site slows down or starts throwing more errors, the developers get an alert, usually before customers notice anything.
How we update the sitewithout downtime
Each new version is built in full in its own folder on the server, with all packages and finished CSS and JavaScript files, while the current version keeps serving visitors. No files are overwritten along the way, so visitors don't see a maintenance page.
client.noCheckingNew version live/var/www/client.no- releases/2026-10-08-1512previous
- releases/2026-10-10-0930new
- shared/ · uploads and .env
releases/2026-10-08-1512releases/2026-10-10-0930- Responds on /health
- Database connected
- Home page, checkout and contact load
- Symlink moved
Before the switch, we check the new version automatically. The checks confirm that the site responds, that it can reach the database and that the most important pages load. When everything has passed, we move a pointer on the server (a symlink) to the new version, and no requests are lost. The switch takes milliseconds, so we can release on a Tuesday morning just as easily as in the early hours of Sunday.
If a release does fail, we move the pointer back to the previous version. The site is then back as it was within minutes, without anyone having to restore a backup. You can read more about the setup in our case study on publishing without downtime.
Manual uploads and CI/CD compared
| Manual uploads | CI/CD pipelineStandard at PXL | |
|---|---|---|
| Release method | Files uploaded with an FTP program | Automatic when code is submitted |
| Time per release | 15–45 minutes, manual | 2–5 minutes, automated |
| Back to the previous version | Restore a backup, 30–60 min | One command, within minutes |
| Testing | Manually in the browser, if there's time | Automatic on every change |
| Traceability | None | Full Git history |
| Who did what | Unknown | Name, time and reason |
| Downtime during releases | Unpredictable | 0 seconds |
| Teamwork | One person at a time | Several people in parallel |
We can look at how you release changes today, and what it would take to automate it.
When CI/CD isn't worth it
Not every site needs a full pipeline.
A simple brochure site with a standard theme and a few well-tested plugins can manage for a long time with the WordPress admin panel and a maintenance agreement, where someone experienced tests updates before they go out. On a project like that, a full pipeline costs more than it saves, and we'll tell you so.
- Brochure site on a standard themeFew plugins and rare changesMaintenance is enough
- Shop with orders every hourCan't be tested on the live sitePipeline
- Vipps or BankIDIntegrations that need testingPipeline
- Several developers in one weekChanges that mustn't trip over each otherPipeline
If an hour of downtime costs more than NOK 10,000, a pipeline pays for itself.
That changes once the site makes money. An online shop that takes orders every hour can't use the live site as its test environment. The same goes for sites with integrations with Vipps, Norway's mobile payment app, or BankID, the national electronic ID, and for sites where several developers make changes in the same week.
Our rule of thumb is this: if an hour of downtime costs more than NOK 10,000, or the site will run custom code for more than two years, the pipeline pays for itself. The setup is a one-off cost, and after that the pipeline is looked after under the maintenance agreement.
Adding CI/CD to an existing WordPress site
- 01 / 05
Assessment
First we look at how changes reach the live site today. Then we separate custom code from plugins and themes made by others.
- 02 / 05
Version control
The theme and in-house plugins move into Git without losing their history. WordPress and plugins from other vendors are managed with Composer, and passwords and API keys move out of the code into the server settings.
- 03 / 05
Test environment and pipeline
We set up a test environment that is a copy of the site, and connect it to a pipeline that runs code checks and tests on every change.
- 04 / 05
Automatic releases
Changes are released automatically with checks, first to the test environment and then to the live site. We switch off file editing in the admin panel, so every change has to go through the pipeline.
- 05 / 05
Handover
Your team gets documentation and training. You can run the pipeline yourselves, or let us look after it under a maintenance agreement.
- Mapping1 day
- Git and Composer2 days
- Staging and pipeline3 days
- Automated releases1 day
- Handover and trainingHalf a day
The site runs as normal, and editors keep publishing as before.
If you're unsure how your current setup works, a technical review is a sensible first step.
Frequently asked questions
What does it cost to set up CI/CD for WordPress?
A complete setup starts at NOK 50,000 as a development project. That gets you the code in Git, managed with Composer, and automated tests on every change. A lighter version with version control and automatic releases, but without full test coverage, takes two to three days and is priced at our day rate, which starts at NOK 12,000. Once the pipeline is running, it's covered by maintenance agreements from NOK 2,500 a month. Whether it pays off depends on what an hour of downtime costs you and how long the site will run custom code.
What is CI/CD for WordPress?
CI/CD stands for Continuous Integration and Continuous Deployment. Continuous Integration means all code is checked into Git and tested automatically straight away. That way, conflicts between two developers' work show up before they reach the site. Continuous Deployment takes over from there: tested code is released to staging and then to the live site, without FTP uploads or checklists that get skipped when there's a deadline. For you, it means you can see who made each change and why, and the previous version is back within minutes if something goes wrong.
Does it work with regular plugins and themes?
Yes. Plugins and themes from other vendors are installed with Composer and WordPress Packagist instead of from the admin panel, with their versions locked in composer.json. A plugin update then becomes an ordinary code change that is tested in staging before it goes further. On the live site we keep file editing in the dashboard switched off, so every change has to go through the pipeline. It takes a bit of discipline from everyone. In return, the log shows exactly which code is running on the site and when it last changed.
What is Bedrock, and do I need it?
Bedrock is a way of organising the files in a WordPress project, made by the Roots team. WordPress is managed with Composer, settings move out of the code, and only a separate folder is reachable from the internet. Bedrock isn't required, and CI/CD also works with a standard folder structure. On new projects we still choose the Bedrock model almost every time. It makes it easier to keep passwords and keys out of the code, and to handle the differences between the developer's machine, staging and the live site.
How long does it take to introduce CI/CD?
A basic pipeline with Git and automatic releases takes two to three days. The full package, with a Composer structure and proper test coverage, usually takes one to two weeks on an existing installation. That depends on how much old custom code needs tidying first. The site runs as normal throughout, and editors publish as before.
Can you take over an existing pipeline?
Yes. It might be a half-finished setup in GitHub Actions, or a pipeline nobody has touched since the developer who wrote the configuration left. We start with a technical review to see what works and where the risks are. Then we document and update the setup and take over day-to-day operation. GitLab CI and Bitbucket Pipelines work just as well as GitHub Actions, since the principles are the same.
Talk to us about releases and testing
Tell us briefly how you release changes today. You'll get an honest answer on whether a pipeline is worth the money for you.