Você está na página 1de 67

Universidade Federal de Pernambuco

Centro de Informática

Graduação em Sistemas de Informação
________________________________________________________

Automatização na escolha de ferramentas em

projetos DevOps

José Eudes de Souza Júnior

Trabalho de Graduação

Recife, Julho de 2017

Universidade Federal de Pernambuco

Centro de Informática

José Eudes de Souza Júnior

Automatização na escolha de ferramentas em

projetos DevOps

Trabalho apresentado ao programa de
GRADUAÇÃO EM SISTEMAS DE INFOR-
MAÇÃO do CENTRO DE INFORMÁTICA da
UNIVERSIDADE FEDERAL DE PERNAMBUCO
como requisito parcial para obtenção do grau de
bacharel em SISTEMAS DE INFORMAÇÃO.

Orientador: Prof. Dr. Vinícius Cardoso Garcia

Recife, Julho de 2017

2
Universidade Federal de Pernambuco

Centro de Informática

José Eudes de Souza Júnior

Automatização na escolha de ferramentas em

projetos DevOps

Aprovado em ___/___/___

BANCA EXAMINADORA

___________________________________________________

Vinícius Cardoso Garcia

Universidade Federal de Pernambuco

___________________________________________________

Kiev Santos da Gama

Universidade Federal de Pernambuco

Recife, Julho de 2017

3
Agradecimentos

Primeiramente, agradeço a Deus, pois ele é a causa primeira e sem a sua mis-
ericórdia, 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 são muito caros e que sem eles eu não con-
seguiria fazer o curso de Sistemas de Informação. Agradeço a Carina Souza, minha
amada esposa, que teve muita paciência comigo durante essa caminhada, pois
sempre me incentivou e me deu forças para que eu não desistisse. Outra pessoa
muito importante é a Aparecida Araújo, minha mãe, 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 força
muito grande, além de sempre acreditarem em mim. Com certeza, sem essas pes-
soas eu não teria chegado até aqui.

Quero a agradecer aos professores do Colégio Santa Bárbara, principalmente
Jorge e Lêucio, que acreditaram muito em mim quando eu me julguei incapaz de
passar no vestibular.

Quero agradecer aos professores do Centro de Informática da UFPE que me
deram a oportunidade de conhecer essa área tão incrível que é a computação. Em
especial quero citar os nomes de Vinícius 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 graduação fizeram parte
da minha trajetória. Em particular Paulo Viana, que se tornou um grande amigo.

Quero também 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-
visão do texto e no entendimento do trabalho. Também me ensinou muito no tempo
em que trabalhamos juntos, na Ustore.

4
Resumo

Após a criação do Manifesto Ágil e a popularização 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 possível esta adaptação, dando a Engenharia de Software mais uma meta
importante, a saber, a eliminação do desperdício, a reação ainda mais rápida às
mudanças nos requisitos e um maior aumento na qualidade, dando origem as práti-
cas contínuas da Engenharia de Software. Nestas práticas, se destacam a inte-
gração, entrega e implantação contínuas. Baseando-se nestas práticas, uma tenta-
tiva de aproximar as equipes de desenvolvimento de software e as equipes de op-
erações das empresas, surgiu o DevOps, que além de promover o alinhamento
destas equipes ainda se utiliza de todas as práticas contínuas, de forma que é pos-
sível contemplar todos os setores da organização com esta cultura. Para que as
práticas contínuas citadas sejam realizadas, é necessário que todas as etapas do
pipeline sejam automatizadas. Com esse objetivo, muitas ferramentas são criadas,
através de empresas que veem na automação 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 dúvida de qual é
adequada, ao se criar um projeto novo ou na iniciativa de migração de um projeto
existente para as práticas do DevOps.

Palavras-chave: DevOps, Pipeline automatizado, Integração Contínua, Entrega Con-
tínua, Implantação Contínua, Ferramentas, Engenharia de Software Contínua, 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 símbolos

ES Engenharia de Software

XP Extreme Programing

IC Integração Contínua

EC Entrega Contínua

DC Deploy Contínuo

DevOps Desenvolvimento e Operações

SLA Acordo de Nível de Serviço

VCS Sistema de Controle de Versão

UI Interface do Usuário

7
Índice de imagens
Figura 1. Continuous * - O conjunto de todas as práticas contínuas ....................... 26

Figura 2. Áreas de cobertura da IC, EC e DC no pipeline de implantação .............29

Figura 3. Pipeline de implantação ............................................................................30

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

Figura 5. Ferramentas de requisitos, desenvolvimento e operações....................... 43

Figura 6. Ferramentas de testes, qualidade e comunicação ................................... 44

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

Figura 8. Botão de redirecionamento de página 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 integrações 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
Sumário
1. INTRODUÇÃO................................................................................................ 13
1.1 CONTEXTO ....................................................................................................13

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

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

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

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

1.6 ORGANIZAÇÃO DO TRABALHO ..................................................................19

2. REFERENCIAL TEÓRICO ............................................................................20
2.1 A IDEOLOGIA LEAN .......................................................................................20

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

2.1.1.1 1º PRINCÍPIO - ELIMINE O DESPERDÍCIO ............................................22

2.1.1.2 2º PRINCÍPIO - AMPLIFIQUE O APRENDIZADO ....................................22

2.1.1.3 3º PRINCÍPIO - ADIE UMA DECISÃO O MÁXIMO POSSÍVEL ...............22

2.1.1.4 4º PRINCÍPIO - ENTREGUE O MAIS RÁPIDO POSSÍVEL .....................23

2.1.1.5 5º PRINCÍPIO - FORTALEÇA A EQUIPE .................................................23

2.1.1.6 6º PRINCÍPIO - CONSTRUA QUALIDADE ..............................................23

2.1.1.7 7º PRINCÍPIO - OTIMIZE O TODO ..........................................................24

2.2 ENGENHARIA DE SOFTWARE CONTÍNUA .................................................24

2.2.1 ESTRATÉGIA E PLANEJAMENTO .............................................................26

2.2.1.1 PLANEJAMENTO CONTÍNUO.................................................................26

2.2.1.2 ORÇAMENTO CONTÍNUO ......................................................................26

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

2.2.2.1 INTEGRAÇÃO CONTÍNUA ......................................................................27

2.2.2.2 ENTREGA CONTÍNUA .............................................................................28
9
2.2.2.3 DEPLOY CONTÍNUO ...............................................................................28

2.2.2.3.1 PIPELINE DE IMPLANTAÇÃO ..............................................................29

2.2.2.3.2 BENEFÍCIOS E DESAFIOS DO DEPLOY CONTÍNUO ........................30

2.2.2.4 VERIFICAÇÃO CONTÍNUA ......................................................................31

2.2.2.5 TESTE CONTÍNUO ..................................................................................31

2.2.2.6 CONFORMIDADE CONTÍNUA ................................................................31

2.2.2.7 SEGURANÇA CONTÍNUA .......................................................................32

2.2.2.8 EVOLUÇÃO CONTÍNUA ..........................................................................32

2.2.3 OPERAÇÕES ..............................................................................................32

2.2.3.1 USO CONTÍNUO ......................................................................................32

2.2.3.2 CONFIANÇA CONTÍNUA .........................................................................32

2.2.3.3 MONITORAMENTO CONTÍNUO .............................................................33

2.2.4 MELHORIA E INOVAÇÃO ...........................................................................33

2.2.4.1 MELHORIA CONTÍNUA ...........................................................................33

2.2.4.2 INOVAÇÃO CONTÍNUA ...........................................................................33

2.2.4.3 EXPERIMENTAÇÃO CONTÍNUA .............................................................33

2.3 DEVOPS .........................................................................................................34

2.3.1 DEVOPS E AGILE .......................................................................................34

3. MAPEAMENTO DAS FERRAMENTAS ......................................................... 36
3.1 ÁREAS DE ATUAÇÃO DAS FERRAMENTAS ............................................... 37

3.1.1 REQUISITOS...............................................................................................37

3.1.2 DESENVOLVIMENTO .................................................................................37

3.1.3 OPERAÇÕES ..............................................................................................38

3.1.4 TESTES .......................................................................................................39

3.1.5 QUALIDADE ................................................................................................39

10
3.1.6 COMUNICAÇÃO E FEEDBACK..................................................................40

3.2 SEPARAÇÃO E CLASSIFICAÇÃO DAS FERRAMENTAS ............................40

3.2.1 NOME ..........................................................................................................40

3.2.2 SUBÁREA ....................................................................................................40

3.2.3 WEBSITE.....................................................................................................41

3.2.4 ARTIGOS .....................................................................................................41

3.2.5 TIPO DE PROJETO ....................................................................................41

3.2.6 LINGUAGEM DE PROGRAMAÇÃO ...........................................................41

3.2.7 MANTENEDORES ......................................................................................41

3.2.8 TIPO DE LICENÇA ......................................................................................41

3.2.9 INTEGRAÇÃO .............................................................................................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 INTEGRAÇÃO 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. CONSIDERAÇÕES FINAIS..............................................................................51
5.1 LIMITAÇÕES ..................................................................................................51

5.2 TRABALHOS FUTUROS................................................................................ 51

11
5.3 CONCLUSÃO ................................................................................................52

REFERÊNCIAS BIBLIOGRÁFICAS .................................................................... 53
APÊNDICE A - TABELA DE FERRAMENTAS ....................................................58
APÊNDICE B - IMAGENS DA FERRAMENTA ....................................................64

12
1. Introdução

1.1 Contexto

Em 2017, a Engenharia de Software (ES) está completando 49 anos de
existência. A busca por métodos de engenharia para o desenvolvimento de software
foi proposta em 1968 na conferência da OTAN [13, 16]. A ES foi criada na tentativa
de resolver os problemas que levaram a falta de eficiência generalizada na entrega
de grandes sistemas, envolvendo atrasos, ausência de funcionalidades e custos
que iam muito além do esperado [16]. Ainda seguindo o raciocínio de [16], como o
software é intangível, logo, ele não tem limites para evoluir, entretanto, de todo esse
potencial emerge a complexidade que envolve os sistemas de software. Ao se
tornarem complexos, além dos problemas citados anteriormente, os sistemas se
tornaram difíceis de entender e muito caros para serem modificados. Como conse-
quência disso, os grandes projetos de software passaram a ser encarados com
grande desconfiança.

