almdeida, silva - entrega contínua um estudo de caso para automatização do fluxo de implantação...

7/25/2019 Almdeida, Silva - Entrega Contnua Um Estudo de Caso Para Automatizao Do Fluxo de Implantao Do Sistema

1/19

ENTREGA CONTNUA: UM ESTUDO DE CASO PARA AUTOMATIZAO DOFLUXO DE IMPLANTAO DO SISTEMA INTEGRA

Alicenaira Lanes Souza Carneiro de ALMEIDACentro de Ensino Superior de Juiz de Fora, Juiz de Fora, MG

Orientador: Evaldo de Oliveira da SILVA

Resumo:Em muitos ambientes de desenvolvimento os processos realizados, entrea solicitao de uma manuteno e a implantao da mesma em produo, soexecutados manualmente. Esse processo de entrega manual faz com que muitasorganizaes que produzem software tenham um ciclo mais longo para gerar umanova verso da aplicao. Quanto maior a durao para implantar uma manutenoou nova funcionalidade em produo, maior ser o risco de ocorrerem erros. AEntrega Contnua uma prtica que busca a reduo da durao dos ciclos deimplantao de sistemas, atravs da utilizao de ferramentas que automatizam oversionamento, a construo e demais processos de desenvolvimento. Este artigo

aborda a implantao da Entrega Contnua com o uso de ferramentas open sourcesem um sistema denominado Novo Integra, que desenvolvido e mantido pelaequipe de desenvolvimento do Instituto de Cincias Exatas da Universidade Federalde Juiz de Fora. Ao final, uma metodologia de implantao proposta e osresultados obtidos com essa abordagem so apresentados.

Palavras-chave:Entrega Contnua; Qualidade de Software; Automatizao deProcessos.

1 INTRODUO

A realizao de entregas manuais de softwarepode expor a organizao e o

usurio final a riscos e gerar um grande desconforto para quem est implantando um

sistema em produo. Em muitos ambientes de desenvolvimento os processos

realizados, entre a solicitao de uma manuteno e a implantao da mesma em

produo, faz com que a durao de um ciclo atinja semanas, meses ou at mesmo

mais de um ano. Quanto maior sua durao, maior ser o risco de ocorrerem erros

durante a implantao. Esse o cenrio atual do sistema Novo Integra, que

desenvolvido e mantido pela equipe de desenvolvimento do Instituto de Cincias

Exatas (ICE) da Universidade Federal de Juiz de Fora (UFJF).

Com o objetivo de automatizar os processos da entrega de software, foi

proposta uma metodologia para a implantao da Entrega Contnua, que de acordo

com Humble e Farley (2014), cria um processo de entrega confivel, previsvel e

passvel de repetio, que, por sua vez, gera grandes redues no tempo de ciclo e

entrega novas funcionalidades e correes aos usurios rapidamente. O estudo de


2/19

caso realizado aponta quais foram as ferramentas open sources utilizadas e os

resultados obtidos com a implantao.

A automatizao dos processos diminui o tempo entre um cdigo pronto e

seu uso pelos usurios finais. Assim, o risco associado entrega tem uma reduo

significativa, permitindo a reverso de mudanas com facilidade e rpida obtenode feedback(SETE, 2013).

Essa automatizao pode ser obtida atravs da integrao de todas as

atividades da entrega de software. Entre elas est o Controle de Modificaes, o

Controle de Verses, o Controle de Gerenciamento de Construo, os Testes

Automatizados, a Anlise Esttica do Cdigo, a Gerncia de Dependncias, a

Gerncia de Artefatos e a Gerncia de Infraestrutura. Para que essas atividades

sejam transformadas em uma etapa normal e contnua fundamental que todos osmembros da equipe trabalhem em conjunto, isso inclui desde desenvolvedores e

testadores, at times de implantao e operao (SATO, 2014).

Este artigo est organizado da seguinte forma: a seo 2 apresenta a

fundamentao terica com as principais tcnicas utilizadas na Entrega Contnua; a

seo 3 apresenta o cenrio inicial do estudo de caso, sugere uma metodologia para

a implantao da Entrega Contnua, indica quais ferramentas open sourcespodem

ser utilizadas e apresenta os resultados obtidos com essa abordagem; finalmente, a

seo 4 apresenta as consideraes finais e trabalhos futuros.

2 REFERENCIAL TERICO

A Entrega Contnua (Continuous Delivery) surgiu para reduzir o custo, o

tempo e o risco da entrega de software. Para isso os processos devem ser

