Para obtener documentación sobre versiones estables, usa el menú desplegable "Documentos con versiones". La vista predeterminada refleja la versión más reciente en el encabezado.

Se usó la API de Cloud Translation para traducir esta página.

Sistemas de compilación basados en tareas

Informa un problema Ver código fuente

En esta página, se abordan los sistemas de compilación basados en tareas, su funcionamiento y algunas de las complicaciones que pueden ocurrir con estos sistemas. Después de las secuencias de comandos de shell, los sistemas de compilación basados en tareas son la próxima evolución lógica de la compilación.

Comprende los sistemas de compilación basados en tareas

En un sistema de compilación basado en tareas, la unidad de trabajo fundamental es la tarea. Cada tarea es una secuencia de comandos que puede ejecutar cualquier tipo de lógica, y especifica otras tareas como dependencias que deben ejecutarse antes. La mayoría de los sistemas de compilación principales que se usan en la actualidad, como Ant, Maven, Gradle, Grunt y Rake, se basan en tareas. En lugar de secuencias de comandos de shell, la mayoría de los sistemas de compilación modernos requieren que los ingenieros creen archivos de compilación que describan cómo realizar la compilación.

Toma este ejemplo del manual de Ant:

<project name="MyProject" default="dist" basedir=".">
   <description>
     simple example build file
   </description>
   <!-- set global properties for this build -->
   <property name="src" location="src"/>
   <property name="build" location="build"/>
   <property name="dist" location="dist"/>

   <target name="init">
     <!-- Create the time stamp -->
     <tstamp/>
     <!-- Create the build directory structure used by compile -->
     <mkdir dir="${build}"/>
   </target>
   <target name="compile" depends="init"
       description="compile the source">
     <!-- Compile the Java code from ${src} into ${build} -->
     <javac srcdir="${src}" destdir="${build}"/>
   </target>
   <target name="dist" depends="compile"
       description="generate the distribution">
     <!-- Create the distribution directory -->
     <mkdir dir="${dist}/lib"/>
     <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
     <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
   </target>
   <target name="clean"
       description="clean up">
     <!-- Delete the ${build} and ${dist} directory trees -->
     <delete dir="${build}"/>
     <delete dir="${dist}"/>
   </target>
</project>

El archivo de compilación está escrito en XML y define algunos metadatos simples sobre la compilación junto con una lista de tareas (las etiquetas <target> en el XML). (Ant usa la palabra target para representar una tarea y la palabra tarea para referirse a los comandos). Cada tarea ejecuta una lista de comandos posibles definidos por Ant, que incluyen la creación y eliminación de directorios, la ejecución de javac y la creación de un archivo JAR. Este conjunto de comandos se puede extender con complementos proporcionados por el usuario para cubrir cualquier tipo de lógica. Cada tarea también puede definir las tareas de las que depende a través del atributo dependientes. Estas dependencias forman un grafo acíclico, como se muestra en la Figura 1.

Figura 1: Un grafo acíclico que muestra dependencias

Para realizar compilaciones, los usuarios deben proporcionar tareas a la herramienta de línea de comandos de Ant. Por ejemplo, cuando un usuario escribe ant dist, Ant sigue estos pasos:

Carga un archivo llamado build.xml en el directorio actual y lo analiza para crear la estructura del grafo que se muestra en la figura 1.
Busca la tarea llamada dist, que se proporcionó en la línea de comandos, y descubre que tiene una dependencia en la tarea llamada compile.
Busca la tarea llamada compile y descubre que tiene una dependencia llamada init.
Busca la tarea init y descubre que no tiene dependencias.
Ejecuta los comandos definidos en la tarea init.
Ejecuta los comandos definidos en la tarea compile, dado que se ejecutaron todas las dependencias de esa tarea.
Ejecuta los comandos definidos en la tarea dist, dado que se ejecutaron todas las dependencias de esa tarea.

Al final, el código que ejecuta Ant cuando ejecuta la tarea dist es equivalente a la siguiente secuencia de comandos de shell:

