Sistemas de build baseados em tarefas

7.3 · 7.2 · 7.1 · 7.0 · 6.5

Esta página aborda os sistemas de build baseados em tarefas, como eles funcionam e algumas das complicações que podem ocorrer com esses sistemas. Depois dos scripts de shell, os sistemas de build baseados em tarefas são a próxima evolução lógica do build.

Noções básicas sobre sistemas de build baseados em tarefas

Em um sistema de build baseado em tarefas, a unidade de trabalho fundamental é a tarefa. Cada tarefa é um script que pode executar qualquer tipo de lógica, e as tarefas especificam outras tarefas como dependências que precisam ser executadas antes delas. A maioria dos principais sistemas de build em uso hoje, como Ant, Maven, Gradle, Grunt e Rake, são baseadas em tarefas. Em vez de scripts de shell, a maioria dos sistemas de build modernos exige que os engenheiros criem arquivos de build que descrevem como realizar o build.

Confira este exemplo do manual do Ant (link em inglês):

<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>

O buildfile é escrito em XML e define alguns metadados simples sobre o build com uma lista de tarefas (as tags <target> no XML). O Ant usa a palavra target para representar uma tarefa e a palavra task para se referir a comandos. Cada tarefa executa uma lista de comandos possíveis definidos pelo Ant, que inclui a criação e a exclusão de diretórios, a execução de javac e a criação de um arquivo JAR. Esse conjunto de comandos pode ser estendido por plug-ins fornecidos pelo usuário para cobrir qualquer tipo de lógica. Cada tarefa também pode definir as tarefas das quais depende pelo atributo "depends". Essas dependências formam um gráfico acíclico, conforme mostrado na Figura 1.

Figura 1. Um gráfico acíclico mostrando dependências

Os usuários realizam builds fornecendo tarefas para a ferramenta de linha de comando do Ant. Por exemplo, quando um usuário digita ant dist, o Ant segue estas etapas:

Carrega um arquivo chamado build.xml no diretório atual e o analisa para criar a estrutura de gráfico mostrada na Figura 1.
Procura a tarefa dist fornecida na linha de comando e descobre que ela tem uma dependência da tarefa compile.
Procura a tarefa chamada compile e descobre que ela tem uma dependência na tarefa chamada init.
Procura a tarefa init e descobre que ela não tem dependências.
Executa os comandos definidos na tarefa init.
Executa os comandos definidos na tarefa compile, desde que todas as dependências da tarefa tenham sido executadas.
Executa os comandos definidos na tarefa dist, desde que todas as dependências da tarefa tenham sido executadas.

No final, o código executado pelo Ant ao executar a tarefa dist será equivalente ao seguinte script de shell:

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

Quando a sintaxe é removida, o arquivo de build e o script de build não são muito diferentes. Mas já ganhamos muito com isso. Podemos criar novos arquivos de build em outros diretórios e vinculá-los. Podemos adicionar facilmente novas tarefas que dependem de tarefas atuais de maneiras arbitrárias e complexas. Só precisamos transmitir o nome de uma única tarefa para a ferramenta de linha de comando ant, que determina tudo o que precisa ser executado.

O Ant é um software antigo, lançado originalmente em 2000. Outras ferramentas, como Maven e Gradle, aprimoraram o Ant nos anos seguintes e substituíram-o pela adição de recursos como gerenciamento automático de dependências externas e uma sintaxe mais limpa, sem XML. No entanto, a natureza desses sistemas mais recentes permanece a mesma: eles permitem que os engenheiros escrevam scripts de build de forma modular e com princípios, como tarefas, e fornecem ferramentas para executar essas tarefas e gerenciar dependências entre elas.

O lado sombrio dos sistemas de build baseados em tarefas

Como essas ferramentas permitem que os engenheiros definam qualquer script como uma tarefa, elas são extremamente poderosas, permitindo que você faça quase tudo o que puder imaginar com elas. No entanto, esse poder tem desvantagens, e os sistemas de build baseados em tarefas podem ficar difíceis de trabalhar à medida que os scripts de build ficam mais complexos. O problema com esses sistemas é que eles acabam dando muito poder aos engenheiros e não o suficiente para o sistema. Como o sistema não tem ideia do que os scripts estão fazendo, a performance sofre, já que ele precisa ser muito conservador na forma como programa e executa as etapas de build. E não há como o sistema confirmar se cada script está fazendo o que deveria. Por isso, os scripts tendem a aumentar de complexidade e acabam sendo outra coisa que precisa de depuração.

Dificuldade de paralelizar etapas de build

As estações de trabalho de desenvolvimento modernas são bastante potentes, com várias cores que são capazes de executar várias etapas de build em paralelo. No entanto, os sistemas baseados em tarefas muitas vezes não conseguem carregar a execução de tarefas em paralelo, mesmo quando parece que deveriam ser possíveis. Suponha que a tarefa A dependa das tarefas B e C. Como as tarefas B e C não dependem uma da outra, é seguro executá-las ao mesmo tempo para que o sistema chegue mais rapidamente à tarefa A? Talvez, se eles não tocarem em nenhum dos mesmos recursos. Mas talvez não. Talvez os dois usem o mesmo arquivo para rastrear os status e a execução deles ao mesmo tempo cause um conflito. Em geral, não há como o sistema saber. Portanto, ele precisa arriscar esses conflitos, levando a problemas de build raros, mas muito difíceis de depurar, ou restringir todo o build para ser executado em uma única linha de execução em um único processo. Isso pode ser um grande desperdício de uma máquina de desenvolvedor poderosa e exclui completamente a possibilidade de distribuir o build em várias máquinas.

