Templating + Git = ❤: Wie Ubitec GmbH Template-Änderungen sicher in hunderte On‑Prem‑Chatbot‑Projekte bringt

Kontext: On‑Prem‑Chatbots, Public Sector und viele individuelle Deployments

In „Templating + Git = ❤“ von Dominik Aumayr (Ubitec GmbH) ging es um ein sehr reales Engineering‑Problem: Wie hält man viele, stark angepasste Kundenprojekte konsistent, wenn sich das zugrundeliegende Template weiterentwickelt? Die Ausgangslage: Ein kleines, fokussiertes Team in Linz baut dialogbasierte Produkte und Services – Chatbots – für Kunden, die on‑premise betreiben. Darunter der öffentliche Bereich, etwa das Finanzministerium („Fred“), der ÖAMTC und die Stadt Wien.

On‑premise heißt: Jede Installation bringt Eigenheiten mit. Unterschiedliche Deployment‑Schemata (Docker/Docker Compose, Kubernetes, OpenShift), abweichende Branding‑Vorgaben (Avatar, Farben), zusätzliche Funktionalitäten und API‑Anbindungen – kurz: eine gemeinsame Basis mit vielfältigen projektspezifischen Abweichungen. Genau hier beginnt die Herausforderung für Versionierung, Wartung und “Template‑Drift”.

Architekturüberblick: Ein Kern, viele Bots

Die Team‑Struktur lässt sich in zwei Ebenen denken:

• Ein Kernsystem, das „Ubitech Bot Framework“, ist gleich für alle Chatbots.
• Darunter sitzen die einzelnen Bot‑Projekte – jeweils mit eigener Projektstruktur, eigenem Branding und eigenem Deployment.

Aus dem Framework wird für jedes Projekt ein Projektbaum erzeugt. Obwohl die Grundstruktur gleich ist, sind Individualisierungen ausdrücklich vorgesehen: Zusätzliche Container, spezielle Anforderungen an das Deployment, differierende Helm‑Chart‑Konfigurationen – all das variiert je nach Kunde. Diese Variabilität muss die Tooling‑Strategie tragen.

Die Grundlagen: Cookiecutter und Git als Rückenwind

Ubitec setzt auf zwei Bausteine:

• Cookiecutter als Template‑ und Gerüstbau‑Werkzeug.
• Git als zentrales Versions‑ und Änderungsmanagement – mit eigenen Repositories für Framework und Bots sowie Tags für Versionen.

Cookiecutter als Generator

Cookiecutter ist ein Command‑Line‑Tool zum Generieren kompletter Projektbäume aus Templates. Die Vorlagen verwenden eine Templating‑Sprache (Jinja2); Variablen werden in Datei‑Inhalten und sogar in Datei‑Namen ersetzt. In der Praxis heißt das: Fragen wie „Wie heißt der Bot?“, „Welcher Slug?“, „Welche Version?“ werden einmal beantwortet und der passende Projektbaum entsteht. Variablenersetzungen greifen sowohl in Konfigurationen als auch in Verzeichnissen und Dateinamen – alles, was ein Projekt eindeutig macht.

Das Team hat ein zentrales Template definiert, das festlegt, welche Dateien zur Bot‑Struktur gehören, welche Parameter abgefragt werden und wo Variablen landen. Ergebnis: ein reproduzierbares Grundgerüst für jedes neue Bot‑Projekt.

Git als Ordnungsrahmen

Sowohl das Ubitech Bot Framework als Template als auch jedes Bot‑Projekt leben in eigenen Git‑Repositories. Änderungen werden sauber getrackt; neue Versionen des Frameworks und der Projekte erhalten Tags. Damit ist klar nachvollziehbar, wann sich was in der Basis geändert hat – etwa am Helm‑Chart, an der Deployment‑Beschreibung oder in einer Konfigurationsdatei.

Diese Kombination – reproducible scaffold (Cookiecutter) plus Versionshistorie (Git) – löst die Initialerstellung elegant. Bleibt die Frage: Was passiert, wenn sich das Template später ändert?

Das Problem hinter der Fassade: Drift nach der Template‑Generierung

Nach der ersten Generierung beginnen die Projekte zu leben. Kundenanforderungen fließen ein, spezifische Deployments werden eingerichtet, zusätzliche Container ergänzt. Parallel entwickelt sich das zentrale Template weiter: neue Dateien kommen hinzu, Felder in Helm‑Charts werden ergänzt, Inhalte ändern sich.

Die naive Antwort wäre: alle bestehenden Kundenprojekte per Hand anpassen. In der Realität ist das untragbar. Es braucht einen Weg, um Template‑Änderungen nachvollziehbar und weitgehend automatisiert in bereits generierte, individuell angepasste Projekte zu übertragen – ohne alles zu überschreiben und ohne die Kundenspezifika zu verlieren.

