Aller au contenu
Langue
DE EN FR
Démarrer un projet

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.

Une ligne avec quatre versions du stack : 1.0 comme premier noyau commun, 2.1 avec noyau, modules et adaptations clients, 2.2 avec Symfony 7.4 comme état actuel que tous les projets 2.1 atteignent en 2026, et en pointillé 3.0 comme prochaine génération à partir de 2027.
Les quatre versions du stack et où en sont les projets clients en 2026.

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.

Rédigé par Kevin Jüni CTO / Senior Fullstack Software Developer

Tech 2 minutes de lecture