En arrivant dans l’équipe technique de SensioLabs, tout le monde passe un peu de temps sur le projet Jobs. Ainsi, chacun peut découvrir l’environnement technique de SensioLabs lors de son onboarding.
Je suis Romain Rosier et je vais vous faire un retour d’expérience sur le projet Jobs.
Un peu de contexte d’abord
Je suis arrivé dans l’équipe technique de SensioLabs, le créateur de Symfony, en tant que stagiaire en avril dernier. J’ai travaillé sur le projet Jobs jusqu’à fin août. Les développeurs qui arrivent chez SensioLabs passent en général deux semaines sur Jobs.
Mon expérience en tant que développeur Symfony était assez basique en début de stage. Je m’étais auto-formé notamment avec SymfonyCasts et j’ai eu l’occasion de faire quelques projets avec Symfony 5 durant mes deux dernières années d’étude.
Globalement, je savais mettre en place un projet et faire quelque chose de fonctionnel, mais tout ça sans vrai retour sur la qualité de mon travail. En plus de ça, je n’avais quasiment aucune connaissance sur Docker, Behat ou sur certains composants que j’ai pu utiliser dans Jobs.
Mon démarrage sur Jobs chez SensioLabs
Jobs est un projet fictif en Symfony qui permet de se familiariser à l’environnement technique de SensioLabs en construisant un projet de développement (une page d’offres d’emploi) depuis zéro.
J’ai tout d’abord commencé par mettre en place la stack Docker. Au départ, j’ai mis du temps pour comprendre le concept des containers. Je n’avais quasiment pas d’expérience avec Docker jusque-là.
J’ai également pu découvrir ce qu’était un spike en méthodologie Agile. Et ce premier spike m’a permis de mettre en place un conteneur PHP avec son Dockerfile et d’installer sur ce conteneur le client Symfony et Composer.
Pour ce qui est de la création du projet en tant que tel et de l’utilisation de Symfony tout au long du projet, cela ne m’a pas posé de problème particulier étant donné que j’avais déjà une expérience avec le framework.
En revanche, pour ce qui est des bonnes pratiques et des trucs et astuces, Jobs m’a vraiment fait progresser. Entre les différentes fonctionnalités à implémenter qui couvrent des cas d’utilisation et tous les retours de l’équipe que j’ai pu avoir sur les fonctionnalités que j’ai faites, j’ai pu apprendre à faire les choses de la bonne manière et de mieux comprendre comment le framework Symfony fonctionne en interne.
Mes premières fonctionnalités : les tests et la chaîne d’intégration
Ensuite, une fois l’environnement et le projet mis en place, je suis entré dans le vif du sujet avec le développement de ma première fonctionnalité.
Qui dit développement dit également tests et pour ce qui est des tests fonctionnels, j’ai utilisé Behat. Pour son installation, j’ai donc utilisé le bundle Symfony Extension de Friends of Behat https://github.com/FriendsOfBehat/SymfonyExtension
Une fois Behat installé, j’ai repéré une petite erreur au moment de lancer les tests. Behat ne trouvait pas la variable d’environnement définissant l’URL de la base de données. Le problème se trouvait dans le fait que je n’avais pas de fichier bootstrap.php au sein de mon projet. Ce fichier n’est plus présent lors de l’installation d’un projet Symfony depuis la version 5.1.
Pour régler ce problème, j’ai ajouté le fichier bootstrap.php à la main avec le contenu ci-dessous :
Toujours avec Behat, j’ai eu des problèmes avec les tests faisant intervenir du JavaScript. Une fonctionnalité du projet demandait de faire une liste des annonces publiées sur la page d’accueil avec un scroll infini.
En lisant la documentation Behat, je me suis rendu compte que le driver de base ne supportait pas les tests en JavaScript et qu’il fallait passer par un serveur Selenium. En tâtonnant avec l’aide d’un article, j’ai mis en place un serveur Selenium fonctionnel, mais les tests ne passaient toujours pas. Etant donné que c’était des tests JavaScript et qu’ils s’exécutaient sur le serveur, une des façons de débugger a été de faire appel à un client VNC. Le client VNC nous a permis d’afficher l’exécution des tests Behat qui s’exécutent sur le serveur Selenium et d’interagir avec la page. J’ai ouvert la console du navigateur et j’ai ainsi pu repérer mes erreurs.
Behat m’a posé quelques problèmes lors de son installation, mais une fois que c’était fait, c’est plutôt confortable pour réaliser des tests fonctionnels. Je trouve que l’écriture des tests est assez parlante, que ce soit pour la lecture ou la compréhension de ceux-ci par la suite.
Sur ce projet, j’ai également mis en place une chaîne d’intégration avec Gitlab-CI. C’était un peu long de la configurer, notamment le registry d’image et la notion du Docker in Docker. Mais le reste de la configuration et l’ajout des étapes de tests a été facile à mettre en place.
Le plus long, c’est d’attendre l’exécution de la CI. Quand on la met en place, on a l’exécution, puis des tests qui ne passent pas avec des erreurs, on les corrige et puis c’est long à relancer. Une fois mise en place, c’est bien pratique d’avoir une automatisation de nos tests.
Mes découvertes sur Jobs
J’ai également fait quelques découvertes intéressantes tout au long du projet.
Tout d’abord, le Makefile que je ne connaissais pas du tout. Durant mes précédents projets, je me suis toujours demandé s’il existait des façons plus simples d’utiliser les commandes projets, notamment concernant l’installation qui peut être un peu lourde quand on a beaucoup de commandes à taper.
Le Makefile le permet. On gagne du temps sur les commandes du quotidien, ce qui est très appréciable.
J’ai parlé de la page d’accueil qui utilisait un scroll infini. La première version de ce code s’appuyait sur du Javascript natif. Suite à une review sur ma merge request, on m’a proposé de le faire avec Stimulus.
C’était l’occasion de découvrir le fonctionnement de Stimulus. Avec cette fonctionnalité, je pense que je n’ai fait qu’effleurer le potentiel de Stimulus. Mais ça me semble très pratique pour intégrer du Javascript dans Symfony.
Concernant la traduction, j’ai utilisé le composant Translation de Symfony. Sur cet aspect de traduction, j’ai pu noter 2 bonnes pratiques :
- Tout d’abord, utiliser le format ICU pour une meilleure prise en charge de la traduction, avec notamment la possibilité de gérer les pluriels et les variables.
- Ensuite, mes fichiers de traduction étaient au format Xliff. La gestion des ID avec ce format peut être compliquée. Une solution plutôt pratique, c’est de définir les clés de traduction en tant qu’ID étant donné que les ID et les clés de traduction doivent être tous les deux uniques. On fait ainsi d’une pierre deux coups, ou du moins on a les deux dans un ensemble cohérent.
En conclusion
Si je devais donner un avis sur le projet Jobs, je dirais que c’est un super projet pour commencer chez SensioLabs. La variété des fonctionnalités permet de couvrir pas mal de choses du point de vue fonctionnel.
Le fait de travailler en mode projets aide à pratiquer la méthodologie Scrum et à avoir un vrai retour sur le travail effectué. C’est une très bonne façon de profiter de l’expérience d’une équipe.
Enfin, je dirais que c’est un projet qui nous laisse le temps d’apprendre. Pour ma part, j’ai passé 5 mois sur le projet pour réaliser tous les tickets proposés. Ça m’a permis de prendre le temps pour faire des recherches, des essais sur les technologies proposées et aussi de bien comprendre comment mieux développer.
SensioLabs recrute chez WeLoveDevs ! Si l’article et les méthodes d’onboarding vous ont plu, n’hésitez pas à candidater ☀️
