Ferramentas de Construção

Ferramentas de Construção
APACHE ANT MAVEN INTEGRAÇÃO CONTÍNUA

Apache Ant INTRODUÇÃO INSTALAÇÃO DESCRITOR PROJETO ALVOS TAREFAS
PROPRIEDADES EXEMPLO

Introdução Sistema de apoio à construção (building) escrito em Java;
Semelhante ao Make; Sem suas limitações para desenvolvimento multi-plataforma (diferentes sistemas operacionais); Descritores escritos em XML; Exibição de resultados em texto, XML, ,etc; Ampla variedade de comandos disponíveis; Extensível via classes Java; Utilizado pela maioria das IDEs de programação. Ant é uma ferramenta desenvolvida em Java que processa roteiros (scripts) escritos em XML. Vantagens: Automatiza tarefas rotineiras sendo utilizada na geração de builds, empacotamento, publicação, execução de testes, etc. Apresenta ampla variedade de comandos. É extensível via classes Java. Incorporado nas IDEs: Eclipse, NetBeans, JBuilder. Site Ant: Similar para .NET:

Introdução Make Ant rm -rf classes/ <delete dir="classes"/>
Utiliza arquivo makefile com formato específico. Utiliza comandos do sistema operacional disparados da própria shell, usualmente shell Linux. rm -rf classes/ Ant Utiliza descritores em formato XML. Resolve o problema de portabilidade do Make. Só necessita Java VM (1.1 ou superior). Tarefas podem ser customizadas e são descritas em Java (geralmente classes java ou jars). <delete dir="classes"/>

Instalação Home-Page:
(versão para .NET/Mono); Embutido em IDEs (Eclipse, NetBeans, JBuilder, etc.) Suporte para a interpretação de descritores; Suporte para a construção de descritores via wizards (em alguns casos); Instalação no Debian Linux: # apt-get install ant Nenhuma configuração é necessária!!!

Descritor Usualmente, os descritores de construção Ant são definidos via arquivo build.xml; Todo descritor de construção Ant é composto por três elementos principais: Project: Representa o projeto em questão; Target: Representa um alvo de construção (e.g.: compila, testa, empacota, etc.); Task: Representa uma tarefa específica a ser automatizada (e.g.: javac, ftp, ssh, cvs, junit, etc.) * * Project Target Task

Projeto Project é o elemento de mais alto nível de um descritor de construção; O elemento project é composto de: Nome do projeto; Alvo default do projeto; Diretório base; Sub-elemento de descrição; Exemplo: <project name="Alo Mundo" default="executa" basedir="."> <description>Projeto de teste do Ant.</description> ... </project>

Alvos Exemplo: Target representa os possíveis alvos de construção;
O elemento target é composto de: Nome do alvo; Dependências de execução; Condições (if e unless); Descrição sucinta; Exemplo: <target name="executa" depends="init,compila"> ... </target>

Alvos Um alvo é executado uma única vez;
Mesmo que exista mais de uma dependência; Todas as dependências são executadas antes do alvo em questão, na ordem informada; Exemplo: <target name="A"/> <target name="B" depends="A"/> <target name="C" depends="B,A"/> Resultado da execução de C: A,B,C;

Alvo Exemplo Suponha que o alvo D deve
<target name="A"/> <target name="B" depends="A"/> <target name="C" depends="A"/> <target name="D" depends="B,C"/> Suponha que o alvo D deve ser executado. Este alvo depende de B e C. C depende de A B depende de A Ordem da execução: ?

Alvo Exemplo Suponha que o alvo D deve
<target name="A"/> <target name="B" depends="A"/> <target name="C" depends="A"/> <target name="D" depends="B,C"/> Suponha que o alvo D deve ser executado. Este alvo depende de B e C. C depende de A B depende de A Ordem da execução: A, B, C, D

Características Ant pode fazer check-out do código-fonte armazenado no repositório do sistema de controle de versões CVS, Subversion, Synergy, Perforce, ClearCase and many more Ant pode compilar o código-fonte Ant pode rodar testes unitários e integrados JUnit3, JUnit4, TestNG, Selenium ou outra aplicação de testes Ant pode empacotar código-fonte jars, wars, ears, tars, zips, etc…

Tarefas Task representa tarefas a serem executadas em um alvo;
O elemento task é composto de: Nome da tarefa; Parâmetros para a sua execução; Tarefas são agrupadas em três tipos: Internas: incluídas no Ant; Opcionais: disponíveis via bibliotecas adicionais; Feitas pelo usuário; Exemplos: <javac srcdir="${src}" destdir="${build}"/>

Tarefas (Internas) Exemplos de tarefas internas existentes: Input;
Ant; BuildNumber; Copy; CVS; Delete; EAR; Echo; Exec; Input; Jar; Java; Javac; Javadoc; Mail; Mkdir; Move; SignJar; Sql; Tempfile; TStamp; Unzip; War; Xslt; Zip;

Tarefas (Opcionais) Exemplos de tarefas opcionais existentes: JspC;
.NET; Clearcase; Continuus; EJB; FTP; JavaCC; JspC; JUnit; JUnitReport; Perforce; Pvcs; Rpm; ServerDeploy; Scp; Sshexec; Starteam; Telnet; SourceSafe;

Propriedades São definidas no descritor de construção ou em um descritor auxiliar: build.properties; Representadas por tuplas nome/valor; Acessadas por ${nome}; Exemplo de propriedades pré-definidas: basedir; ant.project.name; Exemplos: <property file="${basedir}/build.properties"/> No build.properties: builddir = ${basedir}/build <property name="builddir" value="${basedir}/build"/>

