Automatização Na Escolha de Ferramentas em Projetos Que Aplicam DevOps

Universidade Federal de Pernambuco
Centro de Informtica
Graduao em Sistemas de Informao

________________________________________________________
Automatizao na escolha de ferramentas em
projetos DevOps
Jos Eudes de Souza Jnior
Trabalho de Graduao
Recife, Julho de 2017
projetos DevOps
Trabalho apresentado ao programa de

GRADUAO EM SISTEMAS DE INFOR-
MAO do CENTRO DE INFORMTICA da
UNIVERSIDADE FEDERAL DE PERNAMBUCO
como requisito parcial para obteno do grau de
bacharel em SISTEMAS DE INFORMAO.
Orientador: Prof. Dr. Vincius Cardoso Garcia
2
projetos DevOps
Aprovado em ___/___/___
BANCA EXAMINADORA
___________________________________________________
Vincius Cardoso Garcia
___________________________________________________
Kiev Santos da Gama
3
Agradecimentos
Primeiramente, agradeo a Deus, pois ele a causa primeira e sem a sua mis-
ericrdia, eu jamais estaria escrevendo este texto. Deus colocou no meu caminho
muitas pessoas especiais, que me ajudaram nessa rdua caminhada e quero
agradecer a algumas delas.
Quero agradecer queles que me so muito caros e que sem eles eu no con-
seguiria fazer o curso de Sistemas de Informao. Agradeo a Carina Souza, minha
amada esposa, que teve muita pacincia comigo durante essa caminhada, pois
sempre me incentivou e me deu foras para que eu no desistisse. Outra pessoa
muito importante a Aparecida Arajo, minha me, que me criou com muito zelo e
amor, possibilitando que eu chegasse at aqui. Quero agradecer aos meus sogros
Luiz Francisco da Mota e Caselinda Maria Silva da Mota, que me deram uma fora
muito grande, alm de sempre acreditarem em mim. Com certeza, sem essas pes-
soas eu no teria chegado at aqui.
Quero a agradecer aos professores do Colgio Santa Brbara, principalmente

Jorge e Lucio, que acreditaram muito em mim quando eu me julguei incapaz de
passar no vestibular.
Quero agradecer aos professores do Centro de Informtica da UFPE que me

deram a oportunidade de conhecer essa rea to incrvel que a computao. Em
especial quero citar os nomes de Vincius Garcia, meu orientador, Kiev Gama e Car-
la Silva, estes professores se tornaram exemplos para mim.
Quero agradecer aos colegas do Cin, que durante a graduao fizeram parte
da minha trajetria. Em particular Paulo Viana, que se tornou um grande amigo.
Quero tambm agradecer a todos os meus colegas de trabalho na Ustore, que

sempre me impulsionam a ser um profissional melhor. Em particular, quero citar meu
colega de trabalho e amigo Allan Monteiro, que me ajudou muito com este trabalho,
revisando o texto.
Por fim, quero agradecer a Fernando Carvalho (Fish), que me ajudou na re-
viso do texto e no entendimento do trabalho. Tambm me ensinou muito no tempo
em que trabalhamos juntos, na Ustore.
4
Resumo
Aps a criao do Manifesto gil e a popularizao das metodologias geis no

desenvolvimento de software, muitas formas de otimizar ainda mais os processos
do desenvolvimento foram estudadas. Destes estudos, destacam-se as tentativas
de se inserir a ideologia Lean no desenvolvimento de software. Em 2003, um estudo
tornou possvel esta adaptao, dando a Engenharia de Software mais uma meta
importante, a saber, a eliminao do desperdcio, a reao ainda mais rpida s
mudanas nos requisitos e um maior aumento na qualidade, dando origem as prti-
cas contnuas da Engenharia de Software. Nestas prticas, se destacam a inte-
grao, entrega e implantao contnuas. Baseando-se nestas prticas, uma tenta-
tiva de aproximar as equipes de desenvolvimento de software e as equipes de op-
eraes das empresas, surgiu o DevOps, que alm de promover o alinhamento
destas equipes ainda se utiliza de todas as prticas contnuas, de forma que pos-
svel contemplar todos os setores da organizao com esta cultura. Para que as
prticas contnuas citadas sejam realizadas, necessrio que todas as etapas do
pipeline sejam automatizadas. Com esse objetivo, muitas ferramentas so criadas,
atravs de empresas que veem na automao de processos um mercado lucrativo
ou da comunidade DevOps, que muito ativa e desenvolve constantemente novas
ferramentas. Com essa grande quantidade de ferramentas, surge a dvida de qual
adequada, ao se criar um projeto novo ou na iniciativa de migrao de um projeto
existente para as prticas do DevOps.
Palavras-chave: DevOps, Pipeline automatizado, Integrao Contnua, Entrega Con-

tnua, Implantao Contnua, Ferramentas, Engenharia de Software Contnua, Ide-
ologia Lean.
5
Abstract
After the creation of the Agile Manifesto and the popularization of agile
methodologies in software development, many ways to further optimize the pro-
cesses of development have been studied. These studies, noteworthy are the at-
tempts to insert the ideology of Lean in software development. In 2003, a study
made possible this adaptation, giving the Software Engineer and more an important
goal, namely, the elimination of waste, the reaction still faster to changes in require-
ments and a greater increase in the quality, giving rise to the practice of continuous
Software Engineering. These practices include the integration, delivery and deploy-
ment, continuous. On the basis of these practices, an attempt of approaching the
software development teams and the operations teams of the companies, it
emerged in the DevOps, that in addition to promoting the alignment of these teams
still use all the practices continued, so that it is possible to cover all sectors of the
organization with this culture. For that the practices of continuous mentioned are
carried out, it is necessary that all the stages of the pipeline are automated. With this
goal, many tools are created through companies that you see on the automation of
processes to a lucrative market or community DevOps, which is very active and
constantly develops new tools. With such a large amount of tools, comes the ques-
tion of what is appropriate, if you create a new project or on the initiative of the mi-
gration of an existing project to the practices of DevOps.
Keywords: DevOps, Pipeline, automated, Continuous Integration, Continuous Deliv-

ery, Continuous Deployment, Tools, Software Engineering Continuous, Lean Think-
ing.
6
Lista de abreviaturas, siglas e smbolos
ES Engenharia de Software
XP Extreme Programing
IC Integrao Contnua
EC Entrega Contnua
DC Deploy Contnuo
DevOps Desenvolvimento e Operaes
SLA Acordo de Nvel de Servio
VCS Sistema de Controle de Verso
UI Interface do Usurio
7
ndice de imagens
Figura 1. Continuous * - O conjunto de todas as prticas contnuas ....................... 26
Figura 2. reas de cobertura da IC, EC e DC no pipeline de implantao .............29
Figura 3. Pipeline de implantao ............................................................................30
Figura 4. reas de cobertura das ferramentas.........................................................36
Figura 5. Ferramentas de requisitos, desenvolvimento e operaes....................... 43
Figura 6. Ferramentas de testes, qualidade e comunicao ................................... 44
Figura 7. Menu principal da ferramenta ...................................................................45
Figura 8. Boto de redirecionamento de pgina da ferramenta ...............................46
Figura 9. Ferramentas gratuitas mais recomendadas para desenvolvimento

Desktop(Mac) pela ferramenta de escolha .............................................................46
Figura 10. Todas as ferramentas gratuitas recomendadas para desenvolvimento

Desktop(Mac) pela ferramenta de escolha .............................................................. 47
Figura 11. Grafo representando as integraes entre as ferramentas recomendadas

47
Figura 12. Todas as ferramentas gratuitas catalogadas para o MidiaCenter ........... 49
Figura 13. Todas as ferramentas gratuitas catalogadas para o MidiaCenter ........... 50
8
Sumrio
1. INTRODUO................................................................................................ 13
1.1 CONTEXTO ....................................................................................................13
1.2 PROBLEMA ....................................................................................................16
1.3 OBJETIVOS ....................................................................................................17
1.4 ESCOPO ........................................................................................................17
1.5 METODOLOGIA .............................................................................................18
1.6 ORGANIZAO DO TRABALHO ..................................................................19
2. REFERENCIAL TERICO ............................................................................20

2.1 A IDEOLOGIA LEAN .......................................................................................20
2.1.1 A IDEOLOGIA LEAN NA ENGENHARIA DE SOFTWARE ..........................21
2.1.1.1 1 PRINCPIO - ELIMINE O DESPERDCIO ............................................22
2.1.1.2 2 PRINCPIO - AMPLIFIQUE O APRENDIZADO ....................................22
2.1.1.3 3 PRINCPIO - ADIE UMA DECISO O MXIMO POSSVEL ...............22
2.1.1.4 4 PRINCPIO - ENTREGUE O MAIS RPIDO POSSVEL .....................23
2.1.1.5 5 PRINCPIO - FORTALEA A EQUIPE .................................................23
2.1.1.6 6 PRINCPIO - CONSTRUA QUALIDADE ..............................................23
2.1.1.7 7 PRINCPIO - OTIMIZE O TODO ..........................................................24
2.2 ENGENHARIA DE SOFTWARE CONTNUA .................................................24
2.2.1 ESTRATGIA E PLANEJAMENTO .............................................................26
2.2.1.1 PLANEJAMENTO CONTNUO.................................................................26
2.2.1.2 ORAMENTO CONTNUO ......................................................................26
2.2.2 DESENVOLVIMENTO DE SOFTWARE ......................................................27
2.2.2.1 INTEGRAO CONTNUA ......................................................................27
2.2.2.2 ENTREGA CONTNUA .............................................................................28

9
2.2.2.3 DEPLOY CONTNUO ...............................................................................28
2.2.2.3.1 PIPELINE DE IMPLANTAO ..............................................................29
2.2.2.3.2 BENEFCIOS E DESAFIOS DO DEPLOY CONTNUO ........................30
2.2.2.4 VERIFICAO CONTNUA ......................................................................31
2.2.2.5 TESTE CONTNUO ..................................................................................31
2.2.2.6 CONFORMIDADE CONTNUA ................................................................31
2.2.2.7 SEGURANA CONTNUA .......................................................................32
2.2.2.8 EVOLUO CONTNUA ..........................................................................32
2.2.3 OPERAES ..............................................................................................32
2.2.3.1 USO CONTNUO ......................................................................................32
2.2.3.2 CONFIANA CONTNUA .........................................................................32
2.2.3.3 MONITORAMENTO CONTNUO .............................................................33
2.2.4 MELHORIA E INOVAO ...........................................................................33
2.2.4.1 MELHORIA CONTNUA ...........................................................................33
2.2.4.2 INOVAO CONTNUA ...........................................................................33
2.2.4.3 EXPERIMENTAO CONTNUA .............................................................33
2.3 DEVOPS .........................................................................................................34
2.3.1 DEVOPS E AGILE .......................................................................................34
3. MAPEAMENTO DAS FERRAMENTAS ......................................................... 36

3.1 REAS DE ATUAO DAS FERRAMENTAS ............................................... 37
3.1.1 REQUISITOS...............................................................................................37
3.1.2 DESENVOLVIMENTO .................................................................................37
3.1.3 OPERAES ..............................................................................................38
3.1.4 TESTES .......................................................................................................39
3.1.5 QUALIDADE ................................................................................................39
10
3.1.6 COMUNICAO E FEEDBACK..................................................................40
3.2 SEPARAO E CLASSIFICAO DAS FERRAMENTAS ............................40
3.2.1 NOME ..........................................................................................................40
3.2.2 SUBREA ....................................................................................................40
3.2.3 WEBSITE.....................................................................................................41
3.2.4 ARTIGOS .....................................................................................................41
3.2.5 TIPO DE PROJETO ....................................................................................41
3.2.6 LINGUAGEM DE PROGRAMAO ...........................................................41
3.2.7 MANTENEDORES ......................................................................................41
3.2.8 TIPO DE LICENA ......................................................................................41
3.2.9 INTEGRAO .............................................................................................42
3.2.10 PLATAFORMA ...........................................................................................42
3.2.11 PARADIGMA ..............................................................................................43
3.3 FERRAMENTAS MAPEADAS ........................................................................43
3.3.1 FERRAMENTAS CATALOGADAS ..............................................................43
3.3.2 GRAFO DE INTEGRAO DE FERRAMENTAS ......................................44
4. AUTOMATIZANDO A ESCOLHA DAS FERRAMENTAS ...............................45

4.1 FERRAMENTA ..............................................................................................45
4.2 ESTUDO DE CASO ........................................................................................48
4.2.1 EMPRESA ...................................................................................................48
4.2.2 PROJETO ....................................................................................................48
4.2.3 UTILIZANDO A FERRAMENTA ...................................................................49
5. CONSIDERAES FINAIS..............................................................................51
5.1 LIMITAES ..................................................................................................51
5.2 TRABALHOS FUTUROS................................................................................ 51
11
5.3 CONCLUSO ................................................................................................52
REFERNCIAS BIBLIOGRFICAS .................................................................... 53

APNDICE A - TABELA DE FERRAMENTAS ....................................................58
APNDICE B - IMAGENS DA FERRAMENTA ....................................................64
12
1. Introduo
1.1 Contexto
Em 2017, a Engenharia de Software (ES) est completando 49 anos de

existncia. A busca por mtodos de engenharia para o desenvolvimento de software
foi proposta em 1968 na conferncia da OTAN [13, 16]. A ES foi criada na tentativa
de resolver os problemas que levaram a falta de eficincia generalizada na entrega
de grandes sistemas, envolvendo atrasos, ausncia de funcionalidades e custos
que iam muito alm do esperado [16]. Ainda seguindo o raciocnio de [16], como o
software intangvel, logo, ele no tem limites para evoluir, entretanto, de todo esse
potencial emerge a complexidade que envolve os sistemas de software. Ao se
tornarem complexos, alm dos problemas citados anteriormente, os sistemas se
tornaram difceis de entender e muito caros para serem modificados. Como conse-
quncia disso, os grandes projetos de software passaram a ser encarados com
grande desconfiana.
A ES ento passou a dar suporte a criao de produtos de software criados

