SLA w Redmine 5.1: wybór wtyczek i dostosowanie | Przewodnik

# SLA w Redmine 5.1: analiza niepracujących wtyczek i droga do dostosowania

W warunkach braku zautomatyzowanych metryk w zarządzaniu zadaniami kierownicy są zmuszeni ręcznie kontrolować przestrzeganie terminów, co prowadzi do błędów i obniżenia efektywności. Dla firm korzystających z Redmine 5.1 wdrożenie SLA (Service Level Agreement) staje się krytycznie ważne, jednak poszukiwanie gotowego rozwiązania wśród wtyczek ujawniło poważne problemy z kompatybilnością i funkcjonalnością.

Przygotowanie stanowiska testowego w Dockerze

Pod kątem bezpiecznego testowania wtyczek bez ryzyka dla systemu produkcyjnego uruchomiono izolowane stanowisko oparte na Dockerze. Konfiguracja obejmowała oddzielne kontenery dla Redmine i PostgreSQL, stałą wersję Redmine 5.1 oraz dostęp tylko przez localhost. Kluczowym rozwiązaniem było mapowanie lokalnych katalogów dla plików i wtyczek, co pozwoliło uniknąć ponownego budowania obrazu przy każdej zmianie.

Przykład konfiguracji 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:  

Uruchomienie stanowiska odbywało się poleceniem docker-compose up -d. Po pomyślnym starcie (bez błędów) autor zalogował się do interfejsu webowego (login: admin, hasło: admin) i przygotował dane testowe: słowniki, projekt oraz zadania. Przed instalacją wtyczek wykonano kopię zapasową bazy danych poprzez eksport woluminu w Docker Desktop.

Metodologia testowania wtyczek

Każda wtyczka była testowana indywidualnie, aby wykluczyć konflikty. Proces obejmował trzy etapy:

• Kopiowanie folderu wtyczki do katalogu ./local-plugins na maszynie hosta.
• Instalację zależności za pomocą bundle install wewnątrz kontenera Redmine.
• Wykonanie migracji (jeśli potrzebne) poleceniem rake redmine:plugins:migrate.

Na etapie instalacji zależności pojawiły się typowe problemy z brakującymi gemami, na przykład:

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

Rozwiązaniem była ręczna instalacja brakujących komponentów:

gem install business_time
gem install holidays

Ten krok okazał się konieczny dla większości testowanych rozwiązań.

Analiza kompatybilności wtyczek z Redmine 5.1

Przetestowano osiem wtyczek odpowiadających funkcjonalnie zadaniu kontroli SLA. Główne wymagania wobec rozwiązania:

• Kontrola czasu reakcji na zadanie.
• Kontrola czasu pełnego rozwiązania zadania.
• Możliwość filtrowania zadań według podanych parametrów.

Wyniki testów:

• reporting_sla (ostatnia aktualizacja 18.11.2025): brak kompatybilności z wersjami Rails/Redmine. Wymaga głębokiej modyfikacji.
• likehopper/redmine_sla (12.02.2026): działa tylko z PostgreSQL, ale w środowisku testowym używano Oracle. Wysoka wydajność dzięki przeniesieniu logiki do bazy danych.
• redmine_issue_sla (29.01.2018): przestarzała wtyczka dla Redmine 3.x, nie uruchamia się na wersji 5.1.
• redmine_sla_timer (12.07.2020): brak opisu i brak kompatybilności z bieżącą wersją.
• redmine_sla_ola (12.07.2020): jedyny działający wariant, ale wymaga dodatkowych ustawień — dodania niestandardowych pól products i first_reply.
• agile (03.12.2025): rozwiązuje zadania zarządzania projektami, ale nie zapewnia funkcjonalności SLA.
• RedmineUP Helpdesk: rozwiązanie komercyjne z wsparciem, ale nie obejmuje wszystkich scenariuszy i wymaga budżetu.

Zalecenia dotyczące wdrożenia SLA

Po analizie wariantów stwierdzono, że nie istnieje gotowe rozwiązanie „prosto z pudełka” dla Redmine 5.1. Organizacjom proponuje się trzy ścieżki:

• Zakup rozwiązania komercyjnego (np. RedmineUP). Plusy: wsparcie, regularne aktualizacje. Minusy: ograniczenia polityki bezpieczeństwa, niezgodność z specyficznymi wymaganiami.
• Modyfikacja istniejącej wtyczki (redmine_sla_ola). Plusy: podstawowa funkcjonalność już zaimplementowana. Minusy: konieczność dostosowania do własnych procesów, ryzyka przy aktualizacjach Redmine.
• Opracowanie niestandardowej wtyczki. Plusy: dokładne dopasowanie do procesów biznesowych, brak zbędnej funkcjonalności. Minusy: nakład czasu (szacunkowo 3-5 dni na wersję demo).

Dla organizacji, których procesy są ściśle regulowane przez SLA, ignorowanie automatyzacji prowadzi do wzrostu liczby przegapionych terminów. Przy wyborze ścieżki wdrożenia należy brać pod uwagę nie tylko bieżące koszty, ale także TCO (Total Cost of Ownership). Rozwiązania komercyjne mogą wymagać corocznych opłat licencyjnych, podczas gdy dostosowanie jednorazowo rozwiąże problem przy minimalnych dalszych kosztach.

Co jest ważne

• Kompatybilność wersji jest kluczowa: Większość wtyczek nie była aktualizowana pod Redmine 5.1, co czyni je niepracującymi bez modyfikacji.
• Wymagane są dodatkowe ustawienia: Nawet „działające” wtyczki potrzebują dostosowania (np. dodanie pól), co zwiększa nakład pracy.
• Docker — obowiązkowy etap: Testowanie w izolowanym środowisku zapobiega uszkodzeniu systemu produkcyjnego i przyspiesza proces cofania zmian.
• Zależności gemów — częsty problem: Brak biznesowej logiki w gemach (business_time, holidays) wymaga ręcznej instalacji, co komplikuje proces.
• Dostosowanie vs rozwiązania komercyjne: Przy ograniczonym budżecie i jasnych wymaganiach opracowanie własnej wtyczki oszczędza zasoby w dłuższej perspektywie.

— Editorial Team