amparados por ferramentas e scripts de automatizao que garantam que o

software estar pronto para ser implantado em produo a qualquer momento

(HUMBLE; FARLEY, 2014).

Para apoiar o processo de Entrega Contnua, a Gerncia de Configurao de

Software (GCS) fornece tcnicas, processos e ferramentas para automatizar e

implantar software em ciclos curtos. De acordo com Dantas (2009), os principais

sistemas da GCS so o Controle de Modificaes, o Controle de Verses e o

Controle de Gerenciamento de Construo. A seguir sero detalhadas as principais

atividades da GCS e sua importncia no processo de entrega de software.


3/19

2.1 GERNCIA DE CONFIGURAO DE SOFTWARE

Segundo Estublier (2000) a GCS definida como uma rea da Engenharia de

Software (ES) responsvel pelo controle da evoluo de sistemas complexos

permitindo contribuir com a ES no desenvolvimento e manuteno das aplicaes,com a finalidade de possibilitar a rastreabilidade das modificaes realizadas.

A configurao de software composta por um conjunto de itens de

configurao. Entre eles esto documentos, programas, dados e ambiente de

desenvolvimento. Todos esses itens devem ser controlados pela GCS, que aplicada

ao longo de todo o ciclo de vida da aplicao. Seu objetivo identificar, controlar,

auditar e relatar modificaes que ocorrem durante o desenvolvimento e

manuteno do software, evitando assim a perda de controle do projeto(PRESSMAN, 2002).

De acordo com Dantas (2009), sob a perspectiva de desenvolvimento, a

GCS abrange trs sistemas principais: Controle de Modificaes, Controle de

Verses e Controle de Gerenciamento de Construo.

O objetivo do Controle de Modificaes garantir a qualidade e a

consistncia dos itens de configurao de software, medida que as modificaes

so feitas. Sua utilizao permite acompanhar e gerenciar todas as alteraes

realizadas durante o ciclo de vida da aplicao (SALES et al, 2010).

Para controlar as modificaes dos itens e obter o histrico de alteraes, os

mesmos devem ser armazenados em um repositrio. O Controle de Verses

composto por procedimentos e ferramentas que permitem a administrao desse

repositrio e o versionamento de software (GARCIA, 2013).

A construo de software, tambm conhecida como build, corresponde ao

processo de compilao, teste e empacotamento do sistema, sua automatizao

pode ser realizada atravs do Controle de Gerenciamento de Construo. Alm

dessas etapas, o processo de construo pode incluir o Gerenciamento de

Dependncias e a execuo de ferramentas de Anlise Esttica do Cdigo, a

importncia dessas etapas ser esclarecida mais adiante. Aps a execuo de um

buildobtm-se um ou mais arquivos binrios, tambm conhecidos como artefatos,

que estaro prontos para serem implantados em produo (SATO, 2014).

Quando mais de uma pessoa trabalha em um mesmo projeto, frequentemente

as mudanas realizadas por um membro impactam os demais, podendo conflitar

entre si e gerar erros durante a construo ou execuo da aplicao. Dessa forma,


4/19

alm de realizar o controle das mudanas, de verses e o gerenciamento da

construo do software, muito importante que o trabalho de todos os envolvidos

seja integrado para a obteno de um produto coerente (LOPES, 2011).

A Integrao Contnua uma atividade da GCS que consiste em diminuir o

ciclo de integrao, tornando-o o mais frequente possvel. Alm disso, um feedbackcontnuo pode ser obtido atravs de prticas e ferramentas que auxiliam na

verificao e correo de erros de integrao assim que eles so introduzidos,

quando ainda barato corrigi-los (LOPES, 2011).

O pipeline de implantao, que ser apresentado mais a frente, utilizado

para levar o princpio de IC sua concluso lgica. Ao combin-lo com o uso correto

da GCS e um alto grau de testes automatizados possvel realizar entregas em

ambiente de teste, desenvolvimento ou produo, a partir de um clique em umboto.

2.2 GARANTIA E CONTROLE DA QUALIDADE DE SOFTWARE

De acordo com Humble e Farley (2014), testar uma atividade multifuncional

que deve ser executada continuamente desde o comeo do projeto, por todos os

integrantes do time. Para garantir a qualidade, a cada mudana realizada na

aplicao, em sua configurao ou no ambiente de software, devem ser escritos

testes em mltiplos nveis (unitrios, de componentes e de aceitao) e includos no

pipelinede implantao para que sejam executados.