por equipes que eram responsveis por alterar e manter o software durante todo o
seu ciclo de vida. A ES trouxe consigo tambm, um conjunto de tcnicas desti-
nadas a apoiar a especificao, projeto e evoluo dos sistemas de software. Soft-
ware, a partir desse momento, no era mais apenas um programa de computador
ou meramente um sistema, o termo passou a agregar a documentao associada e
os dados de configuraes, que eram necessrios para tornar os sistemas op-
erveis. Os documentos e dados poderiam ser arquivos de configurao, documen-
tao do sistema, documentao da estrutura, manuais, documentos de arquitetura
e documentaes do usurio [16].
Para dar suporte a emergente ES, foram criadas as Metodologias de Desen-

volvimento (ou Processos), que so conjuntos de atividades com resultados associ-
ados que auxiliam a produo de software, onde resultado final o produto [16, 17].
As primeiras metodologias foram criadas utilizando modelos tradicionais da Engen-
haria de Sistemas [16].
13
As Metodologias Tradicionais foram criadas para o contexto da poca visando
os mainframes e os terminais burros [18], entretanto com o avano da tecnologia,
surgiram alternativas de menor custo, o que ajudou a acelerar o surgimento da
globalizao, que por sua vez, abriu novos mercados, gerando uma concorrncia a
nvel mundial. Nesse momento, a competitividade das empresas aumentou severa-
mente, tornando os modelos tradicionais incompatveis, devido a grande demanda
por produtos de software [2, 16]. As Metodologias Tradicionais passaram a ser en-
caradas como pesadas e orientadas a documentao [2, 16, 17, 24] e na dcada de
1980, muitos pesquisadores e desenvolvedores publicaram artigos com o objetivo
de divulgar dados que informavam sobre os problemas que ocorriam com o uso
dessas metodologias no desenvolvimento de software [16, 17]. As mudanas con-
stantes nos projetos e as incertezas nos requisitos converteram o desenvolvimento
de software em uma atividade muito mais dinmica, inviabilizando o levantamento
dos requisitos de forma estvel, como era exigido nos modelos tradicionais,
atrasando o cronograma dos projetos ao postergar a entrega para muito alm do
prazo acordado inicialmente [16]. Esta falta de agilidade dos projetos utilizando
mtodos tradicionais se tornou sria, de modo que alguns projetos ao chegarem na
sua fase final com o software j disponvel para uso, o mesmo j havia se tornado
intil devido as mudanas radicais em requisitos, regras de negcio e etc [16].
Em 1995, o Chaos Report [19] divulgou um preocupante conjunto de dados

tendo como base 8380 projetos. Estes dados mostravam que apenas 16,2% dos
projetos foram entregues com tempo, custos e requisitos de acordo com o espera-
do. 31% destes projetos, foram cancelados mesmo antes de estarem finalizados e
52,7% deles foram entregues com algumas das variveis citadas anteriormente fora
do limite acordado, ou seja, foram entregues fora do prazo, com o custo acima do
acordado ou as funcionalidades no correspondiam as expectativas dos clientes.
Os dados ainda mostravam que entre os projetos que foram entregues com prob-
lemas, a mdia dos atrasos foi de 222% do tempo, a de custo foi de 189% e a m-
dia de funcionalidades entregues conforme o acordado foi de 61% [17, 19].
Na dcada de 1990, a insatisfao com os mtodos tradicionais aumentou

ainda mais. Isso porque esses projetos orientados a planos no atendiam a maioria
dos projetos de software, pois se gastava mais tempo com anlises e documen-
14
taes do que com desenvolvimento e testes [16]. Com isso os desenvolvedores
propuseram a criao das Metodologias geis de Desenvolvimento de Software.
Segundo os desenvolvedores, essas metodologias atendiam melhor o contexto dos
projetos de software e a grande demanda, pois so baseadas em entregas incre-
mentais, sendo mais flexveis no momento em que os requisitos mudam [16, 17].
Finalmente, em 2001 foi criada a Aliana gil, a partir do encontro de 17 especialis-
tas em processos de software que representavam as metodologias Scrum [23], Ex-
treme Programing (XP) [22] e outras. Neste encontro foram estabelecidos princpios
comuns entre as metodologias, dando origem ao Manifesto gil [20, 21].
A partir desse momento, as metodologias geis se tornaram muito populares

[1, 24], passando a ser largamente adotadas at os dias de hoje. Isso se deve s
promessas na velocidade de entrega, na capacidade de se adaptar as mudanas,
alm do aumento na qualidade e maior satisfao dos clientes [2, 4, 9, 12, 16, 17].
Grandes empresas do ramo da tecnologia como Amazon, Facebook e Google uti-
lizam as metodologias geis [2].
Apesar de atender os projetos de software modernos muito melhor que as

metodologias tradicionais, as metodologias geis ainda desperdiam recursos
valiosos ao no incentivar uma sinergia entre os times de qualidade, operaes e
desenvolvimento. Estudos demonstram que uma colaborao mais aperfeioada
entre estas equipes, possibilita melhorias nos processos de desenvolvimento e op-
eraes, tornando a organizao mais competitiva [4, 13].
Nos ltimos anos, estamos vivenciando mais uma revoluo nos processos de
desenvolvimento de software, que est sendo chamada de era Ps-gil [4]. A ne-
cessidade da equipe de desenvolvimento obter maior frequncia nos feedbacks dos
clientes e de entregar frequentemente o software no ambiente de produo, torna
possvel, dependendo do domnio da aplicao, a realizao de vrias implantaes
por dia, o que no vivel em uma abordagem gil, pois apesar de curtas, as iter-
aes duram um certo tempo para serem realizadas [4]. nesse contexto que surge
o conceito de Implantao Contnua (DC1) [4].
O DC tem suas razes nos conceitos da ideologia Lean [2, 4, 6, 9], que orig-
inria da fabricao, sendo inserida no contexto da ES pela primeira vez no Lean
1 Para fins didticos, este trabalho utilizar a sigla DC, misturando o os termos em ingls e em portugus: Deploy Contnuo.
15
Software Development [4]. Esta abordagem tem a Integrao Contnua (IC) e a En-
trega Contnua (EC) como pr-requisitos para ser alcanada, alm de necessitar de
um pipeline de desenvolvimento automatizado e uma ampla infraestrutura acom-
panhada de processos e prticas compatveis [4, 6]. Uma outra abordagem que uti-
liza largamente os mtodos contnuos de desenvolvimento o DevOps [4, 5, 6, 7, 9,
11], que enfatiza a colaborao e a comunicao entre as equipes de desenvolvi-
mento e as de operaes, sob a premissa que a cooperao das duas reas resulta
em um rpido desenvolvimento contnuo [4, 5, 11, 18]. J existem muitas empresas
que utilizam prticas contnuas, incluindo o DC [2, 6, 10]. Trabalhos como [2, 4, 6,
11], mostram que a implantao frequente ajuda na criao e desenvolvimento de
produtos melhores por serem mais reativos.
Para que tudo isso seja possvel, uma mudana na cultura organizacional e
uma quantidade considervel de ferramentas de apoio so requeridas [2, 4, 8, 11].
Para que o pipeline de desenvolvimento seja automatizado at que a implantao
seja feita no ambiente de produo, a empresa deve configurar uma cadeia de fer-
ramentas autoassociadas e estabelecer fluxos de trabalho redirecionados estas
ferramentas [2, 11].
1.2 Problema
No mundo DevOps, vrios tipos de ferramentas so utilizados para garantir a

entrega rpida e com qualidade do software. As ferramentas devem suportar uma
boa parte do pipeline de desenvolvimento, podendo chegar at a sua totalidade,
isso vai depender de vrios fatores que envolvem cultura organizacional e limitaes
tcnicas das equipes e ferramentas, alm do tipo de natureza do produto [25].
Um estudo mostra vrias observaes feitas por usurios do DevOps [15]. Es-
tas observaes foram colhidas atravs de oficinas de design e entrevistas que pos-
teriormente alimentaram um banco de dados, onde foi realizada uma anlise de
sentimentos. Um dos problemas mais evidentes identificados pelos participantes
a escolha de ferramentas para a automao dos processos.
16
1.3 Objetivos
Este trabalho tem como objetivo geral o mapeamento de ferramentas e a cri-

ao de uma ferramenta conceitual, para auxiliar na escolha das ferramentas que
sero utilizadas em projetos DevOps. A ferramenta de escolha deve dar apoio a pro-
jetos que utilizem as prticas de IC, EC ou DC, informando as principais ferramen-
tas, disponveis nos melhores trabalhos da literatura atual, para todo o pipeline de
desenvolvimento.
H destaque tambm para alguns objetivos especficos importantes:
1. Informar quais as diferenas entre as prticas contnuas e as metodolo-

gias geis;
2. Verificar at que ponto as prticas contnuas so benficas para os pro-

jetos de software;
3. Analisar as ferramentas mais utilizadas em projetos reais, atravs de es-

tudos de caso disponveis na literatura;
4. Compreender como as ferramentas so classificadas e organizadas para

cada etapa do pipeline de desenvolvimento.
1.4 Escopo
Este trabalho se limita criao de uma ferramenta conceitual que informa

quais so as principais ferramentas que envolvam as prticas contnuas descritas
na seo 1.3, cobrindo todas as reas do pipeline exibido em [10]. O pipeline ser
explicado na seo 2.2.2.3.1. O estudo e mapeamento das ferramentas foi suporta-
do por dois trabalhos com um vis prtico sobre o assunto, um deles [2] demonstra
empiricamente quais as ferramentas mais usadas pelas equipes DevOps atravs de
entrevistas realizadas em 18 empresas finlandesas que esto comprometidas em
realizar entregas rpidas com maior valor para o cliente. O outro trabalho [26],
fornece uma reviso sistemtica da literatura contendo 69 estudos primrios publi-
cados de 2004 2012, onde a segunda pergunta que motivou a reviso est rela-
cionada ao uso de ferramentas que automatizam o pipeline de implantao.
17
Nestes trabalhos, as ferramentas mapeadas so suficientes para automatizar
os pipelines das diversas empresas e projetos que foram estudados [2, 10], no en-
tanto, vale ressaltar que as ferramentas no cobrem a totalidade da grande maioria
dos casos e o mapeamento contido neste trabalho no exaustivo.
O foco deste trabalho no criar um meio para resolver o problema da escol-

ha de ferramentas, mas sim levantar questionamentos que incentivem a construo
de:
1. Ferramentas que suportem completamente o pipeline dos diversos tipos

de projetos de software;
2. Sistemas que auxiliem as empresas, informando as boas prticas e

faam o mapeamento das diversas ferramentas que automatizam o
pipeline dos diversos tipos de projetos de software.
1.5 Metodologia
O mtodo adotado para chegar ao objetivo composto por uma pesquisa ex-
ploratria, se utilizando dos principais repositrios em busca de artigos, publi-
caes, peridicos, revistas, dissertaes, estudos de caso e revises sistemticas
que tragam informaes das principais pesquisas sobre prticas contnuas e
cadeias de ferramentas que suportem estas prticas, a fim de trazer embasamento
para a redao deste trabalho e possibilitar que os objetivos sejam alcanados.
Os repositrios de busca foram:
IEEEXplore Digital Library [27];
Science Direct [28];
ACM [29];
Scopus [30];
Google Scholar [31].
Outra tcnica utilizada na obteno de trabalhos foi a leitura das referncias

dos trabalhos mais relevantes.
18
Cada trabalho relevante encontrado foi inserido na ferramenta Mendeley 1, um
gerenciador e compartilhador de documentos de pesquisa. Para capturar o trabal-
ho, um plugin desta ferramenta para o Google Chrome2 foi utilizado.
Na leitura de cada trabalho, o pargrafo lido foi grifado e resumido para ajudar
no mapeamento da informao.
Para modelar as ferramentas, foi utilizada a ferramenta Shapes 3. Para criar a

ferramenta, foi utilizada a ferramenta Visual Studio Code.
1.6 Organizao do trabalho
Este trabalho est organizado da seguinte forma: O captulo 1 d uma viso

histrica da ES at a chegada do DevOps, informando as reais necessidades das
criaes de novas formas de se construir software. O captulo 2 d um embasamen-
to terico para todos os conceitos apresentados. O captulo 3 exibe o mapeamento
das ferramentas e informa os dados coletados. O captulo 4 fala da ferramenta cria-
da e mostra um estudo de caso feito em um projeto real. Por fim, o captulo 5 con-
clui o trabalho, dissertando sobre trabalhos futuros e as limitaes deste.
1 https://www.mendeley.com
2 https://www.google.com/chrome/browser/desktop/index.html
3 http://shapesapp.com/
19
2. Referencial Terico
Este captulo servir de arcabouo terico do trabalho, descrevendo os princi-

pais termos que so utilizados.
2.1 A ideologia Lean 1
No fim da dcada de 1940, uma pequena empresa chamada Toyota decidiu

fabricar carros no Japo [35]. Porm, verificou-se que os carros tinham que ser
baratos, pois os estragos causados na segunda grande guerra devastou a econo-
mia do pas e, consequentemente, as pessoas no tinham muito dinheiro [36].
Com o conhecimento que se tinha na poca, a maneira de haver fabricao

barata de automveis era atravs de uma linha de produo em massa. O problema
que este tipo de produo no atendia o mercado japons, pois era um mercado
relativamente pequeno. Para resolver o problema de fabricar carros em pequena
quantidade to baratos quanto os produzidos em massa, surgiu o Sistema Toyota
de Produo, Tendo como a cabea por trs deste sistema, Taiichi Ohno2[35].
Esta nova forma de desenvolver produtos tinha uma meta: A eliminao de

desperdcios [1, 35]. A forma de encarar o desperdcio foi modificada com a nova
ideologia. Desperdcio, a partir desse vis teve o seu significado ampliado, entre os
vrios tipos, possvel destacar:
Superproduo (Recursos no desejados);
Atividades que no so necessrias;
Produto esperando que outras atividades terminem;
Passos extras no processo de desenvolvimento;
Defeitos.
O foco da ideologia era criar e entregar o produto imediatamente aps o pedi-

