A WordPress Development Workflow for Agencies: From Local to Live
With five client sites, almost any way of working holds up. With fifty sites, several developers and a partner or two, it falls apart in predictable ways: someone edits a live site directly, code goes missing, a plugin update takes a site down, and nobody can say which version is running where.
A shared workflow fixes most of it. The setup below works across dozens of client sites, with developers in house or at a white label partner.
1. Work locally
Every change starts on a developer’s machine. Nobody edits the live site. Local, DDEV or a Docker setup gives each developer a full copy of the site to break safely. When you need real data, pull a recent copy of the production database and strip or anonymise personal data first.
2. Put it in Git
Every client site gets a Git repository for its theme and custom plugins. You get a full history of who changed what, a quick way to roll back, and a safe way for several developers to work on the same site at once.
Leave WordPress core, third-party plugins and uploads out of the repo, or manage them with Composer once your team is comfortable with it.
3. Branches and pull requests
Most agencies don’t need anything elaborate. A main branch that matches production, a short-lived branch for each task, and a pull request for every change with a line of description and a link to the task. That’s enough.
The pull request is where review happens.
4. Review before shipping
A second developer catches bugs, security holes and shortcuts that get expensive later. The review can be quick: does the change do what the task asked, does it follow the WordPress coding standards, is output escaped and input sanitised, does anything obvious break? Running PHPCS automatically takes the boring part out of it.
5. Staging for every site
Each client site needs a staging environment that matches production. Changes go there first, get tested, and get approved by your team or the client before going live. Core and plugin updates take the same route. Our guide to WordPress testing and QA covers what to check.
6. Deploy the same way every time
Dragging files over FTP is where things go wrong. Use something repeatable: your host’s Git deployment, a CI/CD pipeline or a deployment tool. Take a backup before every deploy and know exactly how you’d roll back.
7. One place for tasks
Code is only half of the workflow. Every request should become a task in one system (ClickUp, Asana, Jira, Trello, whichever you use) with a clear description and acceptance criteria, links to the design, staging and pull request, and an owner, priority and due date.
Then anyone can see what’s in progress, and reporting to clients takes minutes instead of an afternoon.
8. A short doc per site
Keep a page for every client site: hosting, environments, how to deploy, the plugins that matter, integrations and anything odd. When a new developer joins, or a site comes back after a year of silence, that page saves hours of digging.
9. Keep maintaining after launch
A good workflow does not stop at launch. Updates, backups and monitoring should run on a schedule, with updates tested on staging first. If your developers would rather spend that time on new projects, a white label maintenance team can take it over.
Where a white label partner fits
A good partner adopts your workflow instead of bringing their own. They work in your repositories, deploy to your staging environments, use your task boards, follow your coding standards and send pull requests your team can review. From your side, it looks like a few more developers joined the team.
That is how we work with agencies at Deviart, whether through on-demand tasks, retainers or a dedicated developer. Let’s talk about your workflow.
