Automatizao no Processo de Entrega de Software

Leandro Souza Nunes

FAESA - Faculdades Integradas Esprito-Santenses
Av. Vitria, 2.220 - Monte Belo, Vitria, ES, Brasil
leandronunes.dev@gmail.com

Resumo. Um grande problema que afeta a qualidade do desenvolvimento a

realizao de tarefas importante para a entrega de software que so
executadas manualmente. Este artigo tem o objetivo de mostrar boas prticas
de desenvolvimento que vem sendo estudadas ha vrias dcadas para fornecer
ao mundo uma alternativa s metodologias pesadas e altamente dirigidas por
documentao, permitindo aumentar a capacidade de liberar verses do
sistema sob demanda, de gerar releases bem-sucedidos e implantar o sistema
em qualquer ambiente simplesmente apertando um boto, sem precisar se
preocupar se funcionar ou no.
Abstract. A major problem that affects the quality of development is important
for the realization of software delivery tasks that are performed manually.
This article has the objective of show good development practices that have
been studied for several decades to provide the world an alternative to heavy
and highly targeted methodologies for documentation, allowing an increased
ability to release versions of the system on demand, to generate well-releases
successful and deploy the system in any environment by simply pressing a
button, without having to worry if it will work or not.

1. Introduo
Com a globalizao e o aumento ao acesso a banda larga, o mundo vive uma interao
em tempo real. Ideias, tendncias, necessidades, informaes, dentre outros, navegam
de continente continente em uma velocidade jamais imaginada, tendo o software como
parte fundamental desse processo. Desenvolver software nesse cenrio requer um
processo onde uma ideia na mente do cliente vire cdigo funcional e esteja disponvel
para o usurio final de maneira rpida e confivel. O tempo para efetuar esse processo,
denominado como tempo de ciclo, pode determinar o rumo dos negcios junto a
concorrncia.
Desde 1980, autores como Kent Beck, Martin Fowler, Paul Duvall, Ron Jeffries
e Dave Thomas, estudam melhores prticas de desenvolvimento com o objetivo de
poder fornecer ao mundo uma alternativa s metodologias pesadas e altamente dirigidas
por documentao que esto em uso at hoje [Lopes 2012]. Conforme os dos 12
princpios do Manifesto gil (2001), o software em funcionamento tem maior valor do
que uma documentao abrangente e software funcional a medida primria do
progresso. Software no gera lucro ou valor at que esteja nas mo de seus usurios,
complementa Humble e Farley (2014).
Este artigo demonstra boas prticas das metodologias gil de desenvolvimento
para efetuar entrega contnua de software de valor ao cliente, descreve os passos de
como detectar erros mais cedo atravs da prtica da integrao contnua, permitindo que
se desenvolva software coeso mais rapidamente [Fowler 2006]. Demonstra o padro
pipeline de entrega, capaz de permitir automatizao desde o desenvolvimento do
software at sua entrega final. Conforme Duval (2012), o pipeline de entrega um
processo no qual diversos tipos de tarefas so executadas com base no sucesso da tarefa
anterior.
Com a automatizao dos processos, a entrega de software se torna confivel,
previsvel, com riscos quantificveis e bem entendidos, garantindo que quando for
preciso fazer alguma modificao, o tempo para realiz-las, coloc-las em produo e
em uso, seja o menor possvel e, que problemas sejam encontrados cedo o bastante para
que sejam fceis de corrigir.
O pipeline envolve atividades de todos os interessados pela entrega de software,
amplia as taxas de implantao e fomenta prticas do movimento DevOps, criando um
relacionamento colaborativo entre as equipes de desenvolvimento, qualidade e de
operaes. Automatizar os processos de forma que todos os envolvidos possam executar
tarefas (que at ento so manuais) de forma assncrona, melhora produtividade e a
quantidade de entregas de valor dentro de tempo de ciclo, permitindo implantar o
sistema para qualquer ambiente instantaneamente, refletindo as mudanas de uma forma
eficiente e com baixo custo.

2. Metodologias geis de desenvolvimento