Der zentrale Kniff: Replay‑Datei + Git‑Diff + Patch‑Apply

Der entscheidende Hebel ist eine Cookiecutter‑Fähigkeit, die oft übersehen wird: das „Replay‑File“. Cookiecutter kann nicht nur interaktiv fragen, sondern auch ein JSON mit den Variablenwerten einlesen. Dadurch lässt sich die Generierung vollständig automatisieren.

Ubitec nutzt diese Funktion und geht einen Schritt weiter: Die Replay‑Datei wird in das generierte Projekt mit eingebaut. Damit verfügt jedes Bot‑Projekt über seine eigenen Antworten – Name, Slug, Version und alle weiteren Variablen, die das Template verlangt. Oder wie Dominik Aumayr es zugespitzt ausdrückt: Der Bot kann sich selbst neu generieren.

Auf dieser Basis entsteht ein Verfahrensablauf aus vier Schritten:

1) Alte und neue Template‑Version materialisieren

• Das Team checkt zwei Versionen des Templates aus – zum Beispiel Tag „v1“ und Tag „v2“.
• Für beide Stände wird Cookiecutter nicht interaktiv mit der Replay‑Datei des konkreten Bot‑Projekts ausgeführt.
• Ergebnis: Zwei vollständige Projektbäume, generiert aus der alten und der neuen Template‑Version – jeweils mit den exakt gleichen Projektspezifika (Name, Slug etc.) eingesetzt.

2) Unterschied berechnen

• Zwischen den beiden generierten Bäumen wird ein Git‑Diff gebildet.
• Das liefert eine Änderungsliste, die ausschließlich die Unterschiede zwischen Template v1 und v2 enthält – bereits übersetzt mit den konkreten Werten dieses einen Bot‑Projekts.

3) Patch anwenden

• Mit Git Apply wird dieses Diff auf das echte Kundenprojekt angewendet – auf das Repository, in dem bereits kundenspezifische Anpassungen leben.
• Was im Template neu ist oder sich geändert hat, wird so in das Projekt übertragen; bereits existierende kundenspezifische Änderungen bleiben erhalten, soweit keine direkten Konflikte bestehen.

4) Automatisieren und skalieren

• Der Ablauf wird in ein Shell‑Skript gepackt und in die CI verlagert.
• Der gewünschte Trigger: Wenn ein neuer Template‑Tag gepusht wird, laufen die Schritte für alle betroffenen Kundenprojekte automatisch und erzeugen Merge Requests mit den konkreten Änderungen.
• Entwicklerinnen und Entwickler prüfen anschließend die Merge Requests: Standardprojekte gehen meist ohne Eingriff durch; bei stark angepassten Projekten sind Konflikte möglich und werden im Git‑Workflow sauber sichtbar.

Die Eleganz dieser Strategie liegt darin, dass nicht einfach ein „Roh‑Diff“ aus der Template‑Historie auf Projekte gegossen wird, sondern ein diff der zwei materialisierten Endzustände: alt vs. neu, jeweils mit denselben Projektspezifika. Genau dadurch wird das Patch tatsächlich passend – ohne dass man Variablennamen oder Platzhalter händisch nachziehen muss.

Ein Blick in die Praxis: Helm‑Chart‑Änderungen, neue Felder, neue Dateien

Im Talk nennt Aumayr ein konkretes Beispiel: Im Helm‑Chart wurde die Description geändert und zusätzliche Felder für das Deployment‑Schema eingefügt. Solche Änderungen sind typisch – sie betreffen viele Projekte, dürfen aber projektspezifische Sonderwünsche nicht überschreiben.

Mit dem beschriebenen Replay‑Diff‑Apply‑Verfahren werden genau diese Änderungen identifiziert und als Patch angewandt. Wenn die Helm‑Chart eines Kunden „komplett anders“ ist, entstehen Konflikte. Dann greift das, was Git ohnehin gut kann: Konflikte klar markieren, Diff‑Ansicht zeigen und das Team entscheidet, wie die Änderung für diesen Fall zu übernehmen ist.

Die Vorteile:

• Wiederkehrende Template‑Anpassungen landen automatisiert in allen Projekten.
• Projektindividuelle Anpassungen bleiben erhalten.
• Konflikte werden nicht verschleiert, sondern explizit und nachvollziehbar.

Git als Dreh‑ und Angelpunkt: Taggen, Diffen, Anwenden

Die komplette Lösung baut darauf, Git konsequent als Protokoll und Transportmedium für Änderungen zu verwenden:

