5.4Déploiement & CI/CD (Git, serveur, hébergement)
L'essentiel en 30 secondes
- Déployer = mettre en ligne : faire tourner l'app sur un serveur accessible — mutualisé simple pour débuter, PaaS/VPS pour plus de contrôle.
- CI/CD = livraison auto : à chaque push, tester (PHPUnit) puis déployer si tout passe — fini le FTP manuel risqué.
- Secrets hors du code : config et secrets en variables d'environnement (.env hors dépôt) — jamais dans Git.
Mini-cas filé — Riad met en ligne à Constantine
La boutique conteneurisée de Riad tourne bien — mais seulement sur les postes de l'équipe à Constantine. Il la déploie : dépôt Git connecté, variables d'environnement renseignées sur l'hébergement, HTTPS actif, erreurs journalisées au lieu d'affichées. Puis il ajoute un pipeline : à chaque push, les tests PHPUnit tournent, et le déploiement suit seulement s'ils passent. Dernier épisode des cas 5.1-5.3 — Riad livre un vrai service en ligne.
Dernier épisode des cas 5.1-5.3 — Riad boucle conception, performance et Docker avec la mise en production.
1. Héberger et déployer via Git
Le déploiement fait tourner l'application sur un serveur accessible sur Internet (au lieu de localhost). PHP a l'avantage d'être très répandu et facile à héberger : l'hébergement mutualisé (le plus simple et économique — l'hébergeur gère tout — idéal pour débuter et les petits sites, avec peu de contrôle), les plateformes PaaS (déploiement simplifié depuis le dépôt Git), le VPS (plus de contrôle mais plus de responsabilités : installer PHP, Nginx/Apache, MySQL, sécuriser, HTTPS), le cloud pour l'envergure. Rôle central de Git : on ne transfère plus les fichiers « à la main » par FTP (source d'erreurs) — le serveur récupère le code depuis le dépôt, plus fiable et traçable. Riad commence par un mutualisé pour la vitrine, et vise un VPS quand la boutique grandit.
Recommandation : mutualisé pour mettre ses projets en ligne vite, PaaS pour un déploiement simplifié moderne, VPS pour apprendre l'administration ou gagner en contrôle.
2. CI/CD et essentiels de production
Le CI/CD automatise le chemin code → production. L'intégration continue : à chaque push, un pipeline lance les tests (PHPUnit) et l'analyse qualité pour attraper les problèmes tôt. Le déploiement continu : si tout passe, le code est déployé automatiquement. GitHub Actions (ou GitLab CI) crée ces pipelines. Bénéfices : automatisation (plus de gestes manuels fastidieux), fiabilité (rien de cassé ne part en production), rapidité, traçabilité. Essentiels de production PHP : secrets et config par environnement (fichier .env hors dépôt), HTTPS indispensable, erreurs non affichées (journalisées — elles peuvent divulguer des informations sensibles), OPcache activé, autoloader Composer optimisé, migrations exécutées au déploiement, environnements séparés (dev/staging/prod). Riad écrit son premier pipeline : installer, tester, déployer si vert — c'est l'aboutissement, non seulement créer mais livrer.
Même simple, un pipeline change tout : les tests ne sont plus jamais « oubliés » avant un déploiement.
3. Choisir sans se tromper
Le compromis fondamental : simplicité contre contrôle. Mutualisé : simplicité extrême pour débuter, peu de contrôle. PaaS : simplicité moderne sans gérer de serveur. VPS : contrôle total et flexibilité, mais vous gérez tout (sécurité, mises à jour, sauvegardes). Pour un prototype, un déploiement simple suffit ; dès qu'un projet est sérieux, déployé régulièrement ou en équipe, même un CI/CD simple apporte une vraie valeur. Riad compare les offres des hébergeurs (formules et limites évoluant souvent, il vérifie la documentation actuelle au moment de choisir) et fait valider le choix d'infrastructure sensible par sa DSI avant d'exposer des données réelles, sauvegardes de la base comprises.
Dans tous les cas, les essentiels restent : secrets en variables d'environnement, HTTPS, erreurs journalisées, OPcache, sauvegardes, environnements séparés.
🔎 Exemple concret — Le pipeline de Riad
À chaque push : installer, tester, déployer si vert.
# GitHub Actions (.github/workflows/ci.yml)
# à chaque push :
# composer install → vendor/bin/phpunit → déployer si vert
# secrets & config : variables d'environnement (.env hors dépôt)
# production : HTTPS + OPcache + erreurs journaliséesLecture : le pipeline est la porte : rien de cassé ne passe.
Leçon : les secrets vivent dans l'environnement, jamais dans le dépôt.
Vocabulaire de la section
- Déploiement
- Faire tourner l'app sur un serveur accessible sur Internet.
Exemple simple : La boutique de Riad quitte localhost pour une adresse publique.
Ce que ce n'est pas : envoyer des fichiers par FTP à la main.
Réflexe : mon app est-elle accessible hors de mon poste ?
- Hébergement mutualisé
- Serveur partagé où l'hébergeur gère PHP, la base et le serveur web.
Exemple simple : Riad y met la vitrine en ligne vite et à petit budget.
Ce que ce n'est pas : un serveur qu'on administre soi-même.
Réflexe : ai-je besoin de contrôle, ou de simplicité ?
- VPS
- Serveur virtuel loué qu'on administre soi-même.
Exemple simple : Riad y installerait PHP, MySQL et le HTTPS lui-même.
Ce que ce n'est pas : un hébergement où tout est géré.
Réflexe : suis-je prêt à assumer sécurité et sauvegardes ?
- CI/CD
- Pipeline qui teste à chaque push et déploie si tout passe.
Exemple simple : Le push de Riad déclenche PHPUnit puis la mise en ligne auto.
Ce que ce n'est pas : un déploiement manuel à coups de FTP.
Réflexe : un push peut-il partir en prod sans tests ?
- Variables d'environnement
- Config et secrets fournis par l'environnement, hors du code.
Exemple simple : Le mot de passe base de Riad vit dans le .env, jamais dans Git.
Ce que ce n'est pas : un secret écrit en dur dans le code.
Réflexe : un secret traîne-t-il dans mon dépôt ?
En pratique — Déployer et automatiser une application PHP
- Choisissez un hébergement adapté (mutualisé pour un petit site, PaaS/VPS pour plus de contrôle) et déployez votre application via Git (pas de FTP manuel).
- Configurez la production : secrets et paramètres via variables d'environnement (.env hors dépôt), HTTPS, erreurs journalisées (pas affichées), OPcache activé.
- Mettez en place un pipeline CI/CD (GitHub Actions) : à chaque push, lancer les tests (PHPUnit) et déployer si tout passe.
- Gérez les migrations de base au déploiement (framework) et des environnements séparés (dev / staging / production).
Script prêt à dire — annoncer la mise en ligne
« Notre boutique est prête à sortir de localhost : je la déploie via Git — secrets en variables d'environnement, HTTPS actif, erreurs journalisées. J'ajoute un pipeline simple : PHPUnit à chaque push, déploiement seulement si tout passe. Avant d'exposer des données réelles, je fais valider le choix d'infrastructure et les sauvegardes par la DSI. »
À dire au responsable pour faire valider la mise en ligne et le circuit DSI sur les données sensibles.
Modèle copier-coller — pipeline CI PHP générique
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 / petit budget
Riad seul : un mutualisé + un pipeline qui teste à chaque push suffit — pas de serveur à administrer.
TPE / équipe réduite
Environnements dev et prod séparés, secrets hors dépôt : chaque push testé avant mise en ligne.
PME à Constantine
Riad fait valider l'hébergeur, les accès et les sauvegardes par la DSI à Constantine avant d'exposer des données clients réelles.
Équipe qui démarre
Binôme : l'un écrit le pipeline, l'autre vérifie secrets, HTTPS et sauvegardes ; revue avant le premier déploiement auto.
✓ Bonnes pratiques
- Débuter avec un hébergement simple (mutualisé/PaaS) : en ligne vite, HTTPS géré.
- Mettre config et secrets en variables d'environnement (.env hors dépôt, jamais dans Git).
- Automatiser tests + déploiement avec un pipeline CI/CD (GitHub Actions).
✗ Pièges fréquents
- Mettre des secrets dans le code ou le dépôt Git.
- Déployer sans HTTPS ni sauvegardes vérifiées.
- Déployer manuellement par FTP, à l'aveugle (sans tests automatisés en amont).
Points clés à retenir
- DÉPLOYER = faire tourner l'app PHP sur un serveur accessible sur Internet. Options : HÉBERGEMENT MUTUALISÉ (simple, économique), PaaS, VPS (contrôle + responsabilités), cloud. PHP est facile à héberger.
- Déployer via GIT (le serveur récupère le code) plutôt que par FTP manuel (fiable, traçable). CI/CD (GitHub Actions) automatise : CI (tests PHPUnit à chaque push) + CD (déployer si ça passe).
- Configuration & SECRETS : via variables d'environnement (.env HORS dépôt Git), jamais codés en dur. Essentiels prod : HTTPS, erreurs NON affichées (journalisées), OPcache activé, autoloader Composer optimisé, migrations.
- Ce niveau CONNECTE tout : langage → web → bases → POO → frameworks → sécurité → tests → optimisation → Docker → MENER EN PRODUCTION. Savoir LIVRER (déployer + automatiser) achève le développeur PHP autonome.
Défi 48h — appliquez demain
Déployez 1 app (dépôt Git + HTTPS) avec ses secrets en variables d'environnement : un push déclenche-t-il les tests PHPUnit ?
- Je peux expliquer CI vs CD en une phrase.
- Mon app est en ligne (HTTPS) sans secret dans Git.
- Je sais quand passer du mutualisé au VPS.
Questions fréquentes
Comment choisir où et comment héberger une application PHP, surtout quand on débute ?
Selon la taille du projet, le besoin de contrôle et votre niveau. L'hébergement mutualisé est le plus simple et économique — l'hébergeur gère tout — idéal pour débuter et les petits sites (PHP y est massivement supporté, un atout). Les plateformes PaaS simplifient le déploiement depuis Git, sans gérer de serveur. Le VPS donne plus de contrôle (versions, config) mais plus de responsabilités (installation, sécurité, HTTPS, sauvegardes) — formateur, plus exigeant. Recommandation : commencez mutualisé ou PaaS pour mettre vos projets en ligne ; passez au VPS pour apprendre l'administration. Comparez les offres au moment de choisir (elles évoluent) et faites valider par la DSI avant d'exposer des données sensibles.
Quels sont les points essentiels à ne pas oublier lors de la mise en production d'une application PHP ?
La check-list : secrets par environnement (.env hors dépôt, jamais dans Git) ; HTTPS obligatoire ; erreurs non affichées (journalisées — les détails techniques divulgués sont exploitables) ; OPcache activé et autoloader Composer optimisé (performance) ; migrations exécutées au déploiement ; environnements séparés (dev/staging/prod) ; sauvegardes planifiées et restauration testée. Chacun de ces points oubliés coûte cher : faille de sécurité, lenteur sans raison, ou perte de données. Le pipeline CI/CD verrouille la porte : rien de non testé ne part en production.
Que fait un pipeline CI/CD ?