do, ou seja, o desenvolvimento deveria comear aps a solicitao do cliente,
porm a meta entregar o produto rapidamente. Segundo a ideologia, quando um
projeto comea, ele deve ser finalizado o mais rpido possvel, isso porque o produ-
1 Termo criado por Krafcik em seu trabalho intitulado Triumph of the lean production system no ano de 1988 [2].
2 O Homem que ficou conhecido como o pai do Sistema Toyota de Produo e do Sistema Kanban [37].
20
to que est em desenvolvimento no est agregando valor at que seja entregue.
Produtos em desenvolvimento so encarados como um estoque de fbrica [35].
O primeiro passo para o desenvolvimento enxuto (do ingls, lean) aprender a

detectar o desperdcio. O segundo passo descobrir as maiores fontes de des-
perdcio e elimin-las. Estes dois passos devem ser repetidos sempre. Depois de
um tempo, at as coisas que pareciam mais essenciais sero gradualmente elimi-
nadas [35].
2.1.1 A ideologia Lean na Engenharia de Software
As origens desta metodologia vem da fabricao de carros, mas os seus

princpios podem ser aplicados em outras reas. Entretanto, elas no podem ser
aplicadas diretamente vindas de uma linha de produo de fbrica na ES.
Houveram muitas tentativas de inserir no desenvolvimento de software as

prticas da ideologia Lean. Segundo [35] isso acontece porque a criao de soft-
ware no uma prtica de produo, e sim uma prtica de desenvolvimento.
O conceito de desenvolvimento de software Lean foi introduzido pelo trabalho

publicado por Poppendieck M. e Poppendieck T. [35]. Neste trabalho, o desen-
volvimento de software deve seguir sete princpios fundamentais [2, 24, 35]:
1. Eliminao de desperdcio;
2. Amplificao do aprendizado;
3. Adiamento das decises;
4. Entregar o mais rpido possvel;
5. Fortalecimento da equipe;
6. Construo de qualidade;
7. Otimizao do todo.
Ao incorporar estes princpios ES, surge a abordagem contnua no desen-

volvimento de software, uma tendncia emergente que adota uma abordagem hols-
tica no desenvolvimento contnuo de software [24].
21
2.1.1.1 1 Princpio - Elimine o desperdcio
O desperdcio qualquer coisa que no agrega valor a um produto. O valor

considerado aqui como o produto percebido pelo cliente. Na ideologia Lean, o
conceito de desperdcio um grande obstculo. Se o documento de requisitos fi-
cou somente no papel, isso um desperdcio. Se algo foi feito alm do necessrio,
isso um desperdcio. Se houver cdigo alm do necessrio, isso um desperd-
cio. Na fabricao, mover o produto um desperdcio. No desenvolvimento de pro-
dutos, transferir o desenvolvimento de um grupo para outro o desperdcio. O ideal
descobrir o que o cliente quer, e depois cri-lo ou desenvolv-lo e entregar ex-
atamente o que ele quer imediatamente. Qualquer coisa que no satisfaa rapida-
mente a necessidade do cliente desperdcio [35].
2.1.1.2 2 Princpio - Amplifique o aprendizado
O desenvolvimento de software um trabalho de aprendizado, diferente da

produo que um exerccio de prticas rgidas e, por esse motivo, a ideologia
Lean no desenvolvimento resulta em prticas diferentes das que so realizadas na
produo. Como o desenvolvimento produz variaes no processo de aprendiza-
gem, a equipe deve buscar meios de transferncia de conhecimentos entre os seus
membros. Muito importante para este princpio manter a comunicao entre a
equipe, bem como o feedback contnuo entre as diferentes equipes e usurios du-
rante o desenvolvimento do software [35].
2.1.1.3 3 Princpio - Adie uma deciso o mximo possvel
Como as prticas de desenvolvimento envolvem muitas incertezas, principal-

mente em suas fases iniciais, o adiamento das tomadas de decises so mais efi-
cazes. Postergar as decises importante porque as decises podem ser tomadas
de forma mais eficiente quando so baseadas em fatos, no em especulaes
como ocorre diante das incertezas. Em um projeto em evoluo, manter as opes
disponveis mais valioso do que fazer uma escolha logo no incio [35].
22
2.1.1.4 4 Princpio - Entregue o mais rpido possvel
O desenvolvimento rpido tem muitas vantagens. Sem rapidez na entrega,

voc no consegue atrasar as decises. Sem velocidade, voc no tem feedback
confivel. No desenvolvimento, a descoberta fundamental para a aprendizagem,
design, implementao, feedback, melhoria. Quanto mais curtos forem estes ciclos,
maior a possibilidade de se aprender. Velocidade assegura que os clientes esto re-
cebendo o que precisam agora, e no o que eles precisavam ontem. Tambm per-
mite adiar a ideia final do que eles realmente querem at que eles realmente saibam.
Aumentar o fluxo de valor, tanto quanto for possvel, uma estratgia fundamental
para a eliminao de desperdcio [35].
2.1.1.5 5 Princpio - Fortalea a equipe
Envolver os desenvolvedores nas decises tcnicas fundamental para al-

canar a excelncia. Quando equipados com conhecimentos necessrios e guiados
por um lder, os desenvolvedores tomaro decises melhores em grupo, tanto na
rea tcnica como na de processos. Com as decises sendo tomadas tardiamente
e com velocidade na entrega, no vivel apenas uma pessoa comandando as
atividades. Assim, as prticas Lean usam tcnicas de produo puxada para agen-
dar o trabalho atravs de mecanismos de sinalizao de tarefas para que os trabal-
hadores saibam o que precisa ser feito. No desenvolvimento de software Lean, a
tcnica de produo puxada 1 acordada para entregar verses cada vez mais refi-
nadas do software em intervalos regulares. A sinalizao feita atravs de grficos
visveis, reunies dirias, integrao frequente e testes abrangentes [35].
2.1.1.6 6 Princpio - Construa qualidade
Um sistema de qualidade quando um usurio pensa: "Sim! Isso exata-

mente o que eu quero. Algum leu meus pensamentos!. O software precisa de um
1Um bom texto sobre a tcnica pode ser encontrado aqui: http://www.lean.org.br/conceitos/102/definicao-de-producao-puxada-
e-sistemas-puxados.aspx
23
nvel adicional qualidade: deve manter sua utilidade ao longo do tempo. Espera-se
que o software evolua medida que se adapta s mudanas. O software com qual-
idade possui uma arquitetura coerente, alto grau de usabilidade, eficcia, susten-
tvel, adaptvel e extensvel. Qualidade vem de um projeto liderado sabiamente,
com uma equipe com conhecimentos relevantes, comunicao efetiva, disciplina
saudvel [35].
2.1.1.7 7 Princpio - Otimize o todo
Obter qualidade em sistemas complexos requer uma experincia profunda em

diversas reas. Um dos problemas mais difceis de resolver no desenvolvimento de
um produto que os especialistas em alguma rea (por exemplo, banco de dados
ou GUI) tendem a maximizar o desempenho na parte do produto que representa sua
prpria especialidade em vez de se concentrar no desempenho geral do sistema.
Muitas vezes, o bem comum sofre se as pessoas atendem primeiro a seus prprios
interesses [35].
2.2 Engenharia de Software Contnua
No incio da ES, o desenvolvimento de software foi marcado pela falta de flexi-

bilidade nos processos, o que prejudicava atividades importantes como planeja-
mento, anlise, design e construo. Isso pode ser exemplificado no modelo de
processo em cascata para desenvolvimento de software, descrito por [18]. Ultima-
mente, surgiram abordagens que buscam aumentar a freqncia de certas ativi-
dades crticas no intuito de superar os desafios. Prticas como a entrega antecipa-
da e entrega frequente esto bem estabelecidas no desenvolvimento de software
aberto [2]. Podemos ver claramente esta afirmao concretizada ao observarmos a
crescente adoo da prtica de IC. A popularidade desta prtica se deve a sua re-
comendao explcita no XP [22].
Porm o que se nota nas tendncias recentes que as prticas contnuas vo

muito mais alm do que apenas a prtica da IC. Um exemplo que as prticas
geis no suportam o alinhamento de prticas com as reas de negcios ou recur-
24
sos humanos1. Outro exemplo o DevOps, que reconhece a necessidade das prti-
cas contnuas [2]. Em vez de uma seqncia de atividades que so realizadas por
equipes ou departamentos claramente distintos, a engenharia de software contnua
estabelece prticas contnuas, com suas origens nos conceitos encontrados na
ideologia Lean, no entanto, h alguns estudos que erroneamente ligam estas prti-
cas apenas as prticas geis [9, 24]. Enquanto o desenvolvimento de software gil
foca principalmente no desenvolvimento do software, o desenvolvimento contnuo
tem um foco muito explcito no processo de ponta a ponta: do cliente para a entre-
ga. Com base em uma comparao de princpios e prticas de desenvolvimento
gil e Lean, estudos concluem que este foco de ponta a ponta a principal difer-
ena entre as abordagens [24].
H uma grande quantidade de termos e conceitos envolvidos na engenharia

de software contnua.Por ser uma rea de pesquisa relativamente nova em muitos
aspectos, uma discordncia entre os trabalhos sobre o que uma prtica ou outra e
em certos momentos, algumas prticas se confundem em seus significados. Por
exemplo, o significado de IC em [24] igual ao significado de DC em [2]. J em [4],
o significado de DC se confunde com o de EC apresentado por [2]. Para os fins
deste trabalho, a distino entre IC, EC e DC crucial. Portanto vamos adotar a
seguinte definio:

Integrao Contnua: os desenvolvedores enviam suas mudanas com
frequncia para repositrios de controle de verso, que desencadeiam
testes em servidores de IC;
Entrega Contnua: as etapas da EC incluem passos automatizados, adi-

cionais IC, para preparar uma verso do software pronto para a implan-
tao.Normalmente, a implantao para o ambiente de produo no to-
talmente automatizada e requer interveno manual na EC;
Deploy Contnuo: a implantao no ambiente de produo automatizada.
Esta definio foi a mais comum encontrada nos trabalhos pesquisados.
1Ultimamente tm surgido algumas tentativas do alinhamento das metodologias geis com a rea de negcios, como podemos
ver em [45]
25
A figura 1 mostra todas as prticas contnuas e suas relaes com a organiza-
o. Uma descrio sucinta de cada uma ser feita, porm as mais importantes
para este trabalho sero discutidas mais detalhadamente.
Figura 1. Continuous * - O conjunto de todas as prticas contnuas
Fonte: [2]
2.2.1 Estratgia e Planejamento
Aqui sero citadas as prticas contnuas relativas ao setor estratgico da or-

ganizao, conhecidas como BizDev1.
2.2.1.1 Planejamento Contnuo
Envolve os vrios stakeholders das reas de negcios e de desenvolvimento

de software. Esta prtica gera planos e artefatos dinmicos que vo evoluindo de
acordo com as mudanas no ambiente dos negcios e, portanto, envolvem uma
maior integrao entre planejamento e execuo [9, 24].
2.2.1.2 Oramento Contnuo
1 BizDev no ser detalhado aqui, pois no faz parte do escopo deste trabalho.
26
O oramento tradicionalmente um evento anual, informando as previses de
investimentos, receitas e despesas de uma organizao para o prximo ano. Esta
prtica sugere que o oramento tambm se torne uma atividade contnua, para fa-
cilitar as mudanas durante o ano [9, 24].
2.2.2 Desenvolvimento de software
Aqui sero citadas as prticas contnuas relativas ao setor de desenvolvimento

de software da organizao, que faz parte do DevOps.
2.2.2.1 Integrao contnua
De todas as praticas contnuas, a IC a mais popular. Esta popularidade

possvel porque o XP faz uma recomendao explcita da prtica. De fato, a IC al-
tamente compatvel com as metodologias geis e por isso muitas ferramentas de
cdigo aberto esto disponveis gratuitamente para automatizar o processo de IC
[9].
Como vimos, um dos princpios do desenvolvimento Lean "entregar o mais

rpido possvel. Seguindo esta regra, o processo de desenvolvimento gil incorpo-
ra o conceito de IC.Para permitir a IC, os desenvolvedores da equipe integram seu
trabalho com frequncia no servidor de controle de verso.A IC tambm inclui im-
plicitamente a prtica de Teste Contnuo para obter feedback rpido e frequente
para a equipe de desenvolvimento1 [2]. Por exemplo, h ferramentas que sinalizam
assim que problemas so encontrados na construo [9].
Sthl e Bosch estudaram quais os efeitos da IC [38], apresentando as difer-

enas entre as implementaes desta prtica. Mais tarde, eles desenvolveram um
meta-modelo para a implementao da IC nas organizaes, visando as diferentes
implementaesencontradas em seus estudos [39].Eles descobriram que a prtica
da IC varia entre as empresas e at mesmo entre projetos da mesma empresa.
Tambm descobriram que apesar de as empresas chamarem o seu processo de IC,
nem sempre os princpios das prticas contnuas so seguidos [2].
Um fluxo de etapas da IC est descrito na seo 2.2.2.3.1.
1 A figura 3 ilustra este fluxo.

27
2.2.2.2 Entrega contnua
A EC a prtica que vem logo aps as prticas de IC,implantando o pacote

criado na construo em um ambiente de testes, que no deve ser confundido com
o ambiente de produo. No pacote implantado, h toda a alterao de cdigo de
cada desenvolvedor j integrada, testada e compilada. possvel que existam
vrios estgios de teste neste ambiente antes da implantao na produo. Alguns
testes nesta etapa podem ser manuais, o que a torna um pouco mais demorada.
Com os testes realizados e aprovados, o software aprovado para ser implantado
na produo. A Diferena da EC para o DC, que no DC, o envio para a produo
acontece automaticamente, sem aprovao explcita [2, 45].
A EC permite que os desenvolvedores e o time de qualidade automatizem

