Balinea - Une mise en prod en beauté - 2/3

Passage à l’agile. Il est venu le temps des Post-It !

Ce changement a été l’un des plus longs à opérer - sûrement parce qu’il touche à la façon même dont l’équipe se structure. En parlant avec Eve, People Manager chez KNP, nous avons trouvé des astuces pour accompagner progressivement l’équipe vers des méthodologies agiles, dans le but notamment d’encourager la communication entre les développeurs mais également avec le reste de l’entreprise. Qui plus est, le fameux “cycle en V” est souvent bien peu motivant : la seule échéance que l’on ait est fixée plusieurs mois plus tard et le travail accompli est livré en un seul lot, sans idée de progression intermédiaire ni retour des utilisateurs.

Afin de prendre en compte la naturelle résistance au changement, c’est petit à petit que j’ai alors introduit des “touches d’agilité” : utilisation de Trello, tableau Kanban constitué de post-its au mur, mise en place de cycles de développements - des sprints Scrum qui ne disaient pas leur nom. Après quelques mois de travail acharné de ma part (ah c’est qu’on peut être têtes de mules parfois chez KNP :-)), il a finalement été décidé de passer officiellement à Scrum, avec des sprints de deux semaines.

Pour l’occasion nous avons fait venir Eve chez Balinea, qui a pu par le jeu de serious games et d’analyses des processus de la société, faciliter ce changement soudain dans la manière de travailler. Cela a notamment apporté un beau regain d’énergie chez l’équipe de développement qui a pu toutes les deux semaines retrouver l’adrénaline libérée lors de ces moments où l’on s’évertue avec un bel esprit d’équipe à l’accomplissement des objectifs du sprint. Les développeurs ont pu rendre les processus interactifs, avec la capacité acquise via Scrum de discuter avec les Product Owners.

Mise en place d’environnements de développement locaux avec Docker Compose. Hackathon et Sf Live à la rescousse !

Le fait que les développeurs utilisent des environnements hétérogènes (postes sous Windows, Linux et Mac OS) ne facilitait en aucun cas la mise en place d’environnements de développements locaux.

C’est que le développement d’un site Web est devenu bien complexe de nos jours : en plus du trio “Serveur Web + PHP + Base de données” sur Balinea nous devions également composer avec les briques technologiques que sont Node.js (task-runner gulp, création des fichiers JavaScript et CSS via Browserify et LESS, etc.), RabbitMQ et ses consumers en Go, Redis, ElasticSearch (supprimé par la suite au profit d’Algolia), Varnish, etc.

Étant donné la difficulté d’installer tout ce petit monde sur des OS aussi différents (Windows, I’m looking at you!), le choix avait été fait d’utiliser un serveur de développement distant, sur lequel les développeurs avaient chacun un compte Linux avec un VirtualHost Apache et une base MySQL propres, et avec lequel ils devaient synchroniser leur code.

Travailler via un serveur distant ralentissant tout le monde, nous avons commencé par passer les environnements Windows sous Ubuntu. Vagrant a été envisagé avant cela, mais le partage de fichiers est malheureusement tellement lent avec une VM VirtualBox que les performances pour tout ce qui touchait au “watch” des assets et la surveillance des modifications sur la config qu’exerce Symfony en mode “dev” étaient catastrophiques.

Une fois quasiment tout le monde sous Ubuntu, nous avons mis en place un gros Dockerfile, qui permettait d’installer de manière automatisée et sans perte de performances notables un container Docker qui serait le même pour toute l’équipe, contenant toutes les briques logicielles prêtes à l’emploi.

C’est à ce moment-là qu’a eu lieu le premier “hackathon” de KNP Labs, au cours duquel Florian nous a présenté l’outil “fig”, qui permettait de gérer un ensemble de containers Docker au moyen d’un simple fichier YAML - outil qui allait devenir “Docker Compose” quelques semaines plus tard après son achat par Docker Inc.

Durant cette même période, le Symfony Live 2015 a eu lieu. Nous avons assisté avec l’équipe Balinea à une conférence particulièrement intéressante sur Docker, et notamment sur ses atouts en tant que fondation d’un environnement de développement local. Au retour de la conférence nous avons mis en place Docker Compose, et nous sommes attelés à la formation des développeurs de Balinea à ces outils.

Une année s’est écoulée depuis, et on ne compte plus le temps que Docker Compose nous a fait gagner à chaque fois que nous avons voulu modifier ou ajouter une brique à notre application.

Sans que l’on ait prévu de l’utiliser à ces fins, le fait d’avoir tout notre environnement logiciel défini dans un unique fichier YAML nous a par ailleurs permis de mettre en place facilement une solution d’intégration continue adaptée à nos besoins.

Nous disposons ainsi d’un serveur Jenkins (tournant au moyen du container Docker officiel) qui crée un droplet (serveur virtuel) DigitalOcean à chaque Pull Request. Ce droplet est créé à partir d’un snapshot où l’application a été initialisée avec Docker Compose.

Une fois le droplet opérationnel, nous n’avons plus qu’à lui faire exécuter les tests PHPUnit et Behat exactement de la même façon que celle dont nous les faisons tourner sur nos environnements de développement locaux, via les containers Docker orchestrés par Compose. Ces tests exécutés sur des droplets éphémères sont réalisés en communication avec le serveur Jenkins central, qui nous en donne le résultat en continu, puis détruit le droplet lorsque les tests sont terminés.

La suite sur le choix du monolith or not monolith ;-) (2/3)