Os processos das metodologias tradicionais no acompanharam a evoluo do trfico de
informaes. Conforme Humble e Farley (2014), o principal problema enfrentado pelos
profissionais da rea de desenvolvimento de software como fazer para transformar
uma boa ideia em um sistema e entreg-lo aos usurios o quanto antes.
Em busca de valorizar a importncia da interao entre os envolvidos e a entrega
de software de valor ao cliente a curto prazo, em 2001, 17 pensadores de
desenvolvimento de software se reuniram e concordaram que, em suas experincias
prvias, um pequeno conjunto de princpios sempre parecia ter sido respeitado quando
os projetos davam certo. Esses princpios foram reunidos no Manifesto gil (2001).
Kent Beck definiu um conjunto de valores, princpios e prticas que resultou em
um trabalho denominado Extreme Programming (XP). Segundo Sato (2013), a XP foi
uma das primeiras metodologias geis que revolucionou a forma como os softwares
eram desenvolvidos e, alm de se basear em valores para guiar o desenvolvimento, tais
como a comunicao clara entre os envolvidos, a simplicidade em fazer o suficiente
para atender as necessidades, o feedback para direcionar o produto e a coragem de
efetuar mudanas, trazem uma serie de prticas, como a integrao contnua (IC), o
desenvolvimento guiado por testes e a refatorao. Prticas que quando aplicadas,
contribuem para uma entrega de qualidade e eficiente de software.
Ken Schwaber definiu o Scrum, um conjunto de prticas como o objetivo de
manter o gerenciamento do projeto visvel aos usurios. Uma metodologia gil para
gesto e planejamento de projetos de software, onde o desenvolvimento dividido em
iteraes com perodo de duas a seis semanas, chamadas de Sprints.
Outra metodologia gil que vem sendo utilizada para dar apoio ao Scrum o
Kanban. Kanban um termo de origem japonesa e significa literalmente carto,
criado por Taiichi Ohno para indicar o andamento do fluxo de produo em empresas
de fabricao em srie. Tipicamente usa-se um quadro em branco com post-its (Quadro
Kanban) para mapear o fluxo de valor das atividades relacionadas ao desenvolvimento
de software.
A implementao de metodologias gil proporciona o desenvolvimento
cooperativo, onde baseiam-se mais nas pessoas e suas iteraes em vez de grandes
esforos de planejamento e processos rgidos. Segundo Pressman (2006, p. 58), em
essncia, os mtodos geis foram desenvolvidos em um esforo para vencer as
fraquezas percebidas e reais da engenharia de software convencional.

3. Pipeline de implantao
O processo de levar a funcionalidade da mente do cliente at o usurio final envolve
vrias etapas, dentre elas, a etapa de desenvolvimento. O desenvolvimento composto
de vrios processo alm da codificao e podem ser mapeados atravs da modelagem do
mapa de fluxo de valor. O mapa de fluxo de valor possibilita uma viso mais holstica,
de ponta a ponta do processo de entrega. O objetivo do fluxo de valor mapear uma
solicitao do cliente, do momento em que ela chega at que ela esteja disponvel em
produo [Popperdieck, M. e Popperdieck, T. 2011].

No desenvolvimento, necessrio juntar o cdigo produzido ao cdigo

principal, testar esse cdigo para certificar que no foram adicionados defeitos ao
projeto, configurar ambientes para instalao do software e efetuar a implantao nesses
ambientes, proporcionando demonstraes, testes exploratrio e a disponibilizao para
o usurio final. O pipeline de implantao modela esse processo, e sua inverso em uma
ferramenta de integrao contnua, de gerncia de verses e a utilizao da prtica de
desenvolvimento guiado por teste como o TDD1, o que permite que uma equipe veja e
controle o processo de cada mudana medida que ela se move em direo a entrega.
Para Humble e Farley (2014) o pipeline de implantao uma manifestao
automatizada do processo de levar o software do controle de verso at os usurios.
Cada mudana passa de forma consistente no percurso de entrega atravs da
automatizao. A automatizao torna passos complexos e suscetveis a erros em passos
repetveis e confiveis. Fowler (2013) acrescenta que o pipeline para detectar
quaisquer mudanas que levem os problemas para produo e para permitir a
colaborao entre os envolvidos, possibilitando a visibilidade de todo o fluxo de
mudanas juntamente com uma trilha para uma auditoria completa.

4. Entrega de software automatizada

