Integración Contínua IV – Testflight

Testflight

Testflight es un servicio web que nos permite la distribución de compilaciones de aplicaciones móviles. Hasta ahora, cuando desarrollamos apps, la forma de lograr que nuestros betatesters tuvieran acceso a ella era a través del correo, ya fuera adjuntándola o bien enlazando a un servidor dónde lo tuvieramos almacenado. Con testflight, una vez registrados y configurada una lista de distribución con los betatesters que la han de recibir, sólo tenemos que subir la compilación y notificar a nuestros testers para que se la descarguen y la prueben.

Testflight permite saber cuáles de los testers tienen la app instalada, qué dispositivos ha registrado cada uno… Incluso trae un sdk para poder tener un seguimiento de los errores que se den en el uso de la app, mas completo que el ACRA que ya vimos.

Configuración

Registrarse

El registro en testflight es sencillo y gratuito. Una vez dentro, procederemos a crear nuestro equipo (team, podemos tener varios) al que invitaremos a nuestros betatesters. Listo eso, añadiremos una app a la que subiremos nuestras compilaciones (builds). Todo eso se puede hacer con el botón “+” que está a la derecha del avatar que hayamos elegido – se despliega mostrando las tres opciones.

Las compilaciones (apks) las podemos subir manualmente. De hecho, la primera recomendaría que fuera así para no perderse detalle. Una vez arriba, veremos información sobre si hay o no permisos de acceso para dicha apk. Para dárselos, crearemos una Lista de Distribución con los betatesters que nos interesen (en función de los dispositivos que sepamos que tienen, etc) y así sólo hay que dar permiso a la lista, en vez de ir tester por tester.

Los testers pueden bien recibir correos con el enlace al apk o bien instalarse la app de testflight en la que podrán ver las apks que tienen pendientes de prueba.

Integración con Jenkins

Ya hemos visto cómo hacerlo manualmente, ahora queremos que sea nuestro querido Jenkins el que se encargue de hacer el trabajo por nosotros. Tenemos para ello dos formas.

La primera y mas evidente, es pensar en un plugin. En la configuración del Jenkins ya mencionamos el plugin de testflight. Para poder usarlo harán falta unos datos: el API token y el Team token.

El API token se obtiene desde esta url estando logado en Testflight. El Team Token se obtiene editando la información de nuestro equipo, a lo que accedemos desde el nombre de nuestro equipo que está a la izquierda de nuestro avatar. Recordar siempre, si creamos mas de un equipo, que nuestra app subirá al equipo que la haya creado, así que hay que vigilar de tomar el Token correcto.

Uso

Con los datos obtenidos, podríamos ir a la configuración de Jenkins y crear un “Token Pair Name” que luego nos permitiría usar la acción del plugin Testflight, pero resulta que, tal cual está el plugin a día de hoy (23/septiembre/2013) sólo realizaría la subida, dejándonos a nosotros el proceso de dar permiso de acceso a los betatesters de forma manual.
Pero hay otro modo: usando la API de subida de testflight. Configurando nuestro proyecto en Jenkins, añadimos un “Ejecutar línea de comandos (shell)” y le ponemos el siguiente comando

curl http://testflightapp.com/api/builds.json 
-F file=@ruta-relativa-a-mi-release.apk 
-F api_token='mi-api-token' 
-F team_token='mi-team-token' 
-F notes='Un comentario cualquiera' 
-F notify=True -F distribution_lists='nombre-de-mi-lista-de-distribución-en-testflight'

Mucho cuidado con algo: NO DEJAR SALTOS DE LíNEA. Jenkins lo interpretará como que son comandos independientes y “-F <loquesea>” no existe, por lo que fracasaría. Lo he dejado en líneas independientes para que sea mas fácil de leer.

curl http://testflightapp.com/api/builds.json

Llamamos a la api de subidas de testflight

-F file=@ruta-relativa-a-mi-release.apk

Vamos a la raíz de nuestro repo y vemos la ruta relativa desde ese punto al apk que queramos que usen los betatesters. Normalmente será  <desde raíz de repo>./build/apk/mi-apk-para-subir.apk, pero según tengáis vuestros repositorios, puede variar ligeramente. La @ es obligatoria.

-F api_token='mi-api-token' 
-F team_token='mi-team-token'

Poco misterio aquí, entre comillas simples metemos los tokens que obtuvimos antes.

-F notes='Un comentario cualquiera'

Para comentarios que queramos dejar en la subida.

-F notify=True -F distribution_lists='nombre-de-mi-lista-de-distribución-en-testflight'

Aquí la parte que hace toda la magia que no hacía el plugin de testflight para Jenkins: con esa parte logramos que, tras subir la apk, se le de permisos automáticamente a nuestra lista de distribución y se les notifique por email.

Lo que irá en la caja de comandos shell de Jenkins se parecerá mas a esto.

curl http://testflightapp.com/api/builds.json -F file=@ruta-relativa-a-mi-release.apk -F api_token='mi-api-token' -F team_token='mi-team-token' -F notes='Un comentario cualquiera' -F notify=True -F distribution_lists='nombre-de-mi-lista-de-distribución-en-testflight'

 

Crearemos una tarea nueva para ir viendo cómo funciona. Iremos a la pantalla inicial de Jenkins y pulsaremos sobre “Nueva Tarea”. Le damos un nombre – por ejemplo, el de la app para la que vamos a crear la tarea – y marcamos “Crear Proyecto de Estilo Libre”. Pulsamos en OK y saldrá la pantalla de configuración de la tarea.

Hecho todo esto, guardamos y volveremos a la pantalla principal, dónde ahora veremos nuestra tarea. La ejecutamos y vamos a la Salida de Consola para ir viendo cómo se desarrolla. Cuando veamos que termina con éxito, iremos a la web de testflight y veremos la compilación subida (si no hemos modificado la versión del apk saldrá con un número indicando cuántas veces hemos subido ya una compilación con esa versión) y entrando en ella veremos que aparece el estado “email sent” (correo enviado) para los betatesters que hayamos indicado en nuestra lista de distribución. Sólo quedaría esperar que se la instalaran e hicieran las pruebas pertinentes.

Conclusión

Ahora tenemos una tarea de Jenkins que hace lo siguiente de forma automática:

  • se descarga el código de nuestro repositorio
  • lo compila con gradle (si lo hemos dispuesto así en build.gradle, también firmará la apk)
  • lo analiza con sonar
  • sube la compilación a testflight y lo distribuye entre nuestros testers

Si todo eso lo montamos en un servidor de integración, podemos hacer que suba y distribuya compilaciones regulares (por ejemplo, durante la noche, cuando ya hayamos subido los cambios del día) y si cualquier problema o error surgiera, lo detectaríamos rápidamente gracias a nuestros betatesters que irían probando los cambios con la misma periodicidad. Ello facilitaría enormemente la resolución de dichos fallos. Si no, siempre podemos lanzar nosotros “a patita” la acción al final de nuestro día de desarrollo.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: