Zum Inhalt springen
Sprache
DE EN FR
Projekt starten

Stack 2.2: alle 2.1-Projekte auf Symfony 7.4

2026 heben wir alle Projekte, die heute auf Stack 2.1 laufen, auf Stack 2.2 mit Symfony 7.4. Warum wir Versionen nicht nebeneinander laufen lassen und wie eine Migration abläuft.

Der cloudtec Stack ist die gemeinsame Basis aller Plattformen, die wir bauen: Symfony, das integrierte CMS, Schnittstellen, Betrieb. Gemeinsam heisst dabei nicht «ähnlich», sondern «gleich»: Wir halten die Kundenprojekte auf demselben Stand, statt Versionen nebeneinander laufen zu lassen. 2026 wechseln alle verbliebenen Projekte von 2.1 auf 2.2.

Was eine Stack-Version ist

Version 1.0 ist die erste gemeinsame Basis unseres Stacks und läuft heute noch in wenigen langjährigen Kundenprojekten. Version 2.1 brachte die heutige Struktur aus Kern, Modulen und Kundenanpassungen, basiert auf Symfony 6.4 und ist derzeit am weitesten verbreitet. Version 2.2 ist der aktuelle Stand mit Symfony 7.4, den 2026 alle Projekte erreichen, die heute auf 2.1 laufen. Version 3.0 ist die nächste Generation, die wir parallel entwickeln und ab 2027 einführen.

Eine Linie mit vier Stack-Versionen: 1.0 als erster gemeinsamer Kern, 2.1 mit Kern, Modulen und Kundenanpassungen, 2.2 mit Symfony 7.4 als aktueller Stand, den 2026 alle 2.1-Projekte erreichen, und gestrichelt 3.0 als nächste Generation ab 2027.
Die vier Stack-Versionen und wo die Kundenprojekte 2026 stehen.

Wie Änderungen zu allen Kunden kommen

Eine Änderung am Stack ist ein Pull Request im Stack-Repository. Einmal pro Woche gleichen wir die Kundenprojekte mit dem Stack ab: Was im Stack neu ist, kommt in jedes Projekt. Ein nächtlicher Build prüft, ob jedes Projekt mit dem aktuellen Stack noch baut und seine Tests besteht. Fällt ein Build, wissen wir am Morgen, welches Projekt betroffen ist, bevor ein Kunde es merkt.

Ein Projekt auf einer alten Version fällt aus diesem Kreislauf heraus. Sicherheitsaktualisierungen erreichen es nicht mehr automatisch, und jede Anpassung muss doppelt gebaut werden. Deshalb ziehen wir die 2.1-Projekte nach, auch wenn eine Migration für ein einzelnes Projekt zunächst nach Aufwand ohne sichtbaren Nutzen aussieht.

Wie eine Migration abläuft

Zuerst Staging: Wir heben das Projekt auf 2.2, die automatisierten Tests laufen, das Team des Kunden prüft die wichtigsten Abläufe. Dann die Auslieferung auf die Produktion, gefolgt von Smoke-Tests: Anmeldung, Suche, Formulare, Schnittstellen. Geht etwas schief, rollen wir auf den vorherigen Stand zurück; das Image der alten Version bleibt bereit, bis der neue Stand ein paar Tage gelaufen ist.

Den Anfang machte die Plattform der Reformierten Kirche Baselland für die Kirchgemeinden in Basel-Landschaft. Was dort funktioniert hat, ist seither das Vorgehen für alle weiteren Migrationen. Bis Ende 2026 wechseln alle verbliebenen Projekte auf 2.2.

Was Version 3.0 bringt, erzählen wir im Herbst.

Geschrieben von Kevin Jüni CTO / Senior Fullstack Software Developer

Tech 2 Minuten Lesezeit