Stack 2.2 : tous les projets 2.1 sur Symfony 7.4
En 2026, nous faisons passer tous les projets qui tournent aujourd’hui sur le Stack 2.1 au Stack 2.2 avec Symfony 7.4. Pourquoi nous ne laissons pas des versions coexister, et comment se déroule une migration.
Le cloudtec Stack est la base commune de toutes les plateformes que nous construisons : Symfony, le CMS intégré, les interfaces, l’exploitation. Commune ne signifie pas « semblable », mais « identique » : nous maintenons les projets de notre clientèle au même niveau, au lieu de laisser des versions coexister. En 2026, tous les projets restants passent de 2.1 à 2.2.
Ce qu’est une version du stack
La version 1.0 est la première base commune de notre stack et tourne encore aujourd’hui dans quelques projets clients de longue date. La version 2.1 a introduit la structure actuelle, faite d’un noyau, de modules et d’adaptations propres à chaque client. Elle repose sur Symfony 6.4 et est actuellement la plus répandue. La version 2.2 est l’état actuel, avec Symfony 7.4, que tous les projets tournant aujourd’hui sur 2.1 atteindront en 2026. La version 3.0 est la prochaine génération, que nous développons en parallèle et déployons à partir de 2027.
Comment les modifications parviennent à toute la clientèle
Une modification du stack est une pull request dans le dépôt du stack. Une fois par semaine, nous synchronisons les projets clients avec le stack : ce qui est nouveau dans le stack arrive dans chaque projet. Un build nocturne vérifie que chaque projet se construit toujours avec le stack actuel et réussit ses tests. Si un build échoue, nous savons le matin quel projet est concerné, avant que la clientèle ne s’en aperçoive.
Un projet sur une ancienne version sort de ce cycle. Les mises à jour de sécurité ne l’atteignent plus automatiquement, et chaque adaptation doit être développée deux fois. C’est pourquoi nous mettons à niveau les projets 2.1, même si, pour un projet isolé, une migration ressemble d’abord à un effort sans bénéfice visible.
Comment se déroule une migration
D’abord le staging : nous passons le projet en 2.2, les tests automatisés tournent, l’équipe côté client vérifie les processus les plus importants. Ensuite la livraison en production, suivie de smoke tests : connexion, recherche, formulaires, interfaces. Si quelque chose tourne mal, nous revenons à l’état précédent ; l’image de l’ancienne version reste prête jusqu’à ce que le nouvel état ait tourné quelques jours.
La plateforme de l’Église réformée de Bâle-Campagne pour les paroisses de Bâle-Campagne a ouvert la voie. Ce qui y a fonctionné est depuis la procédure pour toutes les migrations suivantes. D’ici fin 2026, tous les projets restants passeront à 2.2.
Ce qu’apporte la version 3.0, nous vous le raconterons cet automne.