SLA en Redmine 5.1: selección y personalización de plugins | Guía

# SLA en Redmine 5.1: Análisis de plugins no funcionales y el camino hacia la personalización

En ausencia de métricas automatizadas en la gestión de tareas, los gerentes se ven obligados a supervisar manualmente los plazos, lo que genera errores y reduce la eficiencia. Para las empresas que usan Redmine 5.1, implementar SLA (acuerdo de nivel de servicio) es de vital importancia. Sin embargo, la búsqueda de una solución lista para usar entre los plugins reveló serios problemas de compatibilidad y funcionalidad.

Configuración de un entorno de prueba en Docker

Para probar plugins de forma segura sin arriesgar el sistema de producción, se desplegó un entorno de prueba aislado con Docker. La configuración incluía contenedores separados para Redmine y PostgreSQL, una versión fija de Redmine 5.1 y acceso solo vía localhost. La solución clave fue mapear directorios locales para archivos y plugins, lo que evitó reconstruir la imagen en cada cambio.

Ejemplo de configuración 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:  

El entorno se lanzó con el comando docker-compose up -d. Tras un inicio exitoso (sin errores), el autor accedió a la interfaz web (usuario: admin, contraseña: admin) y preparó datos de prueba: rastreadores, un proyecto e incidencias. Antes de instalar plugins, se creó una copia de seguridad de la base de datos mediante exportación de volúmenes en Docker Desktop.

Metodología de prueba de plugins

Cada plugin se probó de forma individual para descartar conflictos. El proceso constó de tres pasos:

• Copiar la carpeta del plugin al directorio ./local-plugins en la máquina host.
• Instalar dependencias mediante bundle install dentro del contenedor de Redmine.
• Ejecutar migraciones (si era necesario) con el comando rake redmine:plugins:migrate.

Durante la instalación de dependencias, surgieron problemas típicos con gems faltantes, por ejemplo:

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

La solución fue instalar manualmente los componentes faltantes:

gem install business_time
gem install holidays

Este paso fue obligatorio para la mayoría de las soluciones probadas.

Análisis de compatibilidad de plugins con Redmine 5.1

Se probaron ocho plugins que cumplían con la funcionalidad de control de SLA. Requisitos clave para la solución:

• Monitoreo del tiempo de respuesta a incidencias.
• Monitoreo del tiempo para resolver completamente las incidencias.
• Capacidad para filtrar incidencias por parámetros especificados.

Resultados de las pruebas:

• reporting_sla (última actualización 18.11.2025): incompatible con las versiones de Rails/Redmine. Requiere modificación profunda.
• likehopper/redmine_sla (12.02.2026): funciona solo con PostgreSQL, pero se usó Oracle en el entorno de prueba. Alto rendimiento gracias a delegar la lógica a la BD.
• redmine_issue_sla (29.01.2018): plugin obsoleto para Redmine 3.x, no arranca en la versión 5.1.
• redmine_sla_timer (12.07.2020): sin descripción e incompatible con la versión actual.
• redmine_sla_ola (12.07.2020): la única opción funcional, pero requiere configuración adicional: agregar campos personalizados products y first_reply.
• agile (03.12.2025): maneja tareas de gestión de proyectos, pero no proporciona funcionalidad SLA.
• RedmineUP Helpdesk: solución comercial con soporte, pero no cubre todos los escenarios y requiere presupuesto.

Recomendaciones para la implementación de SLA

Tras analizar las opciones, no se encontró una solución lista para usar «de fábrica» para Redmine 5.1. Las organizaciones tienen tres caminos posibles:

• Comprar una solución comercial (p. ej., RedmineUP). Ventajas: soporte, actualizaciones regulares. Desventajas: restricciones de políticas de seguridad, desajuste con requisitos específicos.
• Modificar un plugin existente (redmine_sla_ola). Ventajas: funcionalidad principal ya implementada. Desventajas: necesidad de personalización para adaptarse a los procesos, riesgos durante las actualizaciones de Redmine.
• Desarrollar un plugin personalizado. Ventajas: ajuste exacto a los procesos de negocio, sin características innecesarias. Desventajas: inversión de tiempo (estimada en 3-5 días para una versión demo).

Para organizaciones con procesos SLA estrictamente regulados, ignorar la automatización conlleva más incumplimientos de plazos. Al elegir un camino de implementación, considera no solo los costos actuales, sino también el CTO (coste total de propiedad). Las soluciones comerciales pueden requerir tarifas de licencia anuales, mientras que la personalización resuelve el problema de una vez con costos continuos mínimos.

Lecciones clave

• La compatibilidad de versiones es crítica: La mayoría de los plugins no se han actualizado para Redmine 5.1, lo que los hace no funcionales sin modificación.
• Configuración adicional requerida: Incluso los plugins «funcionales» necesitan personalización (p. ej., agregar campos), lo que aumenta el esfuerzo.
• Docker es esencial: Probar en un entorno aislado evita daños al sistema de producción y acelera los retrocesos.
• Dependencias de gems son un problema común: Gems de lógica de negocio faltantes (business_time, holidays) requieren instalación manual, complicando el proceso.
• Personalización vs. soluciones comerciales: Con un presupuesto limitado y requisitos claros, desarrollar tu propio plugin ahorra recursos a largo plazo.

— Editorial Team