Anaka - Retour d'expérience

Le contexte

C'est la troisième année que nous travaillons avec notre client en or CaCom. Celui-ci, content depuis notre premier travail en 2015 pour lui, continue à nous faire confiance depuis et d'ailleurs nous rempilons avec plaisir pour une quatrième année l'an prochain.

Notre client est dans le domaine de la communication print. L’application lui permet de suivre l’état d’avancement de ses projets (ex: catalogue de +1000 pages) avec une grande précision et d’effectuer un certain nombre d’actions sur les pages des catalogues. L'application développée par KnpLabs leur sert tellement qu'elle est devenue centrale dans le fonctionnement de l'entreprise.

Alors forcément comme toute application, elle comporte quelques bugs trouvés sur le tas, mais demande aussi de l'entretien afin de rester dans l'air du temps et de répondre aux nouveaux besoins. La quantité de données traitées a été multipliée par 100 depuis le lancement de l’application. C'est pourquoi l'an dernier elle a déjà subi une refonte permettant de la rendre plus simple et plus rapide avec toujours autant de stabilité.

C’est dans ce contexte que ma mission a démarré avec la reprise du travail de la v2.

Premier constat, l'application est complexe et est complètement centrale pour notre client. La disponibilité de celle-ci est devenue critique à tel point qu'une indisponibilité de l'application bloque l’activité de l'ensemble d'un pôle de 200 personnes.

Agilité

Un projet en évolution

Ligne rouge = besoin initial du client au début du projet

Ligne verte = fin du budget initial

Barre bleue claire = besoin du client

Barre bleue foncée = réalisation

Deuxième constat, le projet évolue ainsi que les besoins et ceci tout au long du projet. L'avantage de l'utilisation des méthodes agiles se fait sentir rapidement et la maîtrise de celle-ci par KnpLabs et notre client rend le projet plaisant et efficient. Pour un budget inchangé, nous avons doublé le périmètre initial des fonctionnalités.

Amélioration continue

L'utilisation de code review, de démonstrations au client ainsi que de rétrospectives nous a permis tout au long du projet de corriger les petits deltas concernant l'attendu et surtout d'éviter de les reproduire dans les itérations suivantes.

Exemple : nous avons constaté quelques oublis de documentation sur les points d'api. C’était compliqué pour notre client de les comprendre et donc de les tester. Suite à cela, nous avons mis en place un axe d'amélioration permettant de surveiller (et simplement d'y penser) ce point lors des review. Résultat : notre API est documentée en temps réel et notre client comprend parfaitement ce qu’elle fait et comment il peut l’utiliser.

Technique

Architecture : de Docker à Swarm

Au niveau technique, l'architecture fonctionnelle n'a pas vraiment changée.

Cependant, afin de répondre au besoin de criticité du projet ainsi qu'à son futur développement, nous avons effectué le choix de passer le projet d'un support Docker à une structure Swarm. Ce changement a nécessité notre implication mais aussi une adaptation du SI existant du client. L'intérêt de cette structure pour le projet et l’accompagnement de KnpLabs ont permis une transition sereine et en douceur.

L'unique modification d'architecture concerne la mise en place des Symfony process https://symfony.com/doc/current/components/process.html afin de différer le traitement de certaines requêtes coûteuses.

Défi technique

Un des besoins d'évolution était la mise en place d'un outil de suivi de planning.

Même si basé sur des technologies type angular/react, la mise en œuvre d'un planning interactif pouvait s'avérer être une grosse source de ralentissement pour notre projet.

Nous avons bien entendu étudié les solutions existantes permettant l'affichage et la gestion d'un planning, cependant aucune ne permettait d'afficher un grand nombre d'informations tout en étant interactif.

Nous avons donc développé une solution "made in KnpLabs" pour l'affichage du planning des projets et des utilisateurs.

Nous pouvions partir sur un planning purement html/css ou faire un mix entre html/css et svg. Nous avons opté pour cette dernière solution, nous permettant d'avoir des rendus spécifiques et efficaces tout en gardant une bonne rapidité d'affichage. L'orchestration de ces deux technologies via angular et rx/js a permis d'avoir une navigation fluide et une maintenance simplifiée grâce à une approche composant.

Optimisation

Nous avons dû faire face à plusieurs choix techniques concernant l'optimisation de l'application, aussi bien au niveau de l'api Symfony que de la partie front angular.

Pour la partie Symfony, de manière classique, on a profilé puis optimisé ce qui était possible ou alors on est passé en process component dans le pire des cas. Merci Blackfire pour leur outil simple et efficace à mettre en place !

Pour la partie js, memoization et optimisation du nombre d'Observables ont été les critères essentiels à surveiller afin de conserver une bonne rapidité d'affichage.

Stabilité du projet

Process : check

Nous partions sur des bases plutôt saines : nombreux tests présents et CI au vert, aussi bien au niveau du front (spec) qu'au niveau du back (behat et phpspec). Cela nous a permis de redécouper, trancher dans le vif sans crainte d'une régression de l'application. Aussi grâce à cette bonne couverture de code, le passage aux dernières versions de Symfony et Angular s'est effectué sans soucis.

Nos processus de développement : CI (circle CI) et review de code nous ont permis d'assurer tout au long du projet une qualité de code continue.

Architecture

“Adobe, we need to talk, don’t take it bad please.”

L'application communique avec des serveurs Adobe peu fiables (traitements hasardeux, requêtes extrêmements longues, ou simple crash du serveur sans raison particulière).

Dans la v2, le processus était le suivant:

(1 worker ->  1 server) x 8

Problème : l'indisponibilité d'un serveur entraînait la chute d'un worker puis tous les autres jusqu’à la paralysie de l’application.

Afin de fiabiliser les échanges, de gérer la charge de travail et surtout de permettre au serveur de redémarrer rapidement sans pénaliser un worker, nous avons modifié le processus :

8 workers -> 8 servers

Ainsi, les workers ne dépendent plus d'une seule et unique adresse Adobe mais d'un serveur haproxy permettant de distribuer automatiquement les requêtes entre tous les serveurs Adobe disponibles. Petite surprise cependant, les serveurs Adobe ne sont à priori capable de traiter qu'une et une seule requête, si une deuxième arrive en parallèle et ceci même dans le pool d'attente, celui-ci a de bonnes chances de crash. Une configuration fine d'haproxy nous a permis de régler cette situation.

Conclusion

Si je dois résumer ce projet, c'est une équipe, client compris, profitant pleinement de l'agilité qui a permis à un projet legacy de continuer d'évoluer sereinement et de manière fiable grâce à des modifications profondes d'architecture et de stabilité, tout en apportant de nouvelles fonctionnalités.

Le tout dans une ambiance de travail vraiment chouette. Merci Nicolas d’être un product owner en or, qui écoute ses utilisateurs - ça nous permet de développer des fonctionnalités vraiment utilisées - et qui comprend et soutient le métier de développeur. Vivement l’année prochaine ;)

Article connexe:

https://knplabs.com/en/blog/how-to-dockerise-a-symfony-4-project https://knplabs.com/en/blog/diving-into-docker-live-coding-session

https://knplabs.com/fr/services/trainings/docker

Want to join the team ? => hello@knplabs.com