Você está na página 1de 10

3

Gerenciamento

O gerenciamento de projeto envolve a realizao de muitas tarefas tais


como: compilao, execuo dos testes, gerao dos artefatos finais, controle de
verses, disponibilizao do produto para o cliente. Fazer qualquer uma dessas
tarefas manualmente, alm de possibilitar o aparecimento de erros, uma
completa perda de tempo. Por isso, fundamental um mecanismo automatizado
para auxiliar no cumprimento dessas tarefas.

PUC-Rio - Certificao Digital N 0511002/CA

3.1.Build Automatizado
Uma das prticas que mais claramente define o conceito de evitar o
desperdcio de tempo o build automatizado. Em XP, a construo do produto
final incluindo a execuo de todos os testes deve ser feita de forma rpida e
automatizada.
A automao do build uma prtica relativamente recente. A engenharia de
software tradicional foi fundada em uma poca em que os computadores eram
extraordinariamente caros. Nesta poca, encontrar e corrigir problemas na
compilao dos lotes de programas era muito devagar. At a metade dos anos 80,
programas grandes demoravam muitas horas para serem compilados (McBreen,
2002). Nos ltimos anos, no entanto, esta situao mudou. O poder computacional
aumentou bastante e tornou-se cada vez mais barato, ao ponto de a maioria dos
programas poderem ser recompilados em poucos segundos. raro, at mesmo
para aplicaes muito grandes, demorar mais do que dez minutos para terminar o
build (McBreen, 2002).
De forma simples, a automao do build pode ser descrita como o ato de
automatizar (por meio de ferramenta ou script) o processo de compilar o cdigofonte na sua forma binria. Com um processo de build manual, uma pessoa efetua
mltiplas tarefas que so normalmente entediantes e passveis de erro. O build
automatizado envolve a automao de uma variedade de tarefas que o
desenvolvedor de software precisa fazer nas suas atividades dirias, incluindo o

Gerenciamento

29

empacotamento do cdigo binrio, execuo dos testes e o deployment15 em um


servidor de produo. O objetivo deste tipo de automao criar um
procedimento de um nico passo para transformar cdigo-fonte em um sistema
funcional. Isto feito para poupar tempo e diminuir a quantidade de erros.
O propsito de uma ferramenta de build minimizar o tempo necessrio
para construir um programa usando as verses atuais do seu cdigo-fonte. Para
cada arquivo alvo do seu projeto, especificam-se as dependncias e como
constru-lo. Ferramentas de build tambm eliminam erros relacionados com a
inconsistncia de estado em que o cdigo-fonte pode estar; estas garantem que o
cdigo ser trazido para um estado consistente (McConnell, 2004).
Esta prtica pode ser dividida em trs categorias: 1) automao conduzida,
aquela que feita por cada desenvolvedor em sua estao de trabalho na linha
de comando ou usando uma IDE16 para verificar se o projeto em que est
PUC-Rio - Certificao Digital N 0511002/CA

trabalhando est sendo construdo corretamente; 2) automao agendada, feita por


uma ferramenta que executa o build em determinados momentos; ou 3) automao
disparada, quando o build feito de acordo com determinadas condies
(commit17 no sistema de controle de verses, por exemplo).
Builds automatizados so muito mais valiosos do que builds que precisam
de interveno humana. No decorrer do projeto, os prazos vo expirando e a
presso aumenta. Builds manuais tendem a ser feitos com menos freqncia e com
menos preciso, resultando em mais erros e maior apreenso. As prticas de XP
tentam reduzir essa apreenso. O uso de builds automatizados torna banal esta

15

O deployment de software toda atividade necessria para que um sistema seja

disponibilizado para uso (isso inclui compilao, construo, instalao e ativao, por exemplo).
16

IDE (do ingls Integrated Development Environment) ou Ambiente de Desenvolvimento

Integrado um programa de computador que rene caractersticas e ferramentas de apoio ao


desenvolvimento de software com o objetivo de agilizar este processo.
17

