Creación de una canalización de CI-CD para un proyecto de Android | por Ansh Sachdeva

Un proyecto de Android es un candidato ideal para las soluciones de CI/CD y podría aprovechar todo el poder de la nube. Google proporciona el entorno completo de compilación de Android como una herramienta de línea de comandos, por lo que configurarlo con un script de CI/CD no es demasiado difícil. Para este artículo, exploraremos más las acciones de GithubP. ¿Qué podemos hacer con un flujo de trabajo de CI/CD?Podemos crear un script que le indique al servidor de CI/CD que realice una serie de acciones en ciertos eventos, como: un impulso de Git a una rama específica, o cuando se activa un PR de una rama de Git a otra. También podemos configurar el script para que se inicie manualmente al presionar una tecla en lugar de en cada evento.P. Pero, ¿qué tarea podemos crear para el proyecto de Android?Nuestro guión podría:

  • Ejecute comprobaciones de pelusa en el código del proyecto.
  • Ejecute analizadores de código estático en el código del proyecto.
  • Ejecute pruebas unitarias y pruebas instrumentales en el código del proyecto.
  • Crear y publicar informes de acción.
  • Compile el código del proyecto para asegurarse de que el código funciona correctamente.
  • Generar artefactos (archivos .AAR, .APK)
  • Publicar los artefactos en sus respectivos mercados, como B. mavenCentral para compilaciones de bibliotecas o Play Store para compilaciones de APK.
  • Enviar notificaciones a Slack
  • y mucho más.

P. ¿Pero por qué querría hacer todas estas tareas?Mientras comprendemos la importancia de cada uno de estos pasos, creemos un script que realizará algunas de las tareas anteriores. Cree una carpeta .github/workflows en su proyecto y agregue el siguiente archivo: envíe este archivo a su repositorio de GitHub y consulte la pestaña Acciones.Una acción de Github realizada en una confirmación específica que se envía a la rama¡Felicidades por ejecutar tu primera acción de Github! Pero, ¿qué está pasando exactamente aquí?

  1. Le decimos al servidor Github CI/CD que queremos ejecutar nuestra acción en un servidor host Ubuntu de última versión (20.4). También lo informamos para proporcionar todos los permisos necesarios para nuestro script.
  2. Checkout es una acción que GitHub creó para nosotros que verifica nuestro repositorio en $GITHUB_WORKSPACE para acceder a su flujo de trabajo. Le indicamos al servidor de CI/CD que realice esta acción. Tenemos varias otras acciones disponibles que han sido creadas por github y la comunidad. setup-java es otra de esas acciones.
  3. En el siguiente paso, ejecutamos la tarea Gradle ./gradlew AssembleDebug. Esta es la tarea que se realizará cuando presionemos el ícono de la flecha verde 🟢 en Android Studio. Tenga en cuenta que no estamos usando una acción de terceros para este paso, estamos usando la herramienta Gradle que viene preinstalada con nuestro servidor host de Ubuntu.

Enchufe desvergonzado: ¡Sígueme para conocer el conocimiento diario de los desarrolladores de Android! 😄4. Finalmente, llamamos a otro artefacto de carga de acción de terceros y le proporcionamos una lista de rutas donde las acciones anteriores deben haber generado una compilación. Si su acción tiene éxito, encontrará estos artefactos cargados en el área de resumen.Genial, entonces construyamos una acción básica que ejecute algunos pasos en cada impulso a la rama maestra. Y esos pasos incluyen la configuración de un entorno, la creación de código y la carga de resultados. ¿Por qué deberíamos hacer ésto? Un buen caso de uso sería un proyecto de código abierto donde cualquiera podría crear un PR que contenga cambios en el código original. Como mantenedor del repositorio, es posible que no tenga tiempo para verificar el código de su RP, compilarlo y asegurarse de que el código anterior no se rompa. Por lo tanto, tal canalización podría resultar útil. Agreguemos dos acciones más bastante obvias controles de pelusa y pruebas unitariasJusto antes del paso Generar AAR, podemos agregar estos 2 pasos más…- Nombre: Verificar lint si: always() run: ./gradlew lint- name: Run Unit Testsif: always() run: ./gradlew testDebugUnitTest – Nombre: generar archivos AAR y APK… Las comprobaciones de Lint son útiles, ya que ayudan a ver las advertencias emitidas por Android Studio durante la construcción. Estos no son una preocupación inmediata, pero podrían convertirse en errores en el futuro dependiendo de su gravedad. De manera similar, la propagación de un código a través de pruebas unitarias es una verificación muy importante para garantizar que el código recién agregado no viole la lógica anterior. Estos pasos en la acción generarán buenos informes y también deberíamos cargarlos a través de la acción de artefacto disponible. Puede consultar el repositorio de dogFinder para obtener el script de acción más reciente para estas tareas.Hasta ahora no hemos tenido que hacer ningún cambio en nuestro código original para que la acción funcione. Esto se debió a que el entorno que configuramos ya nos proporcionaba estas funciones. Incluso podemos ejecutar estas tareas ./gradlew xyz desde nuestra consola de Android Studio y funcionarán correctamente. Sin embargo, funciones como la publicación en mavenCentral, la consola de Google Play o la ejecución de herramientas de análisis de código estático requieren una configuración a nivel de proyecto, por lo que este será el flujo:

  • Agregaremos algunas bibliotecas a nuestro código para permitir la compatibilidad con analizadores de código estático.
  • Estas bibliotecas registran acciones en Gradle que podemos realizar desde la línea de comandos.
  • Durante la configuración de nuestro código en la nube, estas bibliotecas también se inician y registran sus acciones en Gradle en la nube.
  • ¡Entonces CI/CD también puede realizar estas acciones!

Usaremos detekt y checkstyle para los analizadores de código estático más comunes para código Kotlin y Java respectivamente. Agregue esto en su secuencia de comandos de acción: en su archivo Gradle de nivel raíz, agregue: // $projectRoot/build.gradleplugins{Me gustaría(«io.gitlab.arturbosch.detectar»).Ejecución(«1.20.0-RC1»).usar(INCORRECTO)}En sus archivos Gradle de nivel de módulo, agregue lo siguiente: Cree una carpeta llamada config en la raíz de su proyecto y agregue los archivos de configuración asociadosEstas son configuraciones muy básicas de checkstyle y detekt que utilizo para mi proyecto personal. Puede buscar en sus respectivos sitios web los archivos y comandos de configuración completos.

¿Por qué necesitamos analizadores de código estático?Imagina que tienes un equipo de 50 personas trabajando en un solo producto, con diferentes enfoques de código. Cada persona escribirá el código con su propio estilo y es posible que no respete la lógica y las decisiones antiguas. sin acciones como lint y revisiones de código estático, todo el código base podría perder rápidamente la consistencia del estilo del código y ser difícil de examinar. ¡Esas áreas de código difíciles de cambiar luego se convierten en olores de código y luego en esas viejas bombas de tiempo que nadie quiere tocar!

¡Ahora presiona el código para dominar y listo! ¡Otro conjunto de buenas estadísticas para descargar como artefactos para garantizar una calidad de código constante con cada impulso de código!Además de los resultados de las pruebas, también podemos configurar la cobertura de código para obtener información sobre la cantidad de código que cubren los casos de prueba. Jacoco es una gran herramienta que genera un buen informe de cobertura de código y podemos obtenerlo como un artefacto para analizarlo.Sí, sé que mi código necesita más pruebas. {…dependencias {…ruta de clases «com.vanniktech:gradle-android-junit-jacoco-plugin:0.16.0»}}usar enchufar: «com.vanniktech.android.junit.jacoco»Nuestra aplicación apoya así la cobertura del código Jacobo. En lugar de testDebugUnitTest, ahora podemos usar jacocoTestReportDebugaction tanto localmente como en nuestro script de CI/CD para obtener los resultados y un informe de cobertura. El repositorio central de Maven es un repositorio proporcionado por la comunidad de Maven. Contiene una gran cantidad de bibliotecas de uso común y es el lugar más común para cargar su biblioteca. Sin embargo, requiere muchos pasos y es bastante difícil de trabajar, incluso en un entorno de configuración local que no sea en la nube. Afortunadamente, este increíble artículo me ayudó a configurar la publicación de mi biblioteca y dejaré un enlace. Las sucursales que publican estos artefactos se pueden proteger y las claves API utilizadas aquí se pueden mantener en secretos de Github. Dado que esto no era necesario para mi proyecto de demostración, vincularé este excelente artículo para su conveniencia

Deja una respuesta

Tu dirección de correo electrónico no será publicada.