Una de las tareas más ingratas de un programador es a menudo el proceso de despliegue de una aplicación. El proceso en sí es complejo, ya que en el fondo, lo que estamos haciendo es extraer una pequeña parte de tu ordenador y transplantarla en hasta millones de otros ordenadores. Además, el proceso es inherentemente recursivo: una tarea depende de otras varias, cada una de las cuales depende de otras, etc, etc…
A las herramientas para esta tarea, se les llama “build automation tools” (herramientas de automatización del “build”) y como su nombre indica, permiten automatizar el proceso de construcción y despliegue de un proyecto.
En el caso de las Apps para dispositivos móviles, especialmente los casos de más sencillos, puede parecer innecesario el uso de este tipo de herramientas y muchos desarrolladores no le ven la utilidad. Lo único que puedo decirles, es que no saben la suerte que tienen. 😉
En en mundo de las App Stores, el proceso con las build automation tools se lleva a cabo pocas veces, y a veces no parece que valga la pena automatizarlo. Normalmente, una vez a cada dos meses compilamos la App, la firmamos y la subimos. Esperamos dos semanas, nos la rechazan, nos cagamos en sus muelas, hacemos algún cambio y otra vez a repetir. Es decir, el proceso en sí se lleva a cabo unas cuantas veces por semestre, y por pesado que pueda ser, podemos hacerlo manualmente.
La cosa se complica en Apps que tienen muchas versiones. Afortunadamente, en iOS no he tenido casos muy complejos (de momento). Sin embargo, un caso extremo que tuve en el pasado con una aplicación de Windows, podría repetirse en el futuro:
- La aplicación, partiendo de un mismo código, debía generar 3 versiones distintas (con distinto “branding”, UI y funcionalidades)
- Cada una de esas versiones podía tener dos conjuntos de datos que llevaba asociado. Van 6 versiones.
- Cada una de éstas, tenía que estar en dos “locales” (idioma y localización). Ya van 12.
- A su vez, cada una de ellas tenía entre 1 y 3 métodos de despliegue distintos. Total, dieciocho tareas.
Claramente, esto no era manejable por una sola persona, y menos aun alguien despistado como yo. El aburrimiento y el margen de error era excesivamente amplio.
Build Automation Tools: make & Cia
Aquí es donde entran las herramientas de automatización de “build” o, si prefieres, build automation tools.
El abuelo de todos es el viejo make. Es la herramienta estándar con la que se ha construido la mayoría del software del mundo durante años. Esto no habla bien de la herramienta, sino de la paciencia sin fin de los desarrolladores.
Uno de los principales problemas con make es que NO es un lenguaje de programación, sino más bien una especie de lenguaje de “markup“, meramente descriptivo. No puedes expresar ningún algoritmo, solo una cadena de tareas que dependen una de otra.
Mientras solo estés haciendo aquello para lo cual ha sido diseñado (compilar ficheros de c a ficheros objeto y luego enlazarlos), vas más o menos bien, pero en el momento que necesitas algo más (crear una base de datos, ficheros de configuración, notificar el éxito o fracaso del proyecto, etc… estás perdido.
Pronto quedó evidente que el proceso del build de un software es de complejidad comparable al problema que intenta resolver el software.
Si el último no lo has logrado con un lenguaje de markup, ¿por qué ibas a tener suerte con el primero?
Hace falta un lenguaje de programación potente que te permite resolver cualquier problema que se salga del caso más común, pero a la vez con una sintaxis muy sencilla para dicho caso común (compilar código fuente).
Maven: más de lo mismo
Como había quedado claro que un lenguaje de markup no daba la talla y hacia falta un lenguaje de programación completo, la comunidad de Java se arremangó y sacó Maven: un make que usa xml. <largo suspiro>
CMake: alguien empieza a pensar (mal)
No todo ha sido patinazos, y algunas cabezas iluminadas sacaron CMake. Una especie de make, pero con un lenguaje empotrado. Es bastante usado en algunos nichos, por ejemplo en OpenCV. Sin embargo, tiene un “pequeño” problema: el lenguaje que se han inventado es malo y limitado de cojones. En vez de usar una lenguaje preexistente, decidieron reinventar la rueda y en vez de eso, reinventaron el neumático pinchado.
SCons
Con la cantidad de lenguajes de script buenos (y malos) que hay por ahí, ¿por qué no elegir uno, añadirle un DSL sencillo para la tarea de build y usarlo?
Eso debieron de pensar los creadores de SCons, un sistema para Construir Software (¿lo pillas?) usando Python.
Desgraciadamente nunca tuvo demasiado éxito. En parte porque tardó demasiado en tener una versión estable. Sin embargo, en mi opinión, el problema real era más grave: la sintaxis era excesivamente parecida a Python y daba la impresión (correcta) que para poder usarlo, de partida tenías que aprender Python. Lo que la mayoría de los desarrolladores quería era algo para salir rápidamente del atolladero, pero que en caso de encontrarse con un problema serio, poder tirar de toda la potencia de un lenguaje de script.
SCons, fallaba en sentido, haciéndote pagar por adelantado el coste de aprender el lenguaje. Moraleja, no lo usa ni el tato.
Rake
Es el rey en estos momentos, y el más usado por los desarrolladores iOS. Parte de una idea muy sencilla: Rake es un make que incluye Ruby.
El problema que le veo yo, es que la sintaxis de Ruby me parece más incomprensible que una peli de Bruce Lee en Cantonés. sin embargo, es una excelente herramienta.
Gradle
¿Quién me iba a decir a mi, que entre el ecosistema de Java, iba yo a encontrar el Santo Grial? Gradle es una herramienta parecida a Rake, pero que en vez de usar Ruby como lenguaje de script, utiliza Groovy.
Groovy es uno de estos nuevos lenguajes para la JVM que tan de moda parecen estar poniéndose. De todos ellos, Groovy tal vez sea el más fácil de aprender ya que tiene una sintaxis muy sencilla y añade enormes mejoras a Java: lenguaje dinámico (tipo Objective C), expresiones literales para colecciones, funciones de primer nivel (bloques, en Objective C), metaclases, interpolación de cadenas y un largo etcétera.
Groovy es un Java mejor que Java.
Además de usarse mucho para desarrollo web con Grails (Groovy On Rails), es especialmente indicado para crear DSLs. Y ahí es donde entra Gradle.
Gradle es un DSL en Groovy, especializado en “build automation”. Su sintaxis es especialmente sencilla e intuitiva y si la cosa se pone fea, siempre puedes tirar del poder Groovy.
Gradle recientemente ha saltado a la fama, por ser elegido por Google como sistema de build estándar para AndroidStudio.
Si vas a hacer Apps para ambos sistemas (Android e iOS), lo cual es cada vez más frecuente, y uno de ellos ya usa por defecto una excelente herramienta, ¿por qué no usarla para tus proyectos iOS en vez de estar con Gradle por un lado y Rake por otro? ¡Venga y usa las build automation tools!