Metodologia geis valorizam a entrega de software de valor a curto prazo. Com elas,
tem-se um conjunto de boas prticas para o desenvolvimento de software incremental
(ou iterativo), onde o sistema comea a ser implantado logo no incio do projeto e vai
ganhando novas funcionalidades ao longo do tempo. Isso exige que os processos de
entrega sejam executados diversas vezes no decorrer de uma Sprint.
Para a definio de um pipeline de entrega, necessrio ter uma viso de todos
os processos. O quadro Kanban auxilia nessa tarefa. A Figura 01 demonstra um
exemplo do fluxo de entrega. Modelar um pipeline de implantao exige entender seus
processos de entrega e balancear o nvel de feedback que voc quer receber [Sato,
2013]. Projetos anteriores podem servir como base para um novo projeto.
Aps a definio das funcionalidades, elas so adicionadas na coluna
Solicitaes e ficam aguardando o planejamento para a prxima Sprint. No
planejamento, as solicitaes que iro ser desenvolvidas na Sprint, so movidas para a
coluna A Fazer. Ao iniciar a codificao da funcionalidade, o desenvolvedor atualiza
o status da funcionalidade movendo-a para a coluna Fazendo, at que seja concluda.
At esse momento, o processo se deu de forma manual.

Figure 01. Movimentao das funcionalidades no quandro Kanban.

TDD uma tcnica de desenvolvimento de software criada por Kent Beck. Veja em:
http://pt.wikipedia.org/wiki/Test_Driven_Development

A entrada do pipeline inicia-se com o check-in no sistema de controle de verso.

