La semana pasada hablábamos sobre la aventura pandémica en Goxo, donde veíamos lo importante que era abrazar la incertidumbre para poder ser funcional en situaciones donde está todo por construir. También comentábamos la relevancia de tener un buen mecanismo para tomar decisiones y que hay un punto de suerte en casi todo lo que hacemos. Finalmente, hacíamos hincapié en que un equipo de tecnología y producto necesita tener autonomía para hacer su magia y que, en todo esto, tu misión como responsable es proporcionarles esa brújula en forma de propósito hacia donde se dirige la visión de la organización.
En esta nueva entrada, voy a comentar cómo resolvimos algunos de los retos de escalabilidad del negocio desde el punto de vista tecnológico, sobre todo relacionados con escalar la creación de las aplicaciones móviles. ¡Vamos al lío!
Productivización de aplicaciones móviles#
El primer reto al que nos enfrentábamos a medida que íbamos consiguiendo clientes era el de “productivizar” las aplicaciones móviles. Recordemos que para cada cliente teníamos que entregar una aplicación iOS y una aplicación Android con la imagen personalizada de marca del cliente en menos de 24h. La visión a largo plazo era tener un mecanismo de auto-servicio en forma de portal web para que el cliente configurara esa imagen personalizada: los colores primarios y secundarios, imagen del splash al abrir la aplicación, etc., y que una vez seleccionados, se desencadenara un mecanismo de subida de las aplicaciones a las tiendas de aplicaciones de Apple y Android respectivamente.
Reto de los lenguajes de programación#
Para abordar el tema de los lenguajes de programación, nos fue muy útil el conocimiento acumulado cuando éramos una red social, donde la aplicación móvil se había creado con React Native como framework multi-plataforma que nos permitía desarrollar un único código y luego compilarlo para cada plataforma. Al final, nuestra aplicación no necesitaba utilizar las últimas capacidades de los teléfonos donde se ejecuta la aplicación, con lo cual podíamos permitirnos utilizar este tipo de frameworks que, al no ser nativos, siempre van un poco por detrás en cuanto a la posibilidad de explotar todas las características del dispositivo en cuestión.
Plantilla de aplicación y automatización#
Para abordar la distribución, necesitábamos cumplir un primer hito, que era tener una especie de plantilla de la aplicación marca blanca, en nuestro caso marca Goxo, y que con una pequeña configuración (no desarrollo, pues la idea es que esto lo pudiera hacer una persona sin conocimientos técnicos) tuviéramos la aplicación personalizada para el cliente. Lo logramos digitalizando el proceso de cambiar los archivos de configuración necesarios y generando las distintas versiones de los archivos de imágenes en el lugar adecuado para que al subir las aplicaciones a las tiendas de las plataformas, todo estuviera donde tiene que estar. Surgió así el concepto de “churrera de las aplicaciones” (no sé cómo voy a traducir este concepto al inglés, LOL) en la que básicamente sobre el repositorio de la aplicación, aplicábamos un script que vestía la aplicación con la imagen personalizada del cliente.
Automatización de la subida a las tiendas de aplicaciones#
Por tanto, el siguiente hito que teníamos que alcanzar era conseguir que el proceso de subida a la aplicación también fuera automático. El reto aquí era que cada plataforma requiere seguir un procedimiento, normalmente con su propio IDE, en el que se genera un paquete (digamos, un fichero) que contiene la aplicación y que se tiene que firmar antes de subir a la respectiva tienda. En el caso de iOS, todo esto lo tienes que hacer con un ordenador Apple donde ejecutes XCode, que es el IDE para desarrollar aplicaciones para los dispositivos Apple, y desde donde haces todo ese procedimiento. Esto conlleva el tiempo de una persona en modo síncrono delante del ordenador haciendo estos procedimientos, normalmente podíamos tardar en este proceso unos 45 minutos en total. Una pequeña nota para product managers: un KPI que buscábamos optimizar en Goxo era precisamente este time to marketplace, el tiempo que tardábamos en preparar una aplicación para el cliente, ya que era fundamental para nosotros porque estaba correlacionado con el time to cash. Cuando antes pusiéramos la aplicación en el marketplace de aplicaciones, antes empezaría el cliente a recibir pedidos y, por extensión, nosotros a ganar dinero. Nosotros, para atacar este reto, utilizamos una tecnología que se llama Fastlane, que nos permitió crear nuevamente unos scripts que se encargaban de hacer el procedimiento asíncrono de subida de la aplicación a las dos tiendas de aplicaciones, liberando a esta persona de estar pendiente de hacer el proceso por cada cliente.
Evolución y CI/CD#
Pero el reto de escalabilidad no acababa ahí. Hasta ahora hemos resuelto el problema de la puesta en marcha del cliente, pero todos sabemos que las aplicaciones van evolucionando. Hay que añadir nuevas funcionalidades, arreglar fallos y, al estar la aplicación encapsulada y colocada en un escaparate como la tienda de aplicaciones, cada nueva actualización, cada nueva versión de la aplicación, obliga a volver a subir la actualización para todos los clientes, duplicado, una por cada plataforma. Calculando para 50 clientes, supongamos que tardamos 20 minutos con los scripts anteriores en actualizar las dos aplicaciones. Estamos hablando de que tardaríamos 1000 minutos, unas 17 horas de tiempo de ejecución, con lo cual teníamos que buscar formas de paralelizar este mecanismo de actualización. Para ello llegó Bitrise al rescate. Esta plataforma nos permitió crear un conjunto de pipelines de CI/CD con el que resolver este problema. Básicamente, estableces una serie de pasos atomizados a ejecutar en determinados contextos para llevar a cabo la subida a las plataformas de Apple y Google. Tiene funcionalidades muy útiles, como guardar cachés de compilación de dependencias, entre otras cosas.
Reflexión Final#
Algunos os preguntaréis por qué no evitar todo este jaleo haciendo una aplicación web, parametrizar la URL para personalizar al cliente y hacer un simple webview en la app. Podría haber sido una opción en un momento dado una vez que ya dispusiéramos de la aplicación web con paridad de funcionalidades (de hecho, esa era la idea), pero eso “solo” simplificaría los scripts (y el desarrollo de funcionalidades), pero tendríamos el mismo problema de escalabilidad en la distribución, porque cada aplicación tiene su propio registro dentro de las tiendas de aplicaciones de las plataformas móviles.
Con lo cual, después de toda esta evolución, ¿cuál es la principal conclusión que hay que sacar de esta entrada? Pues que hay que pensar en el largo plazo y ejecutar a corto, poner los pasos que te permitan ir construyendo esa visión en la dirección adecuada, el famoso “thinking big, start small” (piensa a lo grande pero empieza por lo pequeño).
Hasta aquí la entrada de hoy. Espero que la hayáis disfrutado. ¿Os habéis enfrentado a estos retos de distribución? ¿Cómo los habéis resuelto? Escribidme y contadme.