Tras mucho esfuerzo, el programador, o grupo de programadores, han logrado formar un prototipo funcional de un sistema. Ya tienen suficiente código como para poder considerar que tienen algo digno de almacenar. Sin embargo, como parte del proceso de programación, al cliente (tomando en esta entrada como “cliente” a todo aquella persona o grupo interesada en el desarrollo) se le ha de proporcionar una versión usable del sistema. Después de todo, a los clientes les interesa ver el producto en acción, no el código.
A esta versión usable, en terminología común, se le denomina build. Estos builds no son más que versiones compiladas del código. Éstos deben de cumplir con ciertas características para poder ser enviadas a los clientes:
- Por si mismos, ser capaz de ejecutarse en la plataforma destino (ya sea Microsoft Windows, Apple Mac OS, GNU/Linux, Android, iOS, etc).
- Debe de contar con todos aquellos recursos que pudiera requerir en el momento, como íconos, fondos, imágenes, archivos de configuración, etc.
- Debe de ser autosuficiente, como lo es el contar con todas las DLLs necesarias (en Microsoft Windows) o equivalentes en Apple MacOS o GNU/Linux.
- Debe de ser lo suficientemente estable como para poder funcionar durante las pruebas.
Para generar estos builds, existen muchas y muy variadas formas. Dependiendo directamente de qué lenguaje se esté usando y la plataforma en que se esté desarrollando, serán las alternativas que se tendrán a la mano. Sin embargo, normalmente, en etapas iniciales de un proyecto, estas opciones no suelen ser consideradas y se suele seguir un proceso manual para generarlos.
El proceso manual requiere, normalmente, el usar un compilador de forma directa, escribiendo los comandos requeridos uno a uno en el orden correcto para, posteriormente, copiar los resultados parciales a una carpeta temporal o final para “armar” el build con las piezas generadas.
Este proceso manual, si bien funciona, es propenso a errores, especialmente si existen pasos intermedios. En estos casos, será común para el desarrollador el encontrarse ante un build defectuoso o incompleto. En estos casos, es necesario realizarle pruebas previas antes de enviarlo al cliente para que éste lo pruebe.
Estos errores que pueden surgir por seguir un proceso manual pueden tener un costo alto en varios rubros. Algunos de los efectos de estos problemas pueden ser:
- Aún para un desarrollador experimentado y que sabe qué se ha de hacer, el realizar los pasos de forma manual puede requerir mucho tiempo.
- Es posible que se omitan pasos intermedios requeridos, cuyos efectos sean observables hasta que todo el proceso haya terminado.
Debido a esto, es que se suele recomendar que los desarrolladores busquen una solución automatizada para la generación de builds. Estas soluciones, normalmente, dependen del uso de archivos script.
Un archivo script (o guión de comandos), normalmente, no es más que un documento de texto simple que contiene una serie de comandos de sistema, uno tras otro, que serán ejecutados de forma lineal. Estos comandos pueden ser usados para cualquier cosa relacionada a la generación de builds, como es:
- Preparación de código fuente: Se pueden realizar modificaciones al código mismo para modificar valores o textos que pueden afectar al sistema.
- Limpieza de proyecto: Como resultado de una compilación previa, es posible realizar la eliminación de archivos temporales no necesarios para evitar que éstos interfieran de alguna forma con la compilación actual.
- Compilación paso a paso: Dependiendo del tipo de proyecto, su estructura, lenguaje y herramientas usadas, éste podría ser compilado con un solo comando, o con una serie de éstos.
- Preparación de build: Una vez que se han compilado las piezas de un proyecto, es posible tomarlas y copiarlas a una carpeta, así como otros componentes adicionales requeridos (como DLLs en el caso de Microsoft Windows).
- Limpieza: En caso de ser necesario, por ejemplo, es posible comprimir el build generado, renombrar archivos o realizar el proceso de limpieza previamente especificado.
- Pruebas: Si el proyecto está diseñado y preparado para ello, es posible realizar pruebas automatizadas del mismo para comprobar su calidad y verificar que funciona correctamente.
Estas ventajas, claramente, no vienen sin un costo. El diseño, programación, pruebas y mantenimiento de un sistema de scripts que automaticen la generación de un build puede ser bastante complejo, rivalizando en algunos casos con el proyecto mismo. Sin embargo, el costo/beneficio del mismo debe de contemplarse a largo plazo, ya que el invertir tiempo en un sistema así puede traer las siguientes ventajas claras:
- Generación desatendida: No es necesario que una persona esté observando o controlando el sistema mientras genera un build.
- Velocidad de generación: Si bien la compilación por si misma suele no variar, la generación del build será mucho más rápida, pues no habrá un factor humano que genere retrasos entre pasos.
- Disminución de errores: Es evidente que al evitar que un desarrollador se encargue del proceso se elimina la posibilidad de generar un error por descuido. Esto aumenta la calidad de los builds al procurar que prácticamente todos estén bien elaborados.
Es por ello que, como un desarrollador experimentado y con trayectoria en el rubro, puedo observar con claridad las ventajas de un sistema que automatice estos procesos, ya que, si bien son complejos (y muchas veces se recurre a soluciones personalizadas), las ventajas que traen superan los costos de tiempo invertido en ellos.
Un sistema de scripts para automatización debería de implementarse para todos aquellos casos que un producto sea enviado a un cliente, ya que, sin importar la extensión de un proyecto, es importante garantizar su calidad en todo momento.
