Un stagiaire arrive lundi matin. Sur un projet classique, sa première journée se résume souvent à installer PHP, Composer, un serveur MySQL, cloner trois dépôts, résoudre deux ou trois incompatibilités de version avec le reste de l’équipe — et parfois, échouer, avant même d’avoir écrit une ligne de code utile. GitHub Codespaces déplace tout l’environnement de développement dans le cloud, décrit une fois pour toutes dans un fichier versionné : ouvrir le dépôt suffit à obtenir un WordPress fonctionnel, base de données et extensions comprises.
Cet article construit ce devcontainer pas à pas. Le sujet ne compare pas les solutions locales entre elles — DDEV, Lando ou Docker Compose répondent à un besoin différent, celui de garder l’exécution sur la machine du développeur.
Le fichier devcontainer.json
Placé dans .devcontainer/devcontainer.json à la racine du dépôt, ce fichier décrit l’environnement complet nécessaire au projet :
{
"name": "Projet WordPress",
"dockerComposeFile": "docker-compose.yml",
"service": "wordpress",
"workspaceFolder": "/var/www/html/wp-content/themes/mon-theme",
"forwardPorts": [80, 3306],
"postCreateCommand": "bash .devcontainer/setup.sh",
"customizations": {
"vscode": {
"extensions": [
"bmewburn.vscode-intelephense-client",
"shevaua.phpcs"
]
}
}
}
Le champ postCreateCommand est l’élément central : il déclenche un script exécuté une seule fois, à la toute première création du Codespace, chargé d’installer WordPress et de le peupler avec des données de départ.
Docker Compose pour WordPress et MySQL
services:
wordpress:
image: wordpress:php8.2
volumes:
- ..:/var/www/html/wp-content/themes/mon-theme
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_NAME: wordpress
depends_on:
- db
db:
image: mysql:8.0
environment:
MYSQL_DATABASE: wordpress
MYSQL_ROOT_PASSWORD: motdepasse
volumes:
- db-data:/var/lib/mysql
volumes:
db-data:
Le script de préparation automatique
Le script .devcontainer/setup.sh installe WordPress via WP-CLI, active le thème du projet et importe un jeu de données de démonstration versionné dans le dépôt :
#!/bin/bash
set -e
until wp db check --path=/var/www/html --allow-root 2>/dev/null; do
echo "En attente de la base de données..."
sleep 2
done
wp core install \
--path=/var/www/html \
--url="https://$CODESPACE_NAME-80.app.github.dev" \
--title="Projet WordPress" \
--admin_user=admin \
--admin_password=admin \
--admin_email=dev@exemple.test \
--allow-root
wp theme activate mon-theme --path=/var/www/html --allow-root
wp db import .devcontainer/demo-data.sql --path=/var/www/html --allow-root
wp plugin activate --all --path=/var/www/html --allow-root
La variable d’environnement CODESPACE_NAME, injectée automatiquement par GitHub Codespaces, permet de générer une URL correcte dès l’installation — un point important, car chaque Codespace obtient une URL publique différente à chaque création.
Persistance et redémarrage
Le script postCreateCommand ne s’exécute qu’une fois, lors de la création initiale du Codespace. Un Codespace mis en pause puis réactivé conserve son état — base de données comprise, grâce au volume Docker déclaré — sans relancer l’installation complète. Un script distinct, déclenché via postStartCommand, peut gérer les tâches à répéter à chaque redémarrage, comme le démarrage du serveur de développement des assets front.
Ports et accès
GitHub Codespaces expose automatiquement les ports déclarés dans forwardPorts via une URL HTTPS publique temporaire, avec une authentification GitHub par défaut qui protège l’accès. Le port 3306 (MySQL), utile pour se connecter avec un client de base de données local depuis la machine du développeur, peut aussi être rendu accessible de cette façon si nécessaire, en le passant en visibilité publique depuis l’onglet « Ports » de l’interface.
Avantages concrets pour l’onboarding
| Situation | Sans Codespaces | Avec Codespaces |
|---|---|---|
| Nouveau contributeur, premier jour | Installation locale complète, 1 à 4 heures selon la machine | Ouvrir le dépôt, attendre ~2 minutes |
| Machine Windows sans WSL configuré | Friction significative | Aucune différence, tout tourne côté serveur |
| Contributeur ponctuel externe | Rarement invité à installer un environnement complet | Accès immédiat via un lien |
Notre verdict
Pour un projet open source ou une agence qui accueille régulièrement des contributeurs temporaires, ce dispositif change réellement la donne. Le coût, en revanche, n’est pas nul : GitHub facture les heures de calcul au-delà d’un quota gratuit, un point à budgéter sur un projet à forte activité.
Codespaces ne dispense pas de maintenir un environnement local viable pour les développeurs à temps plein qui préfèrent leur configuration habituelle — les deux approches se complètent plutôt qu’elles ne s’excluent.
En résumé
Un devcontainer bien conçu transforme la première expérience d’un nouveau contributeur sur un projet WordPress : plus d’installation fastidieuse, plus de divergence de configuration entre les postes. Le fichier devcontainer.json et le script de préparation deviennent, comme un Makefile bien pensé, une forme de documentation vivante et exécutable de l’environnement du projet.