A ES então passou a dar suporte a criação de produtos de software criados
por equipes que eram responsáveis por alterar e manter o software durante todo o
seu ciclo de vida. A ES trouxe consigo também, um conjunto de técnicas desti-
nadas a apoiar a especificação, projeto e evolução dos sistemas de software. Soft-
ware, a partir desse momento, não era mais apenas um programa de computador
ou meramente um sistema, o termo passou a agregar a documentação associada e
os dados de configurações, que eram necessários para tornar os sistemas op-
eráveis. Os documentos e dados poderiam ser arquivos de configuração, documen-
tação do sistema, documentação da estrutura, manuais, documentos de arquitetura
e documentações do usuário [16].

Para dar suporte a emergente ES, foram criadas as Metodologias de Desen-
volvimento (ou Processos), que são conjuntos de atividades com resultados associ-
ados que auxiliam a produção 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 avanço da tecnologia,
surgiram alternativas de menor custo, o que ajudou a acelerar o surgimento da
globalização, que por sua vez, abriu novos mercados, gerando uma concorrência a
nível mundial. Nesse momento, a competitividade das empresas aumentou severa-
mente, tornando os modelos tradicionais incompatíveis, devido a grande demanda
por produtos de software [2, 16]. As Metodologias Tradicionais passaram a ser en-
caradas como pesadas e orientadas a documentação [2, 16, 17, 24] e na década 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 mudanças con-
stantes nos projetos e as incertezas nos requisitos converteram o desenvolvimento
de software em uma atividade muito mais dinâmica, inviabilizando o levantamento
dos requisitos de forma estável, como era exigido nos modelos tradicionais,
atrasando o cronograma dos projetos ao postergar a entrega para muito além do
prazo acordado inicialmente [16]. Esta falta de agilidade dos projetos utilizando
métodos tradicionais se tornou séria, de modo que alguns projetos ao chegarem na
sua fase final com o software já disponível para uso, o mesmo já havia se tornado
inútil devido as mudanças radicais em requisitos, regras de negócio 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 variáveis citadas anteriormente fora
do limite acordado, ou seja, foram entregues fora do prazo, com o custo acima do
acordado ou as funcionalidades não correspondiam as expectativas dos clientes.
Os dados ainda mostravam que entre os projetos que foram entregues com prob-
lemas, a média 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 década de 1990, a insatisfação com os métodos tradicionais aumentou
ainda mais. Isso porque esses projetos orientados a planos não atendiam a maioria
dos projetos de software, pois se gastava mais tempo com análises e documen-

14
tações do que com desenvolvimento e testes [16]. Com isso os desenvolvedores
propuseram a criação 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 são baseadas em entregas incre-
mentais, sendo mais flexíveis no momento em que os requisitos mudam [16, 17].
Finalmente, em 2001 foi criada a Aliança Á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 princípios
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 mudanças,
além do aumento na qualidade e maior satisfação 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 desperdiçam recursos
valiosos ao não incentivar uma sinergia entre os times de qualidade, operações e
desenvolvimento. Estudos demonstram que uma colaboração mais aperfeiçoada
entre estas equipes, possibilita melhorias nos processos de desenvolvimento e op-
erações, tornando a organização mais competitiva [4, 13].

Nos últimos anos, estamos vivenciando mais uma revolução nos processos de
desenvolvimento de software, que está sendo chamada de era Pós-Ágil [4]. A ne-
cessidade da equipe de desenvolvimento obter maior frequência nos feedbacks dos
clientes e de entregar frequentemente o software no ambiente de produção, torna
possível, dependendo do domínio da aplicação, a realização de várias implantações
por dia, o que não é viável em uma abordagem ágil, pois apesar de curtas, as iter-
ações duram um certo tempo para serem realizadas [4]. É nesse contexto que surge
o conceito de Implantação Contínua (DC1) [4].

O DC tem suas raízes nos conceitos da ideologia Lean [2, 4, 6, 9], que é orig-
inária da fabricação, sendo inserida no contexto da ES pela primeira vez no Lean

1 Para fins didáticos, este trabalho utilizará a sigla DC, misturando o os termos em inglês e em português: Deploy Contínuo.
15
Software Development [4]. Esta abordagem tem a Integração Contínua (IC) e a En-
trega Contínua (EC) como pré-requisitos para ser alcançada, além de necessitar de
um pipeline de desenvolvimento automatizado e uma ampla infraestrutura acom-
panhada de processos e práticas compatíveis [4, 6]. Uma outra abordagem que uti-
liza largamente os métodos contínuos de desenvolvimento é o DevOps [4, 5, 6, 7, 9,
11], que enfatiza a colaboração e a comunicação entre as equipes de desenvolvi-
mento e as de operações, sob a premissa que a cooperação das duas áreas resulta
em um rápido desenvolvimento contínuo [4, 5, 11, 18]. Já existem muitas empresas
que utilizam práticas contínuas, incluindo o DC [2, 6, 10]. Trabalhos como [2, 4, 6,
11], mostram que a implantação frequente ajuda na criação e desenvolvimento de
produtos melhores por serem mais reativos.

Para que tudo isso seja possível, uma mudança na cultura organizacional e
uma quantidade considerável de ferramentas de apoio são requeridas [2, 4, 8, 11].
Para que o pipeline de desenvolvimento seja automatizado até que a implantação
seja feita no ambiente de produção, 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, vários tipos de ferramentas são utilizados para garantir a
entrega rápida 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 vários fatores que envolvem cultura organizacional e limitações
técnicas das equipes e ferramentas, além do tipo de natureza do produto [25].

Um estudo mostra várias observações feitas por usuários do DevOps [15]. Es-
tas observações foram colhidas através de oficinas de design e entrevistas que pos-
teriormente alimentaram um banco de dados, onde foi realizada uma análise de
sentimentos. Um dos problemas mais evidentes identificados pelos participantes é
a escolha de ferramentas para a automação dos processos.

16
1.3 Objetivos

Este trabalho tem como objetivo geral o mapeamento de ferramentas e a cri-
ação de uma ferramenta conceitual, para auxiliar na escolha das ferramentas que
serão utilizadas em projetos DevOps. A ferramenta de escolha deve dar apoio a pro-
jetos que utilizem as práticas de IC, EC ou DC, informando as principais ferramen-
tas, disponíveis nos melhores trabalhos da literatura atual, para todo o pipeline de
desenvolvimento.

Há destaque também para alguns objetivos específicos importantes:

1. Informar quais as diferenças entre as práticas contínuas e as metodolo-
gias ágeis;

2. Verificar até que ponto as práticas contínuas são benéficas para os pro-
jetos de software;

3. Analisar as ferramentas mais utilizadas em projetos reais, através de es-
tudos de caso disponíveis na literatura;

4. Compreender como as ferramentas são classificadas e organizadas para
cada etapa do pipeline de desenvolvimento.

1.4 Escopo

Este trabalho se limita à criação de uma ferramenta conceitual que informa
quais são as principais ferramentas que envolvam as práticas contínuas descritas
na seção 1.3, cobrindo todas as áreas do pipeline exibido em [10]. O pipeline será
explicado na seção 2.2.2.3.1. O estudo e mapeamento das ferramentas foi suporta-
do por dois trabalhos com um viés prático sobre o assunto, um deles [2] demonstra
empiricamente quais as ferramentas mais usadas pelas equipes DevOps através de
entrevistas realizadas em 18 empresas finlandesas que estão comprometidas em
realizar entregas rápidas com maior valor para o cliente. O outro trabalho [26],
fornece uma revisão sistemática da literatura contendo 69 estudos primários publi-
cados de 2004 à 2012, onde a segunda pergunta que motivou a revisão está rela-
cionada ao uso de ferramentas que automatizam o pipeline de implantação.

17
Nestes trabalhos, as ferramentas mapeadas são suficientes para automatizar
os pipelines das diversas empresas e projetos que foram estudados [2, 10], no en-
tanto, vale ressaltar que as ferramentas não cobrem a totalidade da grande maioria
dos casos e o mapeamento contido neste trabalho não é exaustivo.

O foco deste trabalho não é criar um meio para resolver o problema da escol-
ha de ferramentas, mas sim levantar questionamentos que incentivem a construção
de:

1. Ferramentas que suportem completamente o pipeline dos diversos tipos
de projetos de software;

2. Sistemas que auxiliem as empresas, informando as boas práticas e
façam o mapeamento das diversas ferramentas que automatizam o
pipeline dos diversos tipos de projetos de software.

1.5 Metodologia

O método adotado para chegar ao objetivo é composto por uma pesquisa ex-
ploratória, se utilizando dos principais repositórios em busca de artigos, publi-
cações, periódicos, revistas, dissertações, estudos de caso e revisões sistemáticas
que tragam informações das principais pesquisas sobre práticas contínuas e
cadeias de ferramentas que suportem estas práticas, a fim de trazer embasamento
para a redação deste trabalho e possibilitar que os objetivos sejam alcançados.

Os repositórios de busca foram:

• IEEEXplore Digital Library [27];

• Science Direct [28];

• ACM [29];

• Scopus [30];

• Google Scholar [31].

Outra técnica utilizada na obtenção de trabalhos foi a leitura das referências
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 parágrafo lido foi grifado e resumido para ajudar
no mapeamento da informação.

Para modelar as ferramentas, foi utilizada a ferramenta Shapes 3. Para criar a
ferramenta, foi utilizada a ferramenta Visual Studio Code.

1.6 Organização do trabalho

Este trabalho está organizado da seguinte forma: O capítulo 1 dá uma visão
histórica da ES até a chegada do DevOps, informando as reais necessidades das
criações de novas formas de se construir software. O capítulo 2 dá um embasamen-
to teórico para todos os conceitos apresentados. O capítulo 3 exibe o mapeamento
das ferramentas e informa os dados coletados. O capítulo 4 fala da ferramenta cria-
da e mostra um estudo de caso feito em um projeto real. Por fim, o capítulo 5 con-
clui o trabalho, dissertando sobre trabalhos futuros e as limitações deste.

