Eine Codebasis, hundert Schulen, eine einzige Quelle der Wahrheit

Wenn Sie in einer Drupal-Umgebung im Hochschulbereich mit mehr als fünfzig Websites gearbeitet haben, wird Ihnen die Geschichte, die wir Ihnen erzählen werden, bekannt vorkommen – mit unterschiedlichen Implementierungen an verschiedenen Hochschulen. Stückwerk-Funktionalität, die von verschiedenen Teams in verschiedenen Jahren angeflanscht wurde. Erhebliche Abhängigkeiten von individuellem Code, den niemand mehr geschrieben hat, der heute noch lebt. Inkonsistente Nutzererlebnisse über Fakultäten und Abteilungen hinweg. Das Onboarding für Redakteure dauert Wochen für jedes neue Programm. Markenrichtlinien in einem PDF, auf die sich jeder bezieht und die niemand durchsetzt.

Dies ist die häufigste Form einer Drupal-Plattform einer Forschungsuniversität nach einem Jahrzehnt dezentraler Entscheidungen. Es ist nicht das Ergebnis schlechter Ingenieurskunst. Es ist das Ergebnis von Wachstum ohne Governance, und die Lösung ist kein weiteres Framework, kein anderer Anbieter oder eine komplette Neuplattformierung.

Die Lösung besteht darin, die bereits vorhandene Plattform regierbar zu machen.

Dies ist die Geschichte, wie wir dies für eine solche Institution umgesetzt haben.

Eine der Top-50 US-Forschungsuniversitäten. Rund 25.000 Studierende. Mehr als 100 institutionelle Websites, Haupt-Properties, Hochschul- und Fakultäts-Websites, Abteilungs-Websites, Microsites und eigenständige Marketingseiten, die Entscheidungen aus einem Jahrzehnt umfassen und auf Drupal 7, 8, 9 und 10 laufen. Gehostet auf Acquia Cloud. Gesteuert von einem gemeinsamen Marketing- und IT-Gremium. Wir wurden hinzugezogen, um eine langjährige etablierte Kreativagentur zu ergänzen, nicht zu ersetzen.

Die technischen Schulden sahen wie folgt aus:

• Fünf verschiedene Inhaltsmodelle für „Dozentenprofile“ über alle Fakultäten hinweg.
• Drei verschiedene Methoden zur Erstellung von Veranstaltungen (Paragraphs, Layout Builder und benutzerdefinierte Blöcke).
• Rund 40 geforkte Varianten des zentralen Design-Frameworks.
• Rund 70 Contrib-Module mit Versionsdrift, einige Websites sind drei Nebenversionen im Rückstand.
• Benutzerdefinierter Code, der sich über vier frühere Agenturen und zwei Generationen interner Mitarbeiter angesammelt hat.
• Markenrichtlinien in einem PDF von 2021, informell bei der Code-Überprüfung durchgesetzt.
• Einarbeitung von Redakteuren von drei bis sechs Wochen pro neuer Fakultät.

Acquia Site Factory stand zur Debatte. Wir haben davon abgeraten.

Die Ursache ist Governance, nicht Technologie:

Die Ursache für das Flickwerk sind nicht „mehr Agenturen“. Es ist das Fehlen von Governance-Gates zum Zeitpunkt der Bereitstellung.

In jeder von uns geprüften Hochschuleinrichtung – und wir haben viele geprüft – zeigt sich dasselbe Muster.

Alles, was die Code-Überprüfung besteht, geht in die Produktion. Prüfer wechseln. Standards driften ab. Markenrichtlinien, die in PDFs existieren, werden nicht durchgesetzt. Komponentenverträge und Barrierefreiheitsprüfungen, die in CI existieren, schon.

Drupal 10 ist in Ordnung. Acquia Cloud ist in Ordnung. Code-Überprüfung ist in Ordnung. Was in fast jeder von uns gesehenen Umgebung fehlt, ist die Durchsetzungsebene zwischen genehmigt und bereitgestellt. Ohne diese Ebene trägt jeder wohlmeinende Anbieter, einschließlich des etablierten, letztendlich zur Entropie bei. Mit ihr wird die Plattform selbstreinigend: Abweichungen werden in dem Moment abgelehnt, in dem sie versuchen, in die Produktion zu gelangen.

Wir mussten die Umgebung dieses Kunden nicht neu schreiben. Wir mussten Gates installieren.