Dificuldade em executar builds incrementais

Um bom sistema de build permite que os engenheiros executem builds incrementais confiáveis para que uma pequena mudança não exija que toda a base de código seja recriada do zero. Isso é importante principalmente se o sistema de build for lento e não conseguir carregar as etapas de build em paralelo pelos motivos acima. Mas, infelizmente, os sistemas de build baseados em tarefas também têm dificuldades. Como as tarefas podem fazer qualquer coisa, não há uma maneira geral de verificar se elas já foram concluídas. Muitas tarefas simplesmente pegam um conjunto de arquivos de origem e executam um compilador para criar um conjunto de binários. Portanto, elas não precisam ser executadas novamente se os arquivos de origem não tiverem mudado. No entanto, sem informações adicionais, o sistema não pode afirmar isso com certeza. Talvez a tarefa faça o download de um arquivo que poderia ter sido alterado ou talvez grave um carimbo de data/hora que pode ser diferente em cada execução. Para garantir a correção, o sistema normalmente precisa executar todas as tarefas novamente durante cada build. Alguns sistemas de build tentam ativar builds incrementais permitindo que os engenheiros especifiquem as condições em que uma tarefa precisa ser executada novamente. Às vezes, isso é possível, mas muitas vezes é um problema muito mais complicado do que parece. Por exemplo, em linguagens como C++, que permitem que arquivos sejam incluídos diretamente por outros arquivos, é impossível determinar o conjunto inteiro de arquivos que precisam ser monitorados para mudanças sem analisar as origens de entrada. Os engenheiros muitas vezes acabam usando atalhos, e esses atalhos podem levar a problemas raros e frustrantes em que um resultado de tarefa é reutilizado mesmo quando não deveria ser. Quando isso acontece com frequência, os engenheiros adquirem o hábito de executar a limpeza antes de cada build para ter um estado novo, derrotando completamente o propósito de ter um build incremental em primeiro lugar. Descobrir quando uma tarefa precisa ser executada novamente é surpreendentemente sutil e é um trabalho melhor processado por máquinas do que por humanos.

Dificuldade em manter e depurar scripts

Por fim, os scripts de build impostos por sistemas de build baseados em tarefas geralmente são difíceis de trabalhar. Embora eles recebam menos atenção, os scripts de build são códigos como o sistema em desenvolvimento e são lugares fáceis para bugs se esconderem. Confira alguns exemplos de bugs muito comuns ao trabalhar com um sistema de build baseado em tarefas:

A tarefa A depende da tarefa B para produzir um arquivo específico como saída. O proprietário da tarefa B não percebe que outras tarefas dependem dela. Por isso, ele a altera para produzir saída em um local diferente. Ela só é detectada quando alguém tenta executar a tarefa A e descobre que ela falhou.
A Tarefa A depende da tarefa B, que depende da tarefa C, que está produzindo um arquivo específico como saída necessária para a tarefa A. O proprietário da tarefa B decide que ela não precisa mais depender da tarefa C, o que faz com que a tarefa A falhe, mesmo que a tarefa B não se importe com a tarefa C.
O desenvolvedor de uma nova tarefa faz uma suposição acidental sobre a máquina que executa a tarefa, como o local de uma ferramenta ou o valor de variáveis de ambiente específicas. A tarefa funciona na máquina, mas falha sempre que outro desenvolvedor tenta.
Uma tarefa contém um componente não determinista, como fazer o download de um arquivo da Internet ou adicionar um carimbo de data/hora a um build. Agora, as pessoas recebem resultados potencialmente diferentes cada vez que executam o build, o que significa que os engenheiros nem sempre conseguem reproduzir e corrigir falhas ou falhas uns dos outros que ocorrem em um sistema de build automatizado.
Tarefas com várias dependências podem criar disputas. Se a tarefa A depender da tarefa B e da tarefa C, e a tarefa B e C modificarem o mesmo arquivo, a tarefa A terá um resultado diferente, dependendo de qual das tarefas B e C terminar primeiro.

Não há uma maneira geral de resolver esses problemas de desempenho, correção ou manutenção no framework baseado em tarefas apresentado aqui. Desde que os engenheiros escrevam um código arbitrário que seja executado durante a criação, o sistema não terá informações suficientes para sempre executar as versões de maneira rápida e correta. Para resolver o problema, precisamos tirar um pouco de poder das mãos dos engenheiros e colocá-lo de volta nas mãos do sistema e reconceptualizar o papel do sistema não como tarefas em execução, mas como produção de artefatos.

Essa abordagem levou à criação de sistemas de build baseados em artefatos, como Blaze e Bazel.