• Das Framework bekommt Tags („v1“, „v2“, …). Welche Version den Aufsatz bildet, ist eindeutig.
• Der Unterschied zwischen zwei Versionen wird nicht abstrakt gezogen, sondern an den konkret generierten Dateien diffed.
• Der Transport in die Zielprojekte erfolgt als Patch via Git Apply – inklusive bekannter Mechanismen für Konflikte und Historie.

Das reduziert Speziallogik im Tooling und nutzt etablierte Entwickler‑Workflows. Oder, wie Aumayr selbstironisch anmerkt: „Weil wir natürlich faule Programmierer sind“ – Automatisieren, was sich automatisieren lässt, und Git als Träger für saubere Änderungen.

CI‑Vision: Hook auf Template‑Tag, Merge Requests für alle Bots

Einmal als Skript formuliert, lässt sich der Prozess in die Pipeline verlagern. Der Plan:

• Ein Server‑Hook lauscht auf neue Tags im Template‑Repository.
• Für jeden Bot wird der Replay‑Diff‑Apply‑Zyklus ausgeführt.
• Pro Kundenprojekt entsteht ein Merge Request in GitLab mit den resultierenden Änderungen.

Für die meisten Standardprojekte ist das „Durchklicken und mergen“. Bei den wenigen stark kundenspezifischen Umgebungen schaut man den Diff an und entscheidet. Das Ganze ist bewusst nicht „silent“ – es erzeugt nachvollziehbare, reviewbare Änderungen, die im Team gesehen und abgenickt werden.

Wichtiges Detail aus dem Talk: Dieser CI‑Teil ist als nächster Schritt vorgesehen, zum Zeitpunkt des Vortrags aber noch nicht umgesetzt. Genau dafür sucht das Team Engineering‑Verstärkung.

Warum das funktioniert: Drei Designentscheidungen, die tragen

1) Projekte sind generierbar – jederzeit

Die Entscheidung, die Cookiecutter‑Replay‑Datei mit ins Projekt zu legen, hebt die Reproduzierbarkeit auf die nächste Stufe. Ein Projekt ist kein einmaliger „Ausdruck“ des Templates, sondern zu jedem Zeitpunkt regenerierbar – mit seinen eigenen Parametern.

2) Unterschiede werden auf konkretisierte Endzustände berechnet

Anstatt „Template‑Datei A alt“ mit „Template‑Datei A neu“ zu vergleichen und dann Platzhalter über Projekte zu mappen, erzeugt das Team zwei vollständige, materialisierte Bäume. Dadurch entspricht der Diff präzise der Realität des konkreten Projekts.

3) Git ist die Konflikt‑ und Historienmaschine

Das Verfahren lehnt sich an das an, was Git hervorragend kann: Änderungen tracken, Diffs erzeugen, Patches anwenden, Konflikte sichtbar machen. Keine proprietären Merge‑Engines, keine Spezialformate – vertraute Werkzeuge, nachvollziehbarer Workflow.

Grenzen und Umgang mit Abweichungen

Die Methode zielt darauf, möglichst viel zu automatisieren und Abweichungen gezielt sichtbar zu machen. Was passiert, wenn ein Kundenprojekt stark vom Template abweicht, z. B. in der Helm‑Chart‑Struktur oder im Deployment?

• Der Patch wird Konflikte erzeugen. Das ist gewollt – so erkennt das Team, wo das Template und die Kundenspezifika auseinanderlaufen.
• In der Review‑Phase entscheidet man pro Projekt, welche Teile des Template‑Updates übernommen werden und welche nicht.
• Erfahrungswert laut Talk: „Die meisten Sachen werden automatisch applied werden und gehen durch“. Nur die stark angepassten Projekte erfordern echten Eingriff.

Damit entsteht eine saubere Trennung: Automatisierung für den Regelfall, Review für den Sonderfall – ohne Hidden Changes.

Übertragbare Lektionen für andere Teams

Auch wenn der Use Case bei Ubitec GmbH Chatbots betrifft, sind die Prinzipien breiter anwendbar. Unsere Takeaways aus dem Talk:

• Templating lohnt sich nur, wenn Projekte regenerierbar bleiben. Das Replay‑File gehört ins Projekt.
• Versioniert das Template konsequent, und zwar mit Tags, die eure CI einfach konsumieren kann.
• Vertraut auf Git für Diffs und Patches anstatt eigene Merge‑Logik zu erfinden.
• Bringt die Unterschiede in den Kontext des konkreten Projekts – generiert alt und neu mit denselben Parametern, dann diffen.
• Akzeptiert, dass es legitime Abweichungen gibt. Normale Projekte laufen durch, Spezialfälle bekommen gezielte Aufmerksamkeit.

Schritt‑für‑Schritt‑Plan zum Nachbauen

Wer eine ähnliche Architektur betreibt – zentrales Framework, viele abgeleitete Projekte – kann den Ansatz folgendermaßen adaptieren:

1) Template sauber definieren