testes que vo alm dos testes de unidade, de forma que seja possvel verificar as
novas verses em vrias dimenses antes de implant-las na produo. Os testes
realizados na EC, podem incluir testes de interface grfica, carga, integrao, confi-
abilidade, API, etc. Esta prtica auxilia a equipe a validar com melhor preciso no-
vas verses, tonando mais fcil a preveno de erros [2, 45].
2.2.2.3 Deploy contnuo
A implantao contnua a prtica de implantao de novos softwares e fun-

cionalidades no ambiente de produo medida em que se desenvolve, ao invs
de fazer implantaes agendadas e menos frequentes. Na teoria, para que a prtica
de DC se concretize, obrigatrio o uso de um pipeline de desenvolvimento ininter-
rupto desde o repositrio at a implantao. Para que isso seja possvel,
necessria uma cadeia de ferramentas para automatizar o processo, e estabelecer
fluxos de trabalho relacionados cadeia de ferramentas. Uma cadeia de ferramen-
tas devidamente documentada e de fcil configurao, permite que uma empresa
adquira o desenvolvimento rpido e facilite a implantao rpida de novos soft-
wares para os clientes [9, 24].
28
2.2.2.3.1 Pipeline de implantao
O DC S pode ser alcanado se a organizao tiver um pipeline de implan-

tao definido e automatizado. Os desenvolvedores fazem alteraes no cdigo.
Aps isso, o sistema de controle de verso desencadeia uma fase de confirmao
no pipeline.Nesta fase, o software normalmente compilado, testado, e um artefato
de construo criado. Muitas vezes, a anlise de cdigo esttico e a coleta de
mtricas de cdigo tambm so feitas.O estgio de confirmao deve ser rpido e
capaz de capturar os erros mais graves [2, 10]. At aqui, as etapas compreendem a
prtica de IC.
Para iniciar as etapas de EC no pipeline, a etapa de testes de aceitao exe-

cutada.Esta etapa automtica,mas estes testes sero executados em um ambi-
ente de testes parecido com o de produo. Estes testes podem demorar mais
tempo para serem concludos.O objetivo desta fase validar que o software atende
aos seus critrios de aceitao e pode ser enviado para o ambiente de
produo.Depois de passar no estgio de teste de aceitao, o software pode pas-
sar por outros estgios de teste que podem ser manuais, como testes de aceitao
do usurio ou testes de capacidade.A etapa de testes manuais deve, no entanto,
ser reduzida ao mnimo, porque ela trava o pipeline de implantao. Aqui, a EC
finalizada.
Depois de passar por todas as etapas de IC e EC, o software pode ser implan-
tado na produo, configurando a prtica do DC [2].
Figura 2. reas de cobertura da IC, EC e DC no pipeline de implantao
Fonte: [44]
29
Com base nos trabalhos encontrados, o pipeline de implantao deve ser au-
tomatizado, tanto quanto possvel, ou no mnimo, semi-automatizado. recomen-
dado que todo o trabalho manual seja reduzido ao mnimo possvel, portanto, as
cadeias de ferramentas adequadas so essenciais para o DC [2].
Se durante o processo houverem falhas, ser criada uma srie de artefatos e

relatrios grficos para ajudar a garantir que os problemas que levaram a essas fal-
has sejam priorizados, sendo resolvidos o mais rpido possvel por quem for con-
siderado responsvel [9].
Figura 3. Pipeline de implantao
Fonte: [10]
2.2.2.3.2 Benefcios e desafios do Deploy contnuo
Em um dos estudos encontrados, o foco est nos potenciais benefcios e de-

safios da implantao contnua, atravs de um estudo de caso em 15 empresas
[25].As entrevistas indicam que, embora que nem todas as empresas precisem de
um DC totalmente automatizado, implantaes frequentes podem ajudar as empre-
sas a criar produtos melhores e mais reativos no desenvolvimento.A cultura organi-
zacional e fatores externos empresa, podem prejudicar a implementao de prti-
cas de implantao contnua.As questes tcnicas, como o tamanho e a complexi-
30
dade dos projetos, e a necessidade de realizar estgios de testes manuais tambm
so vistos como impedimento para a prtica efetiva do DC [2].
O DC permite a implantao (e remoo, se necessrio) de novos recursos e

modificaes com a menor sobrecarga possvel.Isso permite a organizaodeter-
minar o valor dos componentes do software mais rapidamente, com usurios reais
[25].
Um estudo de caso pode detalhar melhor os benefcios e desafios do DC [25].

Este estudo mostra os benefcios e desafios percebidos por funcionrios aps a
adoo do DC em vrias empresas finlandesas que fazem parte do N4S1, atravs
de entrevistas.
2.2.2.4 Verificao contnua
Adoo de atividades de verificao, incluindo mtodos e inspees formais

ao longo do processo de desenvolvimento. Se ope s prticas de execuo dos
testes apenas no fim das atividades de desenvolvimento [9, 24].
2.2.2.5 Teste contnuo
Prtica que envolve a automao dos testes e a priorizao de casos de teste,

para ajudar a reduzir o tempo entre a introduo dos erros e a deteco destes,
com o objetivo de elimin-los de uma forma mais eficaz [9, 24].
2.2.2.6 Conformidade contnua
Nesta prtica, o desenvolvimento de software busca satisfazer os padres de

conformidade de forma contnua, ao invs de operar uma abordagem de "big-bang"
para garantir globalmente a conformidade imediatamente antes da liberao do
produto [9, 24].
1Um programa finlands de pesquisa em empresas da rea de tecnologia da informao e comunicao que utilizam as prti-
cas da ES Contnua [40].
31
2.2.2.7 Segurana contnua
Esta prtica muda a forma como se v a segurana do software. Antes vista

como mais um requisito no funcional, agora encarada como uma preocupao
fundamental em todas as fases do ciclo de vida do desenvolvimento e at mesmo
depois da implantao, apoiada por uma abordagem inteligente para identificar vul-
nerabilidades de segurana [9, 24].
2.2.2.8 Evoluo contnua
A maioria dos sistemas de software evoluem durante o seu ciclo de vida. No

entanto, a arquitetura de um sistema se baseia em um conjunto de decises de pro-
jeto que foram feitas durante a criao do sistema. Com o decorrer do projeto, al-
gumas destas decises podem no ser mais vlidas e a arquitetura poder dificultar
algumas mudanas. Quando uma arquitetura no adequada dificulta a insero de
novos requisitos e certos "atalhos" so feitos para contornar o problema, a dvida
tcnica aumenta. Esta atividade foca em sempre haver revises destas decises de
projeto ao longo do ciclo de vida [9, 14, 24].
2.2.3 Operaes
Aqui sero citadas as prticas contnuas relativas ao setor de operaes da

organizao, que faz parte do DevOps.
2.2.3.1 Uso contnuo
Esta prtica visa a reteno de clientes ao invs de atrair novos [9, 24]. Isso s
possvel atravs da prtica de manuteno contnua, que melhor explorada em
[3].
2.2.3.2 Confiana contnua
Nesta prtica, a confiana desenvolvida ao longo do tempo como resultado

de interaes, baseadas na crena de que um fornecedor atuar de forma coopera-
32
tiva para atender s expectativas dos clientes sem explorar suas vulnerabilidades
[9, 24].
2.2.3.3 Monitoramento contnuo
Nesta prtica, os comportamentos de execuo devem ser monitorados para

permitir a deteco precoce de problemas na qualidade do servio, como a
degradao do desempenho, e tambm o cumprimento de acordos de nvel de
servio (SLAs) [9, 24].
2.2.4 Melhoria e Inovao
Aqui sero citadas as prticas contnuas relativas a melhoria e inovao no de-

senvolvimento de software.
2.2.4.1 Melhoria contnua
Tem base nos princpios da ideologia Lean, onde a tomada de deciso est
pautada na eliminao de desperdcio, trazendo melhorias incrementais de quali-
dade. Aumentando a vantagem competitiva do produto [9, 24].
2.2.4.2 Inovao contnua
Esta prtica prov um processo sustentvel que responde as constantes

evolues do mercado, com base em mtricas apropriadas durante todo o ciclo de
vida das fases de planejamento, desenvolvimento e execuo [9, 24].
2.2.4.3 Experimentao contnua
Uma prtica baseada em experimentao com stakeholders, consistindo em

ciclos de construo-medio-aprendizado [9, 24].
33
2.3 DevOps
No h ainda uma definio rgida nos trabalhos do que o DevOps. Em al-

guns trabalhos definido como uma metodologia, em outros, uma tcnica, e em
alguns, um processo. Os efeitos causados pela sua adoo nas organizaes vo
alm disso. O DevOps pode ser classificado como uma ideologia que evoluiu em
resposta falta de esforos na sinergia entre as equipes de desenvolvimento e op-
eraes.A cultura DevOps atua como um facilitador para oferecer mais funcionali-
dades continuamente, mantendo a estabilidade [11, 12, 15]. Se baseia nas prticas
da ES Contnua, que ajudam a reduzir o tempo entre o desenvolvimento do software
e a sua implantao no ambiente de produo, mantendo alta qualidade de soft-
ware [7]. Para obter esta qualidade, a equipe de desenvolvimento deve reagir imedi-
atamente a qualquer demanda do cliente com o objetivo de entregar o mais rpido
possvel.Para isso, tanto a equipe de desenvolvimento como a de operaes pre-
cisam chegar a um acordo de quais prticas da ES Contnua sero utilizadas para
alcanar este objetivo.Isso inclui o canal de comunicao entre as equipes [13].
2.3.1 DevOps e Agile
Agile o conjunto de prticas baseadas no Manifesto gil relevantes para o

desenvolvimento de software [45]. O Agile pode ser utilizado em conjunto com o
DevOps. Nesse caso, o DevOps incentiva a colaborao entre os membros da
equipe, a automao da construo, implantao e teste, medies e mtricas de
custo, compartilhamento de conhecimento e ferramentas. DevOps adiciona valor ao
Agile ao fornecer uma extenso pragmtica para as atividades geis. Por exemplo,
como o DevOps enfatiza mais a comunicao e a colaborao entre as equipes de
desenvolvimento e operaes, em vez de ferramentas e processos, possvel atin-
gir metas geis para reduzir a carga de trabalho em equipe e estender princpios
geis em todo o pipeline de implantao [5].
No entanto, h um momento em que o DevOps rompe com o Agile. Ao utilizar

as prticas contnuas, o DevOps entra em conflito com os princpios propostos pelo
manifesto gil, em especial com o primeiro princpio. Alm disso, medida que as
34
funcionalidades vo sendo desenvolvidas e implantadas, gradualmente vai dimin-
uindo a necessidade das iteraes [13].
35
3. Mapeamento das Ferramentas
Neste captulo, sero apresentadas as ferramentas utilizadas por equipes cu-

jos projetos possuem a cultura DevOps. As ferramentas so citadas em uma srie
de estudos de caso, artigos e revises sistemticas da literatura. Os estudos
forneceram as informaes que tornaram possvel a realizao do mapeamento das
ferramentas. Os trabalhos utilizados so: [2, 3, 5, 7, 8, 11, 12, 26, 39, 49, 50].
O desenvolvimento de software contnuo deve ser suportado por uma cadeia

de ferramentas que automatizam o pipeline, desde a criao do cdigo at a im-
plantao.O papel das ferramentas garantir que seja possvel desenvolver, testar
e implantar o software enquanto ao mesmo tempo so produzidos comentrios ad-
equados para todas as etapas do processo de desenvolvimento. A figura 4 ilustra
as reas do DevOps que podem se beneficiar do suporte de ferramentas. A figura
ilustra um modelo baseado em outro, apresentado por [2], com algumas modifi-
caes, por influncia dos modelos apresentados nos estudos restantes.
Figura 4. reas de cobertura das ferramentas
Fonte: o Autor, adaptado de [2]

36
3.1 reas de atuao das ferramentas
As reas de atuao das ferramentas so: requisitos, desenvolvimento, oper-

aes, Testes, Qualidade e Comunicao e Feedback, da mesma forma que feito
em [2]. Nos tpicos seguintes, sero justificadas a importncia dos tipos de ferra-
mentas que foram apresentadas na figura 4.
3.1.1 Requisitos
Mesmo que o DC seja realizado vrias vezes por dia, os requisitos devem ser
claros. Para que isso seja possvel, manter um registro de todos os requisitos, bem
como de todos os dados associados eles essencial no desenvolvimento de
software. Para os requisitos, asferramentas que gerenciam os requisitos e o back-
log so consideradas. Os requisitos e feedbacks do usurio podem ser obtidos no
somente atravs da coleta direta com usurios, tambm possvel realizar essa
aproximao atravs de ferramentas de solicitao de melhorias e de monitoramen-
to de uso [2].
O rastreamento de erros tambm est relacionado ao gerenciamento de back-

log, pois a correo de um bug tambm uma tarefa de desenvolvimento, logo,
tambm uma tarefa do backlog como qualquer outra.Em alguns casos, os bugs
tambm so sinalizados por clientes ou usurios finais. Nesse caso, uma ferramenta
para a comunicao pode ser necessria [2].
3.1.2 Desenvolvimento
Sistemas de controle de verso (VCS) existem para gerenciar mudanas em

vrios documentos, como o cdigo-fonte e pginas da Web, e outras informaes
que podem ser alteradas durante o desenvolvimento do software [2].
Os sistemas de construo so fundamentais para o desenvolvimento de

software. Criam os pacotes de instalao baseados em arquivos de
especificao.Estes arquivos de especificao podem incluir instrues para com-
pilao de cdigo, execuo de casos de teste e criao de pacotes de implan-
tao.Ferramentas de construo interpretam estes arquivos, ajudando os desen-
37
volvedores a gerenciar as dependncias internas e externas de software, como
acontece com as bibliotecas externas utilizadas [2].
As construes automatizadas concretizam a prtica da IC, que por sua vez

