Integración continua en Android

¿Cómo pueden los desarrolladores de Android garantizar la calidad de su código en un repositorio compartido?

¿Qué es la integración continua?

La integración continua (IC) es una de las mejores y más importantes prácticas del profesional en la industria del desarrollo de aplicaciones móviles. Permite a los desarrolladores automatizar su proceso de integración y garantiza que el desarrollo de software cumpla con los estándares de calidad requeridos.

En otras palabras, cada vez que alguien envía un código, Android Seamless Integration crea y ejecuta automáticamente pruebas unitarias en el servidor y le notifica al instante sobre cualquier error (también le notifica sobre compilaciones exitosas) antes de cualquier fusión. Esto es genial, ¿no?

¿Qué es la entrega continua?

La entrega continua (CD) es la parte más interesante para mí. Facilita la vida a los desarrolladores e implementa automáticamente nuevas versiones para pruebas o producción en Play Store. Asegura que cualquiera de los desarrollos en el proceso de CI se encuentre en un estado fácilmente implementable.

Con este ejemplo veremos cómo podemos implementar la integración continua para un proyecto de Android usando Fastlane y GitlabCI.

Estos son los pasos que seguiremos en este post:

• Integración Fastlane, configuración Fastfile y definición de todas las pistas que necesitaremos más adelante
• Creación del archivo .gitlab-ci.yml y definición de pasantías y trabajos
• Registro de corredor para nuestro proyecto
• Enviar algo al repositorio y ver la canalización activa en ejecución

Nota: Suponemos que estás familiarizado con el proceso de creación de una aplicación de Android, que puede escribir y ejecutar pruebas localmente y que estás familiarizado con los conceptos básicos de la interfaz de usuario de GitLab UI.

¿Cómo podemos automatizar nuestras tareas?

Para lograr el objetivo, usaremos Fastlane: una plataforma de código abierto escrita en Ruby que automatiza las tareas más aburridas con unos pocos comandos. Fastlane maneja casi todo, desde manejar capturas de pantalla, crear la aplicación, ejecutar pruebas unitarias y la interfaz de usuario, administrar versiones de compilación, cargar una compilación en Firebase o para producción en PlayStore, y más. En este post, cubriremos solo algunos de ellos.

Tiene una gran cantidad de empleados; por lo tanto, podemos encontrar muchos complementos que pueden usarse para ahorrar tiempo: https://fastlane.tools

Estos son los pasos para configurar Fastlane:

• Instale las últimas herramientas de línea de comandos de Xcode: xcode-select --install​
• Instalar Fastlane. Hay dos opciones:
  • Usando RubyGems: sudo gem install fastlane -NV 
  • Usando homebrew: brew install fastlane
• Navegamos a nuestro directorio de proyectos e iniciamos Fastlane con la siguiente línea de comando:
  • cd project_path
  • fastlane init

Se nos pedirá que proporcionemos la siguiente información:

• El nombre del paquete de la aplicación cuando se solicita (por ejemplo, com.myapp.example)
• Presionamos enter cuando se nos solicita la ruta al archivo secreto json
• Responda 'n' cuando se le pregunta si planea cargar información en Google Play a través de Fastlane (podemos configurar esto más adelante)

¡Y ya está! Fastlane generará automáticamente una configuración basada en la información proporcionada.

En este paso puede ver el directorio ./fastlane recién creado y los siguientes archivos:

• GemFile: Definir nuestras dependencias en Fastlane. Esto definirá claramente la versión de Fastlane utilizada y sus dependencias, además de acelerar su uso. Tenga en cuenta que cada vez que agreguemos una gem a este archivo, debemos ejecutar el siguiente comando: bundle install. Agreguemos las siguientes gems:

• Appfile: define la información de configuración global para la aplicación. No hemos editado este archivo.

• Fastfile: que define las "pistas" que guían el comportamiento de la línea rápida. Fastfile es el más importante, ya que contiene todas las pistas para nuestras necesidades.

¿Qué es un lane?

Fastlane agrupa diferentes acciones en lanes. Un carril comienza con la instruccion lane :nombre, donde nombre es el nombre dado a una lane.

En nuestro Fastfile, tenemos los siguientes lanes:


Unit_tests: Realiza pruebas unitarias
Ui_tests_on_emulator: Realiza pruebas de interfaz de usuario en el emulador ya instalado
Ui_tests_on_firebase_testlab: Ejecute UITests en Firebase TestLab
Build: crea el proyecto
Firebase: implementa una versión en Firebase

¿Deberíamos comenzar a escribir todos los scripts desde cero?

La respuesta es no, a menos que quieras escribir varias líneas de código... Usaremos los Fastlane plugins.

Fastlane plugins

Para una acción específica, como iniciar el emulador o subir una versión, no necesitamos ningún desarrollo adicional. Fastlane tiene varios complementos que podemos agregar a nuestro proyecto.

Haz clic aquí: https://docs.fastlane.tools/plugins/available-plugins/

Aquí hay un ejemplo de los complementos que utilicé en este Fastfile:

• Inicia el emulador para las pruebas de interfaz de usuario:

Se puede hacer en una línea simplemente agregando este complemento: https://github.com/elloyg/fastlane-plugin-avd_emulator.

• Ejecuta pruebas de IU en Firebase TestLab para probar la cloud:

Esta es una opción interesante si deseas ejecutar pruebas en la nube en múltiples dispositivos con diferentes configuraciones personalizables: https://github.com/cats-oss/fastlane-plugin-firebase_test_lab_android 

• Implementa una versión de prueba beta en Firebase:

También se puede hacer en una línea de código con una configuración para las notas de la versión y los probadores con los que desea compartir la versión: https://firebase.google.com/docs/app-distribution/android/distribute-fastlane.