1 https://www.mendeley.com
2 https://www.google.com/chrome/browser/desktop/index.html
3 http://shapesapp.com/

19
2. Referencial Teórico

Este capítulo servirá de arcabouço teórico do trabalho, descrevendo os princi-
pais termos que são utilizados.

2.1 A ideologia Lean 1

No fim da década de 1940, uma pequena empresa chamada Toyota decidiu
fabricar carros no Japão [35]. Porém, verificou-se que os carros tinham que ser
baratos, pois os estragos causados na segunda grande guerra devastou a econo-
mia do país e, consequentemente, as pessoas não tinham muito dinheiro [36].

Com o conhecimento que se tinha na época, a maneira de haver fabricação
barata de automóveis era através de uma linha de produção em massa. O problema
é que este tipo de produção não atendia o mercado japonês, pois era um mercado
relativamente pequeno. Para resolver o problema de fabricar carros em pequena
quantidade tão baratos quanto os produzidos em massa, surgiu o Sistema Toyota
de Produção, Tendo como a cabeça por trás deste sistema, Taiichi Ohno2[35].

Esta nova forma de desenvolver produtos tinha uma meta: A eliminação de
desperdícios [1, 35]. A forma de encarar o desperdício foi modificada com a nova
ideologia. Desperdício, a partir desse viés teve o seu significado ampliado, entre os
vários tipos, é possível destacar:

• Superprodução (Recursos não desejados);

• Atividades que não são necessárias;

• Produto esperando que outras atividades terminem;

• Passos extras no processo de desenvolvimento;

• Defeitos.

O foco da ideologia era criar e entregar o produto imediatamente após o pedi-
do, ou seja, o desenvolvimento deveria começar após a solicitação do cliente,
porém a meta é entregar o produto rapidamente. Segundo a ideologia, quando um
projeto começa, ele deve ser finalizado o mais rápido possível, 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 Produção e do Sistema Kanban [37].
20
to que está em desenvolvimento não está agregando valor até que seja entregue.
Produtos em desenvolvimento são encarados como um estoque de fábrica [35].

O primeiro passo para o desenvolvimento enxuto (do inglês, lean) é aprender a
detectar o desperdício. O segundo passo é descobrir as maiores fontes de des-
perdício e eliminá-las. Estes dois passos devem ser repetidos sempre. Depois de
um tempo, até as coisas que pareciam mais essenciais serão gradualmente elimi-
nadas [35].

2.1.1 A ideologia Lean na Engenharia de Software

As origens desta metodologia vem da fabricação de carros, mas os seus
princípios podem ser aplicados em outras áreas. Entretanto, elas não podem ser
aplicadas diretamente vindas de uma linha de produção de fábrica na ES.

Houveram muitas tentativas de inserir no desenvolvimento de software as
práticas da ideologia Lean. Segundo [35] isso acontece porque a criação de soft-
ware não é uma prática de produção, e sim uma prática 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 princípios fundamentais [2, 24, 35]:

1. Eliminação de desperdício;

2. Amplificação do aprendizado;

3. Adiamento das decisões;

4. Entregar o mais rápido possível;

5. Fortalecimento da equipe;

6. Construção de qualidade;

7. Otimização do todo.

Ao incorporar estes princípios à ES, surge a abordagem contínua no desen-
volvimento de software, uma tendência emergente que adota uma abordagem holís-
tica no desenvolvimento contínuo de software [24].

21
2.1.1.1 1º Princípio - Elimine o desperdício

O desperdício é qualquer coisa que não agrega valor a um produto. O valor
considerado aqui é como o produto é percebido pelo cliente. Na ideologia Lean, o
conceito de desperdício é um grande obstáculo. Se o documento de requisitos fi-
cou somente no papel, isso é um desperdício. Se algo foi feito além do necessário,
isso é um desperdício. Se houver código além do necessário, isso é um desperdí-
cio. Na fabricação, mover o produto é um desperdício. No desenvolvimento de pro-
dutos, transferir o desenvolvimento de um grupo para outro é o desperdício. 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 não satisfaça rapida-
mente a necessidade do cliente é desperdício [35].

2.1.1.2 2º Princípio - Amplifique o aprendizado

O desenvolvimento de software é um trabalho de aprendizado, diferente da
produção que é um exercício de práticas rígidas e, por esse motivo, a ideologia
Lean no desenvolvimento resulta em práticas diferentes das que são realizadas na
produção. Como o desenvolvimento produz variações no processo de aprendiza-
gem, a equipe deve buscar meios de transferência de conhecimentos entre os seus
membros. Muito importante para este princípio é manter a comunicação entre a
equipe, bem como o feedback contínuo entre as diferentes equipes e usuários du-
rante o desenvolvimento do software [35].

2.1.1.3 3º Princípio - Adie uma decisão o máximo possível

Como as práticas de desenvolvimento envolvem muitas incertezas, principal-
mente em suas fases iniciais, o adiamento das tomadas de decisões são mais efi-
cazes. Postergar as decisões é importante porque as decisões podem ser tomadas
de forma mais eficiente quando são baseadas em fatos, não em especulações
como ocorre diante das incertezas. Em um projeto em evolução, manter as opções
disponíveis é mais valioso do que fazer uma escolha logo no início [35].

22
2.1.1.4 4º Princípio - Entregue o mais rápido possível

O desenvolvimento rápido tem muitas vantagens. Sem rapidez na entrega,
você não consegue atrasar as decisões. Sem velocidade, você não tem feedback
confiável. No desenvolvimento, a descoberta é fundamental para a aprendizagem,
design, implementação, feedback, melhoria. Quanto mais curtos forem estes ciclos,
maior a possibilidade de se aprender. Velocidade assegura que os clientes estão re-
cebendo o que precisam agora, e não o que eles precisavam ontem. Também per-
mite adiar a ideia final do que eles realmente querem até que eles realmente saibam.
Aumentar o fluxo de valor, tanto quanto for possível, é uma estratégia fundamental
para a eliminação de desperdício [35].

2.1.1.5 5º Princípio - Fortaleça a equipe

Envolver os desenvolvedores nas decisões técnicas é fundamental para al-
cançar a excelência. Quando equipados com conhecimentos necessários e guiados
por um líder, os desenvolvedores tomarão decisões melhores em grupo, tanto na
área técnica como na de processos. Com as decisões sendo tomadas tardiamente
e com velocidade na entrega, não é viável apenas uma pessoa comandando as
atividades. Assim, as práticas Lean usam técnicas de produção puxada para agen-
dar o trabalho através de mecanismos de sinalização de tarefas para que os trabal-
hadores saibam o que precisa ser feito. No desenvolvimento de software Lean, a
técnica de produção puxada 1 é acordada para entregar versões cada vez mais refi-
nadas do software em intervalos regulares. A sinalização é feita através de gráficos
visíveis, reuniões diárias, integração frequente e testes abrangentes [35].

2.1.1.6 6º Princípio - Construa qualidade

Um sistema é de qualidade quando um usuário pensa: "Sim! Isso é exata-
mente o que eu quero. Alguém leu meus pensamentos!”. O software precisa de um

1Um bom texto sobre a técnica pode ser encontrado aqui: http://www.lean.org.br/conceitos/102/definicao-de-producao-puxada-
e-sistemas-puxados.aspx
23
nível adicional qualidade: deve manter sua utilidade ao longo do tempo. Espera-se
que o software evolua à medida que se adapta às mudanças. O software com qual-
idade possui uma arquitetura coerente, alto grau de usabilidade, eficácia, é susten-
tável, adaptável e extensível. Qualidade vem de um projeto liderado sabiamente,
com uma equipe com conhecimentos relevantes, comunicação efetiva, disciplina
saudável [35].

2.1.1.7 7º Princípio - Otimize o todo

Obter qualidade em sistemas complexos requer uma experiência profunda em
diversas áreas. Um dos problemas mais difíceis 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
própria especialidade em vez de se concentrar no desempenho geral do sistema.
Muitas vezes, o bem comum sofre se as pessoas atendem primeiro a seus próprios
interesses [35].

2.2 Engenharia de Software Contínua

No início da ES, o desenvolvimento de software foi marcado pela falta de flexi-
bilidade nos processos, o que prejudicava atividades importantes como planeja-
mento, análise, design e construção. 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 freqüência de certas ativi-
dades críticas no intuito de superar os desafios. Práticas como a entrega antecipa-
da e entrega frequente estão bem estabelecidas no desenvolvimento de software
aberto [2]. Podemos ver claramente esta afirmação concretizada ao observarmos a
crescente adoção da prática de IC. A popularidade desta prática se deve a sua re-
comendação explícita no XP [22].

Porém o que se nota nas tendências recentes é que as práticas contínuas vão
muito mais além do que apenas a prática da IC. Um exemplo é que as práticas
ágeis não suportam o alinhamento de práticas com as áreas de negócios ou recur-

24
sos humanos1. Outro exemplo é o DevOps, que reconhece a necessidade das práti-
cas contínuas [2]. Em vez de uma seqüência de atividades que são realizadas por
equipes ou departamentos claramente distintos, a engenharia de software contínua
estabelece práticas contínuas, com suas origens nos conceitos encontrados na
ideologia Lean, no entanto, há alguns estudos que erroneamente ligam estas práti-
cas apenas as práticas ágeis [9, 24]. Enquanto o desenvolvimento de software ágil
foca principalmente no desenvolvimento do software, o desenvolvimento contínuo
tem um foco muito explícito no processo de ponta a ponta: do cliente para a entre-
ga. Com base em uma comparação de princípios e práticas de desenvolvimento
ágil e Lean, estudos concluem que este foco de ponta a ponta é a principal difer-
ença entre as abordagens [24].

Há uma grande quantidade de termos e conceitos envolvidos na engenharia
de software contínua. Por ser uma área de pesquisa relativamente nova em muitos
aspectos, uma discordância entre os trabalhos sobre o que é uma prática ou outra e
em certos momentos, algumas práticas 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 distinção entre IC, EC e DC é crucial.  Portanto vamos adotar a
seguinte definição:


