Integración continua para iOS y Android con Fastlane + Gitlab CI

0
196
  1. Introducción
  2. Crear el contenedor docker para compilar Android
  3. Usar GitLab Runner para compilar iOS
  4. El uso de fastlane
  5. Los instrumentos de GitLab CI
  6. Conclusiones
  7. Referencias

Introducción

En este tutorial vamos a aprender cómo se puede montar el entorno de integración continua para aplicaciones móviles iOS y Android utilizando las herramientas que nos proporciona la plataforma GitLab. ¿Para qué sirve la integración continua? Si tienes alguna experiencia en la programación, tal vez hayas tenido una situación en la que al bajar algunos cambios de un repositorio algo dejó de funcionar. En un equipo de múltiples personas es bastante complicado controlar la consistencia y la calidad del código. La integración continua puede prevenir las situaciones de este tipo. Pero si eres la única persona que trabaja en un proyecto las compilaciones automáticas y la ejecución de pruebas después de cada commit pueden ser muy útiles también. Con la integración continua, puedes notar problemas más rápido y solucionarlos más pronto.

Crear docker contenedor para compilar Android

Para compilar el proyecto de Android vamos a utilizar el contenedor de Docker. Es una manera eficaz y bastante sencilla para construir y ejecutar las aplicaciones sin tener que utilizar un equipo real. Los contenedores Docker son una manera segura y consistente de crear un entorno de pruebas.

En este fichero docker aparte de Android SDK metemos también las gemas de Ruby como Bundler y Fastlane que nos ayudarán en el proceso de la subida de nuestros binarios a las tiendas online de las aplicaciones AppStore (iOS) y PlayStore (Android).

También tenemos que hacer un par de cambios en nuestra configuración básica de Gradle para facilitar la publicación. En el fichero app/build.gradle tenemos que poner las variables que se utilizarán para firmar nuestra aplicación Android. Podemos usar un fichero que contiene todas variables o utilizar las variables de GitLab. Es más seguro el segundo.

También tenemos que subir la versión de código cada vez que subamos el binario. Para ello introducimos pequeños cambios en el mismo fichero:

Para firmar la versión release inyectamos nuestras variables que hemos introducido antes:

Usar GitLab Runner para compilar iOS

Desafortunadamente para compilar iOS aplicaciones en el entorno Gitlab hace falta un equipo físico. No se puede usar ni los contenedores Docker, ni maquinas virtuales. La única solución es instalar una aplicación GitLab Runner en en equipo físico. Se hace bastante rápido y fácilmente. Aquí puedes ver las instrucciones para todos los sistemas operativos. Después de instalar Gitlab Runner tienes que registrarlo con un token de tu proyecto. También tienes que ponerle un tag para usarlo luego en el script de Gitlab CI. De este modo, las tareas vinculadas al iOS se van a ejecutar en el equipo con el Gitlab Runner instalado.

El uso de fastlane

Para usar Gitlab CI, necesitamos una forma de construir y archivar nuestro proyecto desde terminal. Aunque podemos hacer esto sin herramientas adicionales usando el comando xcodebuild, la mejor solución será usar la herramienta Fastlane. Si no has utilizado Fastlane antes, en resumen, es una herramienta que, basada en un script simple preparado por nosotros, puede realizar automáticamente varias operaciones relacionadas con todo el proceso de desarrollo de la aplicación. Por ejemplo: crear un proyecto, ejecutar pruebas, generar informes de cobertura de código, enviar compilaciones a TestFlight, HockeyApp, etc., generar automáticamente capturas de pantalla de la aplicación, enviar notificaciones de compilación y muchas otras operaciones.

Para asegurarnos de que usamos las mismas versiones de todas las herramientas necesarias en cada ordenador, podemos usar la herramienta Bundler. Se puede decir que Bundler es algo similar a Cocoapods, pero en lugar de un Podfile tenemos un Gemfile y en lugar de administrar versiones de bibliotecas de iOS, se usa para administrar versiones de gemas Ruby, por ejemplo, CocoaPods y Fastlane. Por lo tanto, es otra herramienta que en algunos casos facilita la vida y ayuda a evitar problemas de incompatibilidad entre versiones particulares de gemas de Ruby.

El problema con las diferentes versiones de CocoaPods está relacionado con la situación en la que los Pods no se guardan en el repositorio de git. Si todo el directorio de Pods se mantiene en el repositorio de git y no tienes que descargar bibliotecas externas para compilar su proyecto, entonces el problema no se produce y quizás no necesites Bundler en este caso. Dependiendo de tus preferencias y necesidades, puedes decidir si vale la pena usar Bundler en tu caso o tal vez valga la pena mantener Pods en git. Configuremos Fastlane para que podamos construir y exportar el binario de nuestro proyecto desde la terminal.

De acuerdo con la descripción en https://docs.fastlane.tools/getting-started/ios/setup/ puedes instalar Fastlane con este comando:

El uso de «gem install fastlane -NV» puede requerir sudo si no se usa RVM en tu ordenador ni has cambiado la ruta de instalación de gemas configurando la variable de entorno GEM_HOME. Cuando finalice la instalación de Fastlane, puedes ir al directorio con tu proyecto en la terminal e inicializar Fastlane con el siguiente comando:

Después de eso, se creará un nuevo directorio fastlane con un archivo llamado Fastfile. Alternativamente, en lugar de fastlane init, simplemente puedes crear ese directorio y archivo manualmente. Abre ese archivo en cualquier editor de texto y cambia su contenido a lo siguiente para iOS:

Y para Android:

Ahora puedes probar desde la terminal de tu equipo si todo está bien definido.

Fastlane también nos puede ayudar en subir los binarios a las tiendas de aplicaciones (markets). Para eso hay que utilizar en el caso de Android el comando upload_to_play_store:

y en el caso de iOS upload_to_test_flight:

Ambos tienen muchos parámetros pero los principales son la ubicación del binario (en el caso de iOS lo puedes definir en el fichero Gymfile), los parámetros de las pruebas internas o externas, la información para los testers etc.

Los instrumentos de Gitlab CI

Ya hemos configurado Gitlab Runner y podemos construir nuestro proyecto desde la terminal. Es hora de hacer que nuestro proyecto se construya automáticamente después de cada cambio en git. Necesitamos un archivo de configuración .gitlab-ci.yml que debemos crear en el directorio principal de nuestro repositorio. Entonces deberíamos poner en él el siguiente contenido:

Este job utiliza el template .upload-iOS-app con los ajustes previos de fastlane como export LC_ALL=en_US.UTF-8 y export LANG=en_US.UTF-8 y se ejecutan los comandos de fastlane para incrementar el numero de build, compilar la versión release y subir el fichero ipa (binario) a TestFlight.

Para Android el script es diferente. Utilizamos el contenedor de Docker que ya hemos preparado antes. Tenemos que preparar las variables de GitLab para que funcione nuestro job. $signing_jks_file_hex es un hexdump de nuestro almacenamiento de claves de Android. Luego lo convertimos con el comando «echo «$signing_jks_file_hex» | xxd -r -p – > ./android/key.keystore» en el fichero inicial. Subimos la versión del código de la app utilizando la variable $CI_PIPELINE_IID (el id de nuestro pipeline). Sacamos de otra variable GitLab $google_play_api_key_json la clave de Google Play Api que se utiliza para acceder al Google Play Store. Al final, borramos los ficheros con las claves.

El job «upload-android-dev-app» lanza el comando «bundle exec fastlane android buildRelease flavor:dev» para compilar la aplicación con el flavor (un variante de compilación) «dev». Después se utiliza bundle exec fastlane android internal para subir el binario a Play Store.

Conclusiones

Hay que tener en cuenta que por defecto GitLab ofrece 2 000 minutos de integración continua gratuitos y luego si se te acabarán los minutos tienes que pagar. Aun así para los proyectos pequeños es una gran ayuda. No tienes que montar tu propio entorno de integración continua comprando y manteniendo los equipos propios. Y si ya los tienes puedes usarlos instalando GitLab Runner y gestionando todo el proceso desde la pagina web de GitLab. El equipo de GitLab promete implementar los runners compartidos con Mac OS en el futuro: GitLab issues. Su principal competidor GitHub ya tiene esta funcionalidad. Esperemos que sea pronto y podemos evitar así instalar GitLab Runner en una máquina real. Como veis montar un entorno de pruebas con GitLab CI y Fastlane es bastante sencillo y no requiere mucho tiempo.

Referencias

  1. Android Publishing with Fastlane
  2. iOS CI with fastlane

 

 

 

 

Dejar respuesta

Please enter your comment!
Please enter your name here