um pr-requisito para a EC e para o DC. Isto torna a IC uma espinha dorsal para
qualquer pipeline de DC.As ferramentas de IC monitoram VCSs para verificar mu-
danas que, consequentemente, desencadeiam a execuo das vrias etapas con-
figuradas no servidor de IC.As etapas podem incluir a compilao e o empacota-
mento do cdigo para criar uma verso implantvel do software [2].
Os repositrios de artefatos oferecem uma soluo para os desenvolvedores

gerenciarem dependncias e verses de diferentes bibliotecas [2].
3.1.3 Operaes
Os diferentes ambientes utilizados nas etapas do pipeline possibilitam a cri-

ao de instncias do ambiente de execuo do software.Os diferentes ambientes
em que o software ser executado, so usados em paralelo durante o desenvolvi-
mento, no entanto, devem ser idnticos, de forma que a mesma construo possa
ser implantada em qualquer um deles.Quando se trata doDC, necessrio que a
criao de instncias dos ambientes seja rpida e de fcil execuo, para que a
construo possa passar do desenvolvimento para a produo, sem muitos ob-
stculos ou problemas originados pelas diferenas nos ambientes [2].
As ferramentas de orquestrao automatizam, organizam, coordenam e geren-

ciam a infraestrutura e a criao dos ambientes, fornecendo recursos necessrios,
como criao de mquinas virtuais, alocao de capacidade de armazenamento, e
o gerenciamento de recursos de rede [2].
Humble e Farley apresentam anti-padres comuns relacionados entrega de

software [48]:
1. Implantao manual do software;
2. Implantao em produo apenas no fim de todo o desenvolvimento;
3. Configurao manual dos ambientes.
38
O objetivo do DC deve ser a implantao do software da forma mais automti-
ca possvel [2].
3.1.4 Testes
As ferramentas de IC com testes de unidade automatizados devem garantir

que as mudanas feitas no desenvolvimento no introduzam novos erros.
O teste da interface do usurio (UI) uma tarefa onde a interface grfica do

usurio testada.Algumas reas de testes de UI, como usabilidade ou teste de ex-
perincia do usurio, se aproximam do domnio da garantia de qualidade, pois no
so testes puramente funcionais e podem ser difceis de automatizar [2].
O teste de aceitao um caso especial de teste, onde determinado se o

sistema de software est em conformidade com os requisitos, funcionais ou no.Do
ponto de vista da IC, os testes de aceitao devem ser executados em um ambi-
ente idntico ao de produo [48].
Geralmente, os testes de aceitao exigem que o cliente esteja presente em

sua execuo, porm isso nem sempre possvel, principalmente se houver uma
entrega frequente do software. Para que estes testes sejam automatizados, a pre-
sena do cliente s necessria ao se construir a automao do caso de teste [2].
3.1.5 Qualidade
Os testes funcionais no so suficientes para garantir a qualidade do

software.No entanto, no apenas a IC, mas as prticas geis em geral, incluem na
definio de alta qualidade de software a forma em que o cdigo foi escrito e a
abrangncia de requisitos no funcionais [2].
Uma maneira aparente de garantir aqualidade a criao de mtricas.Por ex-

emplo, garantir desempenho sem monitorar a execuo do software muito
difcil.Para isso, ferramentas de teste de carga e estresse podem ser usadas para
garantir que o software funcionar mesmo em circunstncias ainda mais desfa-
vorveis [2].
Alguns dos parmetros de qualidade podem ser verificados mesmo que o

software no esteja em execuo. Um exemplo so as ferramentas de anlise de
39
cdigo esttico, que verifica o padro de escrita do cdigo, prevendo possveis
bugs, vulnerabilidades e cdigo suspeito [2].
3.1.6 Comunicao e Feedback
Comunicao e feedback so elementos-chave no desenvolvimento de soft-

ware. Os desenvolvedores devem compartilhar o conhecimento atravs de vrios
mecanismos, ajudando a equipe a construir uma identidade.Sistemas colaborativos
envolvem tambm os demais stakeholders, permitindo que eles participem do proje-
to nas etapas de desenvolvimento, criando uma prtica de feedback contnuo. O
pipeline de DC pode at ser til em um sentido tcnico, mas sem os feedbacks dos
stakeholders, a equipe de desenvolvimento perder o rumo, sem saber em que di-
reo seguir [2].
3.2 Separao e classificao das ferramentas
Ao fim, cento e dez ferramentas foram catalogadas e divididas conforme as

reas e subreas descritas. Todos os dados coletados esto no APNDICE A.
Os dados esto divididos em onze reas diferentes, ajudando na criao da

ferramenta de escolha. As reas so: Nome, Subrea, Website, Artigos, Tipo de pro-
jeto, Mantenedores, Tipo de licena, Integrao, Plataforma e Paradigma.
3.2.1 Nome
Indica o nome da ferramenta, No deve ser confundido com o nome da em-

presa ou grupo que a criou.
3.2.2 Subrea
So as reas internas de cada rea apresentada na figura 4 e j explanadas

na seo 3.1.
40
3.2.3 Website
Informa em qual site esto as informaes oficiais da ferramenta. Quando as

ferramentas provm de projetos open source ou tm acesso grtis, o website tam-
bm onde o download da ferramenta deve ser realizado. As informaes das fer-
ramentas foram retiradas dos seus websites.
3.2.4 Artigos
Informa onde cada ferramenta foi encontrada na lista de estudos que foram
utilizados na pesquisa. Os estudos esto descritos no Incio deste captulo.
3.2.5 Tipo de Projeto
Indica se o projeto da ferramenta realizado por grupos privados, ou se o

projeto open source.
3.2.6 Linguagem de programao
Informa qual a linguagem de programao que a ferramenta suporta. H fer-

ramentas que no envolvem programao. Estas ferramentas recebem a classifi-
cao indiferente. H ferramentas que se acoplam a qualquer linguagem de pro-
gramao, recebendo portanto, a classificao qualquer.
As demais ferramentas, se acoplam a linguagens de programao especficas,

recebendo como classificao o nome dessas linguagens.
3.2.7 Mantenedores
Informa o nome das empresas que mantm as ferramentas, no caso de proje-

tos privados. Em todos os projetos open source, os mantenedores foram classifica-
dos como comunidade.
3.2.8 Tipo de licena
Informa se a ferramenta paga. A classificao dada para as ferramentas no

pagas grtis. Se a ferramenta no for grtis ela recebe a classificao paga.
41
3.2.9 Integrao
Informa com quais ferramentas esta se integra. O nome da ferramenta uti-

lizado aqui como classificao. Para as ferramentas que se integram com todas as
outras, dada a classificao diversos, quase todos os tipos. As ferramentas
que as informaes de integrao eram inexistentes em seus websites, dada a
classificao no informado.
3.2.10 Plataforma
Informa a plataforma que a ferramenta suporta. As plataformas que as ferra-

mentas suportam, so classificadas como: Desktop, Desktop(Mac), Mobile,
Mobile(Android), Mobile(IOS), Web, Microsservios.
Desktop: so as ferramentas que suportam projetos em que o software criado

ser usado apenas no ambiente em que ser executado.
Desktop(Mac): so as ferramentas que suportam projetos em que o software

criado ser executado apenas no sistema Mac OS.
Mobile: so as ferramentas que suportam projetos em que o software que ser

criado executar em dispositivos mveis. Se limita aos dispositivos com os sis-
temas operacionais Android e IOS.
Mobile(Android): so as ferramentas que suportam projetos em que o soft-

ware que ser criado executar em dispositivos mveis com o sistema Android.
Mobile(IOS): so as ferramentas que suportam projetos em que o software

que ser criado executar em dispositivos mveis com o sistema IOS.
Web: so as ferramentas que suportam projetos em que o software que ser

criado executar tecnologias para a web, como sistemas que so acessados por
browsers ou websites.
Microsservios: so as ferramentas que suportam projetos de software com

arquitetura distribuda que sero acessados atravs da web.
Quando a ferramenta no envolve programao, ela classificada como in-

diferente. Para as ferramentas que suportam projetos para todas as plataformas, a
classificao todas.
42
3.2.11 Paradigma
Informa o paradigma de programao 1 que a ferramenta d suporte. Os para -

digmas de programao que as ferramentas mapeadas do suporte so: o fun-
cional, o Orientado a Objetos e o Imperativo.
3.3 Ferramentas mapeadas
As figuras 5, 6 mostram as ferramentas de acordo com as reas e subreas

relatadas na figura 4. Todas as ferramentas so citadas nos artigos j informados no
incio do captulo.As demais informaes sobre ferramentas se encontram no
APNDICE A.
3.3.1 Ferramentas catalogadas
Figura 5. Ferramentas de requisitos, desenvolvimento e operaes
Fonte: o Autor
1Um estudo sobre paradigmas de programao pode ser encontrado aqui: http://www.petry.pro.br/sistemas/programacao1/
materiais/artigo_paradigmas_de_programacao.pdf
43
Figura 6. Ferramentas de testes, qualidade e comunicao
Fonte: o Autor
3.3.2 Grafo de integrao de ferramentas
Um dos pontos mais importantes para a classificao das ferramentas a in-

tegrao entre elas. Ferramentas interoperveis facilitam o trabalho, portanto na fer-
ramenta criada, a quantidade de integraes determina a preferncia por uma ou
outra ferramenta. Para exibir a integrao entre as ferramentas, um grafo foi criado,
entretanto, a quantidade de ns e arestas do grafo no permitem a criao de uma
imagem legvel. Para resolver esse problema, uma ferramenta1 foi criada para exibir
o grafo de forma interativa, permitindo que seja possvel visualizar as integraes2.
1Acesse o grafo em: https://projetotcc-urbdvuqhng.now.sh//integracaoferrementas.html

2Coloque o mouse em cima do n e as ligaes sero destacadas. Clique duas vezes no n e as arestas ficaro transpar-
entes.
44
4. Automatizando a escolha das ferramentas
A automao ser feita da forma mais simples possvel. Uma ferramenta

baseada na web foi criada para servir como conceito, na criao de ferramentas
que efetivamente automatizem o processo de escolha de ferramentas. A ferramenta
pode ser encontrada no seguinte endereo: https://projetotcc-urbdvuqhng.now.sh/
4.1 Ferramenta
A ferramenta foi desenvolvida utilizando a linguagem Javascript em conjunto

com os frameworks bootstrap e D3. Inicialmente, a ferramenta exibe um menu prin-
cipal conforme a figura, abaixo:
Figura 7. Menu principal da ferramenta
Fonte: O Autor
Inicialmente, o usurio insere os dados conforme exibido no captulo anterior.

O nico dado que deve ser fornecido e no foi abordado antes a escolha do tipo
de lista que o usurio quer visualizar. Com essa opo, o usurio decide se quer ver
todas as ferramentas recomendadas ou se quer apenas as mais recomendadas,
que no caso, exibe apenas a ferramenta que mais se integra com as demais da
lista. O paradigma de programao interfere na linguagem que o usurio poder se-
lecionar.
No centro da tela, um boto pode ser selecionado para direcionar o usurio

para a pgina que contm o grafo de integrao de todas as ferramentas.
45
Figura 8. Boto de redirecionamento de pgina da ferramenta
Fonte: O Autor
As imagens referentes ao grafo e a ferramenta podem ser encontradas no

APNDICE B.
Aps selecionar todas as opes, um resultado exibido, como no exemplo

abaixo:
Figura 9. Ferramentas gratuitas mais recomendadas para desenvolvimento Desktop(Mac) pela ferramenta de
escolha
Fonte: O Autor
Podemos ver, que o resultado das ferramentas mais recomendadas eficiente

para uma busca rpida, indicando as ferramentas que mais se integram de acordo
com os parmetros inseridos. Caso seja necessria uma busca mais abrangente, a
opo de todas as ferramentas recomendadas, pode ser selecionada para indicar
todas as ferramentas catalogadas, atendendo aos parmetros selecionados.
Quando a opo "Todas as ferramentas recomendadas" for a escolhida, As

ferramentas indicadas devem ser observadas de cima para baixo, onde as ferra-
mentas ao topo da lista so as mais indicadas para o projeto. A escolha das ferra-
mentas mais indicadas est baseada na quantidade de integraes com as demais
ferramentas exibidas.
46
Figura 10. Todas as ferramentas gratuitas recomendadas para desenvolvimento Desktop(Mac) pela ferramenta
de escolha
Fonte: O Autor
Figura 11. Grafo representando as integraes entre as ferramentas recomendadas
Fonte: O Autor
47
Por fim, para ajudar na visualizao das integraes, como possvel ver na
figura 11, um grafo interativo exibido.
4.2 Estudo de caso
A ferramenta foi aplicada em um projeto real, o projeto MidiaCenter da empre-

sa Ustore. Esta seo informa a experincia vivenciada no estudo de caso.
4.2.1 Empresa
A Ustore 1, uma empresa brasileira de software para infraestrutura de com -

putao em nuvem. Nasceu no Porto Digital2 em Recife-PE, mantendo em suas
equipes de desenvolvimento e executivos, profissionais doutores em Cincia da
Computao e Segurana de Sistemas com grande experincia no mercado de
tecnologia da informao e comunicao. As solues da Ustore tornam a in-
fraestrutura das corporaes totalmente programvel de forma segura e distribuda,
viabilizando a implementao de um datacenter 100% virtual, ofertando servios
abrangentes de acordo com a anlise de necessidades dos clientes, por meio de
consultoria e profissionais especializados.
4.2.2 Projeto
O MidiaCenter3 o projeto educacional da Ustore. Hoje, se encontra em fase