Propriedades Propriedades podem definir:
o que precisa ser configurável o que pode vir a mudar no futuro, facilitando a manutenção o que pode ser utilizado em mais de um lugar Propriedades explicitamente definem a parte configurável do build. Diferentes versões do arquivo build.properties podem existir para diferentes contextos: plataformas ambientes sistemas operacionais desenvolvedores

Exemplo Sistema simples em Java (SE): Alvos definidos:
Código fonte em “src”; Código compilado e biblioteca em “build”; Alvos definidos: Init; Compila; Executa; Clean;

Exemplo Propriedades (build.properties): Projeto (build.xml):
mainclass = AloMundo srcdir = ${basedir}/src builddir = ${basedir}/build Projeto (build.xml): <project name="Alo Mundo" default="executa" basedir="."> <description>Projeto de teste do Ant.</description>  <property file="${basedir}/build.properties" />

Exemplo Alvo init: Alvo compila: <!– ALVO INIT -->
<target name="init"> <mkdir dir="${builddir}" /> </target> Alvo compila:  <target name="compila" depends="init"> <javac srcdir="${srcdir}" destdir="${builddir}" />

Exemplo Alvo executa: Alvo clean: 
<target name="executa" depends="init,compila"> <java classname="${mainclass}"> <classpath path="${builddir}"/> </java> </target> Alvo clean:  <target name="clean"> <delete dir="${builddir}"/>

Exemplo Utilização (1ª execução): $ ant Buildfile: build.xml init:
[mkdir] Created dir: /alomundo/build compila: [javac] Compiling 1 source file to /alomundo/build executa: [java] Alo Mundo!!! BUILD SUCCESSFUL Total time: 2 seconds

Exemplo Utilização (demais execuções): $ ant Buildfile: build.xml
init: compila: executa: [java] Alo Mundo!!! BUILD SUCCESSFUL Total time: 1 second

Exemplo Utilização do Ant na IDE Eclipse

Gestão de dependencias Repositorio organizacional
Maven historico Ant x maven Caracteristicas Ciclo de vida Fase Meta (Goal) plugin Gestão de dependencias Repositorio organizacional

Introdução Gerenciador de “builds”. Gerenciador de dependências.
Controla a transformação de itens fonte em itens derivados. Gerenciador de dependências. Faz a gestão de dependências dos módulos envolvidos. Calcula as dependências transitivamente. Gerador de documentação.

Introdução Ferramenta que controla a construção do software, baseada em alguns princípios: Convenção ao invés de configuração. Execução declarativa de acordo com o modelo de projeto definido. Reuso da lógica de build por meio de herança. Organização das dependências por meio de repositórios locais e remotos. Arquitetura baseada em plugins. Portabilidade.

Histórico Make (1979) ... Ant (2000) Maven (2004)

Ant x Maven Ant Maven Fortemente baseada em configuração Procedural
Processo de construção e ferramentas utilizadas ficam misturados Maven Convenção sobre Configuração Declarativo Existência de um processo padrão

Vantagens em relação ao ant
Conjunto de padrões Maven também tem como objetivo padronizar as estruturas dos projetos para que eles possam ser compreendidos mais facilmente. Maven tem, por exemplo, uma estrutura básica de diretórios. Repositório para controle de dependências. Ant precisa definir e guardar as dependências dentro do seu projeto ou apontar diretamente para elas no sistema de arquivos, já o Maven define todas as dependências de uma única maneira (no POM) e a ferramenta se encarrega de fazer com que ela esteja disponível na sua aplicação. Facilidade para gerência de projetos. Maven gerencia as “dependências das dependências” do projeto. Frameworks como o Hibernate utilizam várias outras bibliotecas e em outras ferramentas seria necessário definir todas estas dependências direto na sua configuração, com o Maven, ele utiliza a própria descrição da dependência (o seu POM) para descobrir quais são as suas dependências e as traz junto para o projeto.

Repositório

Repositório Armazenam artefatos declarados nas dependências.
Dois repositórios: local e remoto. Repositório local: ~/.m2/repository Estrutura: /repository /groupId /artifactId /version artifactId-version.jar artifactId-version.pom Repositório central: Maven assume automaticamente que a dependência é um arquivo “.JAR”.

Elementos básicos POM (Project Object Model) Ciclo de vida (lifecycle)
Descritor XML da estrutura de um projeto Ciclo de vida (lifecycle) Processo de construção Ex.: compile  test  package  install  deploy Fase (phase) Passo do processo de construção Ex.: compile Plug-in Ferramenta utilizada no processo de construção Ex.: scm Meta (goal) Funcionalidade provida por uma ferramenta Ex.: scm:checkin

Elementos básicos Ciclo de vida Fase * 1 * 1 Meta Plug-in * 1

Plugins Meios de extensão para o Maven.
São configurados dentro do POM. Existem mais de 80 plugins oficiais catalogados. Tasks do Ant podem ser invocadas pelo Maven. Documentação sobre plugins disponíveis: Plugins para: cobertura de código: Clover, Cobertura. controle de versão: CVS, Subversion verificação de violação de estilo de código: CheckStyle controle de modificações: bugzilla, JIRA

Ciclo de Vida x Fase x Meta
Plugin 1 Fase 1 Meta 2 Fase 2 Meta 1 Fase 3 Meta 2 Plugin 2 ... Meta 3 Fase N ... Ciclo de Vida

Plugins Define um plugin utilizado pelo Maven.
Tem associado alvos específicos para execução. Exemplo: <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-javadoc-plugin</artifactId> <version>2.0-beta-2</version> <executions> <execution> <phase>process-classes</phase> <goals> <goal>javadoc</goal> </goals> </execution> </executions> </plugin> </plugins>

Dependências Dependência deve ser provida no projeto caso seja necessária para executar alguma função. Armazenadas no repositório (local e remoto). São transitivas. Atualizadas automaticamente pelo Maven. <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies>