Um dos sistemas de controle de verso mais utilizado o Git (http://git-scm.com).
Nessa etapa do processo, uma ferramenta de IC como o Jenkis (http://jenkis-ci.org), o
Go (http://go.thoughworks.com), ou at um servio de integrao contnua nas nuvens
como o TravisCI (http://travis-ci.org), pode ser configurada para monitorar o repositrio
a cada alterao e mover a funcionalidade nas trs etapas seguintes.
De acordo com a tecnologia utilizada pela aplicao, possvel fazer uso de
ferramentas como o RSpec (http://rspec.info) e o JUnit (http://junit.org) para escrever os
testes automatizados. A alterao que tenha sido validada com sucesso vira uma nova
verso do software (uma verso candidata a ir para produo). Cada estgio de teste
avalia a verso candidata de uma perspectiva diferente e a cada teste que ela passa,
aumenta a confiana em sua implementao. O objetivo desse processo eliminar as
verses candidatas que no estejam prontas para produo o quanto antes e obter
feedback sobre a falha o mais rpido possvel [Humble e Farley 2014].
Quando a verso candidata passa pelo estgio de teste de aceitao
automatizados, ela se torna algo til e interessante, no sendo mais prioridade da equipe
de desenvolvimento. prefervel que os estgios de implantao para os ambientes de
aceitao e produo no executem automaticamente. Os testadores devem ser capazes
de ver quais verses candidatas passaram com sucesso e implantar o sistema em um
ambientes configurado com um simples apertar de boto. Para a automatizao do
processo de implantao, ferramentas como a Capistrano (http://capistranorb.com) e a
Mina (http://nadarei.co/mina), podem ser utilizadas.
Com a adoo dessa abordagem, no permitido efetuar implantao do sistema
em produo sem que a verso seja apropriadamente testada. Regresses so evitadas ao
se fazer correes, elas passam pelo mesmo processo que quaisquer mudana. Um
aumento da automao de processos leva a uma maior eficincia e amplia as taxas de
implementao com relao as metodologias tradicionais, conforme a Figura 02.
Para a criao dos ambientes de aceitao e de produo, existem uma srie de
ferramentas de provisionamento no mercado, delas destacam-se: Ansible
(http://www.ansibleworks.com/tech/), Chef (http://www.opscode.com/chef), Puppet
(http://puppetlabs.com/puppet) e Salt (http://saltstack.com/). O processo de
provisionamento um conjunto de passos executveis que podem ser aplicados em uma
imagem inicial do sistema operacional para ter tudo configurado corretamente [Tavares,
2013].

Figure 02. Movimentao das funcionalidades no quandro Kanban.

5. Trabalhos relacionados
Este captulo apresenta os trabalhos relacionados a evoluo dos processos que envolve
o desenvolvimento de software, desde a sua concepo at a disponibilizao ao seu
pblico.
Ao longo da dcada de 80, nos Estados Unidos, entre 1986 a 1996 conforme
descrito por Teles (2004, p. 272), Kent Beck e Ward Cunningham desenvolveram um
amplo conjunto de boas prticas que foram publicadas em 1996 sob o ttulo Pattern
Languages of Program Design 2.
Por volta de 1996, Kent Beck publicou o livro Smalltalk Best Practices Patterns
e Martin Fowler em 2000, publicou o Refactoring: Improving the Design of Existing
Code, um trabalho que combina uma grande parte dessas tcnicas. Diretamente das
tcnicas de refactoring como descrito por Teles (2004, 272), surgiu o desenvolvimento
guiado por testes, tendo seu primeiro artigo publicado por Kent Beck para a
SmalltalkReport. Em 1999, Kent Beck agrupou vrias tcnicas de desenvolvimento e
publicou o livro Extreme Programming Explained.
Em 2001, 17 pensadores de desenvolvimento de software, dentre eles: Martin
Fowler, Kent Beck, Kent Schwaber, Ron Jeffries, Dave Thomas, se reuniram para
buscar uma alternativa s metodologias pesadas e altamente dirigias por documentao
(LOPES, 2012, p. 16). Desse encontro surgiu um conjunto de valores denominado
Manifesto gil (2001).
Em 2000, Martin Fowler publica o artigo Continuous Integration, descrevendo
uma das prticas do XP, a Integrao Contnua e em 2007 Paul M. Duvall publica o
livro Continuous Integration, discutindo em detalhes como transformar o processo de
integrao em uma rotina da equipe de desenvolvimento.
Em 2009 durante a conferncia Velocity da OReilly, John Allspan e Paul
Hammond apresentaram 10+ Deploys Per Day, demonstrando como a Flickr efetuava
10 implantaes por dia, desde ento, deu-se origem ao movimento DevOps, buscando
difundir em todo mundo como a colaborao entre todos os envolvidos na entrega do
software.

6. Concluso
Este trabalho teve como foco demonstrar conjunto de boas prticas de desenvolvimento
de software, testadas e validadas por diversos autores. O objetivo est em permitir
efetuar a entrega de software com maior qualidade em um curto perodo e promover a
comunicao com um ciclo de feedback constante entre todos os interessados.
Com isso, muda-se o conceito de pronto,
fazendo com que uma
funcionalidade s esteja pronta quando ela est em produo, fazendo o que tem que
fazer e entregando valor aos seus usurios. Em Startups, esse ciclo de entrega contnua
constantemente utilizado, geralmente se tem pouco recurso e necessrio pensar em
automatizao desde o incio. preciso entregar valor ao usurio para continuar vivo e,
esperar a prxima madrugada para subir a nova funcionalidade pode causar um grande
impacto nos negcios.
A qualidade da aplicao est relacionada tambm com o ambiente onde ela est
implantada. Deve-se tratar as configuraes da mesma forma que o cdigo fonte. Ao
seguir a poltica de que nada modificado em um ambiente a menos que esteja em um
script com verso, automatizado e faa parte de um caminho nico para a produo (o
pipeline de entrega), possvel determinar melhor a causa raiz dos erros mais
rapidamente, acelerando a correo e diminuindo a probabilidade de que pequenos erros
se transformem em grandes dores de cabea no futuro.

Referncias
DUVAL, Paul. (2012) Agile DevOps: O Achatamento do Processo de Reliase de
Software. http://www.ibm.com/developerworks/br/library/a-devops1/
FOWLER, Martin. (2016) Continuous Integration.
http://martinfowler.com/articles/continuousIntegration.html
FOWLER, Martin. (2013) Deployment Pipeline.
http://martinfowler.com/bliki/DeploymentPipeline.html
HUMBLE, J.; FARLEY, D. (2014) Entrega Contnua: Como Entregar Software de
Forma Rpida e Confivel. Porto Alegre: Bookman.
LOPES, Camilo. (2012) TDD na Prtica. Rio de Janeiro: Cincia Moderna.
MANIFESTO GIL. (2001) "Manifesto Para o Desenvolvimento gil de Software".
http://manifestoagil.com.br/
PRESSMAN, R. S. (2006) Engenharia de Software. So Paulo: McGraw-Hill
POPPENDIECK, Mary; POPPENDIECK, Tom. (2011) Implementando o
Desenvolvimento Lean de Software: Do Conceito ao Dinheiro. Porto Alegre:
Bookman.
SATO, Danilo. (2013) DevOps na Prtica: Entrega de Software Confivel e
Automatizada. So Paulo: Casa do Cdigo.
TAVARES, B. (2013) Puppet e Vagrant: Como provisionar mquinas para seu projeto.
http://www.thoughtworks.com/pt/insights/blog/puppet-and-vagrant-how-provisionmachines-your-project.
TELES, Vincius M. (2004) Extreme Programming. So Paulo: Novatec Editora Ltda.