git push production main — three minutes later the site shows a 500 because a SQL migration was skipped. The team knew they had to "be careful." The ritual was fine for a personal blog; it was wrong for a store taking payments.
Git push deploy: remote repo on the server runs a hook that pulls code and reloads PHP-FPM. CI/CD: every push goes through a pipeline that builds, tests, artifacts, then deploys — or refuses. The question is not trendy tech; it is what error cost your organization accepts without a net.
Two rituals, two safety levels
| Dimension | Git push → server | CI/CD (Actions, GitLab, etc.) |
|---|---|---|
| Pre-prod tests | Manual (often skipped) | Automated, blocking |
| Reproducibility | "Works on my machine" | Identical artifact per commit |
| Rollback | Git revert + manual redeploy | Tag/release + pipeline redeploy |
| Audit | SSH logs | Pipeline history + approvals |
| Secrets | Key-on-server risk | CI vault, cloud OIDC |
| Setup time | Hours | Days then minutes/deploy |
Push-direct simplicity is paid in incidents nobody priced before the first Friday evening.
When direct push still holds
Solo, low-criticality project. Static blog, portfolio: local build, rsync or push hook, backup before deploy.
Identical staging. Push staging first, human check, then prod fast-forward — strict manual discipline.
Co-located team, rare deploys. Quarterly update, announced maintenance window.
Non-negotiable even when "simple":
- Protected
mainbranch - Tag or commit hash noted for rollback
- Versioned DB migrations tested on copy
When CI/CD becomes minimum bar
E-commerce, SaaS, sensitive data. Unit + integration tests + post-deploy smoke test.
Team > 2 developers. Code review (PR) + green pipeline before merge.
Compliance. Traceability of who deployed what, when — ISO, SOC2, enterprise clients.
Multi-environment. dev → staging → prod with controlled promotion.
Realistic minimal pipeline:
- Lint + tests on PR
- Build artifact (container or tarball)
- Auto deploy staging
- Manual or auto prod deploy after tag
Hosts like Clever Cloud or PaaS platforms often integrate native Git deploy with remote build — not raw push to /var/www.
Common mistakes on both sides
Direct push: Friday 6 p.m. deploy, irreversible migrations, temporary 777 permissions.
CI/CD: slow unoptimized pipeline, ignored flakiness, plain-text secrets, prod deploy without staging.
The peak: post-receive is not a strategy
Decide and move forward without blind spots
- Estimate hourly cost of prod outage (revenue, SLA, reputation).
- If > low : minimal pipeline within a week (GitHub Actions + SSH deploy or PaaS webhook).
- Keep direct push only for disposable envs with backup.
- Document rollback under 15 minutes — tested.
Compare hosts with integrated Git deploy in directory. See Docker Compose or Kubernetes for next architecture step.
Frequently asked questions
Is direct Git push acceptable in production?
Sometimes for solo brochure sites. Once failure is costly, skipping automated tests is unacceptable.
Does CI/CD slow down small teams?
Minimal pipeline: 2–5 min, often less than manual rollback after prod bug.
Where should deploy secrets live?
Encrypted CI variables, vault, deploy-only keys — never in repo or generalized root SSH.
Can you combine both?
Yes: push triggers CI that deploys if green. Avoid raw prod push with no gate.
Before the next deploy, ask: if this commit breaks prod, how many minutes to roll back — and who knows how? If the answer is fuzzy, the ritual is not yet matched to the risk.