Aber die Installation von Gates über mehr als 100 Websites in einem begrenzten Zeitfenster mit einem einzigen Lieferteam ist nicht nur ein technisches Problem. Es ist ein Durchsatzproblem, ein Rückverfolgbarkeitsproblem und ein Konsistenzproblem unter Druck. Hier kam unser AI Delivery Framework ins Spiel.

Eine Konsolidierung dieser Größenordnung, die etwa 100 Websites, 70 Module und 40 Theme-Varianten umfasst, ist ein Programm, das traditionell achtzehn bis vierundzwanzig Monate dauert und vollständig von der Aufmerksamkeit erfahrener Ingenieure abhängt. Das Risiko liegt nicht in der Technik. Das Risiko liegt in allem, was die Technik umgibt: die richtigen Anforderungen zu ermitteln, die Konsistenz in einem großen Team zu wahren, Fehler zum Zeitpunkt des Commits statt der Veröffentlichung abzufangen und den Fortschritt in einer Sprache zu berichten, auf die ein Lenkungsausschuss reagieren kann.

Wir haben dieses Projekt mit unserem sechsstufigen KI-Lieferframework umgesetzt. Jede Stufe des SDLC wird von einer Engine gesteuert. KI bewältigt das Volumen. Menschen treffen jede kritische Entscheidung. Die gesamte Pipeline läuft auf einer persistenten Wissens-Engine, die den Codebasis-Kontext, Architekturentscheidungsdokumente, Geschäftsregeln und die Plattformkonfiguration speichert und aus jedem Sprint lernt.

1. Discovery Engine: Jedes Gespräch wird zu einem Sprint-bereiten Backlog: Wir haben alle Stakeholder-Artefakte von Kundenseite erfasst: Interviewprotokolle mit über 30 Schul- und Abteilungsleitern, Markenprüfungen, das alte Markenrichtlinien-PDF, Barrierefreiheits-VPATs und die internen Issue-Tickets der letzten drei Jahre. Die KI extrahierte Anforderungen, ordnete Abhängigkeiten zu und generierte ein Sprint-bereites Backlog mit vollständiger Rückverfolgbarkeit zur Quelle, wobei jedes Ticket mit dem Gespräch verknüpft war, das es ausgelöst hatte. Ein erfahrener Projektmanager prüfte jedes Ticket, bevor es in den Sprint aufgenommen wurde. Die Discovery-Arbeit, die sechs Wochen Workshops in Anspruch genommen hätte, dauerte sechs Tage.
2. Build Engine: KI-Pair-Programming mit menschlich überprüften Merges: Jeder Entwickler im Team arbeitete mit einem KI-Pair-Programming-Assistenten, der mit dem vollständigen Codebasis-Kontext der Knowledge Engine geladen war. Der Assistent kennzeichnete Anti-Patterns in Echtzeit, schlug Wiederverwendung statt Neuschreibung vor und richtete jede Änderung am Designsystem aus. Jede Pull-Anfrage durchlief eine KI-Erstprüfung (Korrektheit, Standards, Abdeckung, Leistung), bevor sie von einem erfahrenen Ingenieur manuell freigegeben wurde. +55 % schnellere Aufgabenbearbeitung. −62 % weniger Produktionsfehler in den ersten 90 Tagen.
3. Security Engine: Shift-Left bei jedem Commit: SAST-Analysen, Scans von Geheimnissen und Anmeldeinformationen, SCA-Abhängigkeitsprüfungen und OWASP Top 10-Checks werden bei jedem Commit durchgeführt. KI-gestützte Filterung hielt die Rate der Fehlalarme unter 3 %, verglichen mit den 20–40 %, die bei traditionellem SAST typisch sind. Schwachstellen wurden zum Zeitpunkt des Commits behoben. Es gab keine Sicherheitsüberraschungen bei der Veröffentlichung.
4. Test Engine: Playwright, PHPUnit, KI-generiert, selbstheilend: KI-generierte Playwright E2E-Tests mit selbstheilenden Selektoren deckten browser- und geräteübergreifende User Journeys ab. KI-generierte PHPUnit-Suites erreichten eine Branch-Abdeckung von 85–96 %. Eine Multisite-fähige Regression-Suite führte bei jedem Build einen vollständigen Cross-Component-Verifizierungs-Diff durch. QA-Ingenieure hörten auf, Regressionen zu verfolgen, und führten stattdessen explorative Tests an Edge Cases und der UX durch. Der Wartungsaufwand für Tests wurde um 50–70 % reduziert.
5. Delivery Engine: Bereitstellung mit Stakeholder-Transparenz in jedem Sprint: CI/CD wurde nach QA-Freigabe bereitgestellt, ohne manuelle Release-Schritte. Die Überwachung nach der Bereitstellung verfolgte Regressionen, Fehler und Leistungsverschlechterungen. Die Delivery Engine generierte leicht verständliche Sprint-Retrospektiven für den gemeinsamen Marketing- und IT-Lenkungsausschuss, einschließlich Velocity-Metriken, Risikoprotokoll, Vorfallsübersicht und Empfehlungen für den nächsten Sprint, ohne dass eine technische Übersetzung erforderlich war. Jede Retrospektive floss zurück in die Knowledge Engine, und der nächste Sprint begann intelligenter als der letzte.
6. Knowledge Engine: Die persistente Intelligenzschicht: Enthält die Codebasis, Architekturdiagramme, ADRs, Markenstandards, Barrierefreiheitsrichtlinien, Umgebungskonfiguration und Vorfallhistorie. Liefert Kontext an jede andere Engine. Wächst mit jedem Sprint. Im vierten Monat des Projekts kannte die Knowledge Engine die gesamte Umgebung besser als jedes einzelne Teammitglied.

