SLA v Redmine 5.1: výběr pluginů a přizpůsobení | Průvodce

# SLA v Redmine 5.1: analýza nefunkčních pluginů a cesta k přizpůsobení

V podmínkách absence automatizovaných metrik při řízení úkolů jsou manažeři nuceni manuálně sledovat dodržování lhůt, což vede k chybám a poklesu efektivity. Pro společnosti používající Redmine 5.1 se stává zavedení SLA (Service Level Agreement) klíčové, ale hledání hotového řešení mezi pluginy odhalilo vážné problémy s kompatibilitou a funkcemi.

Příprava testovacího prostředí v Dockeru

Pro bezpečné testování pluginů bez rizika pro provozní systém bylo nasazeno izolované prostředí na bázi Dockeru. Konfigurace zahrnovala samostatné kontejnery pro Redmine a PostgreSQL, pevnou verzi Redmine 5.1 a přístup pouze přes localhost. Klíčovým řešením se stalo mapování lokálních adresářů pro soubory a pluginy, což umožnilo vyhnout se přebudování obrazu při každé změně.

Příklad konfigurace 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:  

Spouštění prostředí probíhalo příkazem docker-compose up -d. Po úspěšném startu (bez chyb) se autor přihlásil do webového rozhraní (přihlašovací jméno: admin, heslo: admin) a připravil testovací data: adresáře, projekt a úkoly. Před instalací pluginů byla provedena záloha databáze exportem svazku v Docker Desktop.

Metodika testování pluginů

Každý plugin byl testován samostatně, aby se vyloučily konflikty. Proces zahrnoval tři kroky:

• Kopírování složky pluginu do adresáře ./local-plugins na hostitelské mašině.
• Instalaci závislostí příkazem bundle install uvnitř kontejneru Redmine.
• Provedení migrací (pokud bylo potřeba) příkazem rake redmine:plugins:migrate.

Během instalace závislostí se objevily typické problémy s chybějícími gemy, například:

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

Řešením byla manuální instalace chybějících komponent:

gem install business_time
gem install holidays

Tento krok se stal povinným pro většinu testovaných řešení.

Analýza kompatibility pluginů s Redmine 5.1

Bylo otestováno osm pluginů odpovídajících funkcím SLA kontroly. Hlavní požadavky na řešení:

• Kontrola času reakce na úkol.
• Kontrola času úplného vyřešení úkolu.
• Možnost filtrování úkolů podle zadaných parametrů.

Výsledky testování:

• reporting_sla (poslední aktualizace 18.11.2025): nekompatibilita s verzemi Rails/Redmine. Vyžaduje hlubokou úpravu.
• likehopper/redmine_sla (12.02.2026): funguje pouze s PostgreSQL, ale v testovacím prostředí byla použita Oracle. Vysoký výkon díky přesunu logiky do DB.
• redmine_issue_sla (29.01.2018): zastaralý plugin pro Redmine 3.x, nespouští se na verzi 5.1.
• redmine_sla_timer (12.07.2020): chybí popis a nekompatibilita s aktuální verzí.
• redmine_sla_ola (12.07.2020): jediné funkční řešení, ale vyžaduje další nastavení – přidání vlastních polí products a first_reply.
• agile (03.12.2025): řeší úkoly řízení projektů, ale neposkytuje SLA funkce.
• RedmineUP Helpdesk: komerční řešení s podporou, ale nezakrývá všechny scénáře a vyžaduje rozpočet.

Doporučení pro zavedení SLA

Po analýze variant se ukázalo, že hotové „z krabice“ řešení pro Redmine 5.1 neexistuje. Organizacím jsou nabízeny tři cesty:

• Nákup komerčního řešení (např. RedmineUP). Výhody: podpora, pravidelné aktualizace. Nevýhody: omezení bezpečnostní politiky, nesoulad se specifickými požadavky.
• Úprava existujícího pluginu (redmine_sla_ola). Výhody: základní funkcionalita je již implementována. Nevýhody: nutnost úprav podle vlastních procesů, rizika při aktualizacích Redmine.
• Vývoj vlastního pluginu. Výhody: přesný soulad s obchodními procesy, absence „zbytečných“ funkcí. Nevýhody: časové náklady (odhad 3–5 dní na demo verzi).

Pro organizace, jejichž procesy jsou přísně regulovány SLA, ignorování automatizace vede k růstu počtu promeškaných termínů. Při výběru cesty zavedení je třeba zohlednit nejen aktuální náklady, ale i TCO (Total Cost of Ownership). Komerční řešení mohou vyžadovat roční licenční poplatky, zatímco přizpůsobení jednorázově vyřeší problém s minimálními následnými náklady.

Co je důležité

• Kompatibilita verzí je klíčová: Většina pluginů nebyla aktualizována pro Redmine 5.1, což je činí nefunkčními bez úprav.
• Vyžadují se další nastavení: I „funkční“ pluginy potřebují přizpůsobení (např. přidání polí), což zvyšuje nároky na práci.
• Docker je povinný krok: Testování v izolovaném prostředí zabraňuje poškození provozního systému a urychluje návrat.
• Závislosti gemů jsou častý problém: Absence obchodní logiky v gemech (business_time, holidays) vyžaduje manuální instalaci, což proces komplikuje.
• Přizpůsobení vs. komerční řešení: Při omezeném rozpočtu a jasných požadavcích vývoj vlastního pluginu ušetří zdroje dlouhodobě.

— Editorial Team