de desenvolvimento, sendo desenvolvido com tecnologias atuais e baseadas nas
plataformas web e mobile. O projeto web desenvolvido em JavaEE4, com o
framework5 Play 6, utilizando uma arquitetura monoltica. Consiste em um sistema
que promove a troca de conhecimentos entre professores e alunos, permitindo o
compartilhamento e a exibio de contedos educacionais entre a comunidade es-
1 http://ustore.com.br
2 http://www.portodigital.org/parque/o-que-e-o-porto-digital
3 http://midiacenter.usto.re
4 Padro Java para aplicaes corporativas (ver: http://www.oracle.com/technetwork/java/javaee/overview/index.html).
5 Abstraoque unecdigoscomuns entre vrios projetos de software provendo uma funcionalidade genrica
6 https://www.playframework.com/
48
colar. Para fazer o armazenamento dos contedos, o sistema utiliza outros produtos
da Ustore.
Atualmente, o projeto MidiaCenter utiliza a prtica de IC. As demais etapas so

realizadas manualmente. Pelos motivos j citados neste trabalho, as etapas do de-
senvolvimento devem ser automatizadas mximo possvel para que a equipe possa
obter os benefcios fornecidos pela prtica do DC. Futuramente o projeto passar
por uma modificao nas prticas de desenvolvimento, adotando o DevOps e au-
tomatizando completamente o pipeline.
4.2.3 Utilizando a ferramenta
Figura 12. Todas as ferramentas gratuitas catalogadas para o MidiaCenter
Fonte: O Autor

Inicialmente, o menu principal foi exibido, como na figura 7. A plataforma do

MidiaCenter web no distribuda, portanto a opo Web Monoltica foi sele-
cionada. Com a plataforma selecionada, a escolha do paradigma de programao
foi o Orientado a Objetos. Aps escolher o paradigma, a escolha da linguagem en-
to foi realizada, sendo o caso do sistema da Ustore, o Java com Play Framework.
49
No caso do MidiaCenter, que far experimentos antes de migrar definitiva-
mente para as prticas contnuas, as ferramentas grtis escolhidas.
Figura 13. Todas as ferramentas gratuitas catalogadas para o MidiaCenter
Fonte: O Autor
50
5. Consideraes finais
Este captulo conclui o trabalho com uma pequena discusso sobre as limi-
taes na criao deste trabalho. Uma discusso sobre trabalhos futuros tambm
iniciada. No final do captulo uma concluso feita.
5.1 Limitaes
As limitaes deste trabalho esto relacionadas principalmente, a ausncia de

informaes sobre boas prticas no uso das ferramentas. A falta destas infor-
maes tornam o modelo criado limitado apenas s reas de aplicao das ferra-
mentas, deixando o resultado das sugestes em alguns casos bastante genrico.
Este trabalho se limita apenas ao estudo de ferramentas, logo, no est no seu es-
copo a discusso de boas prticas no DevOps.
Tambm pode ser considerada uma limitao, a quantidade de ferramentas

mapeadas. Apesar da quantidade de ferramentas ser adequada para este estudo,
existem muitas ferramentas em uso por equipes que utilizam prticas contnuas e o
DevOps.
Outra limitao identificada ferramenta criada, que serve apenas como um

modelo conceitual para a construo de uma ferramenta mais elaborada. Devido a
limitaes por ser apenas uma pgina, alm do tempo, melhores formas de se es-
colher as ferramentas no foram criadas.
5.2 Trabalhos futuros
Para complementar este trabalho, uma reviso sistemtica da literatura

necessria, buscando verificar o estado da arte de estudos que tratam de melhores
prticas em projetos DevOps, e como essas prticas so realizadas na indstria.
Outro trabalho muito importante que deve ser considerado, a criao de uma
ferramenta que torne possvel, a real automao na escolha destas ferramentas,
51
atravs das melhores prticas mapeadas no trabalho anterior, possibilitando a es-
colha, instalao e configurao automtica das ferramentas.
5.3 Concluso
Este trabalho fez um panorama do incio da ES at o DevOps. Apresentou o

conceito da Ideologia Lean e informou quais os benefcios de inserir essa ideologia
na ES. Tambm foram informados os conceitos das prticas contnuas e do Dev-
Ops. Com os conceitos aprendidos possvel diferenciar o DevOps do Agile.
O DevOps s pode ser aplicado efetivamente em uma organizao, se esta

optar por prticas contnuas, principalmente a integrao contnua, a entrega con-
tnua e o deploy contnuo. A entrega e deploy contnuos dependem de um pipeline
automatizado, que por sua vez necessita de ferramentas que concretizem essa au-
tomao. Quando falamos em ferramentas, olhar somente para elas no basta e
isso fica evidente ao se observar a quantidade de ferramentas encontradas. Temos
que entender como elas so aplicadas nas organizaes e quais as melhores prti-
cas nesse uso. Por exemplo, Sthl e Bosch indicam que as prticas contnuas so
realizadas de vrias formas diferentes nas organizaes, as vezes h diferenas de
como estas prticas so realizadas at entre equipes da mesma empresa, mostran-
do que no existe apenas uma forma de se aplicar a ES contnua [38]. O que existe,
no entanto, uma quantidade finita destas variaes e, portanto, possvel estud-
las buscando a melhor forma de aplicar todos estes conceitos e ferramentas da
forma mais otimizada possvel.
Com base em todas as informaes estudadas na pesquisa e na criao deste

trabalho, conclui-se que possvel criar ferramentas robustas e teis para automati-
zar o processo de escolha de ferramentas, no entanto, importante que estas in-
formem como as ferramentas podem ser aproveitadas da melhor forma possvel em
todo o pipeline de implantao.
52
Referncias Bibliogrficas
[1] LEHTONEN, T. et al. Defining metrics for continuous delivery and deployment
pipeline. CEUR Workshop Proceedings. Anais 2015.
[2] MKINEN, S. et al. Improving the delivery cycle: A multiple-case study of the
toolchains in Finnish software intensive enterprises. Information and Software
Technology, v. 80, p. 13391351, 2016.
[3] PANG, C.; HINDLE, A. Continuous Maintenance. 2016 IEEE International Con-
ference on Software Maintenance and Evolution (ICSME). Anais...IEEE, out.
2016Disponvel em: <http://ieeexplore.ieee.org/document/7816494/>. Acesso em: 7
maio. 2017.
[4] LEPPANEN, M.; KILAMO, T.; MIKKONEN, T. Towards Post-Agile Development

Practices through Productized Development Infrastructure. Proceedings - 2nd
International Workshop on Rapid Continuous Software Engineering, RCoSE 2015.
Anais...IEEE, maio 2015. Disponvel em: <http://ieeexplore.ieee.org/document/
7167171/>. Acesso em: 7 maio. 2017.
[5] JABBARI, R. et al. What is DevOps? Proceedings of the Scientific Workshop

Proceedings of XP2016 on - XP 16 Workshops. Anais New York, New York, USA:
A C M P r e s s , 2 0 1 6 D i s p o n v e l e m : < h t t p : / / d l . a c m . o rg / c i t a t i o n . c f m ?
doid=2962695.2962707>. Acesso em: 7 maio. 2017.
[6] KARVONEN, T. et al. Systematic Literature Review on the Impacts of Agile Re-
lease Engineering Practices. Information and Software Technology, v. 86, n. C, p.
87100, jun. 2017.
[7] WETTINGER, J. et al. Streamlining DevOps automation for Cloud applications us-
ing TOSCA as standardized metamodel. Future Generation Computer Systems, v.
56, p. 317332, 2016.
[8] OHTSUKI, M.; OHTA, K.; KAKESHITA, T. Software engineer education support
system ALECSS utilizing DevOps tools. Proceedings of the 18th International
Conference on Information Integration and Web-based Applications and Services -
iiWAS 16. Anais...New York, New York, USA: ACM Press, 2016. Disponvel em:
<http://dl.acm.org/citation.cfm?doid=3011141.3011200>. Acesso em: 7 maio. 2017.
[9] FITZGERALD, B.; STOL, K.-J. Continuous software engineering and beyond:
trends and challenges. Proceedings of the 1st International Workshop on Rapid
Continuous Software Engineering - RCoSE 2014. Anais New York, New York,
USA: ACM Press, 2014Disponvel em: <http://dl.acm.org/citation.cfm?
doid=2593812.2593813>. Acesso em: 7 maio. 2017.
53
[10] GEBERT, S. et al. Continuously delivering your network. Proceedings of the
2015 IFIP/IEEE International Symposium on Integrated Network Management, IM
2015. Anais...IEEE, maio 2015. Disponvel em: <http://ieeexplore.ieee.org/docu-
ment/7140371/>. Acesso em: 7 maio. 2017.
[11] WETTINGER, J.; BREITENBUCHER, U.; LEYMANN, F. Standards-based Dev-

Ops automation and integration using TOSCA. Proceedings - 2014 IEEE/ACM 7th
International Conference on Utility and Cloud Computing, UCC 2014. Anais...IEEE,
dez. 2014. Disponvel em: <http://ieeexplore.ieee.org/document/7027481/>. Acesso
em: 7 maio. 2017.
[12] OLSZEWSKA, M.; WALDN, M. DevOps meets formal modelling in high-critical-

ity complex systems. Proceedings of the 1st International Workshop on Quality-
Aware DevOps - QUDOS 2015, p. 712, 2015.
[13] KILAMO, T.; LEPPNEN, M.; MIKKONEN, T. The social developer: now, then,
and tomorrow. Proceedings of the 7th International Workshop on Social Soft-
ware Engineering - SSE 2015, p. 4148, 2015.
[14] SHAHIN, M.; BABAR, M. A.; ZHU, L. The Intersection of Continuous Deploy-
ment and Architecting Process: Practitioners Perspectives. Proceedings of the
10th ACM/IEEE International Symposium on Empirical Software Engineering and
Measurement. Anais...New York, New York, USA: ACM Press, 2016. Disponvel em:
<http://dl.acm.org/citation.cfm?doid=2961111.2962587>. Acesso em: 7 maio. 2017.
[15] RAJKUMAR, M. et al. DevOps culture and its impact on cloud delivery and
software development. 2016 International Conference on Advances in Computing,
Communication, & Automation (ICACCA) (Spring). Anais...IEEE, abr. 2016. Disponv-
el em: <http://ieeexplore.ieee.org/document/7578902/>. Acesso em: 7 maio. 2017.
[16] SOMMERVILLE, I. Engenharia de Software, 9a Edio. Pearson Ed ed. So

Paulo: Pearson Education, 2011.
[17] SOARES, M. D. S. Comparao entre Metodologias geis e Tradicionais para o

Desenvolvimento de Software. INFOCOMP Journal of Computer Science, v. 27, n.
2, p. 6, 2003.
[18] ROYCE, D. W. W. Managing the Development of large Software Systems. Ieee

Wescon, n. August, p. 19, 1970.
[19] The Chaos Report. . Dennis, MA 02638, USA. 1995. Disponvel em: <https://
www.standishgroup.com/sample_research_files/chaos_report_1994.pdf>.
54
[20] BERNARDO, K. Manifesto gil, como tudo comeou. Disponvel em: <https://
www.culturaagil.com.br/manifesto-agil-como-tudo-comecou/>. Acesso em: 4 junho.
2017.
[21] BECK, K. et al. Manifesto for Agile Software Development. Disponvel em:
<http://agilemanifesto.org/>. Acesso em: 4 jun. 2017.
[22] BECK, K. Extreme programming eXplained : embrace change. [s.l.] Addison-

Wesley, 2000.
[23] SCHWABER, K.; BEEDLE, M. Agile software development with Scrum. [s.l.]
Prentice Hall, 2002.
[24] FITZGERALD, B.; STOL, K. J. Continuous software engineering: A roadmap and

agenda. Journal of Systems and Software, v. 123, p. 176189, 2017.
[25] LEPPANEN, M. et al. The highways and country roads to continuous de-
ploymentIEEE Software, mar. 2015. Disponvel em: <http://ieeexplore.ieee.org/
document/7057604/>. Acesso em: 22 maio. 2017.
[26] SHAHIN, M.; ALI BABAR, M.; ZHU, L. Continuous Integration, Delivery and De-
ployment: A Systematic Review on Approaches, Tools, Challenges and Practices.
IEEE Access, v. 5, p. 11, 2017.
[27] IEEE Xplore Digital Library. Disponvel em: <http://ieeexplore.ieee.org/Xplore/

home.jsp>. Acesso em: 27 jun. 2017.
[28] ScienceDirect.com | Science, health and medical journals, full text articles
and books. Disponvel em: <http://www.sciencedirect.com/>. Acesso em: 27 jun.
2017.
[29] ASSOCIATION FOR COMPUTING MACHINERY. ACM Digital Library.

Disponvel em: <http://dl.acm.org/>. Acesso em: 27 jun. 2017.
[30] Scopus. Disponvel em: <https://www.scopus.com/home.uri?zone=header&ori-

gin=searchbasic>. Acesso em: 27 jun. 2017.
[31] Google Acadmico. Disponvel em: <https://scholar.google.com.br/>. Acesso

em: 27 jun. 2017.
[32] IEEE; BOURQUE, P.; FAIRLEY, R. E. SWEBOK v.3. [s.l: s.n.].
[33] IEEE Computer Society. Disponvel em: <https://www.computer.org/web/swe-

bok>. Acesso em: 30 jun. 2017.
55
[34] ALLEN, J. H. Software security engineering : a guide for project managers.
[s.l.] Addison-Wesley, 2008.
[35] POPPENDIECK, M.; POPPENDIECK, T. Lean software development : an agile

toolkit. [s.l.] Addison-Wesley, 2003.
[36] SERAFINO, N. M.; TARNOFF, C.; NANTO, D. K. U.S. Occupation Assistance:

Iraq, Germany, and Japan Compared. 23 mar. 2006.
[37] OHNO, T. O sistema Toyota de produo : alm da produo em larga es-

cala. [s.l.] Bookman, 1997.
[38] STHL, D.; BOSCH, J. Experienced Benefits of Continuous Integration in

Industry Software Product Development: A Case Study. 2013. Disponvel em:
<http://www.actapress.com/PaperInfo.aspx?paperId=455452>
[39] STHL, D.; BOSCH, J. Modeling continuous integration practice dierences in

industry software development. Journal of Systems and Software, v. 87, n. 1, p.
4859, 2014.
[40] DIMECC N4S-Program: Finnish Software Companies Speeding Digital

Economy - Digile N4S. Disponvel em: <http://www.n4s.fi/en/>. Acesso em: 5 jul.
2017.
[41] IEEE SA - 730-1980 - IEEE Trial Use Standard for Software Quality Assur-
ance Plans. Disponvel em: <https://standards.ieee.org/findstds/standard/
730-1980.html>. Acesso em: 5 jul. 2017.
[42] International Organization for Standardization. Disponvel em: <https://

www.iso.org/home.html>. Acesso em: 5 jul. 2017.
[43] ISO/IEC TR 19759:2005 - Software Engineering -- Guide to the Software

Engineering Body of Knowledge (SWEBOK). Disponvel em: <https://www.iso.org/
standard/33897.html>. Acesso em: 5 jul. 2017.
[44] O que significa distribuio contnua? Amazon Web Services. Disponvel

em: <https://aws.amazon.com/pt/devops/continuous-delivery/>. Acesso em: 5 jul.
2017.
[45] What Is Agile? Disponvel em: <https://www.forbes.com/sites/stevedenning/

2016/08/13/what-is-agile/#4b412ea726e3>. Acesso em: 7 jul. 2017.
[46] SOARES, M. DOS S. Metodologias geis Extreme Programming e Scrum para o

Desenvolvimento de Software. Revista Eletrnica de Sistemas de Informao, v.
3, n. 1, p. 18, 2004.
56
[47] Scrum: metodologia gil para gesto e planejamento de projetos. Disponv-
el em: <http://www.desenvolvimentoagil.com.br/scrum/>. Acesso em: 7 jul. 2017.
[48] HUMBLE, J.; FARLEY, D. Continuous delivery. [s.l.] Addison-Wesley, 2011.
[49] MEYER, M. Continuous integration and its tools. IEEE Software, v. 31, n. 3, p.
1416, maio 2014.
[50] BECK, A.; UEBERNICKEL, F.; BRENNER, W. Fit for continuous integration:
How organizations assimilate an agile practice. 20th Americas Conference on
Information Systems, AMCIS 2014. Anais 2014. Disponvel em: <http://www.sco-
pus.com/inward/record.url?eid=2-s2.0-84905986447&partnerID=tZOtx3y1>
57
Apndice A - Tabela de ferramentas
Esta tabela uma adaptao da tabela de ferramentas encontrada em [2].
Linguagem
Tipo de Mantenedo Tipo de
Nome rea Website Arigos de Integrao Plataforma
projeto res licena
programao
Gerenciame
nto de https://
backlog, Bitbucket,
www.atlassia
Jira Rastreament [2, 5] Privado Indiferente Atlassian Paga Git, bamboo, indiferente
n.com/
o de bugs, Teamcity
software/jira
Comunica
o e feedback
Slack,
Geranciame https:// Github, Jira,
Trello nto de [2, 5] Privado Indiferente Atlassian Gratis indiferente
trello.com/ Twitter,
backlog Bitbucket
Gerenciame https://
nto de www.atlassia Jira,
Confluence backlog, n.com/ [2] Privado Indiferente Atlassian Paga indiferente
Teamcity
Comunica software/
o e feedback confluence
Geranciame
nto de
Backlog,
Rastreament
o de bugs, Gratis, para
https://
Github Controle de [2, 4, 50] Privado Indiferente Github projetos Travis CI, Git indiferente
github.com/
verso, pblicos
Reviso de
cdigo,
Comunica
o e feedback
Geranciame http:// Agilefant

Agilefant nto de www.agilefa [2] Privado Indiferente Paga Trello, Jira indiferente
LTDA
backlog nt.com/
https://
Geranciame www.google. No
Google Docs nto de [2] Privado Indiferente Google Gratis indiferente
com/docs/ informado
backlog about/
https://
Geranciame products.offi No
Excel nto de [2] Privado Indiferente Microsoft Paga indiferente
ce.com/en- informado
backlog us/excel
Geranciame http:// Accept

Accept360 nto de www.accept [2] Privado Indiferente Paga Confluence Indiferente
Software
backlog 360.com/
http://
Geranciame kanbanik.git Open Comunidad No
Kanbanik nto de [2] Indiferente Gratis indiferente
hub.io/ Source e informado
backlog kanbanik/
https:// Diversos, Desktop(Ma
developer.ap Swift,
Xcode IDE Privado Apple Gratis quase todos c),
ple.com/ Objective C os tipos. Mobile(IOS)
xcode/
https://
developer.an Diversos,
Android droid.com/ Mobile(Andr
IDE Privado Android Jetbrains Gratis quase todos
Studio studio/ oid)
os tipos.
index.html?
hl=pt-br
Desktop,
http:// Diversos,
Open Comunidad Web,
Eclipse IDE www.eclipse. [8, 12, 50] Qualquer Gratis quase todos
Source e Microservio
org/ os tipos. s
Rastreament https://
o de bugs, Open Comunidad Eclipse,
Bugzilla www.bugzilla [2] Qualquer Gratis Todos
Reviso de Source e SVN, Git.
.org/
cdigo
Controle de Diversos,
https://git- [2, 3, 5, 7, 8, Open Comunidad
Git verso, Qualquer Gratis quase todos Todos
scm.com/ 26, 49, 50] Source e
Implantao os tipos.
https:// Diversos,
Controle de Open Comunidad
Subversion subversion.a [2, 26, 50] Qualquer Gratis quase todos Todos
verso Source e
pache.org/ os tipos.
58
Linguagem
projeto res licena
programao
Rastreament
o de bugs, https:// Jira,
Controle de
Bitbucket bitbucket.org [26] Privado Qualquer Atlassian Gratis Bamboo, Todos
verso, / Hipchat
Comunica
o e feedback
Controle de https://
verso,
TFS www.visualst [3] Privado Qualquer Microsoft Gratis Diversos Todos
Comunica udio.com/tfs/
o e feedback
Bugzilla,
Maven,
https:// Capistrano,
Controle de Open Comunidad
Mercurial www.mercuri [2] Qualquer Gratis Jenkins, Todos
verso Source e
al-scm.org/ Hudson, Git,
SVN, Ant,
MSBuild.
https://
Controle de Jira, Jenkins,
Perforce www.perforc [2, 3] Privado Qualquer Perforce Paga Todos
verso Eclipse.
e.com/
Construo,
Integrao
Contnua, [2, 3, 5, 8, Diversos,
Repositrio https:// Open Comunidad
Jenkins 26, 39, 49, Qualquer Gratis quase todos Todos
de artefatos, jenkins.io/ Source e
50] os tipos.
Implantao,
Qualidade e
performance
Construo, https:// Diversos,
Open Comunidad
Maven Repositrio maven.apac [2, 26] Qualquer Gratis quase todos Todos
Source e
de artefatos he.org/ os tipos.
Desktop,
http:// Diversos,
Open Comunidad Web,
Nant Construo nant.sourcef [26] .Net Gratis quase todos
orge.net/ os tipos. s
https:// Desktop,
Diversos,
github.com/ Open Comunidad Web,
MSBuild Construo [26] .Net Gratis quase todos
Microsoft/ Source e Microservio
os tipos.
msbuild s
Desktop,
http:// Diversos,
Open Comunidad Web,
Ant Construo ant.apache.o [2, 3, 8, 26] Java Gratis quase todos
rg/ os tipos. s
Diversos,
https:// Open Comunidad
CMake Construo [2] C, C++ Gratis quase todos Desktop
cmake.org/ Source e os tipos.
https:// Diversos,
www.gnu.org Open Comunidad
Make Construo [2, 26] C, C++ Gratis quase todos Desktop
/software/ Source e os tipos.
make/
Diversos,
https:// Open C, C++, Comunidad Desktop,
GCC Construo [2] Gratis quase todos
gcc.gnu.org/ Source Objective C e Mobile(IOS)
os tipos.
Construo, http:// Diversos,
Qualidade Open C, C++, Comunidad Desktop,
Clang clang.llvm.or [2] Gratis quase todos
de Source Objective C e Mobile(IOS)
g/ os tipos.
performance
http:// Diversos,
Ruby on Open Comunidad
Construo rubyonrails.o [2] Ruby on Raills Gratis quase todos Web
Rails Source e
rg/ os tipos.
Desktop,
http:// Diversos,
Open Scala, Java Comunidad Web,
Sbt Construo www.scala- [2] Gratis quase todos
Source Play e Microservio
sbt.org/ os tipos. s
Diversos,
http:// Open Comunidad
Grunt Construo [2] Javascript Gratis quase todos Web
gruntjs.com/ Source e os tipos.
https:// Diversos,
Integrao www.jetbrain
TeamCity [2, 26, 49] Privado Qualquer Jetbrains Paga quase todos Todos
Contnua s.com/ os tipos.
teamcity/
https:// Diversos,
Integrao br.atlassian.c
Bamboo [26, 49] Privado Qualquer Atlassian Paga quase todos Todos
Contnua om/software/ os tipos.
bamboo
http://
CruiseContr Integrao cruisecontrol Open Comunidad No
[26] Qualquer Gratis Todos
ol Contnua .sourceforge. Source e informado
net/
https://
Integrao Open Comunidad No
Hudson eclipse.org/ [26] Qualquer Gratis Todos
Contnua Source e informado
hudson/
Integrao http:// Open Comunidad No
Buildbot [2] Qualquer Gratis Todos
Contnua buildbot.net/ Source e informado
Controle de
https:// verso,
Repositrio
Artifactory www.jfrog.co [2] Privado Qualquer Jfrog Paga Integrao Todos
de artefatos m/artifactory/ contnua,
Construo
VMware
vSphere,
Virtualbox,
https:// Rackspace,
Orquestra Open Comunidad
Vagrant www.vagrant [2] Indiferente Gratis Ansible, Todos
o Source e
up.com/ Chef,
Puppet,
Foreman,
Steam
59
Linguagem
projeto res licena
programao
Provisionam
ento de https:// Open Comunidad
Docker ambientes, www.docker. [3, 7, 11] Indiferente Gratis Docker Todos
Source e
Orquestra com/
o
Desktop,
Provisionam https:// Diversos, Mobile(Andr
Open Comunidad
Virtualbox ento de www.virtualb [2] Indiferente Gratis quase todos oid), Web,
Source e
ambientes ox.org/ os tipos. Microservio
s
https:// Desktop,
Provisionam www.vmwar Diversos, Mobile(Andr
VMware ento de e.com/ [2] Privado Indiferente Vmware Paga quase todos oid), Web,
vSphere ambientes products/ os tipos. Microservio
vsphere s
Docker,
Github,
Provisionam Bitbucket, Desktop,
ento de https:// Vagrant, Mobile(Andr
Ambientes, Open Comunidad
Ansible www.ansible. [2] Indiferente Gratis Jenkins, oid), Web,
Orquestra Source e
com/ Teamcity, Microservio
o, Virtualbox, s
implantao Vmware,
Foreman..
Desktop,
Provisionam Diversos, Mobile(Andr
ento de https:// Open Comunidad
Chef [2, 5, 7, 11] Indiferente Gratis quase todos oid), Web,
ambientes, www.chef.io/ Source e os tipos. Microservio
Implantao s
Jenkins,
Teamcity,
Bamboo, Desktop,
hudson,
Provisionam Mobile(Andr
https:// Open Comunidad Buildbot,
Puppet ento de [2, 12, 26] Indiferente Gratis oid), Web,
puppet.com/ Source e Virtualbox,
ambientes Microservio
vSphere, s
Docker,
Vagrant,
Foreman.
Slack,
Docker,
Ansible, Desktop,
http:// Chef, Mobile(Andr
Orquestra Open Comunidad
Foreman theforeman. [2] Indiferente Gratis Puppet, oid), Web,
o Source e
org/ Jenkins, Microservio
Slack, s
vSphere,
Github,
http:// Open Comunidad Slack,
Capistrano Implantao capistranorb. [2] Indiferente Gratis Todos
Source e Hipchat
com/
https://
www.hockey
HockeyApp Implantao [2] Privado Indiferente Microsoft Paga Jenkins Mobile
app.net/
features/
Desktop,
Diversos,
Teste de https:// Open Comunidad Web,
Nunit [26] .Net Gratis quase todos
Unidade nunit.org/ Source e Microservio
os tipos. s
Teste de Desktop,
Diversos,
Unidade, http:// Open Comunidad Web,
JUnit [2, 3, 8] Java Gratis quase todos
Teste de junit.org/ Source e Microservio
os tipos.
aceitao s
Desktop,
Diversos,
Teste de http:// Open Comunidad Web,
Mockito [2] Java Gratis quase todos
Unidade mockito.org/ Source e Microservio
os tipos. s
Teste de
Unidade, http:// Diversos,
Open Comunidad
Jasmine Teste de jasmine.gith [2] Javascript Gratis quase todos Web
Source e
interface do ub.io/ os tipos.
usurio
Diversos,
Teste de https:// Open Comunidad
Mocha [2] Javascript Gratis quase todos Web
Unidade mochajs.org/ Source e os tipos.
Desktop,
http:// Diversos,
Teste de Open Comunidad Web,
Leiningen leiningen.org [2] Clojure Gratis quase todos
Unidade Source e Microservio
/ os tipos. s
Desktop,
https:// Diversos,
Midje github.com/ [2] Clojure Gratis quase todos
marick/Midje os tipos. s
https:// Diversos,
Teste de github.com/ Open Comunidad
Google Test [2] C++ Gratis quase todos Desktop
Unidade google/ Source e os tipos.
googletest
https://
gcc.gnu.org/ Diversos,
Teste de Open C, C++, Comunidad Desktop,
Gcov onlinedocs/ [2, 26] Gratis quase todos
Unidade Source Objective C e Mobile(IOS)
gcc/ os tipos.
Gcov.html
https:// Diversos,
Teste de wiki.qt.io/ Open Comunidad
Qt Autotest [2] Qualquer Gratis quase todos Todos
Unidade Qt_Autotest_ Source e os tipos.
Environment
https:// Desktop,
Diversos,
Teste de etorreborre.g Open Scala, Java Comunidad Web,
Specs2 [2] Gratis quase todos
Unidade ithub.io/ Source Play e Microservio
os tipos.
specs2/ s
Desktop,
http:// Diversos,
Scalatest www.scalate [2] Scala Gratis quase todos
st.org/ os tipos. s
60
Linguagem
projeto res licena
programao
Desktop,
Diversos,
Rspec [2] Ruby Gratis quase todos
Unidade rspec.info/ Source e Microservio
os tipos. s
https:// Desktop,
Diversos,
Teste de github.com/ Open Comunidad Web,
Minitest [2] Ruby Gratis quase todos
Unidade seattlerb/ Source e Microservio
os tipos.
minitest s
Teste de
interface do
usurio, http:// Diversos,
Open Comunidad
Selenium Teste de www.seleniu [2] Indiferente Gratis quase todos Web
Source e
aceitao, mhq.org/ os tipos.
Qualidade e
performance
Teste de
interface do
usurio, http://
Robot Open Comunidad
Teste de robotframew [2] Indiferente Gratis Jenkins Web
Framework Source e
aceitao, ork.org/
Qualidade e
performance
https://
Teste de Diversos,
karma- Open Comunidad
Karma Interface do [2] Javascript Gratis quase todos Web
runner.github Source e
usurio os tipos.
.io/
Teste de http:// Diversos,
Open Comunidad
PhantomJS Interface do phantomjs.or [2] Javascript Gratis quase todos Web
Source e
usurio g/ os tipos.
Teste de https://
BrowserStac BrowserSta No
Interface do www.browse [2] Privado Indiferente Paga Web
k ck informado
usurio rstack.com/
https:// Cucumber,
Teste de github.com/ Open Comunidad Rspec,
Capybara Interface do [2] Qualquer Gratis Web
teamcapybar Source e Minitest,
usurio a/capybara Selenium
Teste de .Net, Java, Desktop,
interface do Ruby, Groovy, Diversos,
https:// Open Comunidad Web,
Cucumber usurio, [2] Javascript, Gratis quase todos
cucumber.io/ Source e Microservio
Teste de Clojure, Gosu, os tipos. s
aceitao PHP, Python
Diversos,
Teste de http:// Open Comunidad
Chai [2] Javascript Gratis quase todos Web
aceitao chaijs.com/ Source e os tipos.
Desktop,
Diversos,
TestNG [2] Java Gratis quase todos
aceitao testng.org/ Source e Microservio
os tipos. s
TFS,
https:// Cruisecontro
Teste de www.froglogi l, Jenkins,
aceitao,
Squish c.com/ [2] Privado Qualquer FrogLogic Paga Hudson, Web
Qualidade e squish/gui- Bamboo,
performance testing/ Teamcity,
Ant, Maven
Qualidade e http:// Diversos,
performance
Sonar www.sonarq [2, 26] Privado Qualquer Sonarqube Gratis quase todos Todos
, Reviso de ube.org/ os tipos.
cdigo
Reviso de http:// Open Comunidad
JsHint [2] Javascript Gratis Eclipse Web
cdigo jshint.com/ Source e
Qualidade e TFS, Desktop,
http:// ZEN
performance Cruisecontro Web,
Ndepend www.ndepen [26] Privado .Net PROGRAM Paga
, Reviso de l, Sonar, Microservio
d.com/ LTD
cdigo Jenkins, s
http:// Diversos,
Reviso de Open Comunidad
JsLint www.jslint.co [2] Javascript Gratis quase todos Web
cdigo Source e
m/ os tipos.
Qualidade e http:// Open Comunidad

