![Joomla Entwicklungsworkflow vom GitHub Issue über Tests und Pull Requests bis zum fertigen Release](https://webdesign-hannover-laatzen.de/images/news/joomla-entwicklung-issue-pull-request-release.webp) Featured# So entsteht Joomla vom Issue bis zum Release Veröffentlicht: 25. September 2026 \\ Autor: [Thorsten Schulz](https://webdesign-hannover-laatzen.de/thorsten-schulz) \\ [Joomla News](https://webdesign-hannover-laatzen.de/joomla-news)Wie entsteht eigentlich eine neue Joomla‑Version? Was passiert, wenn ein Fehler entdeckt oder eine neue Funktion vorgeschlagen wird? Hinter jedem Joomla‑Release steht ein klar organisierter Entwicklungsprozess, an dem Anwender, Tester, Entwickler, Maintainer, Release-Manager, Übersetzer und weitere Mitglieder der internationalen Joomla‑Community beteiligt sind. Vom ersten Issue auf GitHub bis zur Veröffentlichung einer stabilen Version durchläuft jede Änderung zahlreiche Prüf- und Qualitätssicherungsstufen. Wer [Joomla](https://webdesign-hannover-laatzen.de/joomla-webdesign "Joomla") auf einer Unternehmenswebsite, Vereinsseite oder einem umfangreichen Webprojekt einsetzt, sieht am Ende meist nur das fertige Update im Backend. Der Weg dorthin ist jedoch wesentlich komplexer. Fehler müssen reproduziert, neue Funktionen bewertet, Code geschrieben, Pull Requests geprüft, automatische und manuelle Tests durchgeführt, Dokumentationen angepasst und Übersetzungen vorbereitet werden. Erst danach kann eine Änderung Bestandteil eines offiziellen Joomla‑Releases werden. Genau dieser strukturierte Workflow ist ein wichtiger Grund dafür, warum wir seit mehr als 20 Jahren auf Joomla setzen und Erfahrungen aus über 500 Joomla-Websites von Joomla 1.5 bis Joomla 6 gesammelt haben. ## Joomla wird offen auf GitHub entwickelt Joomla ist ein Open-Source-Content-Management-System. Der Quellcode des CMS ist öffentlich zugänglich und die Entwicklung findet zu einem großen Teil auf GitHub statt. Dort werden Fehler gemeldet, neue Funktionen diskutiert, Änderungen am Programmcode vorgeschlagen und Pull-Requests geprüft. Grundsätzlich kann sich jeder an der Weiterentwicklung beteiligen. Wer einen Fehler entdeckt, eine Verbesserung vorschlagen möchte oder selbst Code beitragen will, benötigt dafür lediglich einen GitHub-Account. Die offene Entwicklung bedeutet jedoch nicht, dass Änderungen ungeprüft in den Joomla‑Core gelangen. Jeder Beitrag durchläuft einen strukturierten Prozess. Genau diese Kombination aus Offenheit und kontrollierter Qualitätssicherung gehört zu den Stärken des Joomla-Projekts. Der offizielle Joomla-Entwicklungsworkflow beschreibt diesen Weg von der Meldung bis zum fertigen Release sehr detailliert. ## Alles beginnt mit einem Issue Am Anfang steht häufig ein sogenanntes **Issue**. Dabei kann es sich um einen vermuteten Fehler, einen Verbesserungsvorschlag oder die Idee für eine neue Funktion handeln. Ein Issue sollte möglichst genau beschreiben, was beobachtet wurde oder was geändert werden soll. Bei einem Fehler helfen insbesondere konkrete Angaben wie: - verwendete Joomla-Version - PHP-Version - Serverumgebung - Schritte zum Reproduzieren des Problems - erwartetes Verhalten - tatsächliches Verhalten - Fehlermeldungen oder Screenshots Nach der Veröffentlichung ist das Issue für andere Community-Mitglieder sichtbar. Sie können Kommentare ergänzen, Rückfragen stellen oder versuchen, das Problem auf einer eigenen Joomla‑Installation nachzustellen. Dadurch beginnt bereits die erste Form der Qualitätssicherung: Ein gemeldeter Fehler wird nicht einfach ungeprüft übernommen, sondern von mehreren Personen analysiert. ## Die Joomla-Bug-Squad prüft gemeldete Fehler Nicht jedes Issue ist automatisch ein bestätigter Fehler im Joomla-Core. Manche Probleme entstehen beispielsweise durch ein Template, eine Erweiterung eines Drittanbieters oder eine bestimmte Serverkonfiguration. Hier kommt die **Joomla-Bug-Squad** ins Spiel. Ihre Mitglieder analysieren Meldungen, versuchen, Fehler zu reproduzieren, und klassifizieren das Issue. Dabei geht es unter anderem um Fragen wie: - Ist das Problem tatsächlich ein Fehler in Joomla? - Ist der Fehler neu oder besteht er schon länger? - Wie groß sind die Auswirkungen? - Wie viele Installationen könnten betroffen sein? - Lässt sich das Problem zuverlässig reproduzieren? Je nach Ergebnis wird ein Issue anschließend als Bug, Feature Request oder andere Aufgabenart eingeordnet. ## Neue Funktionen durchlaufen einen eigenen Feature-Workflow Ein bestätigter Fehler muss früher oder später korrigiert werden. Bei einer neuen Funktion ist die Situation anders. Bevor zusätzlicher Code dauerhaft Bestandteil des Joomla-Cores wird, muss zunächst entschieden werden, ob die Funktion überhaupt zu Joomla passt. Feature-Requests werden deshalb von den Maintainern bewertet. Dabei spielen unter anderem folgende Fragen eine Rolle: - Sollte Joomla diese Funktion grundsätzlich enthalten? - Entsteht ein Bruch der Abwärtskompatibilität? - Welche Auswirkungen hat die Änderung auf bestehende Websites? - Könnten Erweiterungen von Drittanbietern betroffen sein? - Wie hoch ist der langfristige Wartungsaufwand? Solche Entscheidungen können intensive Diskussionen auslösen. Nicht jeder Feature-Request wird angenommen. Wird eine neue Funktion grundsätzlich freigegeben, bedeutet das außerdem nicht, dass sie sofort umgesetzt wird. Der Vorschlag kann zunächst in einer Warteschlange bleiben, bis sich ein Entwickler findet, der die technische Umsetzung übernimmt. ## Vom bestätigten Problem zum Pull Request Ist klar, was geändert werden soll, beginnt die eigentliche Entwicklungsarbeit. Niemand verändert den produktiven Joomla‑Core einfach direkt. Stattdessen wird eine Änderung in einem eigenen Entwicklungszweig programmiert und anschließend als **Pull Request**, kurz PR, eingereicht. Ein Pull Request kann sehr unterschiedlich umfangreich sein. Bei einem einfachen Schreibfehler reichen möglicherweise wenige geänderte Zeichen. Bei komplexeren Aufgaben müssen dagegen zunächst Ursachen analysiert, Abhängigkeiten geprüft und umfangreiche Anpassungen vorgenommen werden. Eine gute Einreichung dokumentiert außerdem: - welches Problem gelöst wird - welche Änderung vorgenommen wurde - wie die Änderung getestet werden kann - welches Verhalten vor der Änderung auftritt - welches Verhalten danach erwartet wird Auch das offizielle Joomla-Repository unterscheidet inzwischen klar zwischen Bugfixes, Features und Änderungen für kommende Hauptversionen und ordnet diese unterschiedlichen Entwicklungszweigen zu. ## Automatische Tests beginnen sofort Sobald ein Pull Request eingereicht wurde, starten automatische Prüfungen. Für die Betreuung dieser Testinfrastruktur gibt es innerhalb des Joomla-Projekts ein eigenes **Automatic-Testing Team**. Die automatisierten Tests prüfen, ob bestimmte Funktionen weiterhin erwartungsgemäß arbeiten und ob der eingereichte Code technische Anforderungen erfüllt. Schlägt ein Test fehl, muss der Entwickler die Ursache untersuchen und den Pull Request entsprechend überarbeiten. Werden alle automatischen Prüfungen erfolgreich abgeschlossen, kann das System spezielle Installationspakete erstellen, die bereits die Änderungen des Pull Requests enthalten. Diese Pakete können anschließend auf realen Joomla-Installationen getestet werden. ## Code-Review durch erfahrene Maintainer Automatisierte Tests können viele technische Fehler erkennen. Sie können jedoch nicht vollständig beurteilen, ob eine Lösung langfristig sinnvoll aufgebaut ist. Deshalb prüfen Joomla-Maintainer den eingereichten Code zusätzlich manuell. Dabei wird unter anderem darauf geachtet, ob: - Joomla Coding Standards eingehalten werden - die Lösung zur bestehenden Architektur passt - unnötige Abhängigkeiten vermieden werden - die Abwärtskompatibilität berücksichtigt wurde - der Code langfristig wartbar bleibt Maintainer können einen Pull-Request freigeben, Änderungen verlangen oder Verbesserungsvorschläge machen. Häufig entstehen dadurch mehrere Überarbeitungsrunden, bevor eine Lösung als technisch ausgereift gilt. ## Benutzertests unter realen Bedingungen Ein weiterer wesentlicher Bestandteil der Joomla-Entwicklung sind praktische Tests durch Anwender und Community-Mitglieder. Grundsätzlich kann jeder Pull-Requests testen. Die Schwierigkeit variiert allerdings stark. Manche Änderungen lassen sich auf einer einfachen Joomla-Testinstallation innerhalb weniger Minuten überprüfen. Andere benötigen spezielle Voraussetzungen, beispielsweise: - mehrsprachige Websites - enorme Mengen an Beiträgen - besondere Benutzerrechte - spezielle Datenbankkonfigurationen - komplexe Erweiterungen oder Workflows Gerade diese praktischen Benutzertests sind ein wichtiger Bestandteil der Qualitätssicherung – und gleichzeitig einer der Engpässe in der Joomla-Entwicklung. Automatisierte Tests können in Sekunden ausgeführt werden. Für reale Nutzungsszenarien braucht es dagegen Menschen, die Testanweisungen sorgfältig durchführen und ihre Ergebnisse dokumentieren. Die Joomla‑Community unterstützt diesen Prozess unter anderem über eine eigene PR-Testgruppe auf Mattermost sowie durch Veranstaltungen wie **Pizza, Bugs & Fun**. ## Testergebnisse werden im Joomla-Issue-Tracker bestätigt Ein praktischer Test wird nicht nur informell durchgeführt. Das Ergebnis muss im Joomla-Issue-Tracker bestätigt werden. Tester prüfen zunächst das Verhalten vor der Änderung und anschließend die Version mit dem jeweiligen Pull Request. Nur wenn nachvollziehbar dokumentiert ist, dass das Problem vorher besteht und nach der Änderung behoben wurde, gilt der Test als erfolgreich. Dadurch entsteht eine nachvollziehbare Dokumentation darüber, wer eine Änderung getestet hat und unter welchen Bedingungen sie funktioniert. ## Ready to Commit – die nächste Freigabestufe Sobald **zwei erfolgreiche Tests** im Joomla-Issue-Tracker vorliegen, kann ein Mitglied der Bug-Squad oder des Maintainer-Teams einen Pull-Request auf **„RTC – Ready to Commit“** setzen. RTC bedeutet, dass die Änderung die erforderlichen Prüfungen grundsätzlich bestanden hat und zur Übernahme in den Joomla‑Core bereit ist. Das bedeutet allerdings noch nicht automatisch, dass der Pull Request sofort übernommen wird. Bei umfangreichen oder besonders sensiblen Änderungen können weitere Prüfungen notwendig sein. Außerdem entwickelt sich der Joomla‑Core währenddessen weiter. Andere Pull Requests können den betroffenen Bereich verändern oder neue Probleme sichtbar machen. In einem solchen Fall kann der RTC-Status wieder entfernt werden und der Pull-Request kehrt in den normalen Entwicklungszyklus zurück. ## Release-Manager entscheiden über den Merge Ein Pull Request mit RTC-Status kann schließlich in den Joomla‑Core übernommen werden. Dieser Vorgang wird als **Merge** bezeichnet. An dieser Stelle übernehmen die Release-Manager eine zentrale Rolle. Für jede Joomla-Version gibt es **zwei Release-Manager**. Sie tragen gemeinsam Verantwortung für die jeweilige Veröffentlichung und entscheiden letztlich, ob und in welcher Joomla‑Version ein Pull Request aufgenommen wird. Auch bei der kommenden Joomla-Version 6.2 sind zwei Release-Manager benannt: Viviana Menzel und Martin Kopp. ## Semantic Versioning steuert die Versionszuordnung Joomla orientiert sich an den Regeln des **Semantic Versioning**. Dadurch ist klarer definiert, welche Änderungen in welcher Versionsart veröffentlicht werden können. Eine Joomla-Versionsnummer wie 6.1.3 besteht aus drei Teilen: - **6** – Major-Version - **1** – Minor-Version - **3** – Patch-Version Patch-Releases dienen vor allem der Fehler- und Sicherheitskorrektur. Minor-Versionen können neue Funktionen und Verbesserungen enthalten, ohne die Abwärtskompatibilität innerhalb der Hauptversion unnötig zu brechen. Größere technische Änderungen, bei denen bestehende Schnittstellen verändert oder entfernt werden müssen, können dagegen für eine neue Major-Version vorgesehen werden. Das lässt sich aktuell direkt im Joomla-Repository beobachten: Parallel existieren Entwicklungszweige für Joomla 5.4, Joomla 6.1, 6.2, 6.3 und bereits für Joomla 7. ## Joomla 6.2 steht unmittelbar vor der Veröffentlichung Der aktuelle Entwicklungsplan zeigt den beschriebenen Workflow sehr anschaulich. Für Joomla 6.2 wurden zunächst mehrere Alpha- und Beta-Versionen vorgesehen. Der Release Candidate ist für den **29. September 2026** geplant, die stabile Version Joomla 6.2.0 für den **13. Oktober 2026**. Der Joomla-Projektfahrplan weist ausdrücklich darauf hin, dass sich solche Termine abhängig vom Entwicklungsverlauf und der Verfügbarkeit der ehrenamtlichen Beteiligten noch ändern können. ## Programmcode allein reicht nicht Ist eine technische Änderung abgeschlossen, bedeutet das noch nicht, dass die Arbeit beendet ist. Hat ein Pull-Request Auswirkungen auf die Benutzeroberfläche, müssen etwa die Benutzerdokumentation und Hilfetexte aktualisiert werden. Wird eine neue Klasse oder Methode in den Joomla‑Core aufgenommen, benötigt auch die Entwicklerdokumentation entsprechende Ergänzungen. Diese Dokumentation ist entscheidend, damit Anwender und Erweiterungsentwickler neue Funktionen verstehen und korrekt einsetzen können. ## Neue Funktionen müssen übersetzt werden Joomla wird international eingesetzt und unterstützt zahlreiche Sprachen. Deshalb können selbst kleine Änderungen zusätzliche Arbeit für die Übersetzungsteams erzeugen. Enthält ein Pull Request neue Sprachschlüssel, müssen diese Texte für die unterschiedlichen Joomla-Sprachpakete übersetzt werden. Ein neues Eingabefeld im Backend kann damit nicht nur Entwicklungs- und Testarbeit verursachen, sondern gleichzeitig Dokumentation und Übersetzungen für zahlreiche Sprachen erforderlich machen. ## Das CMS‑Release-Team prüft die komplette Version Vor der Veröffentlichung einer neuen stabilen Joomla‑Version beginnt eine weitere Phase der Qualitätssicherung. Die Release-Manager stellen je nach Entwicklungsphase bis zu drei Alpha-Versionen, mehrere Beta-Versionen und anschließend Release-Candidates bereit. Jetzt geht es nicht mehr nur darum, einzelne Pull-Requests isoliert zu testen. Das **CMS‑Release-Team** prüft die gesamte Joomla-Version und kontrolliert, ob die vielen zusammengeführten Änderungen auch im Zusammenspiel mit der kompletten Anwendung zuverlässig funktionieren. ## Sicherheitskorrekturen benötigen besondere Abläufe Sicherheitslücken stellen innerhalb der Entwicklung einen Sonderfall dar. Details über eine noch ungepatchte Schwachstelle können selbstverständlich nicht öffentlich auf GitHub diskutiert werden. Für solche Fälle besitzt Joomla das **Security Strike Team**. Sicherheitskorrekturen werden zunächst vertraulich entwickelt und geprüft. Auch diese Änderungen durchlaufen vor der Veröffentlichung Tests. Das CMS‑Release-Team kontrolliert die Sicherheitskorrekturen gemeinsam mit den übrigen Bestandteilen eines kommenden Releases. Erst wenn eine korrigierte Joomla-Version bereitsteht, können Details über geschlossene Sicherheitsprobleme veröffentlicht werden. Dadurch erhalten Website-Betreiber zunächst die Möglichkeit, ihre Installation zu aktualisieren. ## Am Ende steht die Joomla-Release-Party Nach Issues, Entwicklung, Pull Requests, automatisierten Tests, Reviews, Benutzertests, Merge, Dokumentation und Übersetzungen kommt schließlich der Moment der Veröffentlichung. Eine stabile Joomla-Version wird während einer sogenannten **Release-Party auf Mattermost** erstellt. Community-Mitglieder können teilnehmen und die Veröffentlichung live verfolgen. Damit wird besonders deutlich, dass hinter einem Joomla-Release nicht nur Programmcode steht. Entwickler, Tester, Maintainer, Release-Manager, Dokumentations-Teams, Übersetzer, Sicherheitsteams und zahlreiche weitere Helfer wirken gemeinsam an einer Version mit. ## Wer Joomla testet oder Code beiträgt, wird Contributor Wer einen Pull Request erfolgreich beiträgt oder Änderungen testet, beteiligt sich unmittelbar an der Weiterentwicklung des Joomla-CMS. Contributor werden in den Release Notes der jeweiligen Version aufgeführt. Auch aktuelle Joomla‑Releases weisen Tester und Entwickler namentlich aus und zeigen damit transparent, wer an der jeweiligen Version mitgewirkt hat. ## Warum dieser Entwicklungsprozess für Website-Betreiber wichtig ist Der Joomla-Entwicklungsworkflow ist nicht nur für Programmierer interessant. Er zeigt Website-Betreibern, wie viel Qualitätssicherung hinter einem Update steckt. Eine Änderung gelangt nicht deshalb in eine neue Version, weil ein einzelner Entwickler sie für sinnvoll hält. Zahlreiche Prüfungen und unterschiedliche Personen sind daran beteiligt. Das bedeutet selbstverständlich nicht, dass Software vollständig fehlerfrei sein kann. Kein komplexes Content-Management-System kann das garantieren. Entscheidend ist vielmehr, dass es einen transparenten und strukturierten Prozess gibt, mit dem Probleme erkannt, Lösungen entwickelt, getestet und anschließend kontrolliert veröffentlicht werden. Genau deshalb sind regelmäßige Joomla‑Updates ein wichtiger Bestandteil des professionellen Betriebs einer Website. ## Open Source bedeutet bei Joomla nicht unkontrollierte Entwicklung Gerade im geschäftlichen Umfeld begegnet uns gelegentlich die Vorstellung, Open-Source-Software werde von beliebigen Entwicklern ohne klare Verantwortlichkeiten verändert. Der Joomla-Workflow zeigt das Gegenteil. Die Mitarbeit ist offen, die Übernahme von Änderungen dagegen kontrolliert. Mehrere organisatorische und technische Ebenen greifen ineinander: - öffentliche Issues - Bug Squad - Feature-Workflow - Pull Requests - Automatic-Testing Team - Maintainer und Code-Reviews - Community-Tests - Joomla Issue Tracker - Ready to Commit - Release-Manager - CMS‑Release-Team - Security Strike Team - Dokumentations- und Übersetzungsteams Diese Kombination aus Transparenz, weltweiter Beteiligung und klaren Qualitätsstufen ist ein wichtiger Vorteil des Joomla-Projekts. ## Über 20 Jahre Joomla‑Erfahrung und mehr als 500 Websites Wir beschäftigen uns seit mehr als zwei Jahrzehnten intensiv mit Joomla. Unsere Webdesign-Agentur aus Hannover hat sich bereits früh auf das CMS spezialisiert und inzwischen Erfahrungen aus **mehr als 500 Joomla-Websites** gesammelt. Diese Erfahrung reicht von Joomla 1.5 über Joomla 2.5, Joomla 3, Joomla 4 und Joomla 5 bis zur aktuellen Joomla-6-Generation. In dieser Zeit haben wir zahlreiche technologische Veränderungen begleitet. Anforderungen an PHP, Datenbanken, Sicherheit, Datenschutz, responsives [Webdesign](https://webdesign-hannover-laatzen.de/webdesign "Webdesign"), Barrierefreiheit und [Suchmaschinenoptimierung](https://webdesign-hannover-laatzen.de/suchmaschinenoptimierung-seo "Suchmaschinenoptimierung") haben sich erheblich weiterentwickelt. Joomla konnte diesen Wandel über viele Jahre begleiten, weil das CMS nicht statisch bleibt. Bestehender Code wird gepflegt, Funktionen werden modernisiert, technische Altlasten entfernt und neue Anforderungen über einen organisierten Entwicklungsprozess integriert. ## Regelmäßige Updates halten Joomla-Websites zukunftsfähig Der Entwicklungsworkflow zeigt zugleich, warum eine Joomla‑Website nach ihrer Veröffentlichung dauerhaft gepflegt werden sollte. Neue Versionen enthalten nicht einfach nur zusätzliche Funktionen. Sie bringen Fehlerkorrekturen, Sicherheitsupdates, technische Verbesserungen und Anpassungen an moderne Plattformen mit. Unsere Kunden mit aktivem Administrationsvertrag erhalten deshalb Joomla‑Updates innerhalb ihrer jeweiligen Joomla‑Versionslinie automatisch im Rahmen der laufenden Betreuung. Damit bleiben Joomla Core und eingesetzte Erweiterungen möglichst nah an der aktuellen technischen Entwicklung. ## Häufige Fragen zum Joomla-Entwicklungsworkflow ### Wo wird Joomla entwickelt? Die Entwicklung des Joomla-CMS findet überwiegend öffentlich auf GitHub statt. Dort werden Issues, Pull Requests und unterschiedliche Entwicklungszweige verwaltet. ### Kann jeder einen Fehler melden? Grundsätzlich ja. Anwender können Issues eröffnen und Fehler beziehungsweise Verbesserungsvorschläge beschreiben. Eine möglichst genaue und reproduzierbare Beschreibung erleichtert die Bearbeitung. ### Was ist die Joomla-Bug-Squad? Die Joomla-Bug-Squad analysiert und klassifiziert gemeldete Probleme. Sie prüft unter anderem, ob ein Fehler reproduzierbar ist und wie groß seine Auswirkungen sind. ### Was ist ein Pull Request? Ein Pull Request ist ein Vorschlag zur Änderung des Joomla-Quellcodes. Er enthält den geänderten Programmcode und normalerweise eine Beschreibung sowie Testanweisungen. ### Was ist das Automatic-Testing-Team? Das Automatic-Testing-Team betreut die Infrastruktur für automatisierte Tests. Diese Prüfungen werden bei Pull Requests ausgeführt und helfen dabei, technische Probleme frühzeitig zu erkennen. ### Kann jeder einen Joomla-Pull-Request testen? Grundsätzlich ja. Viele praktische Tests können auch von erfahrenen Joomla‑Anwendern durchgeführt werden. Manche Änderungen benötigen allerdings spezielle technische Voraussetzungen oder Entwicklungskenntnisse. ### Was bedeutet RTC? RTC steht für „Ready to Commit“. Sobald zwei erfolgreiche Tests im Joomla-Issue-Tracker vorliegen, kann ein berechtigtes Teammitglied einen Pull-Request entsprechend kennzeichnen. Damit gilt er grundsätzlich als bereit für die Übernahme in den Joomla-Core. ### Wer entscheidet, ob ein Pull Request übernommen wird? Die Maintainer und insbesondere die für eine Version zuständigen Release-Manager spielen dabei eine zentrale Rolle. Für jede Joomla-Version sind zwei Release-Manager vorgesehen. ### Was ist ein Joomla-Release-Candidate? Ein Release Candidate ist eine weit fortgeschrittene Vorabversion. In dieser Phase steht die Prüfung der geplanten stabilen Version im Mittelpunkt. Neue Funktionen sollten zu diesem Zeitpunkt grundsätzlich nicht mehr kurzfristig ergänzt werden. ### Wie werden Sicherheitslücken behandelt? Sicherheitsrelevante Änderungen werden nicht öffentlich entwickelt, solange dadurch ungepatchte Installationen gefährdet werden könnten. Das Joomla Security Strike Team bereitet entsprechende Korrekturen vertraulich vor. ### Was ist die Joomla-Release-Party? Die endgültige stabile Version wird im Rahmen einer Release-Party auf Mattermost erstellt. Mitglieder der Joomla‑Community können diesen Prozess begleiten. ### Warum ist dieser Workflow für Unternehmen relevant? Er zeigt, dass Änderungen am Joomla‑Core nicht unkontrolliert veröffentlicht werden. Tests, Code-Reviews, Maintainer, Release-Manager und spezialisierte Teams sorgen für einen strukturierten Entwicklungs- und Freigabeprozess. ## Professionelles Joomla-Webdesign und laufende Betreuung Sie möchten eine neue Joomla‑Website entwickeln, eine ältere Installation modernisieren oder Ihre bestehende Website dauerhaft technisch betreuen lassen? Unsere Webdesign-Agentur aus Hannover unterstützt Unternehmen, Vereine und Organisationen von der Konzeption über die Joomla-Migration bis zur laufenden [Administration und Pflege](https://webdesign-hannover-laatzen.de/administration-pflege "Administration und Pflege"). [Joomla Webdesign](https://webdesign-hannover-laatzen.de/joomla-webdesign) | [Joomla-Migration](https://webdesign-hannover-laatzen.de/joomla-migration) | [Administration und Pflege](https://webdesign-hannover-laatzen.de/administration-pflege) | [CMS-Templatedesign](https://webdesign-hannover-laatzen.de/cms-templatedesign)