A execuo sistemtica de testes tem o objetivo especfico de encontrar e

remover o maior nmero possvel de erros, evitando assim que eles sejam

encontrados pelo cliente. Os testes no garantem que o cdigo no possui erros, no

entanto, so essenciais para verificar se uma mudana em uma parte do software

no afetou outras que dependem direta ou indiretamente dela (PRESSMAN, 2002).

Para garantir que o software entregue ao cliente possui alta qualidade, alm

da execuo de testes automatizados, necessrio realizar o controle da qualidade

de cdigo atravs da anlise esttica do mesmo, que definida por Terra e Bigonha

(2008) como um dos instrumentos conhecidos pela engenharia de software para a

mitigao de erros, seja por sua utilizao para a verificao de regras de estilos,

para a verificao de erros ou ambos.

A anlise esttica do cdigo muito importante para o controle de qualidade,

no entanto, muitos projetos podem evoluir para uma massa de cdigo impossvel de


5/19

ser mantida, caso no sejam divididos em componentes menores quando isso ainda

possvel.

2.3 GERNCIA DE DEPENDNCIAS E DE ARTEFATOS

A diviso de uma aplicao em uma coleo de componentes com baixo

acoplamento e com um bom encapsulamento alm de representar uma boa

arquitetura tambm permite colaborao mais eficiente e feedbackmais rpido em

sistemas de grande porte (SATO, 2014).

A diferena de um softwarebaseado em componentes o fato de que sua

base de cdigo separada em pores menores, que possuem interaes limitadas

e bem definidas. A partir do momento que uma aplicao possui componentessignifica que depende dos mesmos para funcionar corretamente. Essa relao

conhecida como dependncia. Alm dos componentes, uma aplicao pode

depender de pacotes que so desenvolvidos, disponibilizados e controlados por

terceiros, que so conhecidos como bibliotecas (MURTA, 2006).

A Gerncia de Dependncias responsvel por recuperar dependncias com

verses especficas de um repositrio da Internet ou de um repositrio de artefatos

da organizao. Quando a organizao possui um repositrio de artefatos prprio,

possvel realizar a Gerncia de Artefatos para manter, controlar e disponibilizar

bibliotecas e componentes. Dessa forma possvel reduzir o volume de downloads

de bibliotecas da internet e consequentemente o trfego na rede (SATO, 2014).

O uso da abordagem baseada em componentes, alm de incentivar o reuso,

contribui para a colaborao entre grandes equipes. Para alcanar entrega eficiente

e feedbackrpido, fundamental o uso de componentes, de pipelinesbaseados em

dependncias, de um gerenciamento eficiente de artefatos, alm de um ambiente

estvel que esteja preparado para a implantao.

2.4 GERNCIA DE INFRAESTRUTUTRA

Um ambiente formado por um conjunto de recursos necessrios para que a

aplicao funcione de forma correta. Esses recursos so obtidos atravs da

configurao de hardware dos servidores, da infraestrutura de rede que os conecta e

da configurao do sistema operacional e middleware. A infraestrutura representa

todos os ambientes em conjunto com todos os servios que os apoiam, isso inclui


6/19

servidores de DNS, os firewalls, os roteadores, os repositrios de controle de

verso, o armazenamento, as aplicaes de monitoramento, os servidores de e-mail,

entre outros (HAMBLE; FARLEY, 2014).

Os princpios da Gerncia de Infraestrutura incluem a especificao do estado

desejado da infraestrutura por meio de configurao mantida no controle de verso;correo automtica da infraestrutura at chegar ao estado desejado; e uso de

instrumentao e monitoramento para saber o estado atual da infraestrutura.

Quando no realizada de forma correta, resulta em atrasos, perda de eficincia no

desenvolvimento e aumento de custo continuado. Sua responsabilidade preparar e

gerenciar ambientes de homologao e produo presentes no Pipeline de

Implantao (SATO, 2014).

2.5 O PIPELINE DE IMPLANTAO

O pipeline de implantao uma implementao de ponta a ponta da

automatizao do processo de compilao, testes e implantao, que permite s

equipes de teste e operao implantar a aplicao em ambientes de teste, de

homologao e de produo com o apertar de um boto. Aos desenvolvedores,

permitida a visualizao dos estgios do processo de entrega alcanados por cada

verso do softwaree dos problemas encontrados em cada uma delas. Alm disso,

proporciona ao gerente a verificao e monitorao de mtricas fundamentais como

