ROUTB

Plataforma de transporte compartido para estudiantes de la Universidad Tecnológica de Bolívar.

Contenido

• ROUTB
  • Contenido
  • Descripción
  • Equipo de desarrollo
  • Tecnologías
  • Inicio rápido
  • Pruebas y calidad de código
    • Pruebas locales
    • Pruebas automatizadas (CI)
    • Análisis de SonarCloud
  • Despliegue en la nube
    • Estado actual
    • Piezas desplegadas
    • Variables de entorno
    • Pasos para recrear el entorno desde cero
  • Calidad y métricas

---

Descripción

La aplicación permite consultar a estudiantes conductores y rutas disponibles, conocer la cantidad de cupos libres y reservar un cupo antes del viaje, haciendo que la organización del transporte sea más rápida y eficiente.

El objetivo es reducir los tiempos de espera y mejorar la coordinación entre estudiantes conductores y pasajeros, facilitando la organización del transporte dentro de la comunidad universitaria.

La descripción completa del problema se encuentra en Problema.

---

Equipo de desarrollo

• Diego Baron
• Junior Orozco
• Keiner Mendivil
• Julian Manjarrez

---

Tecnologías

Tecnología	Uso
Flutter	Aplicación móvil
FastAPI	Backend y API
PostgreSQL (Supabase)	Base de datos relacional administrada
Docker	Contenedor del backend (backend/Dockerfile)
Dokploy	Hosting del backend en la nube
Git / GitHub	Control de versiones

---

Inicio rápido

Para iniciar el proyecto, ejecuta el script correspondiente según tu sistema operativo en el directorio raíz del proyecto:

• Windows: start.bat
• Linux/Mac: start.sh

Para compilar la app Android hace falta además frontend/android/app/google-services.json, descargado de la consola de Firebase del proyecto del equipo. El archivo está excluido de Git (.gitignore), así que cada persona lo baja por su cuenta: el plugin com.google.gms.google-services se aplica siempre y sin ese archivo el build de Android falla.

---

Pruebas y calidad de código

Pruebas locales

Para validar el código del backend de forma local, asegúrate de estar en la carpeta backend con el entorno virtual activo y ejecuta:

pytest

Pruebas automatizadas (CI)

El recorrido de validación del flujo de autenticación se encuentra implementado y ejecutado en la nube mediante Integración Continua.

• Archivos de prueba:

  • Prueba de salud
  • Prueba de registro
  • Prueba de cupos
  • Prueba de viajes
  • Prueba de contrato

• Evidencia de ejecución (Success): GitHub Actions Run #36063583782

  Conclusion de la última ejecución: La ejecución de las pruebas automatizadas ha sido exitosa, lo que indica que el código cumple con los estándares de calidad establecidos.

Análisis de SonarCloud

El análisis de calidad se ejecuta desde GitHub Actions con el scanner oficial de SonarCloud cuando el secreto SONAR_TOKEN está configurado en el repositorio (Settings → Secrets and variables → Actions). En pull requests sin acceso a secretos, el paso se omite.

• Enlace: ROUTB en SonarCloud

---

Despliegue en la nube

Estado actual

El backend está desplegado y accesible públicamente por HTTPS:

• URL base: https://routb.iscoutb.dev
• Health check: https://routb.iscoutb.dev/health

Evidencia: Al entrar a los links de verificación, se puede observar que el servicio está funcionando correctamente. Si se necesita verificar más a fondo, se puede consultar toda la evidencia en docs/evidencia/despliegue-dokploy.md

Piezas desplegadas

El backend corre en un servidor propio administrado con Dokploy, la base de datos se guarda en el plan gratuito de Supabase y la geocodificación usa la capa gratuita de Google Maps Platform. Ninguna de estas piezas genera costo para el proyecto dentro de los límites documentados.

Pieza	Dónde se ejecuta	Proveedor	Decisión
API Backend	Contenedor Docker en servidor propio	Dokploy	ADR 0015
Base de datos	PostgreSQL 15 administrado	Supabase	ADR 0006
Geocodificación y rutas	Cliente Flutter	Google Maps Platform	ADR 0018
Renderizado del mapa	Cliente Flutter	OpenStreetMap + flutter_map	ADR 0019