No contexto de cincia da computao, commit significa a idia de tornar um conjunto de

alteraes temporrias em modificaes permanentes. Em um sistema de controle de verses, o


commit significa enviar as alteraes feitas em uma estao de trabalho para um repositrio de
verses de arquivos.

Gerenciamento

30

atividade. Algum erro foi cometido? s executar o build e verificar (Beck &
Andres, 2004).
Se o processo de build no for automatizado, partes importantes do sistema
podem ser construdas e testadas inadequadamente. Por isso, esta a primeira
prtica que deve ser empregada em qualquer tipo de projeto, pois realmente
indispensvel. A automao do build tambm obrigatria para o funcionamento
da integrao contnua do sistema. Segundo a definio proposta em (Beck &
Andres, 2004), builds automatizados devem construir o sistema inteiro e test-lo
em dez minutos. Se demorar muito mais do que isso, o build no ser feito com a
freqncia necessria, limitando a oportunidade de obteno de feedback.
Mais do que simplesmente compilar o cdigo, algumas ferramentas de build
vo alm e permitem a gerncia do projeto em vrios sentidos. Algumas
ferramentas integram funcionalidades de verificao do cdigo de acordo com um
PUC-Rio - Certificao Digital N 0511002/CA

estilo, geram relatrios com mtricas e informaes sobre o projeto, gerenciam as


dependncias e produzem verses do programa.
Toda a configurao feita para automatizar o build tambm serve como
documentao. Na configurao ficam informaes como a localizao das
classes de teste, qual o tipo de empacotamento que deve ser feito para um
determinado projeto, onde o artefato final deve ser instalado e outras. Basta olhar
o build e todas essas informaes podem ser obtidas.
3.2.Ferramentas
Para que a automao do build seja alcanada, preciso que uma ferramenta
seja utilizada e configurada para executar as devidas tarefas. A ferramenta
escolhida deve ser rica o suficiente ao ponto de permitir, entre outras
funcionalidades, a produo dos artefatos, a execuo dos testes, o deployment em
um servidor remoto, a gerao de verses dos artefatos, a gerncia das
dependncias do projeto e a gerao de documentao.
Como a ferramenta de build ser responsvel pela realizao de muitas
tarefas fundamentais, mais cedo ou mais tarde o bom funcionamento do processo
de desenvolvimento estar totalmente dependente dela. Por isso, muito
importante definir bem qual a ferramenta ser empregada, pois esta ser crucial

Gerenciamento

31

para que as outras prticas funcionem. Uma restrio na ferramenta pode impedir
a utilizao de outras prticas.
Alm de ser completa naquilo que faz, importante que a ferramenta de
build se integre bem com o ambiente de desenvolvimento (IDE), mas que ao
mesmo tempo no seja dependente deste. Caso contrrio, muita perda de tempo
pode ocorrer.
Para o desenvolvimento Java, duas ferramentas so muito utilizadas para
automao: Ant e Maven.
3.2.1.Ant18
O Ant uma ferramenta que possibilita a automatizao do processo de
build. Neste sentido, o Ant muito parecido com a ferramenta Make19, mas ao

PUC-Rio - Certificao Digital N 0511002/CA

contrrio do Make, o Ant foi projetado especificamente para o desenvolvimento


Java. Um arquivo XML conhecido como buildfile especifica quais as tarefas
devem ser realizadas pelo Ant na hora de construir um projeto. Por meio de
classes Java, as tarefas do Ant so implementadas e podem realizar qualquer
operao permitida na linguagem Java. A API20 do Ant aberta e feita para ser
estendida; se for necessrio, qualquer pessoa pode escrever um novo tipo de tarefa
(Burke & Coyner, 2003).
O ciclo de construo e distribuio tambm deve ser automatizado para no
incorporar erros do operador. Escrever um script de build serve como
documentao do processo de construo do sistema. Possuir estes dados torna-se
crtico quando um desenvolvedor sai de uma empresa. Usando o Ant, a empresa
retm o conhecimento necessrio para distribuir o sistema, uma vez que o ciclo de
construo e distribuio est automatizado por um script Ant e no esquecido na
cabea do desenvolvedor que foi embora (Hightower et al., 2004).
18