tempo de ciclo, taxa de transferncia e qualidade de acesso, permitindo a

visibilidade sobre o processo de entrega que torna possvel a identificao,

otimizao e remoo de gargalos. Dessa forma, obtm-se um processo de Entrega

Contnua que alm de mais rpido, tambm mais seguro (HUMBLE; FARLEY,

2014).

O principal objetivo do pipeline de implantao permitir que todos os

envolvidos no processo de entrega tenham visibilidade sobre o progresso dos

processos, dessa forma, torna-se possvel identificar quais mudanas quebraram a

aplicao e quais se tornaram verses candidatas apropriadas para a execuo de

testes manuais e entrega. Quando uma verso passa por todo o pipeline com

sucesso, significa que ela foi submetida a testes automatizados e manuais em

ambiente similares aos de produo. Essa a garantia de que est pronta para ser

colocada em produo com um simples apertar de um boto (HUMBLE; FARLEY,

2014).


7/19

3 METODOLOGIA PARA IMPLANTAO DA ENTREGA CONTNUA

O Integra que desenvolvido e mantido pela equipe de desenvolvimento de

softwaredo Instituto de Cincias Exatas (ICE) da Universidade Federal de Juiz de

Fora (UFJF), pode ser acessado atravs do endereo http://integra.ice.ufjf.br/. Deacordo com o prprio site, o projeto consiste na criao de uma plataforma, que

pode ser vista como uma forma de se abstrair a complexidade da unio de dados

providos de sistemas diferentes atravs de interfaces de gerenciamento de

recursos.

O sistema interno do ICE foi criado em 1999 e com o passar dos anos notou-

se que o mesmo havia se tornado um sistema legado. Devido ao alto acoplamento,

foi decidido que um novo sistema deveria ser criado para substituir o antigo. Em2013 o Novo Integra comeou a ser desenvolvido. O lanamento da verso inicial

est previsto para junho de 2014.

Entre as suas principais funcionalidades est o controle de salas, marcao

de aulas, grupos de discusso, eleies, e-mail institucional, matriz curricular,

eventos, grade de horrio, cadastro de computadores rede sem fio e o Plano de

Expanso e Reestruturao (REUNI).

O Novo Integra conta com as tecnologias Java, ZK Framework, Maven,

Hibernete e Spring e com as ferramentas NetBeans, Mysql Workbank e Tortoise

SVN. Alm disso, faz integrao com o Sistema Integrado de Gesto Acadmica da

UFJF (UFJF/SIGA) e com o Google.

Atualmente a equipe formada por trs funcionrios efetivos (estando um

deles afastado para mestrado) e mais dois estagirios. O mtodo de

desenvolvimento gil Kanban utilizado para apoiar o desenvolvimento e a gerncia

de modificaes.

Devido ao tamanho da equipe, existe uma grande dificuldade para conciliar o

desenvolvimento do novo sistema e as manutenes do sistema antigo. A busca

pela automatizao do processo de entrega do Novo Integra comeou com o

objetivo de reduzir o tempo gasto com tarefas manuais, garantir a qualidade da

entrega para evitar o retrabalho e dessa forma aumentar a produtividade da equipe.

O estudo de caso, previamente autorizado pelo Diretor responsvel pelo ICE,

apresenta os resultados obtidos com o uso da metodologia sugerida no artigo para a

automatizao do fluxo de implantao do Novo Integra. Aps a realizao da

pesquisa sobre Entrega Contnua, foi proposto um modelo que pode ser aplicado em


8/19

outros projetos. Atravs de sua utilizao, foram escolhidas as ferramentas que so

responsveis pela automatizao de cada um dos processos do estudo de caso. A

metodologia foi divida nos seguintes procedimentos:

Definio de qual ferramenta ser utilizada para acompanhar a

evoluo do desenvolvimento de software; Determinao do Sistema de Controle de Verso a ser utilizado;

Identificao das dependncias do projeto e definio de como sero

gerenciadas;

Verificao de qual ser o servidor utilizado para a integrao entre os

mdulos dos projetos;

Definio dos mecanismos que sero utilizados para analisar a

qualidade do cdigo; Determinao dos tipos de testes necessrios para verificar a

execuo das funcionalidades do projeto;

Levantamento das configuraes dos ambientes para definio de um

gerenciador de infraestrutura;

Estabelecimento de uma soluo para a implantao da aplicao em

ambiente de produo.

Para fortalecer o modelo sugerido para a implantao da Entrega Contnua,no detalhamento de cada procedimento sero apresentados grficos que indicam a