• Fragt in Cookiecutter alle Variablen ab, die das Projekt eindeutig machen (Name, Slug, Version, Deployment‑Flags etc.).
• Verwendet Variablen sowohl in Datei‑Inhalten als auch in Dateinamen/Verzeichnisnamen, wo sinnvoll.

2) Replay‑Datei generieren und mitliefern

• Stellt sicher, dass Cookiecutter beim ersten Generieren das Replay‑File erzeugt.
• Legt die Datei im Projekt ab, sodass sie versioniert und jederzeit verfügbar ist.

3) Git‑Organisation aufsetzen

• Template und jedes abgeleitete Projekt leben in eigenen Repositories.
• Vergesst die Tags am Template nicht. Sie sind der Auslöser für Updates.

4) Update‑Prozess formulieren

• Für ein Zielprojekt: Template „alt“ auschecken, mit Replay generieren; Template „neu“ auschecken, mit demselben Replay generieren.
• Git‑Diff der beiden generierten Trees bilden.
• Diff als Patch auf das Ziel‑Repository anwenden.

5) CI‑Integration planen

• Trigger: neuer Tag im Template‑Repo.
• Job: für alle Projekte das Verfahren durchlaufen lassen und Merge Requests erstellen.
• Review‑Regeln: Standard‑Projekte direkt mergen, Sonderfälle explizit prüfen.

Diese fünf Schritte sind bewusst generisch gehalten – sie folgen exakt der Logik aus dem Talk und nutzen ausschließlich die dort genannten Komponenten.

On‑Prem‑Realität: Warum die Lösung passt

On‑premise‑Projekte im öffentlichen Sektor bringen heterogene Betriebsumgebungen mit sich. Es ist bezeichnend, dass Ubitec für dieselbe Grundsoftware drei Deployment‑Schemata adressiert: Docker/Docker Compose, Kubernetes, OpenShift. Dazu kommen projektspezifische Container, besondere Sicherheitsanforderungen und individuelle Integrationen.

Ein Ansatz, der Updates zentral baut und dann „per Gießkanne“ ausspielt, funktioniert hier nicht. Gefragt ist ein Verfahren, das:

• projektspezifische Realität respektiert,
• Standardänderungen automatisiert transportiert,
• Abweichungen sichtbar macht statt sie zu verschleifen,
• und im gewohnten Dev‑Workflow (Git, Merge Requests) bleibt.

Genau das leistet die Kombination aus Replay + materialisiertem Diff + Git‑Apply.

Zitatmomente und Merksätze aus dem Talk

• Zur Selbstgenerierung: „Auf einmal sind wir in der Situation, dass sich der Bot … selber neu generieren kann.“
• Zum Automatisierungsdrang: „Weil wir natürlich faule Programmierer sind“ – alles in ein Skript packen und von der CI ausführen lassen.
• Zum CI‑Status: Die „Server‑Hooks“ und automatischen Merge Requests sind als nächster Schritt geplant; noch nicht umgesetzt – eine Einladung an Engineers, genau diese Pipeline zu bauen.

Fazit: Ein pragmatisches Muster für skalierbare Template‑Updates

„Templating + Git = ❤“ ist mehr als ein hübscher Titel: Es ist ein tragfähiges Rezept, um Template‑Weiterentwicklung in eine Flotte individueller Projekte zu überführen – reproduzierbar, überprüfbar, konfliktbewusst. Cookiecutter sorgt für deterministische Generierung, das Replay‑File macht Projekte jederzeit regenerierbar, Git liefert Diff, Patch und Historie.

Für Teams mit einem zentralen Framework und vielen abgeleiteten, on‑premise betriebenen Kundenprojekten ist das ein Blaupause‑Wert. Die meisten Änderungen lassen sich automatisiert übernehmen; echte Abweichungen werden transparent und können gezielt entschieden werden. Genau so bleibt ein lebendes Template lebendig – ohne die Realität der Projekte zu ignorieren.

Wer die CI‑Seite dieser Idee spannend findet: Dominik Aumayr hat im Talk klar gemacht, dass hier Ausbaupotenzial besteht – und dass Ubitec GmbH daran arbeitet, diese Pipeline zu bauen. Für uns bei DevJobs.at ist das eine der erfreulichsten Erkenntnisse aus dem Vortrag: Nicht alles braucht neue Tools. Oft reicht es, die richtigen Bausteine klug zu kombinieren – Templating und Git eben.

• 

  

  Robert Aistleitner, Principal Engineer bei Ubitec

  Principal Engineer bei Ubitec Robert Aistleitner redet im Interview über die Organisation des Devteams, auf was beim Recruiting und Onboarding Acht gegeben wird und welche technologischen Challenges das Bot-Framework von Ubitec mit sich bringt.

  Jetzt ansehen