./createTimestamp.sh
mkdir build/
javac src/* -d build/
mkdir -p dist/lib/
jar cf dist/lib/MyProject-$(date --iso-8601).jar build/*

Cuando se quita la sintaxis, el archivo de compilación y la secuencia de comandos de compilación no son demasiado diferentes. Pero, gracias a esto, ya hemos ganado mucho. Podemos crear archivos de compilación nuevos en otros directorios y vincularlos. Podemos agregar tareas nuevas con facilidad que dependan de tareas existentes de formas arbitrarias y complejas. Solo necesitamos pasar el nombre de una sola tarea a la herramienta de línea de comandos de ant, y determina todo lo que se debe ejecutar.

Ant es una antigua pieza de software que se lanzó originalmente en el año 2000. Otras herramientas, como Maven y Gradle, mejoraron en Ant en los años intermedios y, en esencia, la reemplazaron agregando funciones como la administración automática de dependencias externas y una sintaxis más limpia sin ningún XML. Sin embargo, la naturaleza de estos sistemas más nuevos sigue siendo la misma: permiten que los ingenieros escriban secuencias de comandos de compilación de acuerdo con principios y modulares como tareas, y proporcionan herramientas para ejecutarlas y administrar las dependencias entre ellas.

El lado oscuro de los sistemas de compilación basados en tareas

Debido a que estas herramientas básicamente permiten que los ingenieros definan cualquier secuencia de comandos como una tarea, son extremadamente potentes, lo que te permite hacer casi cualquier cosa que puedas imaginar. Sin embargo, esa potencia conlleva desventajas y puede resultar difícil trabajar con los sistemas de compilación basados en tareas a medida que sus secuencias de comandos de compilación se vuelven más complejas. El problema con estos sistemas es que, en realidad, terminan dando demasiado poder a los ingenieros y no suficiente energía al sistema. Debido a que el sistema no tiene idea de lo que hacen las secuencias de comandos, el rendimiento se ve afectado, ya que debe ser muy conservador en cuanto a la programación y ejecución de los pasos de compilación. Además, no hay forma de que el sistema confirme que cada secuencia de comandos hace lo que debería, por lo que las secuencias de comandos tienden a crecer en complejidad y terminan siendo otra cosa que necesita depuración.

Dificultad para paralelizar pasos de compilación

Las estaciones de trabajo de desarrollo modernas son bastante potentes con varios núcleos capaces de ejecutar varios pasos de compilación en paralelo. Sin embargo, a menudo, los sistemas basados en tareas no pueden paralelizar la ejecución de tareas, incluso cuando parecen poder hacerlo. Supongamos que la tarea A depende de las tareas B y C. Debido a que las tareas B y C no dependen unas de otras, ¿es seguro ejecutarlas al mismo tiempo para que el sistema pueda llegar a la tarea A con mayor rapidez? Quizás, si no tocan ninguno de los mismos recursos. Pero tal vez no, ya que ambos usan el mismo archivo para hacer un seguimiento de sus estados y ejecutarlos al mismo tiempo provocan un conflicto. El sistema no tiene manera de saber en general, por lo que debe arriesgarse a estos conflictos (lo que genera problemas de compilación poco frecuentes pero muy difíciles de depurar) o debe restringir la ejecución completa de la compilación para un solo subproceso en un solo proceso. Esto puede ser un gran desperdicio de una máquina de desarrollo potente y descarta completamente la posibilidad de distribuir la compilación en varias máquinas.

Dificultad para realizar compilaciones incrementales

Un buen sistema de compilación permite a los ingenieros realizar compilaciones incrementales confiables de modo que un pequeño cambio no requiera que todo el código base se vuelva a compilar desde cero. Esto es muy importante si el sistema de compilación es lento y no puede paralelizar los pasos de la compilación por los motivos antes mencionados. Sin embargo, los sistemas de compilación basados en tareas también tienen dificultades. Debido a que las tareas pueden realizar cualquier acción, no hay forma general de comprobar si ya se realizaron. Muchas tareas simplemente toman un conjunto de archivos de origen y ejecutan un compilador para crear un conjunto de objetos binarios; por lo tanto, no necesitan volver a ejecutarse si los archivos de origen subyacentes no cambiaron. Sin embargo, sin información adicional, el sistema no puede establecerlo con certeza. Quizás, la tarea descarga un archivo que podría haber cambiado, o quizás escribe una marca de tiempo que podría ser diferente en cada ejecución. Para garantizar la precisión, el sistema, por lo general, debe volver a ejecutar cada tarea durante cada compilación. Algunos sistemas de compilación intentan habilitar compilaciones incrementales y permiten que los ingenieros especifiquen las condiciones en las que se debe volver a ejecutar una tarea. A veces esto es factible, pero a menudo es un problema mucho más difícil de lo que parece. Por ejemplo, en lenguajes como C++ que permiten que otros archivos incluyan directamente los archivos, es imposible determinar todo el conjunto de archivos que se deben supervisar en busca de cambios sin analizar las fuentes de entrada. Por lo general, los ingenieros terminan tomando atajos, y estos pueden generar problemas poco comunes y frustrantes en los que se vuelve a usar el resultado de una tarea, incluso cuando no debería. Cuando esto sucede con frecuencia, los ingenieros adoptan el hábito de ejecutar una limpieza antes de cada compilación para obtener un estado nuevo, lo que anula por completo el propósito de tener una compilación incremental. Saber cuándo es necesario volver a ejecutar una tarea es sorprendentemente sutil y un trabajo mejor manejado por las máquinas que los humanos.

Dificultad para mantener y depurar secuencias de comandos

Por último, las secuencias de comandos de compilación impuestas por los sistemas de compilación basados en tareas suelen ser difíciles de usar. Aunque a menudo reciben menos escrutinio, las secuencias de comandos de compilación son código al igual que el sistema que se está compilando y son lugares sencillos para ocultar los errores. Estos son algunos ejemplos de errores que son muy comunes cuando se trabaja con un sistema de compilación basado en tareas:

La tarea A depende de la tarea B para producir un archivo en particular como resultado. El propietario de la tarea B no se da cuenta de que otras tareas dependen de ella, por lo que la cambia para producir resultados en una ubicación diferente. No se puede detectar hasta que alguien intente ejecutar la tarea A y detecte que falla.
La tarea A depende de la tarea B, que depende de la tarea C, que produce un archivo en particular como resultado que necesita la tarea A. El propietario de la tarea B decide que ya no necesita depender de la tarea C, lo que hace que la tarea A falle, aunque la tarea B no se preocupe por la tarea C en absoluto.
El desarrollador de una tarea nueva hace una suposición accidental sobre la máquina que ejecuta la tarea, como la ubicación de una herramienta o el valor de variables de entorno específicas. La tarea funciona en su máquina, pero falla cada vez que otro desarrollador la prueba.
Una tarea contiene un componente no determinista, como descargar un archivo de Internet o agregar una marca de tiempo a una compilación. Ahora, las personas obtienen resultados potencialmente diferentes cada vez que ejecutan la compilación, lo que significa que los ingenieros no siempre podrán reproducir y corregir las fallas entre sí o que ocurran en un sistema de compilación automatizado.
Las tareas con varias dependencias pueden crear condiciones de carrera. Si la tarea A depende de la tarea B y la tarea C, y ambas tareas modifican el mismo archivo, la tarea A obtiene un resultado diferente según cuál de las tareas B y C finaliza primero.

No existe una manera general de resolver estos problemas de rendimiento, precisión o mantenimiento dentro del marco de trabajo basado en tareas que se expone aquí. Siempre que los ingenieros puedan escribir un código arbitrario que se ejecute durante la compilación, el sistema no puede tener la información suficiente para poder ejecutar compilaciones con rapidez y de forma correcta. Para resolver el problema, necesitamos quitar algo de poder de los ingenieros y ponerlo en manos del sistema, y replantear la función del sistema, no como tareas en ejecución, sino como producción de artefactos.

Este enfoque llevó a la creación de sistemas de compilación basados en artefactos, como Blaze y Bazel.