Dependências compile – A dependência fica disponível durante todas as fases do projeto, desde a compilação até a instalação do sistema. Deve ser utilizada para dependências que são chamadas diretamente pelo código. Este é o escopo padrão do Maven quando nenhum escopo é definido (o nó <scope/> em uma dependência é opcional). provided – A dependência está disponível para compilação mas em tempo de execução ela deve ser disponibilizada pelo ambiente no qual a aplicação está executando.

Dependências runtime – É o contrário de provided, a dependência não está disponível em tempo de compilação mas é enviada junto com o projeto em tempo de execução, normalmente é utizada para bibliotecas que são carregadas dinamicamente (como drivers JDBC) e que não precisam estar disponíveis para que o sistema seja compilado. test – A dependência só vai estar disponível para a execução dos testes do sistema e não vai ser enviada junto com a aplicação. Deve ser utilizada para bibliotecas que são utilizadas apenas para testar o sistema, como a biblioteca do JUnit. system – Indica que a dependência não estará disponível no repositório do Maven e sua localização deve ser fornecida dentro do POM.

Dependências e Herança
Dependências definidas no POM não precisam ser definidas novamente naqueles que tem relacionamento de herança.

Herança X Módulo

Funcionalidades do Maven
Geração da estrutura do projeto Gestão do processo de construção Gestão de dependências Utilização de repositório organizacional Geração do site do projeto

Geração da Estrutura do Projeto
Problema: “Onde cada artefato do projeto deve ser colocado?” Maven permite gerar o esqueleto do projeto (layout) aderente às suas convenções Fornece 292 layouts, dentre eles: Aplicação Java, Groovy, Ruby, Scala Site web Documento DocBook e LaTeX Maven Archetype (ou seja, é possível criar o seu próprio layout)

Geração da Estrutura do Projeto (exemplo de geração)
$ mvn archetype:generate [80: remote -> maven-archetype-quickstart (An archetype which contains a sample Maven project.)] ... Define value for property 'groupId': : uff Define value for property 'artifactId': : teste Define value for property 'version': 1.0-SNAPSHOT: Define value for property 'package': uff: O que foi gerado? pom.xml src/main/java/uff/App.java src/test/java/uff/AppTest.java

Geração da Estrutura do Projeto (geração no Eclipse)

Geração da Estrutura do Projeto (geração no NetBeans)

Geração da Estrutura do Projeto (pom.xml)
<project ...> <modelVersion>4.0.0</modelVersion> <groupId>uff</groupId> <artifactId>teste</artifactId> <version>1.0-SNAPSHOT</version> <packaging>jar</packaging> <name>teste</name> <url> <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> </dependencies> </project>

Geração da Estrutura do Projeto (edição do POM no Eclipse)

Geração da Estrutura do Projeto (edição do POM no NetBeans)

Geração da Estrutura do Projeto (src/main/java/uff/App.java)
package uff; /** * Hello world! * */ public class App { public static void main( String[] args ) System.out.println( "Hello World!" ); }

Geração da Estrutura do Projeto (src/test/java/uff/AppTest.java)
package uff; import junit.framework.Test; import junit.framework.TestCase; import junit.framework.TestSuite; /** * Unit test for simple App. */ public class AppTest extends TestCase { (...) * Rigourous Test :-) public void testApp() assertTrue( true ); }

Geração da Estrutura do Projeto (convenção geral de estrutura)
src/main/java Código fonte da aplicação (no exemplo, código java) src/main/resources Recursos da aplicação (imagens, sons, etc.) src/test/java Código de teste (no exemplo, testes junit) src/test/resources Recursos de teste src/site Site do projeto target Diretório com arquivos gerados pelo processo de build LICENSE.txt Licença do projeto README.txt Visão geral do projeto pom.xml Descritor Maven do projeto

Gestão do Processo de Construção
Problema: “Como posso construir o projeto?” Maven permite utilizar um processo padrão para construção do projeto Processo composto das seguintes fases (dentre outras): Compilação Testes Empacotamento

Comandos Básicos do Maven
Descrição mvn compile Compila o código fonte do projeto. mvn package Cria um arquivo, por exemplo, jar, para o projeto. mvn site Gera um site com a documentação do projeto. mvn clean Remove os diretórios criados pelo Maven no processo de build. mvn test Roda os testes unitários. mvn integration-test Executa os testes de integração (os que são feitos com a aplicação empacotada e implantada em um container). mvn install Instala o artefato gerado no repositório local do Maven. mvn deploy Envia o artefato gerado para um servidor remoto para que ela seja implantado.

Gestão do Processo de Construção (exemplo de compilação)
$ mvn compile [INFO] Scanning for projects... [INFO] [INFO] Building teste [INFO] task-segment: [compile] [INFO] [compiler:compile {execution: default-compile}] [INFO] Compiling 1 source file to C:\Users\leomurta\workspace\teste\target\classes [INFO] BUILD SUCCESSFUL [INFO] Total time: 3 seconds [INFO] Finished at: Sat Oct 16 11:47:39 BRT 2010 [INFO] Final Memory: 15M/130M

Gestão do Processo de Construção (exemplo de teste)
$ mvn test ... [INFO] [compiler:compile {execution: default-compile}] [INFO] Nothing to compile - all classes are up to date [INFO] [compiler:testCompile {execution: default-testCompile}] [INFO] Compiling 1 source file to target\test-classes [INFO] [surefire:test {execution: default-test}] [INFO] Surefire report directory: C:\Users\leomurta\workspace\teste\target\surefire-reports T E S T S Running uff.AppTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: sec

Gestão do Processo de Construção (exemplo de empacotamento)
$ mvn package ... [INFO] [compiler:compile {execution: default-compile}] [INFO] Nothing to compile - all classes are up to date [INFO] [compiler:testCompile {execution: default-testCompile}] [INFO] [surefire:test {execution: default-test}] [INFO] Surefire report directory: target\surefire-reports [INFO] [jar:jar {execution: default-jar}] [INFO] Building jar: target\teste-1.0-SNAPSHOT.jar

