CI/CD for a 36-Person Team: What Actually Worked (and What Didn't)

CI/CD for a 36-Person Team: What Actually Worked (and What Didn't)

Rolling out CI/CD to a team of 36 developers across 8 concurrent projects is not a weekend task. Here's the honest account of what we tried, what failed, and what we kept.

What We Started With

Manual deployments via SSH. A shared staging server that was perpetually broken. Developers afraid to push on Fridays. Sound familiar?

Attempt 1: Full GitOps from Day One (Failed)

We tried to implement full GitOps with ArgoCD immediately. The problem: our team had varying Docker experience, and the cognitive overhead of debugging Kubernetes manifests on top of learning the new workflow caused adoption to stall. Two weeks in, people were bypassing the pipeline.

What Actually Worked: Incremental Adoption

We broke it into three phases over 8 weeks:

**Phase 1 — Automated testing only.** GitHub Actions runs PHPUnit and ESLint on every PR. No deployment automation yet. This built trust in the pipeline without changing deploy habits.

**Phase 2 — Automated staging deploys.** Merges to `develop` auto-deploy to staging via Docker Compose on a single VM. Simple, debuggable, fast.

**Phase 3 — Production deploy with manual gate.** A one-click approval step in GitHub Actions before production deploy. Gives confidence without removing human oversight.

The Numbers

Deployment time: 45 minutes → 8 minutes. Post-deploy incidents: down 60%. Developer confidence: measurably higher (we surveyed the team).

Key Lesson

CI/CD adoption is a people problem as much as a tooling problem. Start with the part that gives developers immediate value (fast feedback on PRs), then expand.