• Integração Contínua: os desenvolvedores enviam suas mudanças com
frequência para repositórios de controle de versão, que desencadeiam
testes em servidores de IC;

• Entrega Contínua: as etapas da EC incluem passos automatizados, adi-
cionais à IC, para preparar uma versão do software pronto para a implan-
tação. Normalmente, a implantação para o ambiente de produção não é to-
talmente automatizada e requer intervenção manual na EC;

• Deploy Contínuo: a implantação no ambiente de produção é automatizada.


Esta definição foi a mais comum encontrada nos trabalhos pesquisados.

1Ultimamente têm surgido algumas tentativas do alinhamento das metodologias ágeis com a área de negócios, como podemos
ver em [45]
25
A figura 1 mostra todas as práticas contínuas e suas relações com a organiza-
ção. Uma descrição sucinta de cada uma será feita, porém as mais importantes
para este trabalho serão discutidas mais detalhadamente.

Figura 1. Continuous * - O conjunto de todas as práticas contínuas

Fonte: [2]

2.2.1 Estratégia e Planejamento

Aqui serão citadas as práticas contínuas relativas ao setor estratégico da or-
ganização, conhecidas como BizDev1.

2.2.1.1 Planejamento Contínuo

Envolve os vários stakeholders das áreas de negócios e de desenvolvimento
de software. Esta prática gera planos e artefatos dinâmicos que vão evoluindo de
acordo com as mudanças no ambiente dos negócios e, portanto, envolvem uma
maior integração entre planejamento e execução [9, 24].

2.2.1.2 Orçamento Contínuo

1 BizDev não será detalhado aqui, pois não faz parte do escopo deste trabalho.
26
O orçamento é tradicionalmente um evento anual, informando as previsões de
investimentos, receitas e despesas de uma organização para o próximo ano. Esta
prática sugere que o orçamento também se torne uma atividade contínua, para fa-
cilitar as mudanças durante o ano [9, 24].

2.2.2 Desenvolvimento de software

Aqui serão citadas as práticas contínuas relativas ao setor de desenvolvimento
de software da organização, que faz parte do DevOps.

2.2.2.1 Integração contínua

De todas as praticas contínuas, a IC é a mais popular. Esta popularidade é
possível porque o XP faz uma recomendação explícita da prática. De fato, a IC é al-
tamente compatível com as metodologias ágeis e por isso muitas ferramentas de
código aberto estão disponíveis gratuitamente para automatizar o processo de IC
[9].

Como vimos, um dos princípios do desenvolvimento Lean é "entregar o mais
rápido possível”. 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 frequência no servidor de controle de versão. A IC também inclui im-
plicitamente a prática de Teste Contínuo para obter feedback rápido e frequente
para a equipe de desenvolvimento1 [2]. Por exemplo, há ferramentas que sinalizam
assim que problemas são encontrados na construção [9].

Ståhl e Bosch estudaram quais os efeitos da IC [38], apresentando as difer-
enças entre as implementações desta prática.  Mais tarde, eles desenvolveram um
meta-modelo para a implementação da IC nas organizações, visando as diferentes
implementações encontradas em seus estudos [39]. Eles descobriram que a prática
da IC varia entre as empresas e até mesmo entre projetos da mesma empresa.
Também descobriram que apesar de as empresas chamarem o seu processo de IC,
nem sempre os princípios das práticas contínuas são seguidos [2]. 

Um fluxo de etapas da IC está descrito na seção 2.2.2.3.1.

1 A figura 3 ilustra este fluxo.
27
2.2.2.2 Entrega contínua

A EC é a prática que vem logo após as práticas de IC, implantando o pacote
criado na construção em um ambiente de testes, que não deve ser confundido com
o ambiente de produção. No pacote implantado, há toda a alteração de código de
cada desenvolvedor já integrada, testada e compilada. É possível que existam
vários estágios de teste neste ambiente antes da implantação na produção. 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 produção. A Diferença da EC para o DC, é que no DC, o envio para a produção 
acontece automaticamente, sem aprovação explícita [2, 45].

A EC permite que os desenvolvedores e o time de qualidade automatizem
testes que vão além dos testes de unidade, de forma que seja possível verificar as
novas versões em várias dimensões antes de implantá-las na produção. Os testes
realizados na EC, podem incluir testes de interface gráfica, carga, integração, confi-
abilidade, API, etc. Esta prática auxilia a equipe a validar com melhor precisão no-
vas versões, tonando mais fácil a prevenção de erros [2, 45].

2.2.2.3 Deploy contínuo

A implantação contínua é a prática de implantação de novos softwares e fun-
cionalidades no ambiente de produção à medida em que se desenvolve, ao invés
de fazer implantações agendadas e menos frequentes. Na teoria, para que a prática
de DC se concretize, é obrigatório o uso de um pipeline de desenvolvimento ininter-
rupto desde o repositório até a implantação. Para que isso seja possível, é
necessária 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 fácil configuração, permite que uma empresa
adquira o desenvolvimento rápido e facilite a implantação rápida de novos soft-
wares para os clientes [9, 24].

28
2.2.2.3.1 Pipeline de implantação

O DC Só pode ser alcançado se a organização tiver um pipeline de implan-
tação definido e automatizado.  Os desenvolvedores fazem alterações no código.
Após isso, o sistema de controle de versão desencadeia uma fase de confirmação
no pipeline. Nesta fase, o software é normalmente compilado, testado, e um artefato
de construção é criado.  Muitas vezes, a análise de código estático e a coleta de
métricas de código também são feitas. O estágio de confirmação deve ser rápido e
capaz de capturar os erros mais graves [2, 10]. Até aqui, as etapas compreendem a
prática de IC.

Para iniciar as etapas de EC no pipeline, a etapa de testes de aceitação é exe-
cutada. Esta etapa é automática, mas estes testes serão executados em um ambi-
ente de testes parecido com o de produção. Estes testes podem demorar mais
tempo para serem concluídos. O objetivo desta fase é validar que o software atende
aos seus critérios de aceitação e pode ser enviado para o ambiente de
produção. Depois de passar no estágio de teste de aceitação, o software pode pas-
sar por outros estágios de teste que podem ser manuais, como testes de aceitação
do usuário ou testes de capacidade. A etapa de testes manuais deve, no entanto,
ser reduzida ao mínimo, porque ela trava o pipeline de implantação.  Aqui, a EC é
finalizada.

Depois de passar por todas as etapas de IC e EC, o software pode ser implan-
tado na produção, configurando a prática do DC [2].

Figura 2. Áreas de cobertura da IC, EC e DC no pipeline de implantação

Fonte: [44]

29
Com base nos trabalhos encontrados, o pipeline de implantação deve ser au-
tomatizado, tanto quanto possível, ou no mínimo, semi-automatizado.  É recomen-
dado que todo o trabalho manual seja reduzido ao mínimo possível, portanto, as
cadeias de ferramentas adequadas são essenciais para o DC [2].

Se durante o processo houverem falhas, será criada uma série de artefatos e
relatórios gráficos para ajudar a garantir que os problemas que levaram a essas fal-
has sejam priorizados, sendo resolvidos o mais rápido possível por quem for con-
siderado responsável [9].

Figura 3. Pipeline de implantação

Fonte: [10]

2.2.2.3.2 Benefícios e desafios do Deploy contínuo

Em um dos estudos encontrados, o foco está nos potenciais benefícios e de-
safios da implantação contínua, através 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, implantações 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 implementação de práti-
cas de implantação contínua. As questões técnicas, como o tamanho e a complexi-

30
dade dos projetos, e a necessidade de realizar estágios de testes manuais também
são vistos como impedimento para a prática efetiva do DC [2].

O DC permite a implantação (e remoção, se necessário) de novos recursos e
modificações com a menor sobrecarga possível. Isso permite a organização deter-
minar o valor dos componentes do software mais rapidamente, com usuários reais
[25].

Um estudo de caso pode detalhar melhor os benefícios e desafios do DC [25].
Este estudo mostra os benefícios e desafios percebidos por funcionários após a
adoção do DC em várias empresas finlandesas que fazem parte do N4S1, através
de entrevistas.

2.2.2.4 Verificação contínua

Adoção de atividades de verificação, incluindo métodos e inspeções formais
ao longo do processo de desenvolvimento. Se opõe às práticas de execução dos
testes apenas no fim das atividades de desenvolvimento [9, 24].

2.2.2.5 Teste contínuo

Prática que envolve a automação dos testes e a priorização de casos de teste,
para ajudar a reduzir o tempo entre a introdução dos erros e a detecção destes,
com o objetivo de eliminá-los de uma forma mais eficaz [9, 24].

2.2.2.6 Conformidade contínua

Nesta prática, o desenvolvimento de software busca satisfazer os padrões de
conformidade de forma contínua, ao invés de operar uma abordagem de "big-bang"
para garantir globalmente a conformidade imediatamente antes da liberação do
produto [9, 24].

1 Um programa finlandês de pesquisa em empresas da área de tecnologia da informação e comunicação que utilizam as práti-
cas da ES Contínua [40].
31
2.2.2.7 Segurança contínua

Esta prática muda a forma como se vê a segurança do software. Antes vista
como mais um requisito não funcional, agora é encarada como uma preocupação
fundamental em todas as fases do ciclo de vida do desenvolvimento e até mesmo
depois da implantação, apoiada por uma abordagem inteligente para identificar vul-
nerabilidades de segurança [9, 24].

2.2.2.8 Evolução contínua

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 decisões de pro-
jeto que foram feitas durante a criação do sistema. Com o decorrer do projeto, al-
gumas destas decisões podem não ser mais válidas e a arquitetura poderá dificultar
algumas mudanças. Quando uma arquitetura não adequada dificulta a inserção de
novos requisitos e certos "atalhos" são feitos para contornar o problema, a dívida
técnica aumenta. Esta atividade foca em sempre haver revisões destas decisões de
projeto ao longo do ciclo de vida [9, 14, 24].

2.2.3 Operações

Aqui serão citadas as práticas contínuas relativas ao setor de operações da
organização, que faz parte do DevOps.

