Étape 3: De zéro à la production

5.0 version
Maintained

De zéro à la production

J’aime aller vite et je veux que notre petit projet soit réalisé le plus rapidement possible. Du genre en production, dès maintenant. Comme nous n’avons encore rien développé, nous allons commencer par déployer une simple page « En construction ». Vous allez adorer !

Passez un peu de temps à chercher sur internet un GIF animé « En construction » bien démodé. Voici celui que je vais utiliser :

../_images/under-construction.gif

Je vous l’ai dit, nous allons bien nous amuser.

Initialiser le projet

Créez un nouveau projet Symfony avec la commande symfony que nous avons installée ensemble auparavant :

1
2
$ symfony new guestbook --version=5.0
$ cd guestbook

Cette commande est une mince surcouche de Composer qui facilite la création de projets Symfony. Elle utilise un squelette de projet qui inclut uniquement les composants Symfony requis par presque tous les projets : un outil console et l’abstraction HTTP nécessaire pour créer des applications web.

Si vous regardez le dépôt GitHub pour le squelette, vous remarquerez qu’il est presque vide : il ne contient qu’un fichier composer.json, mais le répertoire guestbook est lui plein de fichiers. Comment est-ce possible ? La réponse se trouve dans le paquet symfony/flex. Symfony Flex est un plugin Composer qui se greffe au processus d’installation. Lorsqu’il détecte un paquet pour lequel une recette existe, il l’exécute.

Le point d’entrée principal d’une recette Symfony est un fichier manifest qui décrit les opérations à effectuer pour intégrer automatiquement le paquet dans l’application. Vous n’avez jamais besoin de lire un fichier README pour installer un paquet avec Symfony. L’automatisation est au cœur de Symfony.

Comme Git est installé sur notre machine, symfony new nous a également créé un dépôt Git, dans lequel a été ajouté le tout premier commit.

Jetons un coup d’oeil à la structure des répertoires :

1
2
3
4
5
6
7
8
9
├── bin/
├── composer.json
├── composer.lock
├── config/
├── public/
├── src/
├── symfony.lock
├── var/
└── vendor/

Le répertoire bin/ contient le principal point d’entrée de la ligne de commande : console. Vous l’utiliserez tout le temps.

Le répertoire config/ est constitué d’un ensemble de fichiers de configuration sensibles, initialisés avec des valeurs par défaut. Un fichier par paquet. Vous les modifierez rarement : faire confiance aux valeurs par défaut est presque toujours une bonne idée.

Le répertoire public/ est le répertoire racine du site web, et le script index.php est le point d’entrée principal de toutes les ressources HTTP dynamiques.

Le répertoire src/ héberge tout le code que vous allez écrire ; c’est ici que vous passerez la plupart de votre temps. Par défaut, toutes les classes de ce répertoire utilisent le namespace PHP App. C’est votre répertoire de travail, votre code, votre logique de domaine. Symfony n’a pas grand-chose à y faire.

Le répertoire var/ contient les caches, les logs et les fichiers générés par l’application lors de son exécution. Vous pouvez le laisser tranquille. C’est le seul répertoire qui doit être en écriture en production.

Le répertoire vendor/ contient tous les paquets installés par Composer, y compris Symfony lui-même. C’est notre arme secrète pour un maximum de productivité. Ne réinventons pas la roue. Vous profiterez des bibliothèques existantes pour vous faciliter le travail. Le répertoire est géré par Composer. N’y touchez jamais.

C’est tout ce que vous avez besoin de savoir pour l’instant.

Créer des ressources publiques

Tout ce qui se trouve dans le répertoire public/ est accessible par un navigateur. Par exemple, si vous déplacez votre fichier GIF animé (nommez-le under-construction.gif) dans un nouveau répertoire public/images/, il sera alors disponible à une URL comme https://localhost/images/under-construction.gif.

Téléchargez mon image GIF ici :

1
2
$ mkdir public/images/
$ php -r "copy('http://clipartmag.com/images/website-under-construction-image-6.gif', 'public/images/under-construction.gif');"

Lancer un serveur web local

