En transporte y travel tech casi nunca empiezas con una página en blanco. Ya operas una plataforma que vende billetes, planifica rutas o enlaza reservas, y esa plataforma es la que genera el dinero. El reto, por tanto, no es escribir una aplicación desde cero, sino hacer desarrollo de aplicaciones de transporte que siga funcionando las 24 horas y aun así gane funcionalidades cada trimestre. Si eres CTO, responsable de plataforma o director de TI, conoces la tensión: el negocio quiere ir más rápido, mientras la deuda técnica y el riesgo de caídas tiran en sentido contrario.
Por nuestra experiencia, lo más difícil es preservar la continuidad - añadir valor sin derribar lo que ya funciona. Para un proveedor de tecnología de aviación y viajes hacemos exactamente eso: desarrollamos nuevas funcionalidades de sus aplicaciones existentes, mantenemos los sistemas y ejecutamos migraciones cloud-to-cloud sobre Java, microservicios y GCP. A continuación lo desglosamos.
¿Por qué el desarrollo y el mantenimiento de apps de transporte son lo mismo?
Porque en un producto que vive durante años no puedes separarlos sin perder algo. Un equipo que solo «apaga fuegos» nunca entiende hacia dónde va la arquitectura. Un equipo que solo entrega funcionalidades nuevas e ignora lo que ya existe te deja, un año después, con una plataforma que nadie quiere tocar.
Por eso lo tratamos como un único flujo de trabajo: el desarrollo de nuevas funcionalidades y el mantenimiento del sistema pasan por el mismo equipo, que conoce el código, las dependencias y la historia de las decisiones pasadas. Así, cada funcionalidad nueva se enchufa a la arquitectura existente de forma deliberada y no como un parche, y las pequeñas correcciones de mantenimiento se convierten en oportunidades para reducir deuda técnica. En transporte, donde las integraciones con sistemas externos están por todas partes, esa continuidad vale especialmente.
¿Cómo añadimos funcionalidades a sistemas de transporte existentes?
No reescribimos el producto, lo hacemos crecer de forma incremental. Entramos en código que funciona, leemos su lógica y añadimos funcionalidades para que el resto de la plataforma siga operando.
- leemos la arquitectura y las dependencias existentes antes de cambiar nada,
- diseñamos cada funcionalidad nueva como parte de un conjunto mayor, no como una isla,
- protegemos el cambio con pruebas para que las regresiones no maten lo que ya existe,
- desplegamos en pasos pequeños, con la opción de revertir.
Este enfoque encaja con productos que gestionan tráfico real de pasajeros o reservas y no se pueden parar una semana «por una reconstrucción».
¿Cómo construimos el backend en transporte: Java, Spring y microservicios?
El corazón de la mayoría de las plataformas de transporte es un backend en Java. Lo construimos sobre Spring y lo dividimos en microservicios, porque en este sector las distintas partes del sistema evolucionan a velocidades distintas: el motor de búsqueda de conexiones cambia a un ritmo diferente que el módulo de pagos o una integración con un proveedor.
Esa división nos da despliegues independientes por servicio, límites claros de responsabilidad y la posibilidad de escalar solo lo que está realmente bajo carga. Por encima está la capa de datos: diseñamos y mantenemos los procesos ETL/ELT que alimentan el reporting, la analítica y las integraciones. En transporte, los datos de rutas, precios y disponibilidad son un producto en sí mismos, así que tratamos su flujo con tanta seriedad como la lógica de la aplicación.
¿Cómo es un frontend de transporte en React y Angular?
Del lado del usuario trabajamos sobre todo en React y Angular. La elección depende de en qué esté escrito el producto existente - nos adaptamos al stack del cliente en lugar de imponer el nuestro.
Desarrollamos interfaces que tienen que soportar complejidad real: búsquedas de conexiones, calendarios de disponibilidad, paneles de reserva y vistas operativas. Nos aseguramos de que el frontend no se desmorone bajo una pila creciente de funcionalidades - mantenemos los componentes ordenados, vigilamos el rendimiento de renderizado y conservamos la coherencia con el resto del ecosistema. Aquí un mismo equipo se ocupa del frontend y del backend, así que una funcionalidad nueva se arma desde la API hasta la pantalla sin que la responsabilidad rebote entre proveedores.
¿Cuándo recurrimos a componentes en C++ en transporte?
Cuando lo que cuenta es el rendimiento puro. Algunos sistemas de transporte tienen secciones donde los milisegundos y el uso de memoria marcan la diferencia: procesar grandes volúmenes de datos, algoritmos computacionalmente pesados, componentes cercanos al hardware o a la infraestructura. Ahí recurrimos a C++, en el estándar C++17.
No es nuestra opción por defecto para una aplicación entera, sino una herramienta para elementos concretos, críticos en rendimiento, que luego conectamos al resto de la plataforma de Java y microservicios. El producto gana rendimiento exactamente donde lo necesita, sin complicar todo lo demás.
¿Cómo ejecutamos la migración de apps de transporte a la nube (GCP, cloud-to-cloud)?
Tratamos una migración a la nube como cirugía sobre un organismo vivo, no como un «mover los ficheros» de una vez. Para el proveedor de tecnología de aviación y viajes ejecutamos migraciones cloud-to-cloud a GCP, moviendo sistemas en producción entre entornos cloud sin que el negocio lo note.
- contenerizamos las aplicaciones (Docker) y las orquestamos en Kubernetes,
- describimos la infraestructura como código en Terraform, para que los entornos sean reproducibles,
- automatizamos los despliegues con CI/CD en Jenkins,
- migramos por etapas, con control de qué se conmuta y cuándo.
Esa infraestructura entrega después aquello por lo que migras: despliegues más rápidos y seguros, entornos predecibles y escalado al tráfico real.
¿Cómo aseguramos la calidad: QA y automatización de pruebas?
En un sistema que cambia constantemente, las pruebas manuales no dan abasto. Por eso automatizamos todo lo que podemos. Construimos pruebas end-to-end de interfaz en Selenium y pruebas de API en REST Assured, y las conectamos al pipeline de CI/CD para que cada cambio se verifique antes de seguir adelante.
Como resultado, desarrollar nuevas funcionalidades deja de significar un riesgo constante de regresión - el equipo puede añadir valor más rápido porque la red de pruebas detecta los fallos pronto. Esa es una de las condiciones para llevar desarrollo y mantenimiento en paralelo en lugar de por turnos.
¿Qué competencias aportamos a un proyecto de transporte?
Damos forma al equipo en torno al sistema concreto y a la etapa en la que está, no a partir de una plantilla fija. Normalmente combinamos varios roles:
- desarrolladores de backend (Java/Spring) que desarrollan microservicios y lógica de dominio,
- desarrolladores de frontend (React/Angular) responsables de las interfaces,
- ingenieros de C++ allí donde el rendimiento importa,
- ingenieros DevOps / cloud que llevan la contenerización, Kubernetes, Terraform y CI/CD,
- ingenieros de QA que construyen la automatización de pruebas,
- especialistas de datos que mantienen los procesos ETL/ELT.
No cubrimos todos estos roles por si acaso - incorporamos los que el proyecto realmente necesita.
¿Cómo lo hacemos en RITS?
Lo hacemos como partner nearshore desde Polonia, con experiencia real en transporte y travel tech. Para un proveedor de tecnología de aviación y viajes desarrollamos, mantenemos y migramos a la nube sus aplicaciones: añadimos nuevas funcionalidades a sistemas existentes, los mantenemos en marcha y ejecutamos migraciones cloud-to-cloud a GCP.
Por debajo corre un stack coherente: Java, Spring y microservicios en el backend, React y Angular en el frontend, C++17 en los componentes críticos de rendimiento, más Docker, Kubernetes, Terraform y Jenkins en la capa cloud y Selenium y REST Assured en la automatización de pruebas. Un equipo así trata el desarrollo y el mantenimiento como un solo trabajo, de modo que la plataforma crece en lugar de desmoronarse.
¿Por dónde empezar con el desarrollo y la migración de apps de transporte?
Empieza por un mapa honesto de lo que tienes: qué sistemas aportan valor, dónde está la deuda técnica y qué te bloquea para añadir nuevas funcionalidades. Solo eso te dice si lo más urgente es el desarrollo, el mantenimiento o una migración a la nube - y qué competencias necesitas. Tratamos las diferencias entre modelos de colaboración en nuestro artículo sobre modelos de colaboración en TI.
¿Construyes, mantienes o migras a la nube aplicaciones de transporte? Hablemos - ajustaremos un equipo y un stack a tu sistema.
Construye, mantén y migra a la nube apps de transporte con nosotros