2.2.3.1 Uso contínuo

Esta prática visa a retenção de clientes ao invés de atrair novos [9, 24]. Isso só
é possível através da prática de manutenção contínua, que é melhor explorada em
[3].

2.2.3.2 Confiança contínua

Nesta prática, a confiança é desenvolvida ao longo do tempo como resultado
de interações, baseadas na crença 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 contínuo

Nesta prática, os comportamentos de execução devem ser monitorados para
permitir a detecção precoce de problemas na qualidade do serviço, como a
degradação do desempenho, e também o cumprimento de acordos de nível de
serviço (SLAs) [9, 24].

2.2.4 Melhoria e Inovação

Aqui serão citadas as práticas contínuas relativas a melhoria e inovação no de-
senvolvimento de software.

2.2.4.1 Melhoria contínua

Tem base nos princípios da ideologia Lean, onde a tomada de decisão está
pautada na eliminação de desperdício, trazendo melhorias incrementais de quali-
dade. Aumentando a vantagem competitiva do produto [9, 24].

2.2.4.2 Inovação contínua

Esta prática provê um processo sustentável que responde as constantes
evoluções do mercado, com base em métricas apropriadas durante todo o ciclo de
vida das fases de planejamento, desenvolvimento e execução [9, 24].

2.2.4.3 Experimentação contínua

Uma prática baseada em experimentação com stakeholders, consistindo em
ciclos de construção-medição-aprendizado [9, 24].

33
2.3 DevOps

Não há ainda uma definição rígida nos trabalhos do que é o DevOps. Em al-
guns trabalhos é definido como uma metodologia, em outros, uma técnica, e em
alguns, um processo. Os efeitos causados pela sua adoção nas organizações vão
além disso. O DevOps pode ser classificado como uma ideologia que evoluiu em
resposta à falta de esforços na sinergia entre as equipes de desenvolvimento e op-
erações. A cultura DevOps atua como um facilitador para oferecer mais funcionali-
dades continuamente, mantendo a estabilidade [11, 12, 15]. Se baseia nas práticas
da ES Contínua, que ajudam a reduzir o tempo entre o desenvolvimento do software
e a sua implantação no ambiente de produção, 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 rápido
possível. Para isso, tanto a equipe de desenvolvimento como a de operações pre-
cisam chegar a um acordo de quais práticas da ES Contínua serão utilizadas para
alcançar este objetivo. Isso inclui o canal de comunicação entre as equipes [13].

2.3.1 DevOps e Agile

Agile é o conjunto de práticas 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 colaboração entre os membros da
equipe, a automação da construção, implantação e teste, medições e métricas de
custo, compartilhamento de conhecimento e ferramentas. DevOps adiciona valor ao
Agile ao fornecer uma extensão pragmática para as atividades ágeis. Por exemplo,
como o DevOps enfatiza mais a comunicação e a colaboração entre as equipes de
desenvolvimento e operações, em vez de ferramentas e processos, é possível atin-
gir metas ágeis para reduzir a carga de trabalho em equipe e estender princípios
ágeis em todo o pipeline de implantação [5].

No entanto, há um momento em que o DevOps rompe com o Agile. Ao utilizar
as práticas contínuas, o DevOps entra em conflito com os princípios propostos pelo
manifesto ágil, em especial com o primeiro princípio. Além disso, à medida que as

34
funcionalidades vão sendo desenvolvidas e implantadas, gradualmente vai dimin-
uindo a necessidade das iterações [13].

35
3. Mapeamento das Ferramentas

Neste capítulo, serão apresentadas as ferramentas utilizadas por equipes cu-
jos projetos possuem a cultura DevOps. As ferramentas são citadas em uma série
de estudos de caso, artigos e revisões sistemáticas da literatura. Os estudos
forneceram as informações que tornaram possível a realização do mapeamento das
ferramentas. Os trabalhos utilizados são: [2, 3, 5, 7, 8, 11, 12, 26, 39, 49, 50].

O desenvolvimento de software contínuo deve ser suportado por uma cadeia
de ferramentas que automatizam o pipeline, desde a criação do código até a im-
plantação. O papel das ferramentas é garantir que seja possível desenvolver, testar
e implantar o software enquanto ao mesmo tempo são produzidos comentários 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-
cações, por influência dos modelos apresentados nos estudos restantes.

Figura 4. Áreas de cobertura das ferramentas

Fonte: o Autor, adaptado de [2]
36
3.1 Áreas de atuação das ferramentas

As áreas de atuação das ferramentas são: requisitos, desenvolvimento, oper-
ações, Testes, Qualidade e Comunicação e Feedback, da mesma forma que é feito
em [2]. Nos tópicos seguintes, serão justificadas a importância dos tipos de ferra-
mentas que foram apresentadas na figura 4.

3.1.1 Requisitos

Mesmo que o DC seja realizado várias vezes por dia, os requisitos devem ser
claros. Para que isso seja possível, manter um registro de todos os requisitos, bem
como de todos os dados associados à eles é essencial no desenvolvimento de
software. Para os requisitos, as ferramentas que gerenciam os requisitos e o back-
log são consideradas. Os requisitos e feedbacks do usuário podem ser obtidos não
somente através da coleta direta com usuários, também é possível realizar essa
aproximação através de ferramentas de solicitação de melhorias e de monitoramen-
to de uso [2]. 

O rastreamento de erros também está relacionado ao gerenciamento de back-
log, pois a correção de um bug também é uma tarefa de desenvolvimento, logo,
também é uma tarefa do backlog como qualquer outra. Em alguns casos, os bugs
também são sinalizados por clientes ou usuários finais. Nesse caso, uma ferramenta
para a comunicação pode ser necessária [2].

3.1.2 Desenvolvimento

Sistemas de controle de versão  (VCS) existem para gerenciar mudanças em
vários documentos, como o código-fonte e páginas da Web, e outras informações
que podem ser alteradas durante o desenvolvimento do software [2]. 

Os sistemas de construção  são fundamentais para o desenvolvimento de
software. Criam os pacotes de instalação baseados em arquivos de
especificação. Estes arquivos de especificação podem incluir instruções para com-
pilação de código, execução de casos de teste e criação de pacotes de implan-
tação. Ferramentas de construção interpretam estes arquivos, ajudando os desen-
37
volvedores a gerenciar as dependências internas e externas de software, como
acontece com as bibliotecas externas utilizadas [2].

As construções automatizadas concretizam a prática 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-
danças que, consequentemente, desencadeiam a execução das várias etapas con-
figuradas no servidor de IC. As etapas podem incluir a compilação e o empacota-
mento do código para criar uma versão implantável do software [2].

Os  repositórios de artefatos  oferecem uma solução para os desenvolvedores
gerenciarem dependências e versões de diferentes bibliotecas [2]. 

3.1.3 Operações

Os diferentes ambientes utilizados nas etapas do pipeline possibilitam a cri-
ação de instâncias do ambiente de execução do software. Os diferentes ambientes
em que o software será executado, são usados em paralelo durante o desenvolvi-
mento, no entanto, devem ser idênticos, de forma que a mesma construção possa
ser implantada em qualquer um deles. Quando se trata do DC, é necessário que a
criação de instâncias dos ambientes seja rápida e de fácil execução, para que a
construção possa passar do desenvolvimento para a produção, sem muitos ob-
stáculos ou problemas originados pelas diferenças nos ambientes [2].

As ferramentas de orquestração automatizam, organizam, coordenam e geren-
ciam a infraestrutura e a criação dos ambientes, fornecendo recursos necessários,
como criação de máquinas virtuais, alocação de capacidade de armazenamento, e
o gerenciamento de recursos de rede [2].

Humble e Farley apresentam anti-padrões comuns relacionados à entrega de
software [48]: 

1. Implantação manual do software;

2. Implantação em produção apenas no fim de todo o desenvolvimento;

3. Configuração manual dos ambientes.

38
O objetivo do DC deve ser a implantação do software da forma mais automáti-
ca possível [2]. 

3.1.4 Testes

As ferramentas de IC com testes de unidade automatizados devem garantir
que as mudanças feitas no desenvolvimento não introduzam novos erros. 

O teste da interface do usuário (UI)  é uma tarefa onde a interface gráfica do
usuário é testada. Algumas áreas de testes de UI, como usabilidade ou teste de ex-
periência do usuário, se aproximam do domínio da garantia de qualidade, pois não
são testes puramente funcionais e podem ser difíceis de automatizar [2].

O teste de aceitação  é um caso especial de teste, onde é determinado se o
sistema de software está em conformidade com os requisitos, funcionais ou não. Do
ponto de vista da IC, os testes de aceitação devem ser executados em um ambi-
ente idêntico ao de produção [48].

Geralmente, os testes de aceitação exigem que o cliente esteja presente em
sua execução, porém isso nem sempre é possível, principalmente se houver uma
entrega frequente do software. Para que estes testes sejam automatizados, a pre-
sença do cliente só é necessária ao se construir a automação do caso de teste [2].

3.1.5 Qualidade

Os testes funcionais não são suficientes para garantir a qualidade do
software. No entanto, não apenas a IC, mas as práticas ágeis em geral, incluem na
definição de alta qualidade de software a forma em que o código foi escrito e a
abrangência de requisitos não funcionais [2]. 

Uma maneira aparente de garantir a qualidade é a criação de métricas. Por ex-
emplo, garantir desempenho sem monitorar a execução do software é muito
difícil. Para isso, ferramentas de teste de carga e estresse podem ser usadas para
garantir que o software funcionará mesmo em circunstâncias ainda mais desfa-
voráveis [2].

Alguns dos parâmetros de qualidade podem ser verificados mesmo que o
software não esteja em execução.  Um exemplo são as ferramentas de análise de
39
código estático, que verifica o padrão de escrita do código, prevendo possíveis
bugs, vulnerabilidades e código suspeito [2]. 

3.1.6 Comunicação e Feedback

Comunicação  e feedback são elementos-chave no desenvolvimento de soft-
ware.  Os desenvolvedores devem compartilhar o conhecimento através de vários
mecanismos, ajudando a equipe a construir uma identidade. Sistemas colaborativos
envolvem também os demais stakeholders, permitindo que eles participem do proje-
to nas etapas de desenvolvimento, criando uma prática de feedback contínuo.  O
pipeline de DC pode até ser útil em um sentido técnico, mas sem os feedbacks dos
stakeholders, a equipe de desenvolvimento perderá o rumo, sem saber em que di-
reção seguir [2].

3.2 Separação e classificação das ferramentas

Ao fim, cento e dez ferramentas foram catalogadas e divididas conforme as
áreas e subáreas descritas. Todos os dados coletados estão no APÊNDICE A.

Os dados estão divididos em onze áreas diferentes, ajudando na criação da
ferramenta de escolha. As áreas são: Nome, Subárea, Website, Artigos, Tipo de pro-
jeto, Mantenedores, Tipo de licença, Integração, Plataforma e Paradigma.

3.2.1 Nome

Indica o nome da ferramenta, Não deve ser confundido com o nome da em-
presa ou grupo que a criou.

3.2.2 Subárea

São as áreas internas de cada área apresentada na figura 4 e já explanadas
na seção 3.1.

40
3.2.3 Website

Informa em qual site estão as informações oficiais da ferramenta. Quando as
ferramentas provêm de projetos open source ou têm acesso grátis, o website tam-
bém é onde o download da ferramenta deve ser realizado. As informações 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 estão descritos no Início deste capítulo.

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 programação

Informa qual a linguagem de programação que a ferramenta suporta. Há fer-
ramentas que não envolvem programação. Estas ferramentas recebem a classifi-
cação “indiferente”. Há ferramentas que se acoplam a qualquer linguagem de pro-
gramação, recebendo portanto, a classificação “qualquer”.

As demais ferramentas, se acoplam a linguagens de programação específicas,
recebendo como classificação o nome dessas linguagens.

3.2.7 Mantenedores

Informa o nome das empresas que mantêm 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 licença

Informa se a ferramenta é paga. A classificação dada para as ferramentas não
pagas é grátis. Se a ferramenta não for grátis ela recebe a classificação paga.

41
3.2.9 Integração

Informa com quais ferramentas esta se integra. O nome da ferramenta é uti-
lizado aqui como classificação. Para as ferramentas que se integram com todas as
outras, é dada a classificação “diversos, quase todos os tipos”. As ferramentas
que as informações de integração eram inexistentes em seus websites, é dada a
classificação “não informado”.

3.2.10 Plataforma

Informa a plataforma que a ferramenta suporta. As plataformas que as ferra-
mentas suportam, são classificadas como: Desktop, Desktop(Mac), Mobile,
Mobile(Android), Mobile(IOS), Web, Microsserviços.

Desktop: são as ferramentas que suportam projetos em que o software criado
será usado apenas no ambiente em que será executado.

Desktop(Mac): são as ferramentas que suportam projetos em que o software
criado será executado apenas no sistema Mac OS.

Mobile: são as ferramentas que suportam projetos em que o software que será
criado executará em dispositivos móveis. Se limita aos dispositivos com os sis-
temas operacionais Android e IOS.

Mobile(Android): são as ferramentas que suportam projetos em que o soft-
ware que será criado executará em dispositivos móveis com o sistema Android.

Mobile(IOS): são as ferramentas que suportam projetos em que o software
que será criado executará em dispositivos móveis com o sistema IOS.

Web: são as ferramentas que suportam projetos em que o software que será
criado executará tecnologias para a web, como sistemas que são acessados por
browsers ou websites.

Microsserviços: são as ferramentas que suportam projetos de software com
arquitetura distribuída que serão acessados através da web.

Quando a ferramenta não envolve programação, ela é classificada como “in-
diferente”. Para as ferramentas que suportam projetos para todas as plataformas, a
classificação é todas.

42
3.2.11 Paradigma

Informa o paradigma de programação 1 que a ferramenta dá suporte. Os para -
digmas de programação que as ferramentas mapeadas dão suporte são: 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 subáreas
relatadas na figura 4. Todas as ferramentas são citadas nos artigos já informados no
início do capítulo.As demais informações sobre ferramentas se encontram no
APÊNDICE A.

3.3.1 Ferramentas catalogadas

Figura 5. Ferramentas de requisitos, desenvolvimento e operações

Fonte: o Autor

1Um estudo sobre paradigmas de programação 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 comunicação

Fonte: o Autor

3.3.2 Grafo de integração de ferramentas

Um dos pontos mais importantes para a classificação das ferramentas é a in-
tegração entre elas. Ferramentas interoperáveis facilitam o trabalho, portanto na fer-
ramenta criada, a quantidade de integrações determina a preferência por uma ou
outra ferramenta. Para exibir a integração entre as ferramentas, um grafo foi criado,
entretanto, a quantidade de nós e arestas do grafo não permitem a criação de uma
imagem legível. Para resolver esse problema, uma ferramenta1 foi criada para exibir
o grafo de forma interativa, permitindo que seja possível visualizar as integrações2.

1Acesse o grafo em: https://projetotcc-urbdvuqhng.now.sh//integracaoferrementas.html
2Coloque o mouse em cima do nó e as ligações serão destacadas. Clique duas vezes no nó e as arestas ficarão transpar-
entes.
44
4. Automatizando a escolha das ferramentas

A automação será feita da forma mais simples possível. Uma ferramenta
baseada na web foi criada para servir como conceito, na criação de ferramentas
que efetivamente automatizem o processo de escolha de ferramentas. A ferramenta
pode ser encontrada no seguinte endereço: 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 usuário insere os dados conforme exibido no capítulo anterior.
O único dado que deve ser fornecido e não foi abordado antes é a escolha do tipo
de lista que o usuário quer visualizar. Com essa opção, o usuário 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 programação interfere na linguagem que o usuário poderá se-
lecionar.

No centro da tela, um botão pode ser selecionado para direcionar o usuário
para a página que contém o grafo de integração de todas as ferramentas.

45
Figura 8. Botão de redirecionamento de página da ferramenta

Fonte: O Autor

As imagens referentes ao grafo e a ferramenta podem ser encontradas no
APÊNDICE B.

Após selecionar todas as opções, 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 rápida, indicando as ferramentas que mais se integram de acordo
com os parâmetros inseridos. Caso seja necessária uma busca mais abrangente, a
opção de todas as ferramentas recomendadas, pode ser selecionada para indicar
todas as ferramentas catalogadas, atendendo aos parâmetros selecionados.

Quando a opção "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 são as mais indicadas para o projeto. A escolha das ferra-
mentas mais indicadas está baseada na quantidade de integrações 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 integrações entre as ferramentas recomendadas

Fonte: O Autor

47
Por fim, para ajudar na visualização das integrações, como possível 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 seção informa a experiência vivenciada no estudo de caso.

4.2.1 Empresa