La commande symfony inclut un serveur web optimisé pour le développement. Comme vous vous en doutez, il marche très bien avec Symfony. Cependant, ne l’utilisez jamais en production.

À partir du répertoire du projet, démarrez le serveur web en arrière-plan (option -d) :

1
$ symfony server:start -d

Le serveur a démarré sur le premier port disponible (à partir de 8000). Pour gagner du temps, vous pouvez ouvrir le site web dans un navigateur à partir de la ligne de commande :

1
$ symfony open:local

Votre navigateur favori devrait recevoir le focus et ouvrir un nouvel onglet affichant une page similaire à celle-ci :

Astuce

Pour résoudre les problèmes, exécutez symfony server:log ; cette commande affiche les derniers logs de votre serveur web, de PHP et de votre application.

Naviguez vers /images/under-construction.gif. Est-ce que cela ressemble à ceci ?

Tout est bon ? Commitons notre travail :

1
2
$ git add public/images
$ git commit -m'Add the under construction image'

Ajouter une favicon

Pour éviter que nos logs ne se remplissent de messages d’erreur 404 à cause d’une favicon manquante, ajoutons-en une maintenant :

1
2
3
$ php -r "copy('https://symfony.com/favicon.ico', 'public/favicon.ico');"
$ git add public/
$ git commit -m'Add a favicon'

Se préparer pour la production

Qu’en est-il du déploiement de notre travail en production ? Je sais, nous n’avons même pas encore de page HTML pour accueillir convenablement nos internautes, mais voir la petite image « en construction » sur un serveur de production serait une grande satisfaction. Et vous connaissez la devise : déployer tôt, déployez souvent.

Vous pouvez héberger cette application chez n’importe quel fournisseur supportant PHP, soit presque tous les hébergeurs. Vérifiez tout de même quelques points : nous voulons la dernière version de PHP et la possibilité d’héberger des services comme une base de données, une file d’attente, etc.

J’ai fait mon choix, ce sera SymfonyCloud. Il fournit tout ce dont nous avons besoin et aide à financer le développement de Symfony.

La commande symfony supporte nativement SymfonyCloud. Initialisons un projet SymfonyCloud :

1
$ symfony project:init

Cette commande crée quelques fichiers requis par SymfonyCloud : .symfony/services.yaml, .symfony/routes.yaml et .symfony.cloud.yaml.

Ajoutez-les à Git et faites un commit :

1
2
$ git add .
$ git commit -m"Add SymfonyCloud configuration"

Note

Utiliser la commande générique et risquée git add . fonctionne bien ici car un fichier .gitignore a déjà été généré. Il exclut automatiquement tous les fichiers que nous ne voulons pas intégrer au commit.

Mise en production

On déploie ?

Créez un nouveau projet SymfonyCloud :

1
$ symfony project:create --title="Guestbook" --plan=development

Cette commande fait beaucoup de choses :

  • La première fois que vous lancez cette commande, identifiez-vous avec votre compte SymfonyConnect, si ce n’était pas déjà fait.
  • Elle crée un nouveau projet sur SymfonyCloud (vous bénéficiez de 7 jours gratuits sur tout nouveau projet de développement).

Puis, déployez :

1
$ symfony deploy

Le code est déployé en pushant le dépôt Git. À la fin de la commande, le projet sera accessible par un nom de domaine précis.

Vérifiez que tout fonctionne bien :

1
$ symfony open:remote

Vous devriez obtenir une 404, mais si vous naviguez vers /images/under-construction.gif vous devriez pouvoir admirer votre travail.

Notez que vous n’obtenez pas la belle page par défaut de Symfony sur SymfonyCloud. Pourquoi ? Vous apprendrez bientôt que Symfony supporte plusieurs environnements, et que SymfonyCloud a automatiquement déployé le code en environnement de production.

Astuce

Si vous voulez supprimer le projet sur SymfonyCloud, utilisez la commande project:delete.


  • « Previous Étape 2: Présentation du projet
  • Next » Étape 4: Adopter une méthodologie

This work, including the code samples, is licensed under a Creative Commons BY-NC-SA 4.0 license.