SLA in Redmine 5.1: Plugin-Auswahl und -Anpassung | Anleitung

SLA in Redmine 5.1: Analyse nicht funktionierender Plugins und der Weg zur Anpassung

Ohne automatisierte Metriken im Task-Management sind Manager gezwungen, Fristen manuell zu überwachen, was zu Fehlern und geringerer Effizienz führt. Für Unternehmen, die Redmine 5.1 nutzen, ist die Implementierung eines SLA (Service Level Agreement) von entscheidender Bedeutung. Die Suche nach einer fertigen Lösung unter den Plugins hat jedoch erhebliche Kompatibilitäts- und Funktionsprobleme offenbart.

Einrichtung einer Testumgebung in Docker

Zur sicheren Plugin-Testung ohne Risiko für das Produktionssystem wurde eine isolierte Testumgebung mit Docker aufgesetzt. Die Konfiguration umfasste separate Container für Redmine und PostgreSQL, eine feste Redmine 5.1-Version sowie Zugriff ausschließlich über localhost. Die zentrale Lösung bestand im Mapping lokaler Verzeichnisse für Dateien und Plugins, wodurch bei jeder Änderung ein erneuter Image-Build vermieden wurde.

Beispielkonfiguration für docker-compose.yml:

services:
   postgres:
     image: postgres:16
     volumes:
       - db_data:/var/lib/postgresql/data
     environment:
       POSTGRES_USER: "redmine"
       POSTGRES_PASSWORD: "password"
       POSTGRES_DB: "redmine"
       PGDATA: "/var/lib/postgresql/data"
     restart: always
   redmine:
     image: redmine:5.1
     ports:
       - 80:3000
     volumes:
       - ./local-files:/usr/src/redmine/files
       - ./local-plugins:/usr/src/redmine/plugins
     depends_on:
       - postgres
     environment:
       REDMINE_DB_POSTGRES: "postgres"
       REDMINE_DB_USERNAME: "redmine"
       REDMINE_DB_PASSWORD: "password"
       REDMINE_DB_DATABASE: "redmine"
     restart: no
     

volumes:
  redmine_data:
  db_data:  

Die Umgebung wurde mit dem Befehl docker-compose up -d gestartet. Nach einem erfolgreichen Start (ohne Fehler) loggte der Autor sich in die Weboberfläche ein (Login: admin, Passwort: admin) und bereitete Testdaten vor: Tracker, ein Projekt und Issues. Vor der Installation der Plugins wurde ein Datenbank-Backup über das Volume-Export in Docker Desktop erstellt.

Plugin-Testmethodik

Jedes Plugin wurde einzeln getestet, um Konflikte auszuschließen. Der Prozess umfasste drei Schritte:

• Kopieren des Plugin-Ordners in das Verzeichnis ./local-plugins auf dem Host-System.
• Installieren der Abhängigkeiten via bundle install im Redmine-Container.
• Ausführen der Migrationen (falls erforderlich) mit dem Befehl rake redmine:plugins:migrate.

Bei der Abhängigkeitsinstallation traten typische Probleme mit fehlenden Gems auf, z. B.:

Could not find gem 'business_time (>= 0.13.0)'
Could not find gem 'holidays (>= 7.1.0)'

Die Lösung bestand in der manuellen Installation der fehlenden Komponenten:

gem install business_time
gem install holidays

Dieser Schritt war für die meisten getesteten Lösungen zwingend erforderlich.

Kompatibilitätsanalyse der Plugins mit Redmine 5.1

Acht Plugins mit SLA-Steuerungsfunktionalität wurden getestet. Wichtige Anforderungen an die Lösung:

• Überwachung der Reaktionszeit auf Issues.
• Überwachung der Zeit bis zur vollständigen Lösung von Issues.
• Möglichkeit, Issues nach festgelegten Parametern zu filtern.

Testergebnisse:

• reporting_sla (letztes Update 18.11.2025): inkompatibel mit Rails/Redmine-Versionen. Erfordert umfangreiche Modifikationen.
• likehopper/redmine_sla (12.02.2026): funktioniert nur mit PostgreSQL, in der Testumgebung wurde jedoch Oracle verwendet. Hohe Performance durch Auslagerung der Logik in die DB.
• redmine_issue_sla (29.01.2018): veraltetes Plugin für Redmine 3.x, startet nicht unter Version 5.1.
• redmine_sla_timer (12.07.2020): keine Beschreibung und inkompatibel mit der aktuellen Version.
• redmine_sla_ola (12.07.2020): die einzige funktionierende Option, erfordert aber zusätzliche Einrichtung – Hinzufügen benutzerdefinierter Felder products und first_reply.
• agile (03.12.2025): behandelt Projektmanagement-Aufgaben, bietet aber keine SLA-Funktionalität.
• RedmineUP Helpdesk: kommerzielle Lösung mit Support, deckt jedoch nicht alle Szenarien ab und erfordert Budget.

Empfehlungen zur SLA-Implementierung

Nach Analyse der Optionen wurde keine sofort einsatzbereite „out-of-the-box“-Lösung für Redmine 5.1 gefunden. Organisationen haben drei Wege nach vorn:

• Kauf einer kommerziellen Lösung (z. B. RedmineUP). Vorteile: Support, regelmäßige Updates. Nachteile: Einschränkungen durch Sicherheitsrichtlinien, Abweichungen von spezifischen Anforderungen.
• Anpassen eines bestehenden Plugins (redmine_sla_ola). Vorteile: Kernfunktionalität bereits implementiert. Nachteile: Anpassungsbedarf an Prozesse, Risiken bei Redmine-Updates.
• Entwicklung eines individuellen Plugins. Vorteile: exakte Anpassung an Geschäftsprozesse, keine unnötigen Features. Nachteile: Zeitaufwand (geschätzt 3–5 Tage für eine Demo-Version).

Für Organisationen mit streng regulierten SLA-Prozessen führt das Ignorieren der Automatisierung zu mehr verpassten Fristen. Beim Auswahl des Implementierungswegs nicht nur die aktuellen Kosten, sondern auch die TCO (Total Cost of Ownership) berücksichtigen. Kommerzielle Lösungen können jährliche Lizenzgebühren verursachen, während Anpassungen das Problem einmalig mit minimalen Folgekosten lösen.

Wichtige Erkenntnisse

• Versionskompatibilität ist entscheidend: Die meisten Plugins wurden nicht für Redmine 5.1 aktualisiert und sind ohne Modifikation nicht funktionsfähig.
• Zusätzliche Einrichtung erforderlich: Sogar „funktionierende“ Plugins brauchen Anpassungen (z. B. Hinzufügen von Feldern), was den Aufwand erhöht.
• Docker ist unverzichtbar: Testen in einer isolierten Umgebung schützt das Produktionssystem und beschleunigt Rollbacks.
• Gem-Abhängigkeiten sind ein häufiges Problem: Fehlende Gems für Business-Logik (business_time, holidays) erfordern manuelle Installation und erschweren den Prozess.
• Anpassung vs. kommerzielle Lösungen: Bei begrenztem Budget und klaren Anforderungen spart die Eigenentwicklung langfristig Ressourcen.

— Editorial Team