Cómo publicamos una app de iPhone en piloto automático: la historia de Fastlane en Bardi Fuels
Subir una app a la App Store de Apple es famoso por lo quisquilloso que resulta. Hacerlo una y otra vez, de forma fiable, es donde los equipos pierden días en silencio. Así conseguimos que las releases fueran aburridas, en el mejor sentido, para Bardi Fuels.
El problema: publicar una app a mano es lento y arriesgado
Cada release de iPhone implica una lista larga: firmar la app con los certificados correctos, encajar los perfiles de aprovisionamiento, subir los números de versión, compilar, subir el binario, rellenar los datos de la App Store y enviarlo a revisión. A mano lleva una tarde entera, y un certificado equivocado o un número mal tecleado significa subida rechazada y vuelta a empezar.
Para Bardi Fuels, una plataforma de mercado solo para socios en la que la app tenía que salir y después seguir recibiendo actualizaciones, ese baile manual no servía. Las releases tenían que ser rápidas, repetibles y lo bastante seguras como para que el equipo las lanzara sin miedo.
Qué hace Fastlane en realidad
Fastlane es una herramienta de código abierto que automatiza las partes aburridas y propensas a error de publicar apps móviles. Describes los pasos de tu release una vez, como “lanes” con nombre, y a partir de ahí una release es un solo comando en vez de una lista de veinte pasos.
Piénsalo como la diferencia entre montar un paquete a mano cada vez y pulsar un botón que lo hace perfecto, igual, siempre.
Cómo lo montamos para Bardi
Construimos un conjunto de lanes que cubren toda la vida de una release:
- Build: compilar la app, firmarla correctamente y empaquetarla, con la versión y el número de build gestionados solos.
- Submit: subirla a Apple y enviarla a revisión con los datos correctos adjuntos.
- Ship: llevar una build probada a TestFlight para que gente real la pruebe antes de que salga al público.
- Status: ver de un vistazo en qué punto de la cola de revisión de Apple está un envío.
- Resubmit: relanzar limpiamente un envío si Apple pide un cambio, sin recompilar desde cero.
Una vez existieron, publicar una actualización dejó de ser un proyecto y pasó a ser un comando: menos errores, arreglos más rápidos y un proceso de release que el propio equipo del cliente puede ejecutar.
El resultado: una revisión resuelta en un día, no en una semana
La revisión de Apple señaló una incidencia en la app de Bardi, una observación habitual sobre cómo funciona el registro de cuentas. El camino manual habría sido cambiar la app, recompilarla, volver a subirla y esperar días a una revisión nueva.
En vez de eso, como la app y el pipeline de release estaban construidos para ser flexibles, lo resolvimos con un cambio pequeño en nuestro lado, sin necesidad de una build nueva, reformulamos las notas de revisión y reenviamos con un solo lane. Aprobado rápido. Conocer la plataforma, con la automatización lista, convirtió un parón de una semana en un arreglo del mismo día.
Por qué esto importa aunque lo que compres sea una web
Nunca vas a ver Fastlane. Pero el instinto que hay detrás es el mismo que hay detrás de cada proyecto de Kalebtec: automatizar las partes frágiles y repetitivas para que las publicaciones sean aburridas y fiables. Las webs que entregamos se despliegan exactamente igual: de forma automática, repetible y con el mismo cuidado.
Esa es la idea entera de Kalebtec Websites: el rigor con el que se publican apps en producción, apuntado a que tu web quede terminada y en línea, sin que tengas que pensar nunca en la maquinaria de debajo.
El trabajo se completó en menos tiempo del que se indicó inicialmente y el seguimiento ha sido impecable hasta ahora.
Pierre F. Baranyanka, fundador, Bardi Fuels