http://ant.apache.org/

19

O Make um programa de computador concebido para compilar automaticamente o

cdigo fonte de um programa. Este utiliza instrues contidas num arquivo chamado "Makefile" e
capaz de resolver as dependncias do programa que se pretende compilar.
20

Application Programming Interface ou simplesmente API um conjunto de rotinas e

padres estabelecidos por um software para utilizao de suas funcionalidades. De modo geral, a
API composta por uma srie de funes acessveis somente por programao e que permitem
utilizar caractersticas do software menos evidentes ao usurio tradicional.

Gerenciamento

32

Outra vantagem de usar o Ant o formato do buildfile. Por ser escrito em


XML, fcil de ser lido e compreendido. Dessa forma, a configurao da
automao do processo de build e deploy torna-se uma documentao deste
processo. Onde os artefatos finais devem ser instalados? Onde est o cdigofonte? As classes de teste devem fazer parte do produto final? Basta olhar o script
e ver a resposta.

PUC-Rio - Certificao Digital N 0511002/CA

A seguir, um exemplo de um buildfile simples do Ant:


<project>
<target name="limpar">
<delete dir="classes"/>
</target>
<target name="compilar">
<mkdir dir="classes"/>
<javac srcdir="src" destdir="classes"/>
</target>
<target name="empacotar" depend="compile">
<mkdir dir="build"/>
<jar destfile="build/HelloWorld.jar" basedir="classes"/>
</target>
</project>

Neste exemplo so definidos trs objetivos:

limpar, compilar

empacotar.

Com esse script possvel compilar o cdigo-fonte de uma aplicao e gerar um


arquivo HelloWorld.jar simplesmente executando o comando ant

empacotar.

O Ant popular porque fcil de aprender e estender. Alm disso, muitas


IDEs e ferramentas de desenvolvimento suportam o Ant, como por exemplo o
Eclipse, Netbeans e JBuilder. Muitos projetos open source tambm utilizam Ant.
Por isso, o Ant tornou-se muito utilizado para a automao de projetos Java.
Uma boa ferramenta de build como o Ant decisiva para o sucesso no uso
das prticas de XP. No se pode esperar que uma equipe de programadores faa
refactoring do cdigo constantemente, execute os testes de unidade e integre suas
modificaes sem um ambiente de build previsvel e veloz (Burke & Coyner,
2003).
3.2.2.Maven21
Alm de controlar o processo de construo de um software, o Maven
oferece uma abordagem abrangente para gerenciar projetos de software. Desde a
compilao at a distribuio, incluindo documentao e colaborao entre a
21

http://maven.apache.org/

Gerenciamento

33

equipe, o Maven oferece as abstraes necessrias para encorajar o reuso e


diminuir muito do trabalho para fazer os builds de um projeto (Massol & Van Zyl,
2006).
O Maven baseado em quatro princpios fundamentais: 1) conveno ao
invs de configurao; 2) execuo declarativa, de acordo com o modelo de
projeto definido; 3) reuso da lgica de build por meio de herana; e 4)
organizao coerente das dependncias, por meio de repositrios locais e remotos.
O objetivo desta ferramenta sempre foi tornar mais fcil para os
desenvolvedores a tarefa de seguir mtodos geis, tornando um pouco difcil
escapar de algum deles (por exemplo, para que um build seja bem sucedido, no
basta que o cdigo compile corretamente, todos os testes tambm precisam

PUC-Rio - Certificao Digital N 0511002/CA

passar). Outros objetivos do Maven so:

Tornar o processo de build mais simples.

Oferecer um sistema de build uniforme.

Fornecer informaes sobre a qualidade do projeto.

Proporcionar um guia claro sobre o processo de desenvolvimento de


software.

Apresentar orientaes para a completa aplicao de prticas de teste.

Possibilitar uma visualizao coerente das informaes de um projeto.

Permitir uma migrao transparente para novas funcionalidades.


O Maven consegue satisfazer esses objetivos e continua sendo melhorado

graas a sua arquitetura baseada em plug-ins. Alguns benefcios proporcionados


por esta ferramenta so:

Layout dos projetos bem definido: A maioria dos projetos adere ao layout
bsico de um projeto, o que torna muito mais fcil para o desenvolvedor
navegar e procurar por itens em qualquer projeto. Projetos que seguem a
estrutura padro de diretrios precisam de menos configuraes.

Teste de unidade embutido: O plug-in do Maven para o JUnit oferece as


funcionalidades necessrias para que todos os testes de unidade de um
projeto sejam executados.

Visualizao do cdigo e dos relatrios: O Maven possui vrios relatrios


prontos para serem gerados de forma a ajudar a equipe a focar no projeto e

Gerenciamento

34

os problemas relacionados com ele. Todos estes relatrios podem ser


integrados na construo de um site com documentao sobre o projeto.

Integrao com outras tecnologias geis: O Maven inclui plug-ins para


cobertura de cdigo, controle de verso, formatao de cdigo, verificao
de violao de estilo de cdigo e rastreamento de bugs.
Por causa do conjunto de padres, do formato de repositrio para controle

de dependncias e do componente de software usado para gerenciar e descrever


projetos, qualquer pessoa que conhea a estrutura de um projeto que utiliza o
Maven ter muita facilidade para trabalhar em qualquer outro projeto controlado
por esta ferramenta. Essa uma das grandes vantagens em relao ao Ant.
Portanto, o uso dessa ferramenta altamente recomendado para qualquer tipo de
projeto.
O Maven fornece uma linguagem comum para descrio de projetos.
PUC-Rio - Certificao Digital N 0511002/CA

Sistemas que seguem essa abordagem declarativa tendem a ser mais transparentes,
mais reusveis e mais fceis de serem mantidos e compreendidos. Logo, se voc
pode construir um projeto usando o Maven, voc capaz de construir qualquer
outro projeto que use o Maven; se voc pode aplicar um plug-in de testes para um
projeto, ento possvel aplicar para todos os projetos. Voc descreve o seu
projeto usando um modelo do Maven e ganha acesso a particularidades e boas
prticas de uma comunidade inteira (Massol & Van Zyl, 2006).
A seguir, um arquivo POM (sigla para Project Object Model), modelo para
descrio de projetos do Maven:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>meu.grupo</groupId>
<artifactId>projeto-exemplo</artifactId>
<version>1.0</version>
<name>Projeto de Exemplo</name>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.0</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>

Neste arquivo so definidas informaes como: o nome do artefato


(artifactId), o nome do projeto (name), o tipo de artefato que deve ser gerado
(packaging) e as dependncias do projeto (dependencies), entre outras

Gerenciamento

35

informaes. Seguindo a estrutura proposta pelo Maven, com um arquivo simples


como esse, possvel compilar o cdigo-fonte, executar todos os testes, gerar o
artefato final (um arquivo JAR) e gerar uma documentao bsica sobre o projeto.
3.3.Precaues
Sem sombra de dvidas, o build automatizado o corao do
funcionamento de um projeto. Por isso, importante que todos os programadores
tenham um conhecimento razovel sobre a ferramenta de build que esto
utilizando. Uma dica comear por essa prtica antes de qualquer outra. Com o
build automatizado, menos tempo ser desperdiado.
E se a equipe no tiver tempo para aprender a usar uma nova ferramenta?
Ento ela ter que ter tempo para os problemas. Se a equipe for pequena e o

PUC-Rio - Certificao Digital N 0511002/CA

nmero de projetos grande (cinco desenvolvedores trabalhando em quatro


projetos, por exemplo), o problema ser ainda maior, pois praticamente cada
desenvolvedor ter que criar o seu arquivo de build, aumentando a possibilidade
de todos passarem repetidas vezes pelo mesmo problema.
Enquanto a equipe inteira no entender como usar a ferramenta de build
como uma parte integrada do ambiente de desenvolvimento de software, ela no
estar pronta para iniciar a primeira etapa do desenvolvimento (McBreen, 2002).
Se a equipe no tiver tempo suficiente para se familiarizar com as ferramentas,
ser muito fcil voltar para a forma como era feito anteriormente sem prticas
de XP o que pode facilmente significar a runa de um projeto (McBreen, 2002).
Algumas boas prticas com relao ao uso da ferramenta de build tambm
devem ser levadas em considerao:

O arquivo de build deve ficar no diretrio raiz do projeto. Algumas


ferramentas de build permitem que o arquivo de configurao de um
projeto fique em uma pasta dentro ou fora do projeto. Essa informao faz
parte da descrio do projeto, por isso deve estar dentro dele.
aconselhvel que o arquivo de build fique no diretrio raiz porque, assim,
quando for necessrio construir um projeto, basta ir para o seu diretrio raiz
e executar o comando especificado. Alm disso, qualquer pessoa que
obtenha o projeto j saber qual o tipo de ferramenta est sendo utilizada
apenas pelo nome do arquivo de build.

Gerenciamento

36

Usar convenes e um estilo consistente para estruturao do projeto e


configurao do arquivo de build. A liberdade que algumas ferramentas
oferecem para a definio de aes pode dar mais trabalho. Quando se tem
mais de um projeto, a mesma ao pode ser executada de forma diferente
em cada um deles. Por exemplo, a ao que limpa os arquivos gerados pode
ser executada de vrias formas diferentes:

clean, clear

ou

limpa.

Com o

uso do Maven este tipo de problema no existe. Devido aos padres


definidos, cada etapa do ciclo de construo tem um nome prdeterminado.

No se repetir (do ingls Dont Repeat Yourself). Esse uma das frases
adotadas pela turma de XP que implica em no permitir duplicao. No
caso dos builds, isso significa no ficar repetindo as mesmas configuraes
em vrios projetos. Algumas ferramentas, como o Maven, por exemplo,

PUC-Rio - Certificao Digital N 0511002/CA

permitem que a lgica de build seja reaproveitada por meio de herana das
configuraes.

Comentar os scripts de build, oferecendo ajuda para pessoas que no esto


familiarizadas com o projeto. Algumas ferramentas permitem que metadados sejam associados s tarefas que esto sendo realizadas. Escreva
mensagens que ajudem a esclarecer qual tipo de erro pode estar
acontecendo.

Gerenciar as dependncias apropriadamente com o uso de uma ferramenta


como o Maven.

Utilizar propriedades especficas do usurio para permitir que as


configuraes definidas por padro sejam sobrescritas, como, por exemplo,
localizao de diretrios e conexes com o banco de dados.

Manter o build independente de interveno humana. O build deve ser


completamente automatizado. A nica tarefa que pode ser manual a
inicializao do build, que pode ser feita por um desenvolvedor ou por uma
ferramenta de integrao.

Conservar a configurao do build em um sistema de controle de verses,


junto com o cdigo. Para construir um projeto em uma determinada etapa,
deve-se utilizar as configuraes daquele momento. Novas configuraes
podem ser incompatveis com o estado do projeto em uma fase anterior.

Gerenciamento

37

Alm disso, as configuraes de build, assim como o cdigo, vo evoluindo


com o decorrer do projeto. Isso significa que erros no build tambm podem
aparecer. Nestes casos, importante possuir maneiras de voltar atrs, para
uma verso que funcione.
O build automatizado promove um ganho muito grande de tempo, alm de
atenuar a preocupao com as tarefas de construo e distribuio de sistemas. Se
for decidido que mais nenhuma prtica de XP ser adotada, certamente a
automao do build no ser descartada. Apenas com o uso desta prtica, muito
tempo que antes era desperdiado ao fazer um build ou deployment manual poder

PUC-Rio - Certificao Digital N 0511002/CA

ser empregado em tarefas mais nobres.

Você também pode gostar