5.4Deployment & CI/CD (Git, server, hosting)
The essentials in 30 seconds
- Deploying = going online: running the app on an accessible server — simple shared to start, PaaS/VPS for more control.
- CI/CD = auto delivery: on each push, test (PHPUnit) then deploy if everything passes — the end of risky manual FTP.
- Secrets out of code: config and secrets in environment variables (.env out of the repo) — never in Git.
Running case — Riad goes online in Constantine
Riad's containerised shop runs well — but only on the team machines in Constantine. He deploys it: connected Git repo, environment variables set on the hosting, HTTPS active, errors logged instead of displayed. Then he adds a pipeline: on each push, the PHPUnit tests run, and deployment follows only if they pass. Final episode of cases 5.1-5.3 — Riad delivers a real online service.
Final episode of cases 5.1-5.3 — Riad closes the loop of design, performance and Docker with going to production.
1. Hosting and deploying via Git
Deployment runs the application on a server accessible on the Internet (instead of localhost). PHP has the advantage of being very widespread and easy to host: shared hosting (the simplest and cheapest — the hoster manages everything — ideal to start and for small sites, with little control), PaaS platforms (simplified deployment from the Git repo), the VPS (more control but more responsibilities: installing PHP, Nginx/Apache, MySQL, securing, HTTPS), the cloud for scale. Central role of Git: files are no longer transferred “by hand” over FTP (a source of errors) — the server fetches the code from the repo, more reliable and traceable. Riad starts with shared hosting for the showcase, and aims for a VPS as the shop grows.
Recommendation: shared for getting your projects online fast, PaaS for modern simplified deployment, VPS to learn administration or gain control.
2. CI/CD and production essentials
CI/CD automates the path from code to production. Continuous integration: on each push, a pipeline runs the tests (PHPUnit) and quality analysis to catch problems early. Continuous deployment: if everything passes, the code is deployed automatically. GitHub Actions (or GitLab CI) creates these pipelines. Benefits: automation (no more tedious manual steps), reliability (nothing broken goes to production), speed, traceability. PHP production essentials: secrets and config by environment (a .env file out of the repo), HTTPS mandatory, errors not displayed (logged — they can disclose sensitive information), OPcache enabled, optimised Composer autoloader, migrations run at deployment, separated environments (dev/staging/prod). Riad writes his first pipeline: install, test, deploy if green — it is the culmination, not only creating but delivering.
Even simple, a pipeline changes everything: tests are never “forgotten” before a deployment again.
3. Choosing without going wrong
The fundamental trade-off: simplicity versus control. Shared: extreme simplicity to start, little control. PaaS: modern simplicity with no server to manage. VPS: total control and flexibility, but you manage everything (security, updates, backups). For a prototype, a simple deployment is enough; once a project is serious, deployed regularly or in a team, even a simple CI/CD brings real value. Riad compares hosters' offers (plans and limits often evolving, he checks the current documentation when choosing) and gets the sensitive infrastructure choice validated by his IT department before exposing real data, database backups included.
In all cases, the essentials remain: secrets in environment variables, HTTPS, logged errors, OPcache, backups, separated environments.
🔎 Concrete example — Riad's pipeline
On each push: install, test, deploy if green.
# GitHub Actions (.github/workflows/ci.yml)
# on each push:
# composer install → vendor/bin/phpunit → deploy if green
# secrets & config: environment variables (.env not committed)
# production: HTTPS + OPcache + logged errorsReading: the pipeline is the gate: nothing broken gets through.
Lesson: secrets live in the environment, never in the repo.
Section vocabulary
- Deployment
- Running the app on a server accessible on the Internet.
Simple example: Riad's shop leaves localhost for a public address.
What it is not: sending files by hand over FTP.
Reflex: is my app accessible outside my machine?
- Shared hosting
- Shared server where the hoster manages PHP, the database and the web server.
Simple example: Riad puts the showcase online fast and on a small budget.
What it is not: a server you administer yourself.
Reflex: do I need control, or simplicity?
- VPS
- Rented virtual server you administer yourself.
Simple example: Riad would install PHP, MySQL and HTTPS there himself.
What it is not: hosting where everything is managed.
Reflex: am I ready to take on security and backups?
- CI/CD
- Pipeline that tests on each push and deploys if everything passes.
Simple example: Riad's push triggers PHPUnit then automatic going online.
What it is not: manual deployment with FTP.
Reflex: can a push go to prod without tests?
- Environment variables
- Config and secrets supplied by the environment, out of the code.
Simple example: Riad's database password lives in .env, never in Git.
What it is not: a secret written hard-coded in the code.
Reflex: is a secret lying around in my repo?
In practice — Deploying and automating a PHP application
- Choose a suitable hosting (shared for a small site, PaaS/VPS for more control) and deploy your application via Git (no manual FTP).
- Configure production: secrets and settings via environment variables (.env out of the repo), HTTPS, logged errors (not displayed), OPcache enabled.
- Set up a CI/CD pipeline (GitHub Actions): on each push, run the tests (PHPUnit) and deploy if everything passes.
- Manage database migrations at deployment (framework) and separated environments (dev / staging / production).
Ready-to-say script — announcing going online
“Our shop is ready to leave localhost: I deploy it via Git — secrets in environment variables, HTTPS active, logged errors. I add a simple pipeline: PHPUnit on each push, deployment only if everything passes. Before exposing real data, I get the infrastructure choice and backups validated by the IT department.”
Say to the manager to get going online and the IT-department circuit on sensitive data approved.
Copy-paste template — generic PHP CI pipeline
name: CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
- run: composer install --no-progress
- run: vendor/bin/phpunitSolo / small budget
Riad alone: shared hosting + a pipeline testing on each push is enough — no server to administer.
Small business / small team
Separate dev and prod environments, secrets out of the repo: each push tested before going online.
SME in Constantine
Riad gets the hoster, access and backups validated by the IT department in Constantine before exposing real customer data.
Starting team
Pair: one writes the pipeline, the other checks secrets, HTTPS and backups; review before the first auto deployment.
✓ Best practices
- Start with simple hosting (shared/PaaS): online fast, HTTPS handled.
- Put config and secrets in environment variables (.env out of the repo, never in Git).
- Automate tests + deployment with a CI/CD pipeline (GitHub Actions).
✗ Common pitfalls
- Putting secrets in code or the Git repo.
- Deploying with no HTTPS or verified backups.
- Deploying manually over FTP, blind (with no automated tests upstream).
Key takeaways
- DEPLOYING = running the PHP app on a server accessible on the Internet. Options: SHARED HOSTING (simple, cheap), PaaS, VPS (control + responsibilities), cloud. PHP is easy to host.
- Deploying via GIT (the server fetches the code) rather than manual FTP (reliable, traceable). CI/CD (GitHub Actions) automates: CI (PHPUnit tests on each push) + CD (deploy if it passes).
- Configuration & SECRETS: via environment variables (.env OUT of the Git repo), never hard-coded. Prod essentials: HTTPS, errors NOT displayed (logged), OPcache enabled, optimised Composer autoloader, migrations.
- This level CONNECTS everything: language → web → databases → OOP → frameworks → security → tests → optimisation → Docker → TAKING TO PRODUCTION. Knowing how to DELIVER (deploy + automate) completes the autonomous PHP developer.
48h challenge — apply tomorrow
Deploy 1 app (Git repo + HTTPS) with its secrets in environment variables: does one push trigger the PHPUnit tests?
- I can explain CI vs CD in one sentence.
- My app is online (HTTPS) with no secret in Git.
- I know when to move from shared to VPS.
Frequently asked questions
How to choose where and how to host a PHP application, especially when starting out?
By project size, need for control and your level. Shared hosting is the simplest and cheapest — the hoster manages everything — ideal to start and for small sites (PHP is massively supported there, an asset). PaaS platforms simplify deployment from Git, with no server to manage. The VPS gives more control (versions, config) but more responsibilities (installation, security, HTTPS, backups) — instructive, more demanding. Recommendation: start shared or PaaS to get your projects online; move to VPS to learn administration. Compare offers when choosing (they evolve) and get validation from the IT department before exposing sensitive data.
What are the essential points not to forget when putting a PHP application into production?
The check-list: secrets by environment (.env out of the repo, never in Git); mandatory HTTPS; errors not displayed (logged — disclosed technical details are exploitable); enabled OPcache and optimised Composer autoloader (performance); migrations run at deployment; separated environments (dev/staging/prod); backups planned and restore tested. Each of these forgotten points costs dearly: security flaw, slowness for no reason, or data loss. The CI/CD pipeline locks the gate: nothing untested goes to production.
What does a CI/CD pipeline do?