Parallel-Safe CI/CD for a Multi-Site Portfolio with Docker
Introducing GitHub Actions and Docker-based CI/CD across a group of websites so multiple developers could work in parallel on staging, testers could validate every change on a dedicated dev branch, and verified changes reached production automatically instead of by hand.
0
Manual deploy steps
3
Environments per site
Per branch
Dev environments
Automated
Deployment path
Problem
Multiple developers were shipping changes to the same group of websites without a consistent path from local changes to production — deployments were manual, staging environments diverged between developers' machines, and there was no gate that guaranteed a change had actually been tested before it reached production.
Challenges
- Letting multiple developers work on the same group of sites in parallel without their staging environments stepping on each other
- Giving testers a stable, containerized environment on the dev branch that matched production closely enough to trust
- Automating the path from a tested dev-branch change to a production deploy without a manual release step
- Keeping each site's build, environment variables, and dependencies isolated and reproducible across staging, dev, and production
- Rolling this out across an existing group of live sites without breaking whichever one shipped next
Architecture
Each site was containerized with Docker so its build and runtime environment was identical across staging, dev, and production instead of depending on whichever machine it ran on. GitHub Actions pipelines were wired to the branch model: pushes to a developer's staging branch build and deploy an isolated Docker environment for that branch, so parallel work doesn't collide; merges into the dev branch trigger a build that testers validate against; and once a dev-branch build passes testing, promoting it to the production branch triggers an automated build-test-deploy pipeline with no manual deployment step.
Developer pushes to a staging branch → GitHub Actions builds an isolated Docker environment for that branch
Change merged into dev branch → pipeline builds a shared dev environment for testers to validate against
Tester signs off on the dev-branch build
Change promoted to the production branch → pipeline runs the automated build, test, and deploy steps
Production deploy completes without a manual release step, with the previous image kept for fast rollback
Database Design
Each environment (staging, dev, production) runs against its own isolated database instance defined per Docker environment, so a developer's in-progress schema change or seed data on staging can never leak into the dev testing environment or production.
Scalability
Because each site's environment is defined as Docker configuration rather than hand-set-up infrastructure, onboarding a new site onto the same pipeline is a matter of adding its configuration rather than repeating manual setup. Parallel branch-scoped environments mean adding more developers doesn't create more contention for a single shared staging box.
Outcome
Multiple developers could work in parallel on staging without colliding, testers had a consistent dev-branch environment to validate against, and verified changes reached production automatically — removing manual deployment as a recurring source of risk and delay across the whole group of sites.
Tech Stack
Have a similar problem you're trying to architect your way through?