popularidade de cada ferramenta que pode ser utilizada. Alm disso, sero

apontadas quais so as opes open sourcese dentre elas quais foram utilizadas na

automatizao do fluxo de implantao do Novo Integra.

3.1 DEFINIO DE QUAL FERRAMENTA SER UTILIZADA PARA

ACOMPANHAR A EVOLUO DO DESENVOLVIMENTO DE SOFTWARE

Acompanhar a evoluo do desenvolvimento de software significa organizar

os requisitos em entregas, designar um desenvolvedor para o cumprimento da tarefa

e manter um histrico com a descrio do que foi realizado durante o

desenvolvimento.

Ferramentas de Gerncia de Issues (ou requisies de mudanas) atendem

aos requistos citados acima e incluem a gesto de novas solicitaes, de mudanas

e de defeitos. A Figura 1 aponta quais so os Gerenciadores de Issues mais

utilizados.


9/19

FIGURA 1Popularidade dos Gerenciadores de Issues

Fonte:White e outros (2013)

So ferramentas open sources o Trac, o Mantis, o Bugzilla e o Redmine.

Entre esses, o Redmine (www.redmine.org) o mais utilizado pelos entrevistados. A

equipe de desenvolvimento j utilizava o mesmo, a mudana realizada na

implantao da Entrega Contnua foi a integrao com o SVN e o Jenkins. Alm

disso, a instalao do plugin ekanban que permite trabalhar com o mtodo de

desenvolvimento gil Kanban, que praticado pela equipe.

3.2 DETERMINAO DO SISTEMA DE CONTROLE DE VERSO A SER

UTILIZADO

Um sistema de controle de verso deve armazenar o cdigo fonte e todos os

itens de configurao de software. Alm disso, deve permitir o acesso a verses

anteriores, o compartilhamento entre equipes e a recuperao de informaes sobre

as alteraes atravs de histricos.

A Figura 2 mostra a popularidade dos Sistemas de Controle de Verso. Entre

eles o Mercurial, o CVS, o Git e o Subversion so open sources.


10/19

FIGURA 2Popularidade dos Sistemas de Controle de Verso


