beer-tracker
Planner de sprints autocontenido con vistas personalizadas para Yandex Tracker y Jira. Aplica a múltiples organizaciones en un solo servidor.
Ficha actualizada 23 sept 2026, 18:11 · upstream 23 sept 2026, 17:56 · release v1.1.0
Qué es beer-tracker
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Beer Tracker es una herramienta de planificación de sprints que permite visualizar tareas organizadas por días y desarrolladores, además de gestionar el backlog y las burndown charts. Funciona como un planner autocontenido que puede integrarse con Yandex Tracker o Jira (Cloud/On-premise) a través de OAuth, API tokens o PATs. El proyecto utiliza Next.js 16 para la interfaz web, TypeScript y Tailwind CSS, junto con Redis como cola de trabajo opcional mediante BullMQ.
- Planificación visual de sprints en equipos distribuidos
- Gestión del backlog de desarrollo con vistas por desarrollador
- Visualización de burndown charts para seguimiento de progreso
- Control de objetivos y metas del sprint mediante checklists
- Integración con Yandex Tracker o Jira como fuente de datos externa
- Soporte multi-tenancy en un solo servidor con PostgreSQL, Redis y S3 para archivos
- Diseño responsivo con Next.js 16 y React 19 usando Tailwind CSS y Radix UI
- Sincronización asíncrona mediante BullMQ con Redis para mantener datos consistentes
- Soporte de múltiples proveedores de issue tracking (Yandex, Jira Cloud, Jira On-premise)
- API REST completa documentada con OpenAPI/Swagger
- No incluye gestión de epic a nivel de sprint ni planificación a nivel trimestral
- La sincronización entre tracker externo y planner requiere configuración manual del cron job
- El uso de OAuth con Yandex Tracker requiere un cliente OAuth configurado en el proveedor
- Las imágenes de las tarjetas de usuario se almacenan en S3, lo que puede generar costos adicionales
- No incluye funcionalidades de gestión de usuarios ni permisos avanzados
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Se recomienda desplegar en un entorno Docker Compose con PostgreSQL y Redis. Para producción, usar el build `pnpm start` o subir a AWS ECS/EKS. Configurar S3 para archivos estáticos requiere crear un bucket antes de la primera carga. El servicio sync-worker debe ejecutarse como cron job separado (ej. via systemd) para mantener la consistencia de datos entre instancias.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.