WordPress CI/CD and DevOps

A complete setup starts at NOK 50,000 as a development project. For that, the code sits in Git on a Composer structure, and automated tests run on every push. Lighter variants with version control and automatic deploys, but without full test coverage, land at the bottom of that range. Our day rates run NOK 12,000–15,000, and once the pipeline is live, its operation is covered by maintenance agreements from NOK 2,500 per month. The number looks large until you set it beside what one failed Friday release costs a webshop in lost orders and frantic cleanup. That bill is bigger, it arrives unannounced, and we routinely watch the first bad deploy a pipeline catches pay for the whole setup on its own.

The letters stand for Continuous Integration and Continuous Deployment. Continuous Integration means all code is checked into Git and tested by machines the moment it arrives, so two developers' work merges cleanly instead of colliding in production where nobody notices until a customer does. Continuous Deployment takes it from there: code that passed the tests moves to staging and then production through an automated process, with no FTP client and no checklist for somebody to skip under deadline pressure. In practice that gives you two things — every change is traceable back to who made it and why, and when a release misbehaves, the previous version is back within minutes.

It does, and well. Third-party plugins and themes install through Composer and WordPress Packagist instead of the dashboard, each version locked in composer.json. A plugin update then becomes an ordinary code change that passes through staging before any visitor encounters it. Dashboard file editing stays off in production, which leaves the pipeline as the only door in. The cost is a little discipline. The reward is certainty about exactly which code the site runs, and when any of it last changed.

Bedrock is a project structure for WordPress, built by the Roots team. Under Bedrock, WordPress itself becomes a Composer dependency, configuration moves into environment variables, and a dedicated web directory serves as the document root. Strictly speaking it is not something you need, since a standard WordPress layout works with CI/CD perfectly well. For new builds we still reach for the Bedrock approach almost without exception, because it bakes in the habits the pipeline would otherwise have to police with custom scripts, especially around secrets and the differences between local, staging and production.

Count on two to three days for a basic pipeline with Git and automatic deploys. The full version, Composer structure and proper test coverage included, usually takes one to two weeks on an existing installation, with old custom code as the main variable in the schedule. The site keeps running normally throughout. Editors publish as always. Visitors see nothing.

Yes, and often. Half-finished GitHub Actions workflows. YAML files nobody has dared open since their author left the company. We open with a technical review to establish what genuinely works and where the risk sits, then document and modernize the setup before taking over daily operation. GitLab CI and Bitbucket Pipelines suit us as well as GitHub Actions do. Underneath, the ideas are identical.