Valgrind [2] Indiferente Gratis Indiferente Todos
performance valgrind.org/ Source e
Desktop,
http://
Reviso de Open Comunidad Eclipse, Web,
FindBugs findbugs.sou [3, 8] Java Gratis
cdigo Source e Maven Microservio
rceforge.net/ s
Desktop,
http://
Qualidade e Open Comunidad Eclipse, Web,
EMMA emma.sourc [3] Java Gratis
performance Source e Maven Microservio
eforge.net/ s
Bitbucket, Desktop,
http:// Eclipse, Android,
Reviso de checkstyle.s Open Comunidad
Checkstyle [3, 8] Java Gratis Gradle, Web,
cdigo ourceforge.n Source e Jenkins, Microservio
et/ Sonar, Sbt s
http://
Reviso de www.gimpel. Gimpel
Flexelint [26] Privado C, C++ Paga Eclipse Desktop
cdigo com/html/ Software
lintfaq.htm
http:// Hudson,
Qualidade e cppcheck.so Open Comunidad Jenkins,
Cppcheck [2] C, C++ Gratis Desktop
performance urceforge.ne Source e Mercurial,
t/ SVN, Git
http://
Qualidade e No
Bullseye www.bullsey [2] Privado C, C++ Bullseye Paga Desktop
performance informado
e.com/
http://
Qualidade e
Testdroid testdroid.co [2] Privado Android, IOS bitbar Paga Jenkins, Jira Mobile
performance m/
61
Linguagem
projeto res licena
programao
https:// Web,
Qualidade e Java, Ruby, No
New Relic newrelic.com [2, 5] Privado KingHost Paga Microservio
performance Python, Node informado
/ s
http:// Web,
Qualidade e Open Comunidad No
JMeter jmeter.apach [2] Java Gratis Microservio
performance Source e informado
e.org/ s
http:// Web,
Qualidade e Open Comunidad No
Zabbix www.zabbix. [2, 5] Qualquer Gratis Microservio
performance Source e informado
com/ s
https:// Web,
Qualidade e Royal
Pingdom www.pingdo [2, 5] Privado Qualquer Paga Slack Microservio
performance Pingdom
m.com/ s
Web,
Qualidade e http:// No
Gatling [2] Privado Qualquer Gatling Paga Microservio
performance gatling.io/ informado s
https://
developers.g
Google Qualidade e oogle.com/ [2] Privado Qualquer Google Paga Nginx Web
PageSpeed performance speed/
pagespeed/
http://
httpd.apache Web,
Qualidade e .org/docs/ Open Comunidad Servidores
Ab [2] Qualquer Gratis Microservio
performance 2.2/ Source e apache s
programs/
ab.html
https://
Reviso de www.gerritco Open Comunidad
Gerrit [2] Qualquer Gratis Git Todos
cdigo dereview.co Source e
m/
https:// SVN, Git,
www.atlassia
Reviso de Mercurial,
Crucible n.com/ [2] Privado Qualquer Atlassian Paga Todos
cdigo Perforce,
software/ Bitbucket
crucible
https:// Jira,
www.atlassia
Reviso de Bamboo,
FishEye n.com/ [2] Privado Qualquer Atlassian Paga Todos
cdigo Hipchat,
software/ Bitbucket
fisheye
Comunica https:// No
Skype oe www.skype.c [2] Privado Indiferente Microsoft Gratis Indiferente
informado
Feedback om/
Slack oe [2] Privado Indiferente Slack Gratis Indiferente
slack.com/ informado
Feedback
Comunica https:// CA No
Flowdock oe www.flowdoc [2] Privado Indiferente Paga Indiferente
Tecnologies informado
Feedback k.com/
Webex oe www.webex. [2] Privado Indiferente Cisco Paga Indiferente
informado
Feedback com/
Comunica https:// Open Comunidad No
XMPP oe [2] Indiferente Gratis Indiferente
xmpp.org/ Source e informado
Feedback
Hipchat oe [2] Privado Indiferente Atlassian Gratis Indiferente
hipchat.com/ informado
Feedback
https://
Comunica products.offi No
Lync oe ce.com/en- [2] Privado Indiferente Microsoft Paga Indiferente
informado
Feedback us/skype-for-
business/
https://
SharePoint oe ce.com/en- [2] Privado Indiferente Microsoft Paga Indiferente
informado
Feedback us/
sharepoint/
https://
Outlook oe [2] Privado Indiferente Microsoft Gratis Indiferente
ce.com/en- informado
Feedback us/outlook/
Comunica https://
Google No
oe analytics.goo [2] Privado Indiferente Google Gratis Indiferente
Analytics informado
Feedback gle.com/
Pagerduty oe www.pagerd [5] Privado Indiferente Pagerduty Paga Indiferente
informado
Feedback uty.com/
Flurry oe developer.ya [2] Privado Indiferente Yahoo Paga Indiferente
informado
Feedback hoo.com/
Intercom oe www.interco [2] Privado Indiferente Intecom Paga Indiferente
informado
Feedback m.io/
http://
Comunica www.adobe. No
Sitecatalyst oe com/uk/ [2] Privado Indiferente Adobe Paga Indiferente
informado
Feedback marketing-
cloud.html
Comunica http:// No
Qlikview oe www.qlik.co [2] Privado Indiferente Qilk Paga Indiferente
informado
Feedback m/
Optimizely oe www.optimiz [2] Privado Indiferente Optimizely Paga Indiferente
informado
Feedback ely.com/
62
Linguagem
projeto res licena
programao
Facebook oe www.facebo [2] Privado Indiferente Facebook Gratis Indiferente
informado
Feedback ok.com/
Twitter oe [2] Privado Indiferente Twitter Gratis Indiferente
twitter.com/ informado
Feedback
63
Apndice B - Imagens da ferramenta
Seletor de escolha de plataforma da ferramenta
Opes de plataformas na ferramenta
Seletor de escolha de paradigma da ferramenta
Opes de escolha de paradigma na ferramenta
64
Seletor de escolha de licena da ferramenta
Opes de escolha de licena na ferramenta
Opes de escolha de linguagem na ferramenta
Grafo de integrao das ferramentas selecionadas
65
Resultado de ferramentas selecionadas
66
Grafo de integrao de todas as ferramentas
67