El manifiesto de referencia del contenedor y de sus variables es compose.lab.yaml. No se aplica automáticamente: los valores reales de los secretos, el dominio y la política de despliegue se administran desde el panel de Dokploy.

Se mantiene la restricción RC-04 (costo recurrente $0.00 USD y cero tarjetas de crédito): el uso de Dokploy en este proyecto no genera costo y el servidor donde se ejecuta tampoco genera facturación para el equipo. Ver Restricciones de arquitectura y costo mensual.

Variables de entorno

Variable	Para qué sirve	De dónde sale el valor	Dónde se configura
DATABASE_URL	Cadena de conexión con la que la API accede a la base de datos (SSL requerido)	Datos de conexión del proyecto, en el panel de Supabase	Dokploy (Environment del servicio)
JWT_SECRET_KEY	Clave secreta con la que la API firma los tokens de autenticación	Se genera una cadena aleatoria (ver paso 4)	Dokploy (Environment del servicio)
ROUTING_TIMEOUT_SECONDS	Tiempo máximo de espera por petición a OSRM (segundos)	1.4 por defecto; ajustable según latencia y disponibilidad del proveedor	Dokploy (Environment del servicio)
FCM_PROJECT_ID	Identificador del proyecto de Firebase desde el que se envían las notificaciones push	Consola de Firebase del proyecto del equipo	Dokploy (Environment del servicio)
FCM_SERVICE_ACCOUNT_B64	Credencial de la cuenta de servicio de Firebase (el JSON en base64) con la que la API firma cada envío	Consola de Firebase → Cuentas de servicio → Generar nueva clave privada	Dokploy (Environment del servicio)
GOOGLE_MAPS_API_KEY	Clave de Google Maps Platform para geocodificación, autocompletado y rutas en el cliente Flutter	Google Cloud → APIs y servicios → Credenciales; debe estar restringida por plataforma y APIs	frontend/.env (ignorado por git) e inyección con --dart-define-from-file=.env

Pasos para recrear el entorno desde cero

Requisitos: cuentas gratuitas en GitHub y Supabase, un servidor con Docker y Dokploy instalado, y un dominio o subdominio con DNS apuntando al servidor.

1. Base de datos (Supabase): crea un proyecto (plan Free) y copia la cadena de conexión del panel; la usarás como DATABASE_URL.
2. Migraciones: en backend, con las dependencias instaladas y DATABASE_URL exportada, ejecuta alembic upgrade head.
3. Servicio (Dokploy): crea un proyecto y un servicio desde el repositorio de GitHub (rama Changes), con backend/Dockerfile como build; compose.lab.yaml documenta el contenedor y sus variables como referencia. Configura el dominio routb.iscoutb.dev y deja que Dokploy emita el certificado TLS.
4. Variables de entorno en Dokploy → Environment: DATABASE_URL (paso 1), JWT_SECRET_KEY (genera una con python -c "import secrets; print(secrets.token_urlsafe(32))"), ROUTING_TIMEOUT_SECONDS (por defecto 1.4) y las credenciales FCM_* si se usan notificaciones push.
5. Verificar: espera a que el servicio quede desplegado y prueba:

   curl https://routb.iscoutb.dev/health
   curl -i https://routb.iscoutb.dev/trips/

El contenedor corre de forma continua en Dokploy: no hay suspensión por inactividad ni arranque en frío. La verificación completa está en docs/evidencia/despliegue-dokploy.md. La documentación interactiva de la API está en /docs.

---

Calidad y métricas

La calidad de rendimiento se verifica con una métrica consultable: el percentil 95 de la latencia de GET /trips/ debe ser menor a 3,99 s. El escenario, la fuente de datos, la consulta, el umbral y la medición realizada están en Metricas frente a escenario de calidad. La medición reproducible de la Semana 14, con el script versionado y las instrucciones para repetirla, está en medición del escenario de rendimiento.