Gestão do Processo de Construção (integração com o Eclipse)

Gestão do Processo de Construção (integração com o NetBeans)

Gestão do Processo de Construção (fases mais comuns)
validate: verifica se o projeto está correto e se os dados estão disponíveis compile: compila o código do projeto test: executa testes de unidade package: empacota o código compilado em um formato apropriado (ex.: jar) integration-test: implanta o pacote em um ambiente apropriado e executa testes de integração verify: executa verificações de qualidade sobre o pacote install: instala o pacote no repositório local deploy: disponibiliza o pacote em um repositório remoto clean: remove artefatos criados por processos anteriores de construção site: gera o site do projeto

Gestão de Dependências
Problema: “Como lidar com situações onde o projeto depende de bibliotecas externas?” Maven permite definir dependências para um projeto As dependências são definidas no pom.xml O Maven calcula as dependências considerando transitividade As dependências são baixadas de repositórios centrais por demanda

Gestão de Dependências (definindo dependência no pom.xml)
<project ...> ... <dependencies> <dependency> <groupId>axis</groupId> <artifactId>axis</artifactId> <version>1.4</version> <scope>compile</scope> </dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependencies> </project>

Gestão de Dependências (vendo dependências transitivas)
$ mvn dependency:tree ... [INFO] [dependency:tree {execution: default-cli}] [INFO] uff:teste:jar:1.0-SNAPSHOT [INFO] +- axis:axis:jar:1.4:compile [INFO] | +- org.apache.axis:axis-jaxrpc:jar:1.4:compile [INFO] | +- org.apache.axis:axis-saaj:jar:1.4:compile [INFO] | +- axis:axis-wsdl4j:jar:1.5.1:runtime [INFO] | +- commons-logging:commons-logging:jar:1.0.4:runtime [INFO] | \- commons-discovery:commons-discovery:jar:0.2:runtime [INFO] \- junit:junit:jar:3.8.1:test

Gestão de Dependências (vendo dependências no Eclipse)

Gestão de Dependências (vendo dependências no NetBeans)

Gestão de Dependências (compilando com dependências)
$ mvn compile ... Downloading: Downloading: Downloading: Downloading: Downloading: [INFO] [compiler:compile {execution: default-compile}] [INFO] Compiling 1 source file to target\classes

Utilização de Repositório Organizacional
Problema: “Como disponibilizar para outros projeto bibliotecas criadas na própria organização?” Maven permite definir repositórios que pertencem à organização Funcionam como cache dos repositórios centrais Permitem que qualquer projeto Maven seja publicado no repositório Permitem que projetos Maven acessem suas bibliotecas

Utilização de Repositório Organizacional (topologia)
Empresa X Internet Computador A Repositório Central Rep. local Repositório Organizacional Repositório Empresa Y Computador B Rep. local

Utilização de Repositório Organizacional (comandos install e deploy)
Empresa X Computador A espaço de trabalho Repositório Organizacional mvn install Rep. local mvn deploy

Utilização de Repositório Organizacional (instalação do Nexus)

Utilização de Repositório Organizacional (configuração do POM)
<project ...> ... <distributionManagement> <snapshotRepository> <id>repo-gems-snapshot</id> <name>Repositorio de Snapshots</name> <url> </snapshotRepository> <repository> <id>repo-gems</id> <name>Repositorio de Releases</name> <url> </repository> </distributionManagement> </project>