Automatização Na Escolha de Ferramentas em Projetos Que Aplicam DevOps

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Automatização Na Escolha de Ferramentas em Projetos Que Aplicam DevOps

Hochgeladen von

Copyright:

Verfügbare Formate

Universidade Federal de Pernambuco

Graduao em Sistemas de Informao

Automatizao na escolha de ferramentas em

Jos Eudes de Souza Jnior

Recife, Julho de 2017

Universidade Federal de Pernambuco

Jos Eudes de Souza Jnior

Automatizao na escolha de ferramentas em

Trabalho apresentado ao programa de

Orientador: Prof. Dr. Vincius Cardoso Garcia

Recife, Julho de 2017

Jos Eudes de Souza Jnior

Automatizao na escolha de ferramentas em

Vincius Cardoso Garcia

Universidade Federal de Pernambuco

Kiev Santos da Gama

Universidade Federal de Pernambuco

Recife, Julho de 2017

Quero a agradecer aos professores do Colgio Santa Brbara, principalmente

Quero agradecer aos professores do Centro de Informtica da UFPE que me

Quero tambm agradecer a todos os meus colegas de trabalho na Ustore, que

Aps a criao do Manifesto gil e a popularizao das metodologias geis no

Palavras-chave: DevOps, Pipeline automatizado, Integrao Contnua, Entrega Con-

Keywords: DevOps, Pipeline, automated, Continuous Integration, Continuous Deliv-

DevOps Desenvolvimento e Operaes

SLA Acordo de Nvel de Servio

VCS Sistema de Controle de Verso

Figura 2. reas de cobertura da IC, EC e DC no pipeline de implantao .............29

Figura 3. Pipeline de implantao ............................................................................30

Figura 4. reas de cobertura das ferramentas.........................................................36

Figura 5. Ferramentas de requisitos, desenvolvimento e operaes....................... 43

Figura 6. Ferramentas de testes, qualidade e comunicao ................................... 44

Figura 7. Menu principal da ferramenta ...................................................................45

Figura 8. Boto de redirecionamento de pgina da ferramenta ...............................46

Figura 9. Ferramentas gratuitas mais recomendadas para desenvolvimento

Figura 10. Todas as ferramentas gratuitas recomendadas para desenvolvimento

Figura 11. Grafo representando as integraes entre as ferramentas recomendadas

Figura 12. Todas as ferramentas gratuitas catalogadas para o MidiaCenter ........... 49

Figura 13. Todas as ferramentas gratuitas catalogadas para o MidiaCenter ........... 50

1.2 PROBLEMA ....................................................................................................16

1.3 OBJETIVOS ....................................................................................................17

1.4 ESCOPO ........................................................................................................17

1.5 METODOLOGIA .............................................................................................18

1.6 ORGANIZAO DO TRABALHO ..................................................................19

2. REFERENCIAL TERICO ............................................................................20

2.1.1 A IDEOLOGIA LEAN NA ENGENHARIA DE SOFTWARE ..........................21

2.1.1.1 1 PRINCPIO - ELIMINE O DESPERDCIO ............................................22

2.1.1.2 2 PRINCPIO - AMPLIFIQUE O APRENDIZADO ....................................22

2.1.1.3 3 PRINCPIO - ADIE UMA DECISO O MXIMO POSSVEL ...............22

2.1.1.4 4 PRINCPIO - ENTREGUE O MAIS RPIDO POSSVEL .....................23

2.1.1.5 5 PRINCPIO - FORTALEA A EQUIPE .................................................23

2.1.1.6 6 PRINCPIO - CONSTRUA QUALIDADE ..............................................23

2.1.1.7 7 PRINCPIO - OTIMIZE O TODO ..........................................................24

2.2 ENGENHARIA DE SOFTWARE CONTNUA .................................................24

2.2.1 ESTRATGIA E PLANEJAMENTO .............................................................26

2.2.1.1 PLANEJAMENTO CONTNUO.................................................................26

2.2.1.2 ORAMENTO CONTNUO ......................................................................26

2.2.2 DESENVOLVIMENTO DE SOFTWARE ......................................................27

2.2.2.1 INTEGRAO CONTNUA ......................................................................27

2.2.2.2 ENTREGA CONTNUA .............................................................................28

2.2.2.3.1 PIPELINE DE IMPLANTAO ..............................................................29

2.2.2.3.2 BENEFCIOS E DESAFIOS DO DEPLOY CONTNUO ........................30

2.2.2.4 VERIFICAO CONTNUA ......................................................................31