30 marzo 2006
El proceso de construcción
Hace ya varios años, leí un artículo en Joel on Software que hablaba de las compilaciones diarias. En aquellos tiempos me sonó a chino, cuando pensaba que la compilación de un programa no era más que seleccionar la opción "Project - Build" de mi IDE.
Sin embargo, con el tiempo me he ido dando cuenta de que no tiene nada que ver la "compilación del programa" con la "construcción del producto", aunque los dos deberían hacerse con un único paso.
Compilar un programa no es más que transformar código fuente en código ejecutable, y eso es un trabajo repetitivo y mecánico (aunque bastante complejo) resuelto por el compilador, que para eso se inventó.
Sin embargo, contruir un producto supone mucho más. Por ejemplo, en nuestro caso, para construir El Cuarto Sello tenemos las siguientes tareas:
Por otro lado tenemos la construcción de Battlewizard, que tiene sus propios pasos, bastante distintos, sobre todo porque Battlewizard tiene una aplicación de escritorio con su propio instalador, generación del archivo ejecutable, etc.
No sé si me dejo algo, pero más o menos nos hacemos a la idea.
Todos estos pasos que hemos descrito forman el proceso de construcción de nuestro producto, sin embargo, nos falta algo importante: automatizarlo. Pues sí, la gracia de todo esto está en que el proceso de construcción sea:
Otro beneficio es que, construyendo completamente el producto y de forma periodica, conseguimos detectar código erróneo muy pronto. Supongamos que una de nuestras librerías lleva sin modificarse meses, y cuando vamos a compilarla y lanzar sus pruebas unitarias, falla por todos los lados. Si todos los días o semanas hubieramos compilado y probado esa librería (junto con el resto del producto), ese error lo habríamos detectado muy pronto, pocas horas o días después de que alguien lo hubiera cometido, y sería mucho más sencillo corregirlo.
Y por último, haciendo construcciones automáticas conseguimos que cualquier persona, incluso aunque sólo lleve unos días en el equipo, sea capaz de generar el producto. El proceso ya se encargará de obtener los ficheros de donde sea, de hacer las copias necesarias, modificar nosequé librerías, etc. pero de cara al usuario, todo se hace en un sencillo paso.
Bueno, mañana hablaremos de la famosa "integración continua" que recomiendan las metodologías ágiles como eXtreme Programming.
Mientras tanto, podéis leer más sobre el tema en estos artículos que no tienen desperdicio:
Sin embargo, con el tiempo me he ido dando cuenta de que no tiene nada que ver la "compilación del programa" con la "construcción del producto", aunque los dos deberían hacerse con un único paso.
Compilar un programa no es más que transformar código fuente en código ejecutable, y eso es un trabajo repetitivo y mecánico (aunque bastante complejo) resuelto por el compilador, que para eso se inventó.
Sin embargo, contruir un producto supone mucho más. Por ejemplo, en nuestro caso, para construir El Cuarto Sello tenemos las siguientes tareas:
- Compilar el motor abstracto de Battlewizard.
- Compilar la implementación específica para el móvil que queremos utilizar: MIDP 2.0, nokia, etc. (Por cierto, tenemos pendiente hablar en detalle de Battlewizard y de su arquitectura).
- Incrementar la versión actual y crear el archivo de manifest
- Empaquetar todo eso en un archivo JAR.
- Compilar el código fuente del juego, utilizando los recursos (gráficos, sonido, cadenas de textos, etc) específicos para el dispositivo e idiomas destino.
- Lanzar las pruebas unitarias de todo el código (con JUnit y J2MEUnit)
- Ofuscar todo (con ProGuard o RetroGuard, dependiendo del caso).
- Optimizar y comprimir el bytecode (con librerías específicas para ello)
- Crear el archivo JAD, indicando el tamaño del archivo JAR, nombre del MIDlet, etc.
Por otro lado tenemos la construcción de Battlewizard, que tiene sus propios pasos, bastante distintos, sobre todo porque Battlewizard tiene una aplicación de escritorio con su propio instalador, generación del archivo ejecutable, etc.
No sé si me dejo algo, pero más o menos nos hacemos a la idea.
Todos estos pasos que hemos descrito forman el proceso de construcción de nuestro producto, sin embargo, nos falta algo importante: automatizarlo. Pues sí, la gracia de todo esto está en que el proceso de construcción sea:
- automático, sin intervención humana, con la mínima posible (se pueden pedir datos al principio, como preguntar al usuario si quiere generar la versión demo o la versión normal).
- tan sencillo como un simple clic (bueno, se admite lanzar un comando de consola o incluso un doble clic :)
- completo (no vale recompilar sólo ciertas librerías, o hacer una compilación incremental)
- y a ser posible diario, ejecutado cada noche (¿no os suenan los famosos nightly builds?) o al menos lanzado de forma periodica.
Otro beneficio es que, construyendo completamente el producto y de forma periodica, conseguimos detectar código erróneo muy pronto. Supongamos que una de nuestras librerías lleva sin modificarse meses, y cuando vamos a compilarla y lanzar sus pruebas unitarias, falla por todos los lados. Si todos los días o semanas hubieramos compilado y probado esa librería (junto con el resto del producto), ese error lo habríamos detectado muy pronto, pocas horas o días después de que alguien lo hubiera cometido, y sería mucho más sencillo corregirlo.
Y por último, haciendo construcciones automáticas conseguimos que cualquier persona, incluso aunque sólo lleve unos días en el equipo, sea capaz de generar el producto. El proceso ya se encargará de obtener los ficheros de donde sea, de hacer las copias necesarias, modificar nosequé librerías, etc. pero de cara al usuario, todo se hace en un sencillo paso.
Bueno, mañana hablaremos de la famosa "integración continua" que recomiendan las metodologías ágiles como eXtreme Programming.
Mientras tanto, podéis leer más sobre el tema en estos artículos que no tienen desperdicio:
- Daily Builds Are Your Friend de Joel on Software, donde empecé a descubrir el mundo de las construcciones.
- Daily Build and Smoke Test de Steve McConnell, habla del enfoque usado en Microsoft para las construcciones diarias y los procesos de QA (calidad).
Etiquetas: programación