¿Cómo puedo probar mis lanes?

Para garantizar que nuestras pistas funcionen correctamente, podemos probarlas por separado utilizando el siguiente comando (ten en cuenta que debes colocarlo en la raíz de la carpeta del proyecto): bundle exec fastlane name_of_the_lane.



Veamos el poder de lo que hemos hecho hasta ahora. Imagina que estás ocupado desarrollando una nueva característica y deseas compartir una compilación con un colega. Simplemente puedes ejecutar la pista específica en dos segundos. ¡Es genial!

Mis carriles funcionan, ¿cómo pueden ejecutarse automáticamente?

Estas pistas deben ejecutarse automáticamente por GitLab CI. Aunque sé que estamos hablando de muchos conceptos, créeme, ¡la combinación de ellos te salvará la vida!


Gitlab CI/CD ​

Gitlab CI / CD es una maravillosa solución de integración continua de GitLab. El servicio GitLab CI (integración continua) es una parte que crea y prueba el software cada vez que un desarrollador envía código a una aplicación.

El CD de GitLab (Implementación continua) es la parte que introduce cambios en todos los códigos en producción, lo que resulta en la implementación de la producción diaria.



GitLab CI se basa en un archivo .gitlab-ci.yml que será orchestre en nuestro repositorio.

Pero espera, ¿qué es .gitlab-ci.yml?

El archivo .gitlab-ci.yml es donde configura lo que CI hace con su proyecto. Vive en la raíz de tu repositorio.
En cualquier inserción en su repositorio, GitLab buscará el archivo .gitlab-ci.yml y comenzará a trabajar en Runners de acuerdo con el contenido del archivo.

Necesitamos crear un archivo llamado .gitlab-ci.yml en el directorio raíz del repositorio.



A continuación se muestra el contenido del archivo .gitlab-ci.yml:


No debemos confundirlo con las nuevas palabras (trabajos, etapas...), aquí hay una explicación de cada detalle:

• Job: bloque de scripts para ejecutar, puede ser una tarea de construcción, una tarea de prueba o una tarea de implementación. Dependiendo de nuestras necesidades, cada job realizará una tarea específica. Cada job contiene uno o más scripts.
• Stages: Cada job pertenece a un solo stage. Un stage puede contener cero, uno o más jobs a realizar. Todos los jobs en un solo stage se realizan en paralelo. El siguiente stage solo se realizará si todos los jobs del stage anterior se completan correctamente o se marcan como fallidos. Si desea permitir una falla en el job y pasar al siguiente stage, marque el trabajo con: allow_failure: true.​ ​​
• Script: El bloque de scripts que se ejecutará para el trabajo.
• ​Tags: Se utilizan para seleccionar corredores específicos de la lista de todos los runners que pueden ejecutar este proyecto.

•  Artifacts: Los artefactos del job son una lista de archivos y directorios creados por un job después de su finalización. Esta característica está habilitada de forma predeterminada en todas las instalaciones de GitLab. Los artefactos de job creados por GitLab Runner se cargan en GitLab y se pueden descargar como un solo archivo utilizando la interfaz de usuario de GitLab o la API de GitLab. Necesitamos proporcionar la ruta a estos archivos con un nombre determinado.

Nota: En este ejemplo, los stages de "compilación" y "prueba" se ejecutarán cada vez que haya un cambio en el repositorio (código enviado, fusión...), sin embargo, el stage de "implementación" se ejecutará cuando hagamos una solicitud de fusión. Este es solo un escenario simple, puede definir cómo y cuándo ejecutar los carriles, según sus necesidades.

¿Quién ejecutará estos Jobs?

La respuesta es Runner. Es una instancia de compilación utilizada para ejecutar jobs en varias máquinas y enviar los resultados a GitLab y que se puede colocar en usuarios, servidores y máquinas locales independientes.

Estos son los pasos para configurar su propio Runner específico.

Instalar el Runner:​

• ​​Instale Runner usando brew: brew install gitlab-runner
• Instalar Runner como un servicio e iniciarlo: brew services start gitlab-runner 
• Una vez que se instala Gitlab Runner, debe registrarlo con Gitlab CI.

- Registro del runner en Gitlab CI:

• Ejecuta la siguiente línea de comando: gitlab-runner register

• La URL y el token se pueden obtener de la siguiente ruta:

​Gitlab Repository >Settings > CI/CD > Expand Runner Section > Specific runners

• El tag se usa para identificar al Runner. Podemos combinar un trabajo con un Runner usando el tag, por ejemplo, si un trabajo tiene un tag "BABEL", en la tubería, ese trabajo se realizará con el Runner que tiene la etiqueta "BABEL";
• Para el ejecutor, elegiremos 'shell' para ejecutar los scripts en nuestro shell local. Esta es la manera más fácil.
• Ahora, si volvemos a los Runners en la configuración (Gitlab Repository >Settings > CI/CD > Expand Runner Section > Specific runners) veremos el Runner recién creado con el estado activo (verde).

¡Felicidades!

¡Hemos llegado al final! Lo tenemos todo hecho! Después de que ocurra un cambio en el repositorio (una nueva solicitud, actualización, solicitud de fusión...), se activará un pipeline. Un pipeline es un paquete para todos los jobs y stages. Ejecutará todos los jobs en sus stages en el orden correcto.

Verá todos los pipelines en la sección de pipelines:
Gitlab Repository > CI/CD > Pipelines



Haga clic en un pipeline para ver los detalles de los jobs:



Si ha ocurrido un problema, el pipeline fallará y notificará a los desarrolladores, aquí hay un ejemplo:



¡Y se acabó!

Espero que hayas disfrutado este post, si tienes alguna pregunta no dudes en contactarme.

Feliz codificación chicos :)