Friday 6:30 p.m.: urgent fix via FTP, file forgotten, opcode cache not cleared, rollback impossible because nobody tagged the previous version. The team is two developers and a founder — no dedicated SRE, no platform budget. Yet a thirty-line pipeline would have deployed the same fix in two minutes, with history.
CI/CD for a small team is not a DevOps catalog. It is automating gestures you already repeat — and stopping tired manual clicks on production.
The minimum viable pipeline
Five steps suffice for most web projects:
1. Trigger — push to main or merged pull request.
2. Install, lint and test — what often breaks production: syntax, payment tests, migration dry-run.
3. Build — versioned artifact (tarball, Docker image, compiled assets).
4. Staging deploy — automatic; smoke test with curl or light Playwright.
5. Production deploy — manual with approval or v* tag; email or team chat notification.
| Step | Common tool | Skip if… |
|---|---|---|
| Lint | ESLint, PHPStan | Never — near-zero cost |
| Tests | PHPUnit, Jest | Throwaway prototype only |
| Build | npm run build | Plain PHP, no compiled assets |
| Deploy | SSH + rsync, Clever Cloud, Forge | Shared host without SSH |
Automate what already caused an outage first. The rest waits.
Hosting and deploy mode
On a VPS with SSH, prefer an idempotent script, releases in /var/www/releases/ and a current symlink — rollback means repointing the link. On PaaS (Clever Cloud, Platform.sh, Render), git push deploy often suffices; CI calls CLI or webhook. On shared hosting, CI stays limited — sometimes FTP only. Consider VPS or PaaS once you deploy more than twice a week.
Compare git-deploy hosts in our comparator.
Minimal workflow example
A thirty-line .github/workflows/deploy.yml often suffices: trigger on main, install dependencies, lint, test, build, SSH deploy to staging. Production stays manual via workflow_dispatch or tag. Document secret variables in the internal README — SSH host, private key, deploy path — so the procedure survives a developer departure.
Small-team mistakes
A twenty-five-minute pipeline gets bypassed: nobody waits, FTP returns. Cleartext secrets in a committed .env remain the most frequent compromise cause. Auto production without staging turns every merge into roulette. No documented rollback triggers panic at first failure. Finally, without notifications, broken deploy is found by the client — never by the team.
Rollback without drama
Tag git on each production release. Keep the last N artifacts. Plan one-step rollback via symlink or PaaS command. For the database, prefer reversible migrations or pre-deploy backup — see our backup strategy guide.
The climax: automation that never runs
This is the operational summit: the tool exists, discipline does not. Three always-green steps beat a bypassed cathedral.
Decide and move forward without blind spots
Start by listing the last three deploy-related outages — that is your priority backlog. Then write a five-step max workflow covering those precise risks. Wire forge secrets and automatic staging deploy. Require a smoke test before any production release. Document rollback on one page accessible to the whole team. If you containerize the artifact, also see our Docker for beginners guide.
Frequently asked questions
Which CI tool for two developers?
GitHub Actions or GitLab CI is enough. Avoid self-hosted Jenkins while admin costs more than gain — two developers cannot maintain a CI forge alongside the product.
What to test before deploy?
Linter, critical tests and clean build form the base. Add staging HTTP test if available — no need for exhaustive coverage to start.
Auto prod deploy on merge?
Too risky without staging. Auto-deploy staging; keep production manual or tag-triggered after validation.
Where to store CI secrets?
In encrypted forge secrets, never the repo. Plan rotation on team departure.
CI/CD for a small team is not "do it like Google." It is no longer deploying production from the couch laptop — without Friday night's explicit permission.