Project
Codzgarage CI/CD pipeline
FTP and manual uploads replaced with GitLab push-to-deploy for 40–50 developers across staging, QA, and production.
40–50Developers
3Environments
FTP →Git deploy
Context
- Org
- Software services company — ~50 developers across multiple concurrent client projects.
- Constraint
- Deployments via FTP and manual file uploads. Schema drift and overwritten files causing production and demo incidents.
- Requirement
- Standardized pipeline with environment promotion gates and automated database migrations.
Role & scope
Team lead and primary engineer for the CI/CD initiative.
- Designed multi-environment pipeline: staging → QA → production
- Built automated database migration steps into deploy stages
- Replaced FTP workflows with GitLab push-to-deploy
- Documented branching strategy and rollback procedures
Key decisions
GitLab CI/CD over Jenkins
Team already on GitLab. Native CI/CD keeps pipelines next to source — no separate tool to operate.
Automated migrations in pipeline
Schema drift was a recurring production issue. Migrations run on deploy with explicit production gates.
Single pipeline, environment-specific config
One pipeline definition with per-environment variables — less duplication as project count grew.
Architecture
Developer push
│
▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ GitLab │────▶│ Staging │────▶│ QA │
│ CI/CD │ │ deploy │ │ deploy │
└─────────────┘ └─────────────┘ └──────┬──────┘
│
▼
┌─────────────┐
│ Production │
│ + migrate │
└─────────────┘
Results
| FTP → Git | Manual uploads replaced with push-to-deploy |
| 3 envs | Staging, QA, production on automated promotion path |
| 40–50 | Developers supported without deployment bottlenecks |
| Fewer | Production incidents from overwritten files and schema drift |
Retrospective
- Deploy friction compounds as team size grows — pipeline work should precede the 30-developer mark.
- Would add deploy frequency metrics from day one to track improvement.