A Ustore 1, é uma empresa brasileira de software para infraestrutura de com -
putação em nuvem. Nasceu no Porto Digital2 em Recife-PE, mantendo em suas
equipes de desenvolvimento e executivos, profissionais doutores em Ciência da
Computação e Segurança de Sistemas com grande experiência no mercado de
tecnologia da informação e comunicação. As soluções da Ustore tornam a in-
fraestrutura das corporações totalmente programável de forma segura e distribuída,
viabilizando a implementação de um datacenter 100% virtual, ofertando serviços
abrangentes de acordo com a análise 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 monolítica. Consiste em um sistema
que promove a troca de conhecimentos entre professores e alunos, permitindo o
compartilhamento e a exibição de conteúdos 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 Padrão Java para aplicações corporativas (ver: http://www.oracle.com/technetwork/java/javaee/overview/index.html).

5 Abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica

6 https://www.playframework.com/

48
colar. Para fazer o armazenamento dos conteúdos, o sistema utiliza outros produtos
da Ustore.

Atualmente, o projeto MidiaCenter utiliza a prática de IC. As demais etapas são
realizadas manualmente. Pelos motivos já citados neste trabalho, as etapas do de-
senvolvimento devem ser automatizadas máximo possível para que a equipe possa
obter os benefícios fornecidos pela prática do DC. Futuramente o projeto passará
por uma modificação nas práticas 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 não distribuída, portanto a opção “Web Monolítica” foi sele-
cionada. Com a plataforma selecionada, a escolha do paradigma de programação
foi o Orientado a Objetos. Após escolher o paradigma, a escolha da linguagem en-
tão 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 práticas contínuas, as ferramentas grátis escolhidas.

Figura 13. Todas as ferramentas gratuitas catalogadas para o MidiaCenter

Fonte: O Autor

50
5. Considerações finais

Este capítulo conclui o trabalho com uma pequena discussão sobre as limi-
tações na criação deste trabalho. Uma discussão sobre trabalhos futuros também é
iniciada. No final do capítulo uma conclusão é feita.

5.1 Limitações

As limitações deste trabalho estão relacionadas principalmente, a ausência de
informações sobre boas práticas no uso das ferramentas. A falta destas infor-
mações tornam o modelo criado limitado apenas às áreas de aplicação das ferra-
mentas, deixando o resultado das sugestões em alguns casos bastante genérico.
Este trabalho se limita apenas ao estudo de ferramentas, logo, não está no seu es-
copo a discussão de boas práticas no DevOps.

Também pode ser considerada uma limitação, a quantidade de ferramentas
mapeadas. Apesar da quantidade de ferramentas ser adequada para este estudo,
existem muitas ferramentas em uso por equipes que utilizam práticas contínuas e o
DevOps.

Outra limitação identificada é ferramenta criada, que serve apenas como um
modelo conceitual para a construção de uma ferramenta mais elaborada. Devido a
limitações por ser apenas uma página, além do tempo, melhores formas de se es-
colher as ferramentas não foram criadas.

5.2 Trabalhos futuros

Para complementar este trabalho, uma revisão sistemática da literatura é
necessária, buscando verificar o estado da arte de estudos que tratam de melhores
práticas em projetos DevOps, e como essas práticas são realizadas na indústria.

Outro trabalho muito importante que deve ser considerado, é a criação de uma
ferramenta que torne possível, a real automação na escolha destas ferramentas,

51
através das melhores práticas mapeadas no trabalho anterior, possibilitando a es-
colha, instalação e configuração automática das ferramentas.

5.3 Conclusão

Este trabalho fez um panorama do início da ES até o DevOps. Apresentou o
conceito da Ideologia Lean e informou quais os benefícios de inserir essa ideologia
na ES. Também foram informados os conceitos das práticas contínuas e do Dev-
Ops. Com os conceitos aprendidos é possível diferenciar o DevOps do Agile.

O DevOps só pode ser aplicado efetivamente em uma organização, se esta
optar por práticas contínuas, principalmente a integração contínua, a entrega con-
tínua e o deploy contínuo. A entrega e deploy contínuos dependem de um pipeline
automatizado, que por sua vez necessita de ferramentas que concretizem essa au-
tomação. Quando falamos em ferramentas, olhar somente para elas não basta e
isso fica evidente ao se observar a quantidade de ferramentas encontradas. Temos
que entender como elas são aplicadas nas organizações e quais as melhores práti-
cas nesse uso. Por exemplo, Ståhl e Bosch indicam que as práticas contínuas são
realizadas de várias formas diferentes nas organizações, as vezes há diferenças de
como estas práticas são realizadas até entre equipes da mesma empresa, mostran-
do que não existe apenas uma forma de se aplicar a ES contínua [38]. O que existe,
no entanto, é uma quantidade finita destas variações e, portanto, é possível estudá-
las buscando a melhor forma de aplicar todos estes conceitos e ferramentas da
forma mais otimizada possível.

Com base em todas as informações estudadas na pesquisa e na criação deste
trabalho, conclui-se que é possível 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 possível em
todo o pipeline de implantação.

52
Referências Bibliográficas

[1] LEHTONEN, T. et al. Defining metrics for continuous delivery and deployment
pipeline. CEUR Workshop Proceedings. Anais… 2015.

[2] MÄKINEN, 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. 1339–1351, 2016.

[3] PANG, C.; HINDLE, A. Continuous Maintenance. 2016 IEEE International Con-
ference on Software Maintenance and Evolution (ICSME). Anais...IEEE, out.
2016Disponível 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. Disponível 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.
87–100, 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. 317–332, 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. Disponível 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, 2014Disponível 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. Disponível 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. Disponível em: <http://ieeexplore.ieee.org/document/7027481/>. Acesso
em: 7 maio. 2017.

[12] OLSZEWSKA, M.; WALDÉN, M. DevOps meets formal modelling in high-critical-
ity complex systems. Proceedings of the 1st International Workshop on Quality-
Aware DevOps - QUDOS 2015, p. 7–12, 2015.

[13] KILAMO, T.; LEPPÄNEN, M.; MIKKONEN, T. The social developer: now, then,
and tomorrow. Proceedings of the 7th International Workshop on Social Soft-
ware Engineering - SSE 2015, p. 41–48, 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. Disponível 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. Disponív-
el em: <http://ieeexplore.ieee.org/document/7578902/>. Acesso em: 7 maio. 2017.

[16] SOMMERVILLE, I. Engenharia de Software, 9a Edição. Pearson Ed ed. São
Paulo: Pearson Education, 2011.

[17] SOARES, M. D. S. Comparação 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. 1–9, 1970.

[19] The Chaos Report. . Dennis, MA 02638, USA. 1995. Disponível em: <https://
www.standishgroup.com/sample_research_files/chaos_report_1994.pdf>.

54
[20] BERNARDO, K. Manifesto ágil, como tudo começou. Disponível 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. Disponível 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. 176–189, 2017.

[25] LEPPANEN, M. et al. The highways and country roads to continuous de-
ploymentIEEE Software, mar. 2015. Disponível 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. 1–1, 2017.

[27] IEEE Xplore Digital Library. Disponível 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. Disponível em: <http://www.sciencedirect.com/>. Acesso em: 27 jun.
2017.

[29] ASSOCIATION FOR COMPUTING MACHINERY. ACM Digital Library.
Disponível em: <http://dl.acm.org/>. Acesso em: 27 jun. 2017.

[30] Scopus. Disponível em: <https://www.scopus.com/home.uri?zone=header&ori-
gin=searchbasic>. Acesso em: 27 jun. 2017.

[31] Google Acadêmico. Disponível 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. Disponível 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 produção  : além da produção em larga es-
cala. [s.l.] Bookman, 1997.

[38] STÅHL, D.; BOSCH, J. Experienced Benefits of Continuous Integration in
Industry Software Product Development: A Case Study. 2013. Disponível em:
<http://www.actapress.com/PaperInfo.aspx?paperId=455452>

[39] STÅHL, D.; BOSCH, J. Modeling continuous integration practice differences in
industry software development. Journal of Systems and Software, v. 87, n. 1, p.
48–59, 2014.

[40] DIMECC N4S-Program: Finnish Software Companies Speeding Digital
Economy - Digile N4S. Disponível 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. Disponível em: <https://standards.ieee.org/findstds/standard/
730-1980.html>. Acesso em: 5 jul. 2017.

[42] International Organization for Standardization. Disponível 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). Disponível em: <https://www.iso.org/
standard/33897.html>. Acesso em: 5 jul. 2017.

[44] O que significa distribuição contínua? – Amazon Web Services. Disponível
em: <https://aws.amazon.com/pt/devops/continuous-delivery/>. Acesso em: 5 jul.
2017.

[45] What Is Agile? Disponível 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 Eletrônica de Sistemas de Informação, v.
3, n. 1, p. 1–8, 2004.

56
[47] Scrum: metodologia ágil para gestão e planejamento de projetos. Disponív-
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.
14–16, 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. Disponível em: <http://www.sco-
pus.com/inward/record.url?eid=2-s2.0-84905986447&partnerID=tZOtx3y1>

57
Apêndice A - Tabela de ferramentas

Esta tabela é uma adaptação da tabela de ferramentas encontrada em [2].

Linguagem
Tipo de Mantenedo Tipo de
Nome Área Website Arigos de Integração Plataforma
projeto res licença
programação

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/
versão, públicos
Revisão de
código,
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. Não
Google Docs nto de [2] Privado Indiferente Google Gratis indiferente
com/docs/ informado
backlog about/

https://
Geranciame products.offi Não
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 Não
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 Microserviço
org/ os tipos. s

Rastreament https://
o de bugs, Open Comunidad Eclipse,
Bugzilla www.bugzilla [2] Qualquer Gratis Todos
Revisão de Source e SVN, Git.
.org/
código

Controle de Diversos,
https://git- [2, 3, 5, 7, 8, Open Comunidad
Git versão, Qualquer Gratis quase todos Todos
scm.com/ 26, 49, 50] Source e
Implantação os tipos.

https:// Diversos,
Controle de Open Comunidad
Subversion subversion.a [2, 26, 50] Qualquer Gratis quase todos Todos
versão Source e
pache.org/ os tipos.

58
Linguagem
Tipo de Mantenedo Tipo de
Nome Área Website Arigos de Integração Plataforma
projeto res licença
programação