O Subversion (http://subversion.apache.org/), tambm conhecido como SVN

utilizado tradicionalmente em projetos Java e, de acordo com a o grfico, continua

sendo o mais utilizado. Apesar da existncia de sistemas mais novos, como o Git

(http://git-scm.com/), o Subversion foi mantido, pois atende a todas as necessidades

do projeto e a equipe j domina o seu uso.

3.3 IDENTIFICAO DAS DEPENDNCIAS DO PROJETO E DEFINIO DE

COMO SERO GERENCIADAS

A identificao das dependncias necessria para levantar quais

modificaes sero realizadas durante a implantao das ferramentas responsveis

pelo seu gerenciamento. O uso de uma ferramenta de build com suporte a

gerenciamento de dependncias, em conjunto com um servidor de gerenciamento

de artefatos permite a padronizao de bibliotecas e componentes do projeto. Alm

disso, torna possvel a execuo do builda partir de um nico comando.

Entre os sistemas open sources que possibilitam o build automatizado e a

gerncia de dependncias esto o Maven, o Gradle e o Ant (em conjunto com o Ivy).

A Figura 3 apresenta a comparao da popularidade dessas ferramentas,

considerando o perodo que vai do final de 2010 at meados de 2013.


11/19

FIGURA 3Popularidade das ferramentas de build Final de 2010 a meados de 2013


No incio do estudo de caso o Maven (http://maven.apache.org/) j estava em

uso e foi mantido, pois alm de permitir a gesto de dependncias e a criao de

componentes, tambm possibilita a automatizao do buildde forma independente,

isto , sem precisar interagir com outras ferramentas.

Entre os servidores open sources de gerenciamento de artefatos esto oNexus e o Artifactory. O Nexus est sendo estudado para implantao futura.

3.4 VERIFICAO DE QUAL SER O SERVIDOR UTILIZADO PARA A

INTEGRAO ENTRE OS MDULOS DOS PROJETOS

A automatizao de processos por si s no suficiente. fundamental

possuir um feedbackque indique se as alteraes realizadas em qualquer um doscomponentes, mdulos ou servios no quebraram o funcionamento de outro ponto

da aplicao.

Servidores de IC possuem a funo de integrar todas as alteraes realizadas

no repositrio e podem enviar notificaes para os responsveis em caso de erros.

A Figura 4 mostra a popularidade dos servidores de IC. Entre eles o Jenkins

(Hudson) a nica opo open source.


12/19

FIGURA 4Popularidade dos Servidores de Integrao Contnua


O Jenkins (http://jenkins-ci.org/) possui interface web com mais de 600plugins

para customizao e possibilita a integrao com tecnologias que permitem a

compilao, anlise, testes e implantao das aplicaes. responsvel por

interligar as ferramentas utilizadas para a entrega de software.

No incio do estudo de caso o Jenkins j estava em uso, no entanto, era

utilizado apenas para integrao e verificao da qualidade atravs de plugins.

Durante a implantao foram criados e configurados jobs especficos para a

compilao, anlise esttica de cdigo, testes e implantao dos componentes,

servios e mdulos que so utilizados nopipelinede implantao.

3.5 DEFINIO DOS MECANISMOS QUE SERO UTILIZADOS PARA

ANALISAR A QUALIDADE DO CDIGO

As ferramentas para a Anlise Esttica de Cdigo utilizam mtricas para

verificar violaes e a evoluo da qualidade estrutural do cdigo. A Figura 5 mostra

a popularidade das ferramentas utilizadas para esse fim, todas as ferramentas

apresentadas so open sources.


13/19

FIGURA 5Popularidade das ferramentas de anlise esttica de cdigo

Fonte:Shelajev e outros (2014)

O Jenkins possibilita a anlise da qualidade de cdigo atravs da instalao

de vriospluginsque geram relatrios e grficos durante a compilao da aplicao.

Entre eles esto o FindBugs (https://wiki.jenkins-

ci.org/display/JENKINS/FindBugs+Plugin), o CheckStyle (https://wiki.jenkins-

ci.org/display/JENKINS/Checkstyle+Plugin) e o PMD (https://wiki.jenkins-

ci.org/display/JENKINS/PMD+Plugin). Aps a realizao de vrios testes, observou-se que o tempo gasto na compilao com a gerao desses relatrios chegou a ser

treze vezes maior que o tempo gasto para uma compilao que no envolvia essa

anlise.

A melhor soluo encontrada foi a implantao do Sonar

(http://www.sonarqube.org/), que uma ferramenta dedicada ao controle e medio

da qualidade do cdigo, que tambm pode ser customizada com a instalao e

configurao de plugins e integrada ao Jenkins. Suas mtricas podem ser

customizadas de acordo com a necessidade de cada projeto e possvel definir um

limite mnimo aceitvel de incidentes que, se ultrapassado, impedir que a

compilao seja realizada com sucesso.

3.6 DETERMINAO DOS TIPOS DE TESTES NECESSRIOS PARA VERIFICAR

A EXECUO DAS FUNCIONALIDADES DO PROJETO

O build de uma aplicao garante que no ocorreram erros durante a

construo do software, no entanto, para entregar valor ao cliente necessrio


14/19

atender aos requisitos especificados. Os testes automatizados so os responsveis

por garantir que quaisquer problemas que comprometam o cumprimento dos

requisitos sejam identificados enquanto o custo para corrigi-los ainda baixo, por

isso devem ser bem definidos. Dessa forma, obtm-se a garantia de que o software

est funcionando como deveria, isso significa menos defeitos, menor custo commanuteno e melhor reputao com o cliente.

Ferramentas para diferentes tipos de testes podem ser escolhidas de acordo

com o escopo e a necessidade de cada projeto. A Figura 6 exibe a popularidade das

ferramentas de automatizao de testes. Todas as ferramentas listadas so open

sources.

As ferramentas escolhidas inicialmente para automatizao de testes do

Novo Integra foram a JUnit (http://junit.org/) para a criao de testes unitrios e aSelenium (http://docs.seleniumhq.org/) para a criao de testes funcionais.

FIGURA 6Popularidade das ferramentas de automatizao de testes


3.7 LEVANTAMENTO DAS CONFIGURAES DOS AMBIENTES PARA

DEFINIO DE UM GERENCIADOR DE INFRAESTRUTURA

O provisionamento de infraestrutura deve ser um processo automatizado para

que seja possvel restabelecer, dentro de um perodo de tempo previsvel, uma novaconfigurao programada em casos de falhas de hardware.


15/19

A escolha de uma ferramenta essencial para reduzir o tempo desperdiado

com a configurao de ambientes. A Figura 7 mostra as ferramentas mais populares

de configurao de infraestrutura.

FIGURA 7Popularidade das ferramentas de configurao de infraestrutura


O Puppet (http://puppetlabs.com/puppet/puppet-open-source) uma

ferramenta que centraliza as configuraes em um nico ponto, permitindo que

sejam distribudas para outros ns dentro de uma rede. Utiliza linguagem declarativapara a configurao de sistemas operacionais, entre eles Linux, Windows e Solaris.

Entre suas principais funcionalidades est a gerncia de configurao do ambiente e

a automatizao da instalao de pacotes. Sua implantao permitiu maior controle

sobre as configuraes dos servidores, tornando possvel sua reproduo para

criao de ambientes de homologao.

3.8 ESTABELECIMENTO DE UMA SOLUO PARA A IMPLANTAO DAAPLICAO EM AMBIENTE DE PRODUO

A implantao da aplicao em um ambiente de produo o ponto crucial da

Entrega Contnua, pois trata o ponto mais crtico que depende de todos os

processos anteriores alm de uma ferramenta para tornar a implantao

automatizada.

Um pipelinede implantao no servidor de IC ajuda a remover ineficincias

do processo, tornando o ciclo de feedbackmais rpido e poderoso. No existe uma


16/19

soluo nica para a criao de um pipeline, as configuraes podem variar de

acordo com a complexidade e arquitetura de cada projeto.

A equipe de desenvolvimento do Novo Integra optou por utilizar o Build

Pipeline Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin) no

Jenkins. Atravs dele possvel interligar os jobs do Jenkins e definir se serodisparados de forma manual ou automtica.

Sua implantao alm de permitir uma visualizao mais ampla do progresso

dos processos da Entrega Contnua, tambm permitiu a identificao do uso de

dependncias desnecessrias em alguns componentes, servios e mdulos do

sistema.

3.9 ANLISE DOS RESULTADOS OBTIDOS

Para identificar em que ponto uma organizao est, em termos de

maturidade de processos e prticas, Humble e Farley (2014) definiram um modelo

de maturidade para a gerncia de configurao e entrega de verso. O modelo

considera as prticas de gesto de construo e IC, ambientes e implantao,

gesto de entrega de verso e observncia, testes e gerncia de configurao. A

progresso baseada em nveis pode ser utilizada para a melhoria contnua dos

processos.

So apresentados cinco nveis globais, que podem ser utilizados para

avaliao geral da organizao. So eles:

Nvel 3 - Otimizao: Foco em melhoria de processo

Nvel 2 - Gerido quantitativamente: Processos medidos e controlados

Nvel 1 - Consistente: Processos automatizados aplicados ao longo de

todo o ciclo de vida da aplicao.

Nvel 0 - Repetvel: Processo documentado e parcialmente

automatizado

Nvel -1 - Regressivo: Processos que no podem ser repetidos, pouco

controlados e reativos

O uso das ferramentas utilizadas durante a confeco desse artigo permitiu

um crescimento que passou do nvel regressivo para o repetvel. A automatizao

dos processos reduziu o tempo desperdiado com processos manuais, no entanto,

ainda existem pontos que precisam ser melhorados para que o nvel de otimizao

seja alcanado.


17/19

4 CONCLUSO

Entrega contnua um assunto relativamente novo, no entanto, a partir do

momento que se entende quais so as prticas envolvidas, possvel buscar por

solues especficas para cada ponto do processo.A metodologia apresentada no captulo 3 possibilitou a automatizao dos

principais processos da entrega de software e pode ser utilizada por qualquer equipe

que pretenda implantar a Entrega Contnua para obter reduo do tempo

desperdiado com tarefas manuais e aumentar a qualidade do software. A escolha

das ferramentas pode variar de acordo com o escopo e a necessidade de cada

projeto, cabe a cada equipe avaliar quais so as melhores solues.

O estudo de caso permite concluir que a implantao da Entrega Contnuadeve ser realizada de forma gradativa. Os nveis mais altos de maturidade podero

ser alcanados atravs da colaborao diria de todos os membros envolvidos na

confeco do software. A prtica diria levar a uma evoluo natural com o

decorrer do tempo, que permitir o incio de buscas por novos procedimentos a partir

do momento que todos entenderem o real significado de entregar valor ao cliente.

A implantao muito flexvel, existem muitas opes de ferramentas para

resolver um mesmo problema. O ponto positivo que havendo alguma ferramenta

que no atenda a alguma necessidade do processo, ser possvel buscar outra

soluo. O ponto negativo decidir quais ferramentas usar no incio da implantao.

Esse foi o principal desafio encontrado durante a elaborao desse artigo.

As avaliaes a respeito de trabalhos futuros mostram que o trabalho est

longe de um fim. Muitos tpicos avanados podem ser explorados com o objetivo de

alcanar melhores nveis de maturidade da Entrega Contnua. Entre eles est a

gerncia de dados, a implantao na nuvem, os sistemas avanados de

monitoramento, os pipelines de entregas complexas e a orquestrao de

implantao. Alm disso, algumas mudanas culturais so essenciais para ajudar na

melhoria contnua dos processos. Uma das prticas que surgiu recentemente

denominada DevOps que sugere a colaborao entre os times de desenvolvimento

e de operaes. Com base nos resultados obtidos possvel vislumbrar uma vasta

continuao para esse assunto ainda to pouco explorado.


18/19

REFERNCIAS

BECK, Kent. Extreme Programming Explained: Embrace Change. Addison-WesleyProfessional, 1999.

DANTAS, Cristine. Gerncia de Configurao de Software: Desenvolvendo

software de forma eficiente e disciplinada. Rio de Janeiro, 2009. Disponvel em: . Acessoem 20 jun 2014.

DIAS, Klessis Lopes; LUCENA, Carlos Jos Pereira de; KULESZA, Uir. Umframework orientado a aspectos para monitoramento e anlise de processosde negcio. 2008. 68f. Dissertao (Mestrado em Informtica)-PontifciaUniversidade Catlica do Rio de Janeiro, Rio de Janeiro, 2008.

ESTUBLIER, Jacky et al. Impact of the research community on the field ofsoftware configuration management: summary of an impact project report.ACM

SIGSOFT Software Engineering Notes, v. 27, n. 5, p. 31-39, 2002.

FOWLER, Martin. Continuous Integration. Disponvel em:. Acesso em 7 fev 2014.

GARCIA, Francisco A. Integrao Contnua: da teoria prtica Parte 1. JavaMagazine, Rio de Janeiro, n. 117, 2013. Disponvel em:. Acesso em 15 abr 2014.

HUMBLE, Jez; FARLEY, David. Entrega contnua: como entregar software deforma rpida e confivel. Porto Alegre: Bookman, 2014.

LOPES, Juan. Integrao Contnua. .net Magazine, Rio de Janeiro, n. 85, PortoAlegre: Bookman, 2011. Disponvel em . Acesso em 15 abr 2014.

MURTA, Leonardo Gresta Paulino. Gerncia de Configurao noDesenvolvimento Baseado em Componentes. Rio de Janeiro, 2006. Disponvelem . Acessado em27 jun 2014.

PRESSMAN, Roger S. Engenharia de Software. 5. Ed. So Paulo: Ed. McGraw-Hill, 2002.

SALES, Ernani O; LIMA REIS, Carla A; REIS, R. Q. Apoio a Gerncia deConfigurao de Artefatos de Software integrado a Execuo de Processos deSoftware. Disponvel em:. Acesso em 20 mar 2014.

SATO, Danilo. DevOps na prtica: entrega de software confivel e automatizada.

So Paulo: Caso do Cdigo, 2014.


19/19

SETE, Mrcio. Continuous Delivery: Passos para implementao. Engenharia deSoftware Magazine, Rio de Janeiro, n. 65, 2013. Disponvel em:. Acesso em 19 fev 2014.

SHELAJEV, Oleg; MUUGA, Sigmar; MAPLE, Simon; WHITE, Oliver. The Wise

Developers Guide to Static Code Analysis featuring FindBugs, Checkstyle,PMD, Coverity and SonarQube. Disponvel em:. Acesso em 05 mai 2014.

TERRA, Ricardo; BIGONHA, Roberto S. Ferramentas para Anlise Esttica deCdigos Java. Belo Horizonte, 2008. Disponvel em:. Acessado em 25 jun2014.

WHITE, Oliver; BADRINARAYANAN, Krishnan; KABANOV, Jevgeni. DevOps /ITOps Productivity Report 2013. Disponvel em:. Acesso em 05 mai 2014.

WHITE, Oliver; MAPLE, Simon; MUUGA, Sigmar; TIMO!IN, Juri; RASMUSSEN,Michael. Java Build Tools Part 2: A Decision Makers Comparison of Maven,Gradle and Ant + Ivy. Disponvel em: .Acesso em 05 mai 2014.

almdeida, silva - entrega contínua um estudo de caso para automatização do fluxo de implantação...

Documents