Utilização de Repositório Organizacional (configuração do ~/
Utilização de Repositório Organizacional (configuração do ~/.m2/settings.xml) <settings ...> <mirrors> <mirror> <id>gems</id> <mirrorOf>*</mirrorOf> <url> </mirror> </mirrors> <servers> <server> <id>repo-gems-snapshot</id> <username>deployment</username> <password>******</password> </server> <id>repo-gems</id> ... </servers>

Utilização de Repositório Organizacional (implantação de biblioteca)
$ mvn deploy ... [install:install] Installing target\teste-1.0-SNAPSHOT.jar to C:\Users\leomurta\.m2\repository\uff\teste\1.0-SNAPSHOT\teste-1.0-SNAPSHOT.jar [deploy:deploy] Uploading: Uploading repository metadata for: 'artifact uff:teste' Uploading project information for teste Uploading repository metadata for: 'snapshot uff:teste:1.0-SNAPSHOT‘

Utilização de Repositório Organizacional (biblioteca implantada)

Utilização de Repositório Organizacional (implantação de biblioteca)
$ mvn compile ... Downloading: pom 2K downloaded (axis-1.4.pom) Downloading: .4/axis-jaxrpc-1.4.pom 280b downloaded (axis-jaxrpc-1.4.pom) Downloading: /axis-saaj-1.4.pom 278b downloaded (axis-saaj-1.4.pom) Downloading: /axis-wsdl4j pom 149b downloaded (axis-wsdl4j pom)

Geração do Site do Projeto
Problema: “Como criar um site com dados técnicos sobre o projeto?” Maven permite gerar automaticamente um site com os dados principais do projeto Equipe Bibliotecas utilizadas Resultados dos testes Repositório de código fonte Repositório de solicitações de modificação

$ mvn site ... [INFO] [site:site {execution: default-site}] [INFO] artifact org.apache.maven.skins:maven-default-skin: checking for updates from central [INFO] Generating "About" report. [INFO] Generating "Issue Tracking" report. [INFO] Generating "Project Team" report. [INFO] Generating "Dependencies" report. [INFO] Generating "Continuous Integration" report. [INFO] Generating "Source Repository" report. [INFO] Generating "Project License" report. [INFO] Generating "Mailing Lists" report. [INFO] Generating "Plugin Management" report. [INFO] Generating "Project Summary" report.

Referências Sonatype, 2008, “Maven: The Definitive Guide”, O’Reilly
Walter dos Santos Filho, 2008, “Introdução ao Apache Maven”, Eteg Tecnologia da Informação Ltda

BUILDS LENTOS X RAPIDOS PRINCIPIOS DA INTEGRAÇÃO CONTÍNUA
INTRODUÇÃO AGENDAMENTOS BUILDS LENTOS X RAPIDOS PRINCIPIOS DA INTEGRAÇÃO CONTÍNUA BUILD PIPELINE VANTAGENS RECOMENDAÇÕES

Integração Contínua http://www. martinfowler
Prática de desenvolvimento de software em que os membros de uma equipe integram o seu trabalho freqüentemente. Pré-requisito para que a posse do código seja compartilhada. Cada integração é verificada por um build automatizado para detectar erros de integração o mais cedo possível.

Como funciona?

Successful build Deve ser feito “check out” do último fonte disponível no Controle deVersões. Todo arquivo deve ser compilado. Toda a suite de teste deve ser executada. Se todos estes passos são executados sem erro (quebra) ou intervenção humana e todos os testes passam (sem quebra lógica) então temos um build com sucesso.

Vantagens Integração Contínua
Cada integração é verificada por um build automatizado. Os erros podem ser detectados o mais rápido possível. Exibe advertências sobre código incompatível ou não compilável. Leva a uma redução significativa dos problemas de integração. Permite que a equipe desenvolva sistemas coesos mais rapidamente. Informa sobre a condição do código produzido utilizando métricas e verificações oferecidas pelas ferramentas de build automatizado.

Vantagens Integração Contínua
Problemas são detectados e corrigidos continuamente. Advertências sobre código incompatível ou não compilável. Testes de unidade executados para todas as alterações. Disponibilidade permanente da versão corrente para testes. Demonstração e Distribuição.

Builds Rápidos e Lentos
O que é um build? É mais do que compilar. É compilar, testar, inspecionar, reconstruir o banco com dados de teste, testar de forma integrada, empacotar o software e fazer o deploy. Significa construir o projeto e empacotar o fonte verificando se o software funciona de forma coesa conforme o esperado. Automatizando o build, tudo pode ser feito com um click de botão.

Builds Rápidos e Lentos

Agendamentos * * 0 16,18,20,22 * * * 42 16 * * *

Principios da Integração Continua
Práticas de Integração Contínua Maintain a Single Source Repository Automate the Build Make Your Build Self-Testing Everyone Commits To the Mainline Every Day Every Commit Should Build the Mainline on an Integration Machine Keep the Build Fast Test in a Clone of the Production Environment Make it Easy for Anyone to Get the Latest Executable Everyone can see what's happening Automate Deployment

Maintain a Single Source Repository
Tudo deve ficar armazenado no repositório de Controle de Versões: tudo que for suficiente para que seja possível a partir de um checkout do repositório fazer o build em uma nova máquina. Tenha uma mainline (trunk): um ramo que tenha a versão atual em desenvolvimento.

Automate the Build É importante que o build seja executado em um servidor de integração contínua por meio de uma linha de comando. mvn clean install Um script de build deve permitir targets alternativos para diferentes configurações de testes ou diferentes ambientes. mvn install -P local mvn install -P integracao-continua -P desenv

Make Your Build Self-Testing
Use TDD, Test Driven Development. Deve ser possível com um simples comando verificar o fonte e visualizar se os testes falharam. Uma vez que o código fonte é testável (self-testing code) e tem um bom nível de cobertura, use ferramentas como Selenium, FITnesse que permitem testar em todos os níveis/camadas da aplicação (end-to-end testing).

Everyone Commits To the Mainline Every Day
Um dos pré-requisitos para o commit na mainline é que o build tenha sucesso inclusive nos testes. Deve-se fazer update local e fazer o merge das suas modificações com a mainline. Após, deve-se executar o build na sua máquina local. Somente se o build tiver sucesso, inclusive nos testes, então o commit na mainline pode ser realizado. Na integração continua cada commit é considerado uma release candidata.

Every Commit Should Build the Mainline on an Integration Machine
Quanto mais frequente for o commit relacionado às pequenas entregas ou tarefas, menores são os conflitos e em caso de bugs mais cedo será possível consertá-los.

Keep the Build Fast O build deve ser rápido uma vez que a Integração Contínua demanda constantes commits, isso pode aumentar a fila de builds a serem executados no servidor de integração contínua. Separação dos builds rápidos e lentos.

Test in a Clone of the Production Environment
O ambiente de teste deve ser idêntico ao de produção Hardware IP e portas Bibliotecas Versão do software Versão do sistema operacional Para montar estes ambientes, a virtualização traz ganhos. Instalar a última versão do software e executar os testes deve ser fácil.

Automate Deployment Build pipeline ou deployment pipeline traz a idéia de múltiplos builds em sequência – Continuous Delivery...

Everyone can see what's happening

Recomendações Versione o código frequentemente
Pelo menos uma vez ao dia. Não versione código quebrado Não versione código que não compila ou não passa nos testes. Conserte builds quebrados imediatamente Embora seja responsabilidade do time, o desenvolvedor que versionou por último deve estar envolvido em consertar o bug. Escreva testes automatizados Execute todos os testes com build automatizado e no servidor de integração contínua. Todos os testes e inspeções devem passar com sucesso Todos (100%) devem passar antes do versionamento (commit) do código.

Recomendações Execute builds privados Evite pegar código quebrado
Faça update das modificações de outros desenvolvedores na mainline e execute um build privado localmente. Evite pegar código quebrado Se o build falhar, ajude o desenvolvedor a consertar o erro e então, atualize sua cópia local com a última versão do Controle de Versões.

Referências

Outras ferramentas que valem o estudo
Cmake Atualmente utilizado no SIGEO (TGEO) Integrado com ferramentas de Integração Contínua: Jenkins.

Gradle: Porque outra ferramenta de build?
Radar Tecnológico da ThoughtWorks Vale a visita: Gradle está em Adopt, Maven está em Hold “Language-based build tools like Gradle and Rake continue to offer finer-grained abstractions and more flexibility long term than XML and plug-in based tools like Ant and Maven. This allows them to grow gracefully as projects become more complex.”

Avaliando o radar Para ferramentas de Controle de Versão
“We continue to see teams run into productivity problems attempting to use TFS as a version control system. Teams that want to practice frequent code checkins, a core part of continuous integration, have found its heavyweight approach significantly drains productivity. This often leads to teams checking in less frequently, causing more problematic merges. We recommend tools such as Git, Perforce, and Subversion instead.”

Gradle INTRODUÇÃO CARACTERISTICAS DECLARATIVO X IMPERATIVO
CONVENÇÕES X ADAPTABILIDADE CONFIGURAÇÕES TAREFAS PLUGINS DEPENDÊNCIAS INTEGRAÇÃO COM MAVEN E NEXUS VANTAGENS X DESVANTAGENS 110

Introdução Maven x Ant e Ivy x Gradle
111 Maven x Ant e Ivy x Gradle Flexibilidade com a perspectiva de automatização de deploy e build pipeline. Dificuldades com Maven: Modificar ciclo de vida; Escrever plugins para Maven; Projetos multi-módulos: no Maven são projetos independentes utilizando o conceito de agregação. Cada módulo tem uma versão e um só artefato. Cristine e Matheus 111

Introdução https://community.jboss.org/wiki/GradleWhy
112 Spring, Hibernate, Grails são exemplos de projetos que utilizam Gradle. Cristine e Matheus 112

Quais são as diferenças?
Introdução 113 Quais são as diferenças? 113

Declarativo x Imperativo
114 Declarativo Imperativo Cristine ou Matheus 114

Declarativo x Imperativo
115 Declarativo javadoc { options.memberLevel = org.gradle.external.javadoc.JavadocMemberLevel.PROTECTED options.author = true options.header = project.name options.encoding = 'UTF-8' excludes = ["br/com/petrobras/ep/pi/**"] } Imperativo task geraChangeLog() { description = 'Gera o changelog do Mercurial.' ext.outputFile = file("${sourceSets.main.output.resourcesDir}/changelog.txt") doLast() { project.exec { executable = 'hg' args = ['log'] standardOutput = new FileOutputStream(outputFile) Cristine ou Matheus 115

Convenções x Adaptabilidade
116 Convenções Adaptabilidade Cristine ou Matheus 116

Convenções Convenção sobre Configuração Convenção e Significado
117 Convenção sobre Configuração Convenção e Significado src/main/java – código fonte src/main/resources – resources Como modificá-la? sourceSets { main { java {srcDir 'src/java’} resources {srcDir 'src/resources’} } Cristine ou Matheus 117

Características 118 Usa uma linguagem de domínio específico (DSL) em Groovy. Permite customizar o build com base na API do gradle e criar regras de configuração. Gradle daemon (--daemon): otimiza o processo de build. Gradle API: Cristine e Matheus 118

Características que vieram de:
119 Ivy Configurações. Maven Convenções, Resolução de dependências, Plugins. Ant Invocar tasks do Ant, Directed Acyclic Graph. Cristine 119

Configurações 120 configurations { cxf } dependencies {
// dependencias do cxf para a geracao do codigo cliente do webservice cxf 'org.apache.cxf:cxf-tools-wsdlto-core:2.6.1' cxf 'org.apache.cxf:cxf-tools-wsdlto-frontend-jaxws:2.6.1' cxf 'org.apache.cxf:cxf-tools-wsdlto-databinding-jaxb:2.6.1' task generateWsdl (type: JavaExec) { ext.urlServico =' classpath = files(configurations.cxf.files) main = 'org.apache.cxf.tools.wsdlto.WSDLToJava' args = ["-d", outputDir, "-p", "br.com.petrobras.ep.wsdl", urlServico] Matheus 120

Directed Acyclic Graph
121 Cristine

Tarefas É um objeto, Tem atividades, usa Gradle API. 122
task geraChangeLog() { description = 'Gera o changelog do Mercurial.' ext.outputFile = file("${sourceSets.main.output.resourcesDir}/changelog.txt“) doLast() { // via linha de comando: hg log > changelog.txt project.exec { executable = 'hg' args = ['log'] standardOutput = new FileOutputStream(outputFile) } jar.dependsOn(geraChangeLog) Cristine 122

Pode invocar tasks do Ant?
123 def run() { getOutputDir().mkdirs() getConfig().resolve().each { file -> logger.info("Assinando arquivo: " + file.name) ant.signjar(destDir: getOutputDir(), jar: file, alias:"signFiles", keystore:getKeystoreFile(), keypass:"smart01", storepass:"smart01", preservelastmodified:"true", force:"true") } Matheus 123

Plugins 124 A automatização do build é feita por plugins, como por exemplo, no plugin java: Tarefas: compileJava e processResources. Objetos de domínio: SourceSet. Convenções: código java está em src/main/java e classes compiladas em build/classes/main. Configurações de dependência: compile, runtime, testCompile, testRuntime. apply plugin: ‘java’ Matheus 124

Cobertura Plugin 125 buildscript { repositories { maven {
name "Nexus Repo" credentials { username = 'snepuser' password = 'snep' } url " dependencies { classpath 'com.mapvine:gradle-cobertura-plugin:0.2' Cristine 125

Cobertura Plugin subprojects { subproject ->
126 subprojects { subproject -> apply plugin: 'cobertura' cobertura { sourceDirs = sourceSets.main.allJava.srcDirs format = 'xml' includes = ['**/*.java'] } Cristine

Integração com Maven e Nexus
127 Publica em repositórios maven e faz download e cache dos artefatos a partir de repositórios maven central ( ou utilizando nexus ). Cache (considera o cache do Maven, .m2) antes de fazer download de dependências. Mecanismos para migração do Maven para gradle. Processo Incremental e modular. maven2gradle Matheus 127

128 repositories { mavenCentral() } // repositorios repositories { maven { name "Nexus Repo" credentials { username = 'snepusername' password = 'sneppassword' } url " Matheus

129 apply plugin: 'maven' uploadArchives { repositories { mavenDeployer { name = 'sshDeployer' uniqueVersion = false configuration = configurations.deployerJars repository(url: "scp://snepmaven.ep.petrobras.com.br/dados/maven/maven2") { authentication(userName: snepmavenUsername, password: snepmavenPassword) } Matheus

Dependências 130 dependencies {
groovy 'org.codehaus.groovy:groovy-all:2.0.1' } dependencies { // hibernate compile 'org.hibernate:hibernate- core:3.6.3.Final' } Matheus // vivid solutions (georeferencia) compile ('com.vividsolutions:jts:1.12') { exclude group: 'xerces' } // modulos ClarityUnidade e ClarityShared compile project(':ClarityUnidade') compile project(':ClarityShared') 130

Definir/Modificar o Ciclo de vida
131 task sourcesJar(type: Jar, dependsOn: classes) { description = "Generates de JAR with all source code." classifier = 'sources' from sourceSets.main.allJava.srcDirs include '**/*.java' } artifacts { tests testJar archives testJar archives sourcesJar archives javadocJar Matheus 131

Projetos Multi-módulos
132 settings.gradle build.gradle include "ClarityTestBase", "ClarityUnidade", "ClarityShared", "ClarityServer", "ClarityClient", "ClarityWar", "ClarityIntegrationTests" allprojects { // plugins para todos os projetos apply plugin: 'idea' apply plugin: 'maven‘ /* constantes */ group = 'br.com.petrobras.ep.clarity' version = '1.1-SNAPSHOT‘ .... } Cristine 132

Projetos Multi-módulos
133 Todos os módulos são considerados projetos (Project). build.gradle subprojects { subproject -> apply plugin: 'groovy' apply plugin: 'cobertura‘ test { jvmArgs '-XX:MaxPermSize=512m' def groupsToExclude = subproject.config.testGroupsToExclude useTestNG() { excludeGroups groupsToExclude } // Tenta resolver o erro de nao rodar testes abstratos. scanForTestClasses = false include 'br/com/petrobras/**/*Test.class' Cristine 133

Vantagens Webinar Ótima documentação Otimizado
134 Webinar Ótima documentação Otimizado Tarefas definidas com entrada e saída (inputs e outputs). Usa uma linguagem de domínio específico (DSL) em Groovy ao invés de xml. Projetos multi módulos Simples para o desenvolvimento de plugins comparativamente ao Maven. Facilidade e ferramentas para migrar do Maven. Cristine e Matheus 134

Desvantagens Aprendizado com groovy.
135 Aprendizado com groovy. Aprendizado da DSL do Gradle quando foge do “feijão-com-arroz”. Menos plugins disponíveis comparativamente ao Maven. Quebra de contrato: Por ser recente, muda a sintaxe de uma versão para outra. Gradle wrapper Atualmente na release 1.6. Cristine e Matheus 135

Referências http://www.gradle.org/ http://www.gradle.org/documentation
136 136

Integração Contínua e One-Click Deployment

Integração Contínua com Jenkins
Controle de versão: Mercurial, TFS (plugins instalados no jenkins) e Subversion. Construção e Empacotamento: maven, gradle, grails. Repositório de Binários/Artefatos: repositório interno maven - snepmaven. Build = traz o código modificado no controle de versões (mainline) + download das dependências por meio do nexus + compila o código + executa testes unitários automatizados + empacota + faz deploy no snepmaven.

Sobre Testes Testes funcionais devem ignorar a estrutura interna do sistema e focar apenas na funcionalidade (entradas e saídas do ponto de vista do negócio). Testes não-funcionais consideram características de qualidade do sistema como, por exemplo, usabilidade, segurança e desempenho. Testes de unidade executam uma classe inteira, método ou um pequeno programa – ou seja, a menor unidade de desenvolvimento possível –, o qual é testado isoladamente do todo (ou um sistema mais completo).

Sobre Testes Testes de integração Normalmente, as falhas no nível de testes de integração estão relacionadas ao envio e recebimento de dados entre eles, ou seja, as suas interfaces. Testes de aceitação são semelhantes aos funcionais, mas enquanto os funcionais estão relacionados a verificar se algum requisito está sendo executado da forma correta, os de aceitação preocupam-se em avaliar se os requisitos estão presentes.

Estado ATUAL Repositório de Artefatos -snepmaven
Governança de Artefatos e repositórios - Nexus Metadata Binario Metadata Binario Binario Build Rápido Compilação Testes unitarios Empacotamento Install Deploy – binário no Repositório Artefatos Build Lento Compilação Testes Unitários Testes de Aceitação Testes de integração Cobertura Sonar Deploy - DSV Deploy – binário em DSV Smoke Test snepciserver – equipe configura e executa jobs, jobs agendados Código-fonte Código-fonte SVN Mercurial Controle de Versões

Estado FUTURO Repositório de Artefatos -snepmaven
Governança de Artefatos e repositórios - Nexus Metadata Binario Metadata Binario Binario Build Rápido Compilação Testes unitarios Empacotamento Install Deploy – binário no Repositório Artefatos Build Lento – Testes de Aceitação Análise Estatica e Estatisticas Compilação Testes Unitários Testes de Integração Cobertura Sonar Deploy - DSV Deploy – binário em DSV Smoke Test middeployer - equipe executa, infra configura snepciserver – equipe configura e executa jobs, jobs agendados snepciserver – equipe configura e executa jobs, jobs agendados Código-fonte Código-fonte Controle de Versões SVN Mercurial

Ferramentas/Frameworks utilizados para testes automatizados executados no build: Testes unitários: NUnit, JUnit, TestNG. Testes de Integração: JMockit, Mockito, DBUnit. Testes de Aceitação: Geb (em fase de prospecção), Selenium, Fest. Jenkins tem jobs que executam testes definidos no Fitnesse (seguindo a filosofia do BDD ou executando testes de banco de dados - shematest-bd). Em maio/2012: Documentação e Testes de Aceitação automatizados com Fitnesse e BDD:

Processo automatizado de release para maven e gradle. Podem ser tarefas separadas dos jobs no Jenkins. Verifica se existe dependências com versão SNAPSHOT Verifica se existe necessidade de commit/push ou update/pull Modifica a versão de x-SNAPSHOT para uma release no arquivo de configuração Necessário commit do arquivo de configuração Modifica o arquivo de Configuração para versão y-SNAPSHOT Faz o BUILD Faz upload do binário no snepmaven Necessário commit do arquivo de configuração Cria tag com nome da release

O jenkins tem integração com todos os repositórios de controle de versão utilizados e executa jobs de aplicações C/C++ (com CMake), Java (Maven, Gradle) e Groovy/Grails (Gradle, Grails). O sonar é executado via Jenkins para aplicações .NET (C#), Java, Groovy/Grails (profiles definidos). O visuwall é atualizado quando o sonar é executado e quando o build é executado no jenkins e no TFS.

Job no Jenkins – Build Lento – Testes de Aceitação Análise Estatica e Estatisticas Info do Sonar: Cobertura Dívida Técnica Linhas de Código Job no Jenkins – Build Lento – Análise Estatica e Estatisticas - sonar runner (TFS) Build Compilação Testes unitarios resultado do build VISUWALL Dashboard Job no Jenkins – Build Rápido – Compilação Testes unitarios Empacotamento Install Deploy – binário no Repositório Artefatos resultado do build TFS Jenkins

One-Click Deployment com Jenkins
Passos Construção e testes unitários (rápido) Deploy em desenvolvimento Testes de integração e aceitação no ambiente de desenvolvimento (incluir Sonar) Deploy em testes/homologação Deploy em produção

Repositório de Artefatos -snepmaven
Governança de Artefatos e repositórios - Nexus Binario Binario Binario Deploy - DSV Deploy – binário em DSV Smoke Test Deploy - HMG Deploy – binário em HMG Smoke Test Release Release Deploy - PRD Deploy – binário em PRD Smoke Test middeployer - equipe executa, infra configura Versão (Release, SNAPSHOT) middeployer - infra executa e configura middeployer - infra executa e configura Script de deploy Script de deploy Script de deploy middeployer Controle de Versões Mercurial

Pré-requisito para Entrega Contínua. Deployment pipeline definido no jenkins considerando DSV-HMG-PRD. Jobs padronizados para servidores de aplicação JBoss e Weblogic. Hot deploy automatizado via maven. Jobs utilizando, atualmente, Apache Ant para deploy no Oracle BPM (em análise).

Pré-requisitos para One-Click Deployment: Deploy no snepmaven. Para executar um job no pipeline, deve ter sido executado com sucesso o job anterior no pipeline, ou seja, para executar em HMG a mesma versão deve ter passado por DSV. É necessário passar como parâmetro a versão em tempo de execução do job. Jenkins de deployment separado do jenkins que executa builds (integração contínua).

Em DSV, a equipe faz deploy automatizado, a versão pode ser release ou versão snapshot. Em HMG e PRD, apenas a infra estrutura faz deploy automatizado e é necessário que a versão seja release. A release segue a nomenclatura: major-minor-bugfixes. Configuração dos jobs no jenkins de deployment é responsabilidade da infra estrutura e grupo de arquitetura. Configuração no jenkins que executa os builds é de responsabilidade do grupo de arquitetura e equipe tem permissão para configurar em conjunto com o grupo.

Integração Contínua e One-Click Deployment com Jenkins
Construção no TFS: Jobs no Jenkins podem fazer a chamada ao deploy no TFS. O build pipeline é configurado no Jenkins. Jobs no Jenkins fazem update do código do TFS (via plugin) e executam o sonar-runner. Jenkins e TFS atualizam o visuwall (dashboard com informações da integração contínua). Jobs são agendados no slave Windows.

Jenkins TFS VISUWALL Jenkins Release Deploy - HMG Deploy – binário
em HMG Smoke Test Release Deploy - PRD Deploy – binário em PRD Smoke Test versão Deploy - DSV Deploy – binário em DSV Smoke Test Jenkins middeployer buildDefinition projeto collection buildDefinition projeto collection buildDefinition projeto collection Deploy - DSV Deploy – HMG Deploy – PRD TFS Build Compilação Testes unitarios Job no Jenkins – Build Lento – Plugin do TFS – Update/Check-Out dos fontes Análise Estatica e Estatisticas - sonar runner (TFS) resultado do build Info do Sonar: Cobertura Dívida Técnica Linhas de Código VISUWALL Dashboard Jenkins snepciserver

Monitoração

Jira + Greenhopper

Ferramentas de Construção

Apresentações semelhantes

Apresentação em tema: "Ferramentas de Construção"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Ferramentas de Construção

Apresentações semelhantes

Apresentação em tema: "Ferramentas de Construção"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback