Una vez que la pull request se fusiona y el c\u00f3digo entra en develop, se puede elegir un momento conveniente: por ejemplo, de noche, cuando todos los servidores est\u00e1n libres, y ejecutar tantas pruebas como se pueda.<\/li>\n<\/ul>\n\nA nadie le gust\u00f3 ejecutar pruebas en su propio port\u00e1til. Cuando el desarrollador termina una funcionalidad, quiere empujarla r\u00e1pidamente y abrir la pull request. Si en ese momento se est\u00e1n ejecutando algunas pruebas largas, no solo es inc\u00f3modo, sino que tambi\u00e9n ralentiza el desarrollo: mientras el port\u00e1til est\u00e1 comprobando algo, no se puede trabajar normalmente.<\/p>\n
Nos gust\u00f3 mucho ejecutar pruebas por la noche, porque hay mucho tiempo y servidores, se puede disfrutar. Pero, desafortunadamente, cuando el c\u00f3digo de la funcionalidad entra en develop, el desarrollador ya tiene mucha menos motivaci\u00f3n para corregir los errores que encontr\u00f3 CI. De vez en cuando me encontraba pensando, al ver el informe matutino con todos los errores encontrados, que los arreglar\u00eda en otro momento, porque actualmente tengo una nueva tarea interesante en Jira que realmente quiero comenzar.<\/p>\n
Si las pruebas bloquean la pull request, entonces hay suficiente motivaci\u00f3n, porque mientras las compilaciones no se pongan en verde, el c\u00f3digo no entrar\u00e1 en develop, y por lo tanto, la tarea no se completar\u00e1.<\/p>\n
Al final, elegimos esta estrategia: por la noche realizamos la m\u00e1xima cantidad posible de pruebas, y las m\u00e1s cr\u00edticas y, lo m\u00e1s importante, r\u00e1pidas, las ejecutamos en la solicitud de extracci\u00f3n. Pero no nos detenemos ah\u00ed; paralelamente optimizamos la velocidad de las pruebas para poder pasarlas de modo nocturno a pruebas en la solicitud de extracci\u00f3n.<\/p>\n
En ese momento, todas nuestras compilaciones pasaban bastante r\u00e1pido, as\u00ed que simplemente activamos como bloqueador en la solicitud de extracci\u00f3n la compilaci\u00f3n ARK, pruebas Junit y el c\u00e1lculo de la cobertura de c\u00f3digo. Lo activamos, pensamos... y nos deshicimos de la cobertura de c\u00f3digo, porque consideramos que no la necesit\u00e1bamos.<\/p>\n
La configuraci\u00f3n b\u00e1sica de CI nos tom\u00f3 dos d\u00edas (las estimaciones de tiempo aqu\u00ed y en adelante son aproximadas, necesarias para dar una idea de la escala). <\/em><\/strong><\/p>\nDespu\u00e9s de esto comenzamos a pensar m\u00e1s: \u00bfestamos verificando correctamente? \u00bfEstamos ejecutando las compilaciones en la solicitud de extracci\u00f3n de manera adecuada?<\/p>\n
Ejecutamos la compilaci\u00f3n en el \u00faltimo commit de la rama desde la cual se abri\u00f3 la solicitud de extracci\u00f3n. Pero las verificaciones de ese commit solo pueden mostrar que el c\u00f3digo que escribi\u00f3 el desarrollador funciona. No demuestran que no rompi\u00f3 nada. En realidad, debemos verificar el estado de la rama develop despu\u00e9s de que se haya integrado la caracter\u00edstica.<\/p>\n
![\"La](\"\/wp-content\/uploads\/2019\/04\/c1a179b68b02c04031177f9bf51a81ed.jpg\")
\n
\nPara esto, escribimos un sencillo script bash. premerge.sh:<\/strong><\/p>\n#!\/usr\/bin\/env bash\n\nset -e\n\ngit fetch origin develop\n\ngit merge origin\/develop<\/code><\/pre>\n\nAqu\u00ed simplemente se traen todos los cambios m\u00e1s recientes de develop y se fusionan en la rama actual. Agregamos el script premerge.sh como primer paso de todas las compilaciones y comenzamos a verificar exactamente lo que queremos, es decir, integraci\u00f3n.<\/strong>.<\/p>\nPara la localizaci\u00f3n de problemas, b\u00fasqueda de soluciones y redacci\u00f3n de este script, nos llev\u00f3 tres d\u00edas.<\/em><\/strong><\/p>\nLa aplicaci\u00f3n fue evolucionando, aparec\u00edan m\u00e1s tareas, el equipo crec\u00eda y premerge.sh a veces comenz\u00f3 a defraudarnos. Cambios conflictivos ingresaban en develop, rompiendo la compilaci\u00f3n.<\/p>\n
Un ejemplo de c\u00f3mo sucede esto:<\/p>\n
![\"La](\"\/wp-content\/uploads\/2019\/04\/6762d9ce4e431549455c49f2317a8f20.jpg\")
\n
\nDos desarrolladores comienzan a trabajar en las caracter\u00edsticas A y B al mismo tiempo. El desarrollador de la caracter\u00edstica A descubre una funci\u00f3n no utilizada en el proyecto, answer()<\/code> y, como un buen explorador, la elimina. Mientras tanto, el desarrollador de la caracter\u00edstica B en su rama agrega una nueva llamada a esta funci\u00f3n.<\/p>\nLos desarrolladores terminan su trabajo y al mismo tiempo abren la solicitud de extracci\u00f3n. Se inician las compilaciones, premerge.sh verifica ambas solicitudes de extracci\u00f3n con respecto al estado fresco de develop: todas las verificaciones est\u00e1n verdes. Despu\u00e9s de esto, se fusiona la solicitud de extracci\u00f3n de la caracter\u00edstica A, se fusiona la solicitud de extracci\u00f3n de la caracter\u00edstica B... \u00a1Boom! Develop se rompe, porque en el c\u00f3digo de develop hay una llamada a una funci\u00f3n inexistente.<\/p>\n
![\"La](\"\/wp-content\/uploads\/2019\/04\/0261dcc9f7f2e5e018ab136081b4679b.jpg\")
\n
\nCuando develop no se compila, esto es cat\u00e1strofe local<\/strong>. Todo el equipo no puede reunir nada para las pruebas.<\/p>\nResulta que, con mayor frecuencia, me ocup\u00e9 de tareas de infraestructura: anal\u00edtica, red, bases de datos. Es decir, fui yo quien escribi\u00f3 las funciones y clases que utilizan otros desarrolladores. Por eso, a menudo me encontraba en situaciones similares. Incluso hubo un tiempo en el que ten\u00eda esta imagen colgada.<\/p>\n
![\"La](\"\/wp-content\/uploads\/2019\/04\/0eb1aadd05b33ce995027ab52d5c1e53.jpg\")
\n
\nDado que eso no nos satisfac\u00eda, comenzamos a explorar opciones para prevenirlo.<\/p>\n
C\u00f3mo no romper develop<\/h2>\n
\nPrimera opci\u00f3n: reconstruir todos los pull requests al actualizar develop. <\/strong>Si en nuestro ejemplo el pull request con la caracter\u00edstica A llega primero a develop, el pull request de la caracter\u00edstica B se reconstruir\u00e1 y, por lo tanto, no pasar\u00e1 las pruebas debido a un error de compilaci\u00f3n.<\/p>\nPara entender cu\u00e1nto tiempo llevar\u00e1 esto, consideremos el ejemplo de dos PR. Abrimos dos PR: dos compilaciones, dos ejecuciones de pruebas. Despu\u00e9s de que el primer PR se mezcle en develop, el segundo necesita ser reconstruido. En total, para dos PR se necesitan tres ejecuciones de pruebas: 2 + 1 = 3.<\/p>\n
En principio, est\u00e1 bien. Pero revisamos las estad\u00edsticas, y una situaci\u00f3n t\u00edpica en nuestro equipo era tener 10 PR abiertos, y entonces el n\u00famero de pruebas ser\u00eda la suma de la progresi\u00f3n: 10 + 9 +\u2026 + 1 = 55. Es decir, para aceptar 10 PR, hay que reconstruir 55 veces. Y eso en una situaci\u00f3n ideal, cuando todas las pruebas pasan a la primera, cuando nadie abre un pull request adicional mientras se procesan esos diez.<\/p>\n
Imag\u00ednate como desarrollador, que necesitas apresurarte a presionar el bot\u00f3n \"merge\" primero, porque si lo hace el vecino, entonces tendr\u00e1s que esperar a que todas las compilaciones se realicen de nuevo... No, eso no funcionar\u00e1, ralentizar\u00e1 gravemente el desarrollo.<\/p>\n
Segunda posible manera: compilar pull requests despu\u00e9s de code review. <\/strong>Es decir, abres un pull request, obtienes la cantidad necesaria de aprobaciones de tus colegas, corriges lo que sea necesario, y despu\u00e9s ejecutas las compilaciones. Si son exitosas, el pull request se mezcla con develop. En este caso, no hay reinicios adicionales, pero la retroalimentaci\u00f3n se ralentiza considerablemente. Yo, como desarrollador, al abrir un pull request, quiero ver inmediatamente si se compila. Por ejemplo, si alguna prueba falla, necesito arreglarla r\u00e1pidamente. En el caso de una compilaci\u00f3n retrasada, la retroalimentaci\u00f3n se ralentiza, lo que significa que todo el desarrollo tambi\u00e9n se ralentiza. Esto tampoco nos satisfizo.<\/p>\nAl final, solo qued\u00f3 la tercera opci\u00f3n \u2014 hacerlo a mano<\/strong>. Todo nuestro c\u00f3digo y todos nuestros archivos fuente se almacenan en el repositorio del servidor Bitbucket. Por lo tanto, tuvimos que desarrollar un complemento para Bitbucket.<\/p>\n![\"La](\"\/wp-content\/uploads\/2019\/04\/5e4b1f770ea1a3449b616c3101640294.jpg\")
\n
\nEste complemento redefine el mecanismo de fusi\u00f3n de solicitudes de extracci\u00f3n. Comienza de manera est\u00e1ndar: se abre una PR, se ejecutan todas las compilaciones y se realiza la revisi\u00f3n de c\u00f3digo. Pero una vez que se ha pasado la revisi\u00f3n de c\u00f3digo y el desarrollador decide pulsar \u00abfusionar\u00bb, el complemento verifica el estado de desarrollo respecto al que se ejecutaron las pruebas. Si despu\u00e9s de las compilaciones el desarrollo se actualiz\u00f3, el complemento no permitir\u00e1 que se fusione esa solicitud de extracci\u00f3n en la rama principal. Simplemente reiniciar\u00e1 las compilaciones en relaci\u00f3n con el desarrollo m\u00e1s reciente.<\/p>\n
![\"La](\"\/wp-content\/uploads\/2019\/04\/0edee880e1f2d286a0c64033103ac136.jpg\")
\n
\nEn nuestro ejemplo con cambios en conflicto, tales compilaciones no pasar\u00e1n debido a un error de compilaci\u00f3n. Por lo tanto, el desarrollador de la funci\u00f3n B tendr\u00e1 que corregir el c\u00f3digo y reiniciar las verificaciones, momento en el cual el complemento aplicar\u00e1 autom\u00e1ticamente el pull request.<\/p>\n
Antes de implementar este complemento, ten\u00edamos un promedio de 2.7 lanzamientos de verificaci\u00f3n por cada pull request. Con el complemento, se convirti\u00f3 en 3.6 lanzamientos. Esto fue satisfactorio para nosotros.<\/p>\n
Cabe destacar que este complemento tiene una desventaja: reinicia la compilaci\u00f3n solo una vez. Es decir, todav\u00eda queda una peque\u00f1a ventana a trav\u00e9s de la cual podr\u00edan entrar cambios en conflicto en develop. Pero la probabilidad de que esto ocurra es baja, y decidimos aceptar este compromiso entre el n\u00famero de lanzamientos y el riesgo de fallos. En dos a\u00f1os, solo sucedi\u00f3 una vez, por lo que probablemente no fue en vano.<\/p>\n
Nos tom\u00f3 dos semanas desarrollar la primera versi\u00f3n del complemento para Bitbucket. <\/em><\/strong><\/p>\nNuevas verificaciones<\/h3>\n
\nMientras tanto, nuestro equipo continu\u00f3 creciendo. Se a\u00f1adieron nuevas verificaciones.<\/p>\n
Pensamos: \u00bfpor qu\u00e9 arreglar errores si se pueden prevenir? Y por eso implementamos an\u00e1lisis est\u00e1tico de c\u00f3digo<\/strong>. Comenzamos con lint, que forma parte del Android SDK. Pero en ese momento no sab\u00eda trabajar con c\u00f3digo Kotlin, y ya ten\u00edamos el 75% de la aplicaci\u00f3n escrita en Kotlin. As\u00ed que junto con lint, se a\u00f1adieron las verificaciones integradas de Android Studio.<\/strong><\/p>\nPara ello, tuvimos que hacer muchas acrobacias: tomar Android Studio, empaquetarla en Docker y ejecutarla en CI con un monitor virtual, para que pensara que estaba corriendo en una laptop real. Pero funcion\u00f3.<\/p>\n
Tambi\u00e9n en ese momento comenzamos a escribir muchas pruebas de instrumentaci\u00f3n<\/strong> e implementamos pruebas de capturas de pantalla<\/strong>. Esto es cuando se genera una captura de pantalla de referencia para una peque\u00f1a vista espec\u00edfica, y la prueba consiste en tomar una captura de pantalla de esa vista y compararla p\u00edxel por p\u00edxel con la referencia. Si hay alguna discrepancia, significa que algo fall\u00f3 en la maquetaci\u00f3n o hay alg\u00fan problema con los estilos.<\/p>\nPero las pruebas de instrumentaci\u00f3n y las pruebas de captura de pantalla deben ejecutarse en dispositivos: en emuladores o en dispositivos reales. Teniendo en cuenta que hay muchas pruebas y se ejecutan con frecuencia, se necesita una granja completa. Crear nuestra propia granja consume demasiados recursos, as\u00ed que encontramos una opci\u00f3n lista: Firebase Test Lab.<\/p>\n
Firebase Test Lab<\/h3>\n
\nSe eligi\u00f3 porque Firebase es un producto de Google, es decir, deber\u00eda ser confiable y es poco probable que desaparezca. Los precios son accesibles: 5$ por hora de uso de un dispositivo real, 1$ por hora de uso de un emulador.<\/p>\n
La implementaci\u00f3n de Firebase Test Lab en nuestro CI tom\u00f3 aproximadamente tres semanas.<\/em><\/strong><\/p>\nSin embargo, el equipo continu\u00f3 creciendo y, desafortunadamente, Firebase comenz\u00f3 a fallarnos. En ese momento no ten\u00eda ning\u00fan SLA. A veces, Firebase hac\u00eda esperar hasta que estuvieran disponibles suficientes dispositivos para las pruebas, en lugar de comenzar a ejecutarlas de inmediato, como dese\u00e1bamos. La espera en la cola pod\u00eda llevar hasta media hora, lo cual es mucho tiempo. Las pruebas de instrumentaci\u00f3n se ejecutaban en cada PR, y los retrasos ralentizaban mucho el desarrollo, y luego lleg\u00f3 la factura mensual con una suma considerable. En resumen, se decidi\u00f3 abandonar Firebase y construir una soluci\u00f3n interna, ya que el equipo hab\u00eda crecido lo suficiente.<\/p>\n
Docker + Python + bash<\/h3>\n
\nTomamos Docker, metimos emuladores en \u00e9l, y escribimos un programa simple en Python que, en el momento adecuado, lanza la cantidad necesaria de emuladores en la versi\u00f3n requerida y, cuando es necesario, los detiene. Y, por supuesto, un par de scripts en bash, \u00bfc\u00f3mo podr\u00edamos estar sin ellos?<\/p>\n
La creaci\u00f3n de nuestro propio entorno de prueba tom\u00f3 cinco semanas.<\/em><\/strong><\/p>\nComo resultado, cada pull request ten\u00eda una extensa lista de verificaciones bloqueantes de fusi\u00f3n:<\/p>\n
\n- Construcci\u00f3n de ARC;<\/li>\n
- Pruebas Junit;<\/li>\n
- Lint;<\/li>\n
- Verificaciones de Android Studio;<\/li>\n
- Pruebas de instrumentaci\u00f3n;<\/li>\n
- Pruebas de captura de pantalla.<\/li>\n<\/ul>\n
\nEsto preven\u00eda muchos posibles fallos. T\u00e9cnicamente, todo funcionaba, pero los desarrolladores se quejaban de que esperar los resultados tomaba demasiado tiempo.<\/p>\n
\u00bfDemasiado tiempo? Examinamos los datos de Bitbucket y TeamCity en un sistema de an\u00e1lisis y entendimos que el tiempo promedio de espera es de 45 minutos<\/strong>. Es decir, un desarrollador que abre un pull request espera en promedio 45 minutos los resultados de los builds. En mi opini\u00f3n, eso es demasiado y no se puede trabajar as\u00ed.<\/p>\nPor supuesto, decidimos acelerar todas nuestras compilaciones.<\/p>\n
Acelerando<\/h2>\n
\nAl ver que a menudo las compilaciones estaban en cola, primero compramos m\u00e1s hardware<\/strong> \u2014 el desarrollo extensivo es lo m\u00e1s sencillo. Las compilaciones dejaron de estar en cola, pero el tiempo de espera solo se redujo un poco, porque algunas verificaciones en s\u00ed mismas tardaban mucho tiempo.<\/p>\nEliminamos las verificaciones demasiado largas<\/h3>\n
\nNuestra integraci\u00f3n continua podr\u00eda detectar este tipo de errores y problemas.<\/p>\n
\n- No compila<\/strong>. La integraci\u00f3n continua puede atrapar un error de compilaci\u00f3n cuando, debido a cambios conflictivos, algo no se compila. Como ya mencion\u00e9, en ese momento nadie puede compilar nada, el desarrollo se detiene y todos se ponen nerviosos.<\/li>\n
- Un error en el comportamiento<\/strong>. Por ejemplo, cuando la aplicaci\u00f3n se compila, pero al hacer clic en un bot\u00f3n se cierra, o el bot\u00f3n ni siquiera responde. Esto es malo porque dicho error puede llegar al usuario.<\/li>\n
- Un error en el dise\u00f1o<\/strong>. Por ejemplo, el bot\u00f3n responde, pero se ha movido 10 p\u00edxeles hacia la izquierda.<\/li>\n
- Aumento de la deuda t\u00e9cnica<\/strong>.<\/li>\n<\/ul>\n
\nAl observar esta lista, nos dimos cuenta de que solo los dos primeros puntos son cr\u00edticos. Queremos detectar tales problemas en primer lugar. Los errores de dise\u00f1o se identifican en la etapa de revisi\u00f3n de dise\u00f1o y se pueden corregir f\u00e1cilmente. El trabajo con la deuda t\u00e9cnica requiere un proceso y planificaci\u00f3n separados, por lo que decidimos no verificarlo en el pull request.<\/p>\n
Bas\u00e1ndonos en esta clasificaci\u00f3n, revisamos toda la lista de verificaciones. Eliminamos Lint<\/strong> y trasladamos su ejecuci\u00f3n a la noche: solo para que entregue un informe de cu\u00e1ntos problemas hay en el proyecto. Acordamos trabajar por separado con la deuda t\u00e9cnica, y nos deshicimos por completo de las verificaciones de Android Studio<\/strong>. Android Studio en Docker para ejecutar inspecciones suena interesante, pero causa muchos problemas en el soporte. Cualquier actualizaci\u00f3n de las versiones de Android Studio es una lucha contra errores inexplicables. Tambi\u00e9n era complicado mantener las pruebas de captura de pantalla, porque la biblioteca no funcionaba muy estable, hab\u00eda disparos falsos. Eliminamos las pruebas de captura de pantalla de la lista de verificaciones<\/strong>.<\/p>\nEn \u00faltima instancia, nos quedaron:<\/p>\n
![\"La](\"\/wp-content\/uploads\/2019\/04\/b283cfd7772d8f479be0754ebbe51b19.jpg\")