Die Disziplin des Frameworks ist hier wichtiger als die reinen Zahlen. KI schlägt vor; Menschen prüfen. Jede Engine hat einen menschlichen Prüfpunkt. Diese Struktur gab dem Lenkungsausschuss das Vertrauen, ein Programm dieser Größenordnung innerhalb eines festen Zeitrahmens zu genehmigen. Sie wurden nicht gebeten, der KI zu vertrauen. Sie wurden gebeten, einer Pipeline zu vertrauen, in der die KI die Volumenarbeit erledigte und Menschen die wichtigen Entscheidungen genehmigten.

Fünf Engines liefern die Arbeit. Drupalfit ist das Gate, das entscheidet, ob die Arbeit ausgeliefert werden darf.

Drupalfit ist in der CI-Pipeline angesiedelt, zwischen dem „Green Build“ der Test Engine und dem „Deploy“ der Delivery Engine. Bei jedem Merge in einen Plattform-Branch führt Drupalfit vier erforderliche Prüfungen durch:

1. WCAG 2.1 AA Barrierefreiheit: Automatisierte axe-core-Scans gegen einen repräsentativen URL-Satz pro Website. Fehlerhafte Scans blockieren den Merge.
2. Design-System-Vertragstests: Jede CSS-Farbe, Schriftfamilie und jedes Brand-Token in jeder kompilierten Komponente wird gegen die Design-System-Token-Zulassungsliste geprüft. Tokens, die nicht dem System entsprechen, blockieren den Merge.
3. Drupal Upgrade-Bereitschaft: Jeder PR führt upgrade_status und drupal-rector aus, um die Anzahl der Deprecations zu bewerten. Deprecations im benutzerdefinierten Code blockieren den Merge.
4. Drupal Sicherheitswarnungen: drush pm:security läuft bei jedem PR. Offene Warnungen blockieren den Merge.

Drupalfit ist die Antwort auf die Frage „Was stoppt das nächste Jahrzehnt des Drifts?“ und die Antwort ist: ein CI-Job, kein PDF.

Die Richtlinie, die im Code-Review existiert, hängt davon ab, welcher Reviewer in dieser Woche an der Reihe ist. Eine Richtlinie, die in CI existiert, wird bei jedem Merge, jedem Mitwirkenden, jeder Website, jederzeit durchgesetzt. Als die Konsolidierung live ging, hatte das System des Kunden Gates. Die Gates laufen immer noch. Der Drift wird weiterhin abgelehnt.

Das ist das nachhaltige Ergebnis.

Wir haben fünf Metriken über das gesamte Engagement hinweg gemessen. Alle fünf sind als Bereiche angegeben und wurden konservativ gegenüber veröffentlichten Benchmarks aus dem Hochschulbereich (Princeton WDS, Stanford Sites, Arizona State, NDSU, UCSF, McGill) gehalten.

Wir haben keine Dollarzahl angegeben. Wir haben keinen Anstieg der Einschreibungen behauptet. Wir haben keinen Lighthouse-Score beansprucht. Diese Metriken sind nicht nachweisbar, ohne die Institution zu nennen, und wir nennen unsere Hochschulkunden nicht. Was wir jedoch behaupten können, ist die operative Verschiebung: Der Bestand hat aufgehört, Schulden anzuhäufen. Die nächsten 50 Websites werden nicht das Flickwerk neu aufbauen, das die ersten 100 taten.

Eine kurze Liste, weil sie genauso wichtig ist wie die Arbeit, die wir geleistet haben:

1. Wir haben die Plattform nicht per „Forklift“ auf Acquia Site Factory umgestellt: Der Kunde nutzt weiterhin Acquia Cloud Multisite, mit einer gemeinsamen Codebasis und pro-Site-Datenbanken. Site Factory ist hervorragend für wirklich vorlagenbasierte Netzwerke geeignet. Es ist der falsche „Forklift“ für eine föderierte Forschungsuniversität, wo jede Fakultät berechtigterweise Variationen verlangen wird.
2. Wir haben nicht jedes benutzerdefinierte Modul neu geschrieben: Wir haben diejenigen neu geschrieben, die die D11-Bereitschaft blockierten, gemeinsame Funktionalitäten an drupal.org zurückgegeben und den Rest durch Core- oder Contrib-Äquivalente ersetzt. 
3. Wir sind nicht zu einer Headless- oder entkoppelten Architektur gewechselt: Drupal rendert das Frontend. Es gab keinen Business Case, dies zu ändern. 
4. Wir haben die bestehende Kreativagentur nicht verdrängt: Sie waren weiterhin für ihre Marke und ihr Design verantwortlich. Wir waren für Plattform-Engineering, Governance-as-Code und die KI-Bereitstellungsschicht zuständig. Langjährige Kreativpartner erledigen den Job für Marke und Design in der Regel gut; was oft fehlt, ist die darunterliegende Plattform-Engineering- und Governance-Schicht. Diese Lücke haben wir geschlossen. 

„Forklift“-Re-Plattformierungen haben mehr Marketingbudgets im Hochschulbereich vernichtet, als sie eingespart haben. Wir haben die Plattform, die der Kunde bereits hatte, regierbar gemacht. Das war der Auftrag.

Für jede Drupal-Installation im Hochschulbereich in den Vereinigten Staaten ticken zwei Uhren.

Die erste ist das End-of-Life von Drupal 10 am 9. Dezember 2026. Drupal 11 erfordert PHP 8.3 und Symfony 7, entfernt alle bis 10.3 als veraltet markierten Funktionen und macht eine lange Liste von Legacy-Modulen (Actions UI, Tracker, Book, Forum, Statistics, Tour, Help Topics) obsolet. Einrichtungen, die bis zum 3. Quartal 2026 warten, um mit der Vorbereitung auf D11 zu beginnen, werden in den Ferien Notfalltarife für Entwicklerstunden zahlen. Einrichtungen, die upgrade_status und drupal-rector jetzt in ihre CI-Pipeline integrieren und als Regressionstest behandeln, werden dies nicht tun müssen.

Die zweite ist die Frist für die WCAG 2.1 AA-Konformität gemäß DOJ Title II für öffentliche Einrichtungen. Öffentliche Einrichtungen, die Bevölkerungsgruppen von 50.000 oder mehr bedienen – was jede öffentliche Forschungsuniversität in den Vereinigten Staaten einschließt – müssen bis zum 24. April 2026 konform sein. Kleinere Einrichtungen bis zum 26. April 2027. Der technische Standard ist unverändert. Das Audit der Drupalfit Challenge 2025 von 148 Drupal-Sites ergab, dass 84,5 % mindestens ein erkennbares Barrierefreiheitsproblem aufwiesen. Einrichtungsweite Konformität ist nur durch Deploy-Time-Gates erreichbar. Ein Team von Barrierefreiheitsspezialisten kann nicht manuell beheben, was über 100 föderierte Content-Editoren jede Woche neu erstellen.

Beide Uhren sind zwingende Faktoren. Keine davon ist der wahre Grund, diese Arbeit zu leisten. Der wahre Grund ist Nachhaltigkeit; die nächsten 50 Sites der Einrichtung sollten nicht die technischen Schulden neu aufbauen, die die letzten 100 angehäuft haben. Die zwingenden Faktoren nehmen lediglich die Möglichkeit des Aufschiebens.