Rastreament
o de bugs, https:// Jira,
Controle de
Bitbucket bitbucket.org [26] Privado Qualquer Atlassian Gratis Bamboo, Todos
versão, / Hipchat
Comunicaçã
o e feedback
Controle de https://
versão,
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
versão 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
versão Eclipse.
e.com/
Construção,
Integração
Contínua, [2, 3, 5, 8, Diversos,
Repositório https:// Open Comunidad
Jenkins 26, 39, 49, Qualquer Gratis quase todos Todos
de artefatos, jenkins.io/ Source e
50] os tipos.
Implantação,
Qualidade e
performance
Construção, https:// Diversos,
Open Comunidad
Maven Repositório maven.apac [2, 26] Qualquer Gratis quase todos Todos
Source e
de artefatos he.org/ os tipos.
Desktop,
http:// Diversos,
Open Comunidad Web,
Nant Construção nant.sourcef [26] .Net Gratis quase todos
Source e Microserviço
orge.net/ os tipos. s
https:// Desktop,
Diversos,
github.com/ Open Comunidad Web,
MSBuild Construção [26] .Net Gratis quase todos
Microsoft/ Source e Microserviço
os tipos.
msbuild s
Desktop,
http:// Diversos,
Open Comunidad Web,
Ant Construção ant.apache.o [2, 3, 8, 26] Java Gratis quase todos
Source e Microserviço
rg/ os tipos. s
Diversos,
https:// Open Comunidad
CMake Construção [2] C, C++ Gratis quase todos Desktop
cmake.org/ Source e os tipos.
https:// Diversos,
www.gnu.org Open Comunidad
Make Construção [2, 26] C, C++ Gratis quase todos Desktop
/software/ Source e os tipos.
make/
Diversos,
https:// Open C, C++, Comunidad Desktop,
GCC Construção [2] Gratis quase todos
gcc.gnu.org/ Source Objective C e Mobile(IOS)
os tipos.
Construção, 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
Construção 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 Construção www.scala- [2] Gratis quase todos
Source Play e Microserviço
sbt.org/ os tipos. s
Diversos,
http:// Open Comunidad
Grunt Construção [2] Javascript Gratis quase todos Web
gruntjs.com/ Source e os tipos.
https:// Diversos,
Integração www.jetbrain
TeamCity [2, 26, 49] Privado Qualquer Jetbrains Paga quase todos Todos
Contínua s.com/ os tipos.
teamcity/
https:// Diversos,
Integração br.atlassian.c
Bamboo [26, 49] Privado Qualquer Atlassian Paga quase todos Todos
Contínua om/software/ os tipos.
bamboo
http://
CruiseContr Integração cruisecontrol Open Comunidad Não
[26] Qualquer Gratis Todos
ol Contínua .sourceforge. Source e informado
net/
https://
Integração Open Comunidad Não
Hudson eclipse.org/ [26] Qualquer Gratis Todos
Contínua Source e informado
hudson/
Integração http:// Open Comunidad Não
Buildbot [2] Qualquer Gratis Todos
Contínua buildbot.net/ Source e informado
Controle de
https:// versão,
Repositório
Artifactory www.jfrog.co [2] Privado Qualquer Jfrog Paga Integração Todos
de artefatos m/artifactory/ contínua,
Construção
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
Tipo de Mantenedo Tipo de
Nome Área Website Arigos de Integração Plataforma
projeto res licença
programação

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. Microserviço
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. Microserviço
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, Microserviço
o, Virtualbox, s
implantação 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. Microserviço
Implantação 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 Microserviço
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, Microserviço
Slack, s
vSphere,
Github,
http:// Open Comunidad Slack,
Capistrano Implantação capistranorb. [2] Indiferente Gratis Todos
Source e Hipchat
com/
https://
www.hockey
HockeyApp Implantação [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 Microserviço
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 Microserviço
os tipos.
aceitação s
Desktop,
Diversos,
Teste de http:// Open Comunidad Web,
Mockito [2] Java Gratis quase todos
Unidade mockito.org/ Source e Microserviço
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.
usuário
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 Microserviço
/ os tipos. s
Desktop,
https:// Diversos,
Teste de Open Comunidad Web,
Midje github.com/ [2] Clojure Gratis quase todos
Unidade Source e Microserviço
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 Microserviço
os tipos.
specs2/ s
Desktop,
http:// Diversos,
Teste de Open Comunidad Web,
Scalatest www.scalate [2] Scala Gratis quase todos
Unidade Source e Microserviço
st.org/ os tipos. s

60
Linguagem
Tipo de Mantenedo Tipo de
Nome Área Website Arigos de Integração Plataforma
projeto res licença
programação

Desktop,
Diversos,
Teste de http:// Open Comunidad Web,
Rspec [2] Ruby Gratis quase todos
Unidade rspec.info/ Source e Microserviço
os tipos. s
https:// Desktop,
Diversos,
Teste de github.com/ Open Comunidad Web,
Minitest [2] Ruby Gratis quase todos
Unidade seattlerb/ Source e Microserviço
os tipos.
minitest s
Teste de
interface do
usuário, http:// Diversos,
Open Comunidad
Selenium Teste de www.seleniu [2] Indiferente Gratis quase todos Web
Source e
aceitação, mhq.org/ os tipos.
Qualidade e
performance
Teste de
interface do
usuário, http://
Robot Open Comunidad
Teste de robotframew [2] Indiferente Gratis Jenkins Web
Framework Source e
aceitação, 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
usuário os tipos.
.io/
Teste de http:// Diversos,
Open Comunidad
PhantomJS Interface do phantomjs.or [2] Javascript Gratis quase todos Web
Source e
usuário g/ os tipos.
Teste de https://
BrowserStac BrowserSta Não
Interface do www.browse [2] Privado Indiferente Paga Web
k ck informado
usuário rstack.com/
https:// Cucumber,
Teste de github.com/ Open Comunidad Rspec,
Capybara Interface do [2] Qualquer Gratis Web
teamcapybar Source e Minitest,
usuário a/capybara Selenium
Teste de .Net, Java, Desktop,
interface do Ruby, Groovy, Diversos,
https:// Open Comunidad Web,
Cucumber usuário, [2] Javascript, Gratis quase todos
cucumber.io/ Source e Microserviço
Teste de Clojure, Gosu, os tipos. s
aceitação PHP, Python
Diversos,
Teste de http:// Open Comunidad
Chai [2] Javascript Gratis quase todos Web
aceitação chaijs.com/ Source e os tipos.
Desktop,
Diversos,
Teste de http:// Open Comunidad Web,
TestNG [2] Java Gratis quase todos
aceitação testng.org/ Source e Microserviço
os tipos. s
TFS,
https:// Cruisecontro
Teste de www.froglogi l, Jenkins,
aceitação,
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
, Revisão de ube.org/ os tipos.
código
Revisão de http:// Open Comunidad
JsHint [2] Javascript Gratis Eclipse Web
código jshint.com/ Source e
Qualidade e TFS, Desktop,
http:// ZEN
performance Cruisecontro Web,
Ndepend www.ndepen [26] Privado .Net PROGRAM Paga
, Revisão de l, Sonar, Microserviço
d.com/ LTD
código Jenkins, s
http:// Diversos,
Revisão de Open Comunidad
JsLint www.jslint.co [2] Javascript Gratis quase todos Web
código Source e
m/ os tipos.

Qualidade e http:// Open Comunidad
Valgrind [2] Indiferente Gratis Indiferente Todos
performance valgrind.org/ Source e
Desktop,
http://
Revisão de Open Comunidad Eclipse, Web,
FindBugs findbugs.sou [3, 8] Java Gratis
código Source e Maven Microserviço
rceforge.net/ s
Desktop,
http://
Qualidade e Open Comunidad Eclipse, Web,
EMMA emma.sourc [3] Java Gratis
performance Source e Maven Microserviço
eforge.net/ s
Bitbucket, Desktop,
http:// Eclipse, Android,
Revisão de checkstyle.s Open Comunidad
Checkstyle [3, 8] Java Gratis Gradle, Web,
código ourceforge.n Source e Jenkins, Microserviço
et/ Sonar, Sbt s
http://
Revisão de www.gimpel. Gimpel
Flexelint [26] Privado C, C++ Paga Eclipse Desktop
código 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 Não
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
Tipo de Mantenedo Tipo de
Nome Área Website Arigos de Integração Plataforma
projeto res licença
programação

https:// Web,
Qualidade e Java, Ruby, Não
New Relic newrelic.com [2, 5] Privado KingHost Paga Microserviço
performance Python, Node informado
/ s
http:// Web,
Qualidade e Open Comunidad Não
JMeter jmeter.apach [2] Java Gratis Microserviço
performance Source e informado
e.org/ s
http:// Web,
Qualidade e Open Comunidad Não
Zabbix www.zabbix. [2, 5] Qualquer Gratis Microserviço
performance Source e informado
com/ s
https:// Web,
Qualidade e Royal
Pingdom www.pingdo [2, 5] Privado Qualquer Paga Slack Microserviço
performance Pingdom
m.com/ s
Web,
Qualidade e http:// Não
Gatling [2] Privado Qualquer Gatling Paga Microserviço
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 Microserviço
performance 2.2/ Source e apache s
programs/
ab.html
https://
Revisão de www.gerritco Open Comunidad
Gerrit [2] Qualquer Gratis Git Todos
código dereview.co Source e
m/
https:// SVN, Git,
www.atlassia
Revisão de Mercurial,
Crucible n.com/ [2] Privado Qualquer Atlassian Paga Todos
código Perforce,
software/ Bitbucket
crucible
https:// Jira,
www.atlassia
Revisão de Bamboo,
FishEye n.com/ [2] Privado Qualquer Atlassian Paga Todos
código Hipchat,
software/ Bitbucket
fisheye
Comunicaçã https:// Não
Skype oe www.skype.c [2] Privado Indiferente Microsoft Gratis Indiferente
informado
Feedback om/
Comunicaçã https:// Não
Slack oe [2] Privado Indiferente Slack Gratis Indiferente
slack.com/ informado
Feedback
Comunicaçã https:// CA Não
Flowdock oe www.flowdoc [2] Privado Indiferente Paga Indiferente
Tecnologies informado
Feedback k.com/
Comunicaçã https:// Não
Webex oe www.webex. [2] Privado Indiferente Cisco Paga Indiferente
informado
Feedback com/
Comunicaçã https:// Open Comunidad Não
XMPP oe [2] Indiferente Gratis Indiferente
xmpp.org/ Source e informado
Feedback
Comunicaçã https:// Não
Hipchat oe [2] Privado Indiferente Atlassian Gratis Indiferente
hipchat.com/ informado
Feedback
https://
Comunicaçã products.offi Não
Lync oe ce.com/en- [2] Privado Indiferente Microsoft Paga Indiferente
informado
Feedback us/skype-for-
business/
https://
Comunicaçã products.offi Não
SharePoint oe ce.com/en- [2] Privado Indiferente Microsoft Paga Indiferente
informado
Feedback us/
sharepoint/
https://
Comunicaçã products.offi Não
Outlook oe [2] Privado Indiferente Microsoft Gratis Indiferente
ce.com/en- informado
Feedback us/outlook/
Comunicaçã https://
Google Não
oe analytics.goo [2] Privado Indiferente Google Gratis Indiferente
Analytics informado
Feedback gle.com/
Comunicaçã https:// Não
Pagerduty oe www.pagerd [5] Privado Indiferente Pagerduty Paga Indiferente
informado
Feedback uty.com/
Comunicaçã https:// Não
Flurry oe developer.ya [2] Privado Indiferente Yahoo Paga Indiferente
informado
Feedback hoo.com/
Comunicaçã https:// Não
Intercom oe www.interco [2] Privado Indiferente Intecom Paga Indiferente
informado
Feedback m.io/
http://
Comunicaçã www.adobe. Não
Sitecatalyst oe com/uk/ [2] Privado Indiferente Adobe Paga Indiferente
informado
Feedback marketing-
cloud.html
Comunicaçã http:// Não
Qlikview oe www.qlik.co [2] Privado Indiferente Qilk Paga Indiferente
informado
Feedback m/
Comunicaçã https:// Não
Optimizely oe www.optimiz [2] Privado Indiferente Optimizely Paga Indiferente
informado
Feedback ely.com/

62
Linguagem
Tipo de Mantenedo Tipo de
Nome Área Website Arigos de Integração Plataforma
projeto res licença
programação

Comunicaçã https:// Não
Facebook oe www.facebo [2] Privado Indiferente Facebook Gratis Indiferente
informado
Feedback ok.com/
Comunicaçã https:// Não
Twitter oe [2] Privado Indiferente Twitter Gratis Indiferente
twitter.com/ informado
Feedback

63
Apêndice B - Imagens da ferramenta

Seletor de escolha de plataforma da ferramenta

Opções de plataformas na ferramenta

Seletor de escolha de paradigma da ferramenta

Opções de escolha de paradigma na ferramenta

64
Seletor de escolha de licença da ferramenta

Opções de escolha de licença na ferramenta

Opções de escolha de linguagem na ferramenta

Grafo de integração das ferramentas selecionadas

65
Resultado de ferramentas selecionadas

66
Grafo de integração de todas as ferramentas

67