UNIVERSIDADE FEDERAL DE PERNAMBUCO

Graduação em Sistemas de Informação

Centro de Informática
Bacharelado em Sistemas de Informação

Júlio Alexandre Pedrosa de Melo

Uma proposta de Arquitetura de Referência para DevOps

Trabalho de Graduação

Recife, de Julho de 2019

 Júlio Alexandre Pedrosa de Melo

Uma proposta de Arquitetura de Referência para DevOps

Trabalho de Conclusão de Curso

Trabalho de Graduação apresentado à

banca examinadora composta pelos
professores Vinícius Cardoso Garcia e
Henrique Rebêlo como requisito parcial para
obtenção do grau de Bacharel em Sistemas
de Informação no Centro de Informática da
Universidade Federal de Pernambuco.

Orientador: Vinícius Cardoso Garcia

Co-orientador: José Fernando Carvalho

Recife, de Julho de 2019

1
 Júlio Alexandre Pedrosa de Melo

Uma proposta de Arquitetura de Referência para DevOps

Trabalho de Conclusão de Curso

Trabalho de Graduação apresentado à

banca examinadora composta pelos
professores Vinícius Cardoso Garcia e
Henrique Rebêlo como requisito parcial para
obtenção do grau de Bacharel em Sistemas
de Informação no Centro de Informática da
Universidade Federal de Pernambuco.

Orientador: Vinicius Cardoso Garcia

Co-orientador: José Fernando Carvalho

Aprovado em _____ de _________________________ de __________ .

BANCA EXAMINADORA

Vinicius Cardoso Garcia

___________________________________________________________________

Henrique Rebêlo

___________________________________________________________________

Recife, de Julho de 2019

2
 Agradecimentos

Primeiramente, gostaria de agradecer a Deus por ter me guiado durante todo

esse percurso. Ele é quem me dá confiança quando não tenho e que me guarda de
tudo. Gostaria de agradecer a minha avó Maria José por todos os anos me
educando, cuidando de mim e por ser um inspiração para mim. A minha mãe Márcia
Pedrosa por ter sido uma mãe que nunca me deixou sentir a ausência do meu pai,
por ser incrível e mesmo trabalhando muito nunca deixou de ser presente, sempre
me ensinando que o conhecimento é a única coisa que ninguém pode nos tirar. Ao
meu padrasto Limberguer Macêdo por sempre cuidar de mim e todas as vezes que
foi me buscar, preocupado, tarde da noite na universidade.
Em especial, agradeço a minha noiva Julianne Mallena por ter mudado a
minha vida e por ter me ajuda a me tornar o homem que sou hoje. Sempre me
confortando quando me encontrava preocupado, mas sempre me repreendendo
quando estava errado. Por apoiar sempre minhas idéias malucas, nos meus sonhos
e a cada vitória conquistada estava sempre ao meu lado.
Ao meu amigo Wanderson Filho, que nos primeiros períodos sempre voltando
naquele Barro/Macaxeira lotado, mas sempre com otimismo de que as coisas iriam
melhorar. Sempre esteve ao meu lado quando precisei, orientando-me e vencendo
comigo nesta trajetória acadêmica.
Ao meu amigo e padrinho de casamento Rodrigo Costa, por ter me orientado
e consolado em um dos momentos mais difíceis da minha vida, por me orientar
teologicamente e por ter sido um dos responsáveis pelo meu primeiro emprego
Queria agradecer ao meu orientador Vinicius Garcia por ter me dado uma
nova chance e liberdade de desenvolver esta pesquisa da forma que mais me sentia
confortável, mas sempre lapidando onde precisava ser melhorado.
Ao meu co-orientador José “Fish” Fernando por ter me ajudado a identificar
que tudo o que eu estava vivendo profissionalmente poderia ser usado no meu TG,

3
por ser um mentor que me ajudou a ser o profissional que sou hoje e pelos
conselhos cristãos.

Bem-aventurado o homem que acha

sabedoria, e o homem que adquire
conhecimento;
Porque é melhor a sua mercadoria do que
artigos de prata, e maior o seu lucro que
o ouro mais fino.

Provérbios 3:13,14

4
Resumo

Desde o surgimento do manifesto ágil [1] o modo como o homem desenvolve

software mudou, trazendo metodologias, ferramentas e práticas que tem o ajudado
a entregarem código, de qualidade e cada vez mais rápido. Sendo que um problema
em particular ainda continuava, existia um "muro" entre as áreas de desenvolvimento
e operações [2]. Um buscando entregar código (desenvolvimento) o outro
(operações), implantação; tarefas coexistentes mas enxergadas pelos dois times
como coisas distintas e a agilidade não se limita mais ao desenvolvimento, mas a
infra também.

Como proposta de solução para esse problema surgiu o DevOps em meados de

2008 [3]. Os conceitos de DevOps são mais enfatizados na comunicação,
colaboração e integração entre todas as equipes [4]. Todo este processo preenche a
lacuna entre as equipes de desenvolvimento, operação e garante a qualidade que
contribuem para uma plataforma, acelera o processo de desenvolvimento e entrega
de software com a ajuda de ferramentas de ponta e processos automatomatizados.
Surgindo como uma abordagem eficaz para software desenvolvimento. Permite
automação, integração, monitoramento e colaboração [11, 12 e 13]. O DevOps
fornece aos desenvolvedores uma ampla variedade de ferramentas úteis para
automatizar o ciclo de desenvolvimento de software (Sincronizar, construir, testar,
implantar, implantar) [12].

Quando se decide implantar ferramentas DevOps no ciclo de vida do projeto não se

sabe qual padrão/modelo arquitetural seguir. RA (Arquitetura de Referência) visa
facilitar a compreensão dos requisitos, usos, características e padrões [10]. A não
adoção de um modelo pode acabar gerando uma utilização ineficiente de
ferramentas.

5
Palavras-chaves: DevOps, Arquitetura de Referência, Engenharia de Software,
Metodologias Ágeis, Integração Contínua, Entrega Contínua e Implantação
Contínua.

6
Abstract

Since the emergence of the Agile Manifesto [1], man's way of developing software
has changed, bringing methodologies, tools, and practices that have helped him
deliver code, quality, and ever faster. As a particular problem still persisted, there
was a "wall" between development and operations [2]. One seeking to deliver code
(development) the other (operations), deployment; tasks coexisting but seen by the
two teams as distinct things and agility is not limited to development, but the infra as
well.

As a proposed solution to this problem came the DevOps in mid 2008 [3]. DevOps
concepts are more emphasized in communication, collaboration and integration
among all teams [4]. This whole process fills the gap between the development,
operation and quality assurance teams that contribute to a platform, accelerates the
software development and delivery process with the help of cutting-edge tools and
automated processes. Emerging as an effective approach to software development.
Allows automation, integration, monitoring and collaboration [11, 12 and 13]. DevOps
provides developers with a wide variety of useful tools to automate the software
development cycle (Synchronize, Build, Test, Deploy, Deploy) [12].

When it is decided to deploy DevOps tools in the project lifecycle it is not known
which standard / architectural model to follow. AR (Architecture Reference) aims to
facilitate the understanding of requirements, uses, characteristics and standards [10].
Failure to adopt a model may lead to inefficient use of tools.

Keywords: DevOps, Reference Architecture, Software Engineer, Agile

Methodologies, Continuous Integration, Continuous Delivery and Continuous
Deployment.

7
 Lista de Figuras

Figura 1. Casa do Sistema Toyota de Produção

Figura 2. Ciclo de desenvolvimento Lean
Figura 3: Continuous Integration
Figura 4. Pipeline Devops
Figura 5. Modelo Físico de Grande Instituição Financeira no Brasil
Figura 6. Modelo Físico de Grande Empresa de Telecomunicação no Brasil
Figura 7. Modelo Conceitual de DevOps
Figura 8. Modelo Conceitual de Plataforma
Figura 9. Visão Integrada do Modelo Conceitual
Figura 10. Modelo Lógico
Figura 11. Modelo Físico
Figura 12. Criação de key-pair, part. I
Figura 13. Criação de key-pair, part. II
Figura 14. Criação de key-pair, part. III
Figura 15. Criação de key-pair, part. IV
Figura 16. Criação de key-pair, part. V
Figura 17. Criação de secret key e access key, part. I
Figura 18. Criação de secret key e access key, part. II
Figura 19. Criação de secret key e access key, part. III
Figura 20. Criação de variáveis terraform
Figura 21. Criação do script Terraform da VPC
Figura 22. Criação do script Terraform do Provider AWS
Figura 23. Criação do script Terraform do Route
Figura 24. Criação do script Terraform de output.
Figura 25. Criação de script principal.
Figura 26. Editando ansible hosts
Figura 27. Verificando conexão com hosts

8
Figura 28. Estrutura de diretórios Ansible
Figura 29. Criação de script Jenkins
Figura 30. Criação de script Phabricator e MariaDB
Figura 31. Criação de script Nexus
Figura 32. Criação de script Spring PetClinic
Figura 33. Criação de script Prometheus e Grafana


9
 Lista de Tabelas

Tabela I - Tabela com modelos e suas respectivas atividades e ferramentas

comumente usadas.
Tabela II - Tabela referente a atores, atividades e ferramentas que podem ser
usadas de um Modelo Físico.

10
 Lista de Abreviaturas e Siglas

IaC - ​Infrastructure as Code

TPS - ​Toyota Production System
MIT - ​Massachusetts Institute of Technology
EUA - Estados Unidos das Américas
CI/CD - ​Continuous Integration & Continuous Delivery
CD - ​Continuous Delivery/Deployment
RA - ​Reference Architecture
ARD - Arquitetura de Referência DevOps
AWS - ​Amazon Web Services
EC2 - ​Elastic Compute Cloud
IAM - ​Identity and Access Management
VPC - Virtual Private Cloud

11
Sumário

1. Introdução 14
1.1 Contexto 14
1.2 Motivação 15
1.3 Objetivos Gerais e Específicos 16
1.4 Estrutura do Documento 16

2. Fundamentação Teórica 18
2.1 Sistema Toyota de Produção 18
2.2 Movimento Lean 19
2.3 Manifesto Ágil 20
2.4 Integração Contínua 22
2.5 Entrega Contínua 23
2.6 Implantação Contínua 24
2.7 Infraestrutura ágil e Movimento Velocity 24
2.8 DevOps 25
2.9 RA 26

3. Metodologia 27
3.1 Etapas da Pesquisa 27
3.2 Considerações Finais 28

4. Proposta de Arquitetura de Referência para DevOps 29

4.1 Projetos Mapeados 29
4.1.1 Grande Instituição Financeira no Brasil 29
4.1.2 Grande Empresa de Telecomunicação no Brasil 30
4.2 Modelos de Arquitetura de Referência DevOps 31
4.2.1 Modelo Conceitual 31
4.2.2 Modelo Lógico 34

12
 4.2.3 Modelo Físico 37
4.3 Proposta 39
4.3.1 Configuração de ferramentas do Pipeline 39
4.3.2 Pipeline de Desenvolvimento 39
4.4 Experimentação 40
4.4.1 Pré-requisitos 40
4.4.2 Configurando acesso às Instâncias 40
4.4.3 Criando scripts para IaC 41
4.5 Hipóteses de Pesquisa 42

5. Conclusões 44
5.1 Contribuições 44
5.2 Limitações e Trabalhos Futuros 45

Referências 46

Apêndice A 51

13
1.​ ​Introdução

Este capítulo apresentará o contexto e a motivação para a realização deste

trabalho, bem como os objetivos, geral e específicos, a serem atingidos a fim de
auxiliar um bom entendimento ao leitor.

1.1​ ​Contexto

No século XX ​Toyota Production System (TPS) trouxe metodologias e

conceito utilizados até hoje por equipes de desenvolvimentos de software. Esse
sistema de produção desenvolvido pela Toyota Motor Corporation visa fornecer a
melhor qualidade, o menor custo e o lead time mais curto por meio da eliminação do
desperdício. O TPS é formado sobre dois pilares, Just-in-Time e Jidoka, e é
normalmente ilustrado pela "casa". O TPS é mantido e melhorado por interações
entre trabalho padronizado e kaizen, seguidos de PDCA ou método científico [30].

Como uma evolução do modelo toyota de produção a produção enxuta ou

lean não apenas desafiou com sucesso as práticas de produção em massa aceitas
na indústria automotiva, alterando significativamente o trade-off entre produtividade
e qualidade, mas também levou a repensar uma ampla gama de operações de
manufatura e serviços além da produção repetitiva de alto volume.

A partir manifesto ágil [1] o modo como a humanidade passou a desenvolver

software mudou, trazendo metodologias, ferramentas e práticas que tem o ajudado
a entregarem código, de qualidade e cada vez mais rápido. Sendo que um problema
em particular ainda continuava, existia um "muro" entre as áreas de desenvolvimento
e operações [2]. A maioria desses problemas é causada pela falta de trabalho
colaborativo entre a equipe de desenvolvimento e a equipe de operações (também
conhecidos como SysAdmins), já que ambas as equipes têm diferentes concepções

14
de suas responsabilidades, enquanto a equipe de desenvolvimento se concentra na
criação de novos produtos e aplicativos, adicionando recursos ou correções de bugs,
a equipe de operações continua responsável por manter os produtos disponíveis e
implantar atualizações no ambiente de produção [29], a equipe de desenvolvimento
fundamentalmente procura introduzir as características e as mudanças da melhor
maneira possível, enquanto a equipe de operações busca a estabilidade do sistema
[4], essa falta de colaboração entre as duas equipes acaba por aumentar o risco de
códigos defeituosos no sistema

Como proposta de solução para esse problema surgiu o DevOps em meados

de 2008 [3]. Os conceitos de DevOps são mais enfatizados na comunicação,
colaboração e integração entre todas as equipes [4]. Todo este processo preenche a
lacuna entre as equipes de desenvolvimento, operação e garante a qualidade que
contribuem para uma plataforma, acelera o processo de desenvolvimento e entrega
de software com a ajuda de ferramentas de ponta e processos automatomatizados.
Surgindo como uma abordagem eficaz para software desenvolvimento. Permite
automação, integração, monitoramento e colaboração [11, 12 e 13]. O DevOps
fornece aos desenvolvedores uma ampla variedade de ferramentas úteis para
automatizar o ciclo de desenvolvimento de software (Sincronizar, construir, testar,
implantar, implantar) [12].

Quando se decide implantar ferramentas DevOps no ciclo de vida do projeto

não se sabe qual padrão/modelo arquitetural a seguir. RA (Reference Architecture)
visa facilitar a compreensão dos requisitos, usos, características e padrões [10].

1.2 Motivação

Quando um projeto ou uma empresa decide adotar o paradigma DevOps

mapea-se as áreas de acordo com os pilares DevOps: pessoas, processos, cultura e
ferramentas. As ferramentas são uma parte importante da abordagem DevOps. Elas

15
estão intimamente relacionados com diferentes práticas, como automação,
monitoramento e configuração [23], os problemas ligados à implementação
tecnológica do DevOps [24, 25] são um dos que mais causam desperdícios.
Existem um conjunto de ferramentas que compõem uma infraestrutura.

1.3 Objetivos Gerais e Específicos

Este trabalho de conclusão de curso tem como intuito identificar

empiricamente, em projetos corporativos, padrões em infraestrutura do pipeline
DevOps (Continuous Integration, Continuous Deployment e Continuous Delivery) e
propor uma RAM. Tendo como objetivos específicos:

● Apresentar conceitos encontrados na literatura que discorrem sobre DevOps

e RAM ;
● Realizar um estudo de caso em times DevOps no intuito de identificar um
padrão na infraestrutura;
● Identificar papéis de cada ferramenta utilizada na infraestrutura no pipeline
DevOps;
● Modelar uma arquitetura de referências DevOps.

1.4 Estrutura do Documento

Este trabalho é composto por 6 capítulos, incluindo este capítulo de

introdução. O capítulo 2 é voltado à revisão bibliográfica que concerne este trabalho,
no qual traz os principais conceitos de DevOps, Arquitetura de Referência, CI/CD,
tudo o que tange o entendimento do DevOps e RA.
O capítulo 3 contempla toda a metodologia adotada nesta pesquisa, com a
classificação da pesquisa, os projetos utilizados para colher insumos para este
trabalho, uma seção voltada às etapas da pesquisa e, por fim, as considerações
finais com relação à metodologia adotada.

16
 O capítulo 4 traz a proposta desta pesquisa, que é pra trazer uma proposta de
Arquitetura de referência para DevOps.
Por fim, o capítulo 5 abrange a conclusão deste trabalho como também suas
contribuições para o mercado e a academia, evidencia as limitações encontradas e
propõe sugestões de trabalhos futuros voltados ao assunto abordado.

17
2. ​Fundamentação Teórica

2.1 Sistema Toyota de Produção

O desenvolvimento do TPS é creditado a Taiichi Ohno, chefe de produção da

Toyota no período posterior à Segunda Guerra Mundial. Começando nas operações
de usinagem, Ohno liderou o desenvolvimento do TPS ao longo das décadas de
1950 e 1960, e sua disseminação à cadeia de fornecedores nas décadas de 1960 e
1970 [30].

Fora do Japão, a disseminação começou com a criação da joint venture

Toyota - General Motors (NUMMI), em 1984, na Califórnia. Os conceitos de
Just-in-Time (JIT) e Jidoka têm raízes no período pré-guerra. Sakichi Toyoda,
fundador do grupo Toyota, inventou o conceito de Jidoka no início do século XX,
incorporando um dispositivo de parada automática em seus teares, que interrompia
o funcionamento de uma máquina caso um fio se partisse. Isso deu espaço a
grandes melhorias na qualidade e liberou os funcionários para a realização de um
trabalho que agregasse mais valor do que o simples monitoramento dos
equipamentos. Por fim, esse conceito simples encontrou espaço em todas as
máquinas, em todas as linhas de produção e em todas as operações da Toyota [31].
O reconhecimento do TPS como um sistema modelo de produção se difundiu
rapidamente com a publicação do livro "A Máquina que Mudou o Mundo", em 1990,
resultado de cinco anos de pesquisa liderada pelo Massachusetts Institute of
Technology (MIT). Os pesquisadores do MIT descobriram que o TPS era muito mais
eficaz e eficiente do que o tradicional sistema de produção em massa, tanto que
representava um paradigma completamente novo e foi cunhado, então, o termo
produção lean (ou produção enxuta), indicando essa abordagem radicalmente
diferente da produção [30].

18
 ​ ​Figura 1. Casa do Sistema Toyota de Produção [30]

2.1 Movimento Lean

Nos anos 80, uma enorme mudança de paradigma atingiu as fábricas em

todos os EUA e na Europa. A produção em massa e as técnicas de gestão científica
do início do século XX foram questionadas quando as empresas manufatureiras
japonesas demonstraram que Just-in-Time era um paradigma melhor. Os conceitos
japoneses de manufatura amplamente adotados passaram a ser conhecidos como
"produção enxuta". Com o tempo, as abstrações por trás da produção enxuta se
espalharam para a logística, e daí para as forças armadas, para a construção e para
a indústria de serviços. Como se constata, os princípios do pensamento enxuto são
universais e foram aplicados com sucesso em muitas disciplinas. Princípios Lean
provaram não apenas ser universais, mas também serem universalmente bem

19
sucedidos na melhoria dos resultados. Quando apropriadamente aplicado, o
pensamento enxuto é uma plataforma bem testada e bem testada sobre a qual se
podem construir práticas ágeis de desenvolvimento de software [32].

Técnicas como Mapeamento do Fluxo de Valor, Placas Kanban e

Manutenção Produtiva Total foram codificadas para o Sistema Toyota de Produção
nos anos 80. Em 1997, o Lean Enterprise Institute começou a pesquisar aplicações
do Lean para outros fluxos de valor, como a indústria de serviços e a saúde [3].

Os princípios lean se concentram em como especificar valor para cada produto,

identificar Cadeia de Valor para cada produto, fazer o fluxo de valor acontecer sem
interrupções, deixar o cliente puxar o valor do produto, perseguir a Perfeição
(produto à medida, tempo de entrega zero, nada em aprovisionamento) [15].

20
Figura 2. Ciclo de desenvolvimento Lean [POPPENDIECK, Mary; CUSUMANO,
Michael A. Lean software development: A tutorial. IEEE software, v. 29, n. 5, p.
26-32, 2012.]

2.2 Manifesto Ágil

Atualmente, as empresas estão operando em um ambiente global e seguem

tendências, que muitas vezes mudam rapidamente. Com o surgimento de novos
mercados e oportunidades, mudanças econômicas e o surgimento de novos
produtos e serviços concorrentes, os softwares necessitam de um desenvolvimento
ágil para que possam responder às pressões provenientes das disputas de mercado.
Diante disto, é praticamente impossível que um sistema possua um grupo de
requisitos de software estáveis. Devido aos fatores externos, os requisitos estão
predispostos à mudanças rápidas e sem uma previsão [26].

A partir desse problema, em 2001, um importante encontro entre dezessete

profissionais de software marcou definitivamente o surgimento e a propagação do
paradigma ágil de desenvolvimento de software. A intenção era gerar um
antagonismo aos chamados "métodos pesados" de desenvolvimento de software,
que prevaleciam no formalismo exagerado e no foco na documentação e burocracia
presentes nos métodos tradicionais. [26]. Tendo como valores[1]:

● Indivíduos e interações mais que processos e ferramentas

● Software em funcionamento mais que documentação abrangente
● Colaboração com o cliente mais que negociação de contratos
● Responder a mudanças mais que seguir um plano

Um princípio-chave era “entregar software de trabalho com frequência, de algumas

semanas a alguns meses, com preferência para a escala de tempo mais curta”,

21
enfatizando a entrega de pequenos pacotes, lançamentos incrementais em vez de
grandes lançamentos em cascata. Outros princípios enfatizaram a necessidade de
equipes pequenas e auto-motivadas, trabalhando em um modelo de gestão de alta
confiança [3].

2.3 Integração Contínua

A integração contínua foi escrita pela primeira vez no livro de Kent Beck,
Extreme Programming Explained (publicado pela primeira vez em 1999) [21]. A ideia
por trás da integração contínua era que, se a integração da sua base de código
fosse boa, por que não fazê-lo o tempo todo? No contexto de integração, ”todo o
tempo ”significa cada vez que alguém efetua qualquer alteração ao sistema de
controle de versão [16]. A Integração Contínua é uma prática de desenvolvimento de
software em que os membros de uma equipe integram seu trabalho com frequência,
geralmente cada pessoa se integra pelo menos diariamente - levando a várias
integrações por dia. Cada integração é verificada por uma compilação automatizada
(incluindo teste) para detectar erros de integração o mais rápido possível. Muitas
equipes acham que essa abordagem leva a problemas de integração
significativamente reduzidos e permite que uma equipe desenvolva softwares
coesos mais rapidamente [17].

22
 ​Figura 3: Continuous Integration [22]

2.5 Entrega Contínua

A entrega contínua é uma prática que surgiu para reduzir tempo, custo e os
riscos da entrega de software, surgiu como uma das prioridades do manifesto ágil
[18]. CD é mais do que apenas uma nova metodologia de entrega. É um paradigma
totalmente novo para administrar um negócio que depende de software [16].

Entrega Contínua significa apenas que você é capaz de realizar implantações

frequentes, mas pode optar por não fazê-lo, geralmente devido a empresas que
preferem uma taxa mais lenta de implantação. Para fazer a Implantação Contínua,
você deve estar fazendo Entrega Contínua [19].
23
2.6 Implantação Contínua

A implantação contínua envolve a implantação automática do software em

algum ambiente, mas não necessariamente para os clientes. A implantação contínua
é um pré-requisito para obter entrega contínua [28]. Virmani [25] afirma que a
implantação contínua é uma etapa crítica na otimização geral da entrega de
software. Os princípios de DevOps recomendam a automação de implantação e
provisionamento de hardware. Configurar manualmente o hardware para testar
compilações pode levar várias semanas e a implantação dos processos não serão
consistentes. Outro princípio do DevOps entra em ação na implantação contínua;
Infraestrutura como código (IaC), o que implica que a infra-estrutura é mantido como
código no repositório do código-fonte.

2.5 Infraestrutura ágil e Movimento Velocity

Na conferência Agile de 2008 em Toronto, no Canadá, Patrick Debois e

Andrew Schafer realizaram uma sessão de“ aves de penugem ”sobre a aplicação
dos princípios ágeis à infraestrutura, em oposição ao código do aplicativo. Apesar de
terem sido as únicas pessoas que apareceram, eles rapidamente conquistaram
seguidores de pensadores afins, incluindo o co-autor John Willis [3].

Mais tarde, na conferência Velocity de 2009, John Allspaw e Paul Hammond

deram a apresentação seminal “10 + Deploys Per Day: Dev and Ops Cooperation at
Flickr”, onde descreveram como criaram metas compartilhadas entre Dev e Ops e
usaram práticas de integração contínua para tornar implantação parte do trabalho
diário de todos.

Logo após, Patrick Debois criou o primeiro DevOpsDays em Ghent, Bélgica.

Onde termo "DevOps" foi ouvido pela primeira vez.

24
2.6 DevOps

O DevOps está sendo definido como uma metodologia, uma técnica ou um

processo, mas na verdade é uma mentalidade que evoluiu em resposta à falta de
colaboração entre as equipes de desenvolvimento e operação. A mesma razão pela
qual alguns dos produtos legados tinham ritmo monolítico de lançamentos e
correções para os clientes. O atrito constante sobre as práticas de processo e
entrega levou a uma revolução de processos e práticas de amadurecimento, que faz
parte da representação da cultura de DevOps [4].

É uma manifestação de criação de organizações dinâmicas e de aprendizado

que continuamente reforçam as normas culturais de alta confiança, é inevitável que
essas organizações continuem a inovar e a ganhar no mercado [3].

São várias as práticas adotadas para se ter DevOps nas organizações,

diversas variáveis são levadas em consideração para se decidir qual metodologia irá
ser utilizada, porém, algumas práticas são bastante comuns nas organizações de TI
que adotam Devops, e a pipeline de entrega é uma delas, por ser de suma
importância para se ter uma melhor comunicação entre os times de desenvolvimento
e de operações, e assim poder garantir uma entrega contínua, que por sua vez é
essencial para a prática do Devops. A pipeline de qualquer organização pode ser
personalizada da forma como necessitar, porém Humble e Farley ilustraram uma
pipeline típica de Devops para se ter a garantia de entrega contínua [22].

Figura 4. Pipeline Devops [22]

25
2.7 Arquitetura de Referência

Uma Arquitetura de Referência é baseada em conceitos comprovados na

prática e a maioria das arquiteturas precedentes é extraída desses conceitos. Com
base em uma elaboração de missão, visão, estratégia e nas necessidades do
cliente, a Arquitetura de Referência é transformada em uma arquitetura que fornece
orientação para várias organizações que evoluem ou criam novas arquiteturas. As
arquiteturas de referência devem abordar arquiteturas técnicas, arquiteturas de
negócios e contexto. Um dos principais desafios é tornar a Arquitetura de Referência
inerentemente abstrata concreta e compreensível, fornecendo informações e
diretrizes específicas suficientes. O valor das Arquiteturas de Referência está
previsto em ambientes com alto fator de multiplicidade, criando complexidade social,
organizacional de negócios, de aplicação e técnica [34].

2.8 Considerações Finais

Neste capítulo foi apresentada a fundamentação teórica sobre o assunto,

onde foram listadas as definições sobre os assuntos principais, DevOps e
Arquitetura de Referência. Essa fundamentação possibilitou a análise mais
aprofundada quanto às definições de DevOps e RA, com isso pode-se refinar o
conteúdo e direcionamento deste trabalho de pesquisa.

26
3. Metodologia

Foi realizada uma pesquisa participante [33] onde através dos resultados
obtidos, foram extraídos conhecimentos relacionados às infraestruturas adotadas
por projetos que fizeram adoção do DevOps como forma de melhoria para o
processo de entrega. As coletas de dados textuais somados a dados empíricos
coletados nesses projetos proporcionou um produto de pesquisa mais próximo da
realidade. Durante o período de 01/2018 à 06/2019 foram coletados dados
referentes às ferramentas e ao fluxo de entrega adotados por esses projetos.

A metodologia de desenvolvimento deste trabalho é dividida em quatro etapas.

1. análise literária focando nas seguintes áreas: RA e DevOps.
2. mapeamento dos papéis desempenhados pelas ferramentas DevOps
utilizadas nos projetos que fiz parte.
3. modelagem da arquitetura de referência baseada nas ferramentas e suas
respectivas funcionalidades.
4. apresentação dos resultados obtidos juntamente com a proposta de uma
ARD​.

3.1 Etapas da Pesquisa

Para alcançar os objetivos pretendidos a pesquisa foi aplicada a partir de
algumas etapas, foram elas:

● Etapa 1 - Análise do Referencial Teórico: ​Nesta fase, foi realizado todo o

estudo, nos principais trabalhos, que concerne à Arquitetura de Referência e
DevOps, onde foi possível compreender seus principais conceitos teóricos e
práticos. Além disso, foi feita uma forte fundamentação teórica que foi
discutida no capítulo 2 e que explana sobre, visando fortalecer e validar as
informações contidas neste projeto

27
 ● Etapa 2 - Mapeamento dos papéis desempenhados pelas ferramentas
DevOps: ​Após ter todo o apanhado teórico necessário para entender sobre
os principais temas discorridos neste projeto. Foi-se mapeado em artigos e
em projetos nos quais participei as funções desempenhadas pelas
ferramentas adotadas pelos mesmos.
● Etapa 3 - Modelagem da arquitetura de referência: ​Com as informações
provenientes do mapeamento desenvolvido, esta etapa teve a função de
modelar uma Arquitetura de Referências DevOps com base no fluxo de
entrega.
● Etapa 4 - Proposta de uma Arquitetura de Referência DevOps: ​Por fim,
nesta fase foi elaborada uma proposta provenientes da modelagem na etapa
anterior.

3.2 Considerações Finais

Este capítulo expôs a importância de como uma pesquisa científica deve

seguir um procedimento, para que desta forma, a investigação obtenha uma
confiabilidade e esteja de acordo com as exigências científicas necessárias para a
sua validade. No próximo capítulo será detalhada a construção da proposta
arquitetural para DevOps.

28
4. Proposta de Arquitetura de Referência para
DevOps

Neste capítulo falaremos sobre os processos que compuseram a construção

da proposta de arquitetura de referência. O objetivo desta etapa é mostrar.
Explorando benefícios, desafios enfrentados para criar modelos arquiteturais para
DevOps e por fim demonstrar algumas ferramentas que auxiliam a execução dos
processos.

4.1 Projetos Mapeados

Os projetos a seguir contribuíram para o processo de construção da

arquitetura, tal qual a comprovação das hipóteses.

4.1.1 Grande Instituição Financeira no Brasil

Este projeto previamente vinha sendo desenvolvido com a metodologia

cascata e processos de entrega de software mal definidos. Por requisição do
cliente, foi necessária a mudança para o uso da metodologia ágil e como
programa ágil, adoção do DevOps. Por não seguiram nenhuma
arquitetura/modelo de referência, houve a compra da ferramenta Jira.
Infelizmente para os fins que o Jira foi comprado, tinha-se o Phabricator
previamente atendendo ao time.

29
Figura 5. Modelo Físico de Grande Instituição Financeira no Brasil

4.1.2 Grande Empresa de Telecomunicação no Brasil

Esse projeto não teve metodologia definida, houve apenas a adoção

de alguns ritos do ágil (ex: Scrum, Kanban, etc). Como referência de
infraestrutura foi utilizado o projeto descrito acima. O processo de entrega foi
definido juntamente com o pipeline, facilitando o processo de adoção de uma
infraestrutura DevOps.

30
 Figura 6. Modelo Físico de Grande Empresa de Telecomunicação no Brasil.

4.2 Modelos de ARD

A construção do ARD foi desenvolvido em três estágios:

4.2.1 Modelo Conceitual

O Modelo Conceitual é ilustrado nas Figuras 7,8 e 9, que mostra uma

combinação de camada conceitual de conceitos DevOps e conceitos de
plataformas. É evidente que o sistema depende principalmente de humanos
que afetam diretamente a implantação do DevOps. Os elementos humanos
como colaboração, cultura, comunicação, estratégia, padrões e princípios
podem variar entre os membros da equipe para diferentes situações ou
projetos. Portanto, as práticas de abordagem do DevOps [35] fornecem à
equipe de DevOps insights claros sobre o projeto e definem uma teoria geral

31
de como a comunicação e a colaboração devem ser conduzidas no nível
profissional.

O ARD usa uma abordagem adaptável e ágil para planejamento e

projeto de projeto contínuo. A abordagem DevOps fornece à equipe melhor
comunicação e mapeamento mais claro do projeto. O sistema permite a
sincronização de ideias, esforço, recursos e resultados. Para obter um
sistema ideal, o ARD depende da plataforma. O gerenciamento de recursos e
a governança de servidores são a chave da integração. Para uma camada de
plataforma de desenvolvimento de software bem-sucedida, oferece controle
de operação clara à equipe de DevOps. O resultado alcançado a partir deste
sistema é a automação do processo de desenvolvimento de software em
ambiente ágil. O processo de desenvolvimento de é composto por:
Planejamento, Colaboração, Desenvolvimento, Sincronização, Criação, Teste,
Monitor, Implantar e Entregar.

O resultado desejado é utilizar essa camada conceitual geral e definir

ou virtualizar um Modelo Lógico para a construção de uma plataforma que
possa ser instanciada em um Modelo Físico.

32
 Figura 7. Modelo Conceitual de DevOps

Figura 8. Modelo Conceitual de Plataforma

33
 Figura 9. Visão Integrada do Modelo Conceitual

4.2.2 Modelo Lógico

O principal objetivo desta pesquisa é propor uma arquitetura de

referência para DevOps. Portanto, a arquitetura lógica detalha de forma
síncrona os elementos lógicos do DevOps ilustrados na Figura 9. O Modelo
Lógico é fundado em cinco modelos. A combinação dos cinco modelos ilustra
como a equipe DevOps pode usá-lo para a implantação de uma plataforma
em ambientes diversos. Modelos Lógicos (M1 a M5) são mapeados na Tabela
I de acordo com suas características e possíveis ferramentas de DevOps. As
ferramentas sugeridas são um conjunto de uma coleção muito maior de
ferramentas de DevOps [35]. Os modelos de ARD são baseados nas práticas
de DevOps [35].

34
Figura 10. Modelo Lógico
35
 Tabela I.

Modelo ARD Modelo Lógico

Atividades Ferramentas

M1 ➔ Sincronização de ➔ GitHub
Código ➔ Bitbucket
➔ Push automático ➔ Gitlab
➔ Relatório de logs ➔ Phabricator
automáticos

M2 ➔ Build automático ➔ Jenkins

➔ Teste automático ➔ GitLab CI
➔ Pipeline script ➔ Travis CI

M3 ➔ Escalabilidade ➔ AWS
➔ Ambiente de ➔ GCP
Implantação ➔ Heroku
➔ Ambiente de ➔ Oracle Cloud
Armazenamento ➔ Bare Metal
de Pacote
➔ Instâncias na
Nuvem
➔ Ambiente de
Staging

M4 ➔ Gerenciamento de ➔ Slack
Relatórios ➔ Microsoft Teams
➔ Integração com ➔ Hip Chat
ferramentas de
Comunicação
➔ Notificações
Automáticas

M5 ➔ Gerenciamento ➔ MongoDB
Cloud DB ➔ DBMaestro
➔ NoSQL DB ➔ Firebase
➔ SQL DB ➔ MySQL
➔ Shared Resources

36
4.2.3 Modelo Físico

O pipeline de é um modelo físico baseada no Modelo lógico (consulte a

Figura 9 e a Tabela I). O modelo de pipeline físico (veja a Figura 10) é a
integração de uma das ferramentas do DevOps. A Tabela II descreve os
modelos de arquitetura das ferramentas de pipeline de ARD (Repositório,
Orquestrador de CI/CD, Ambiente de Deploy, Gerenciador de Logs, Banco de
Dados e Notificador).

O pipeline de ARD (consulte a Figura X) sugere a implantação das

ferramentas de automação. Ele fornece uma equipe de DevOps com
gerenciamento em tempo real e uma visão clara das etapas de implantação
usando ferramentas de comunicação e monitoramento (Notificador e Coletor
de Logs do modelo M4). O modelo físico M2 (Orquestrador) é um agente de
integração contínua para implantar automaticamente uma aplicação no
modelo físico M5 (Plataformas).

O código da aplicação é automaticamente enviado da ferramenta

Modelo-M1 (Repositório) para a ferramenta Modelo-M2 (Orquestrador). Os
usuários podem utilizar o aplicativo a partir de qualquer dispositivo, uma vez
implantado em qualquer plataforma.

O aplicativo (consulte a Tabela II) é implantado nas plataformas com

um dispositivo (Figura 10). Os dados coletados no tempo de execução devido
a essa interação são salvos como entradas no Banco de Dados (M5). As
operações do software tem seus logs monitorados pelo coletores de Logs.

37
 Figura 11. Modelo Físico

Tabela II.

Atores ARD Modelo Físico

Atividades Ferramentas

DevOps Team Configurar integração do MySQL

projeto com do pipeline. Docker
Ansible
Criar scripts para Terraform
automação de
provisionamento de
instâncias e configuração
delas.

Repositório Criar repositório para Github

projetos localmente ou Phabricator
na nuvem e integrar Slack
notificação.

Orquestrador Configurar scripts de Jenkins

38
 CI/CD e integrar com Slack
plugin de notificação.

Plataforma Criar instâncias via AWS

scripts configurando toda Heroku
a VPC ou Bare Metal. Bare Metal

Monitoramento Configurar Hygieia

agentes/plugins ou Zabbix
coletores da ferramenta Prometheus
de monitoramento para ELK
se conectar as
ferramentas do pipeline.

4.3 Proposta

Esta seção discute os detalhes de desenvolvimento ou implementação do

design. A implementação do ARD consiste em duas etapas:

4.3.1 Configuração de ferramentas do Pipeline

A integração entre as ferramentas do pipeline (consulte a Figura 10) é

o fator-chave dessa arquitetura de referência. Um orquestrador é usado para
lidar com a integração contínua e implantação automatizada (entrega) de
softwares em várias plataformas (consulte a Tabela II).

4.3.2 Pipeline de Desenvolvimento

As ferramentas utilizadas para demonstração foram :

1. Phabricator;
2. Jenkins;
3. Nexus;
4. MariaDB;
5. Prometheus;
6. Grafana.
39
4.4 Experimentação

Nesta seção iremos implementar um tutorial exemplo de uma infraestrutura

CI/CD DevOps baseada na arquitetura de referência proposta. Será provisionada
utilizando instâncias na AWS. Para critérios de validação da hipótese três (HP03)
utilizaremos IaC para a construção da mesma.

4.4.1 Pré-requisitos

Aplicações previamente necessárias:

● Acesso a instâncias na AWS EC2
● Uma máquina com Terraform, Ansible e Terraform Inventory, é
preferível que seja um sistema Linux pela compatibilidade.

4.4.2 Configurando acesso às Instâncias

Antes da criação dos scripts, é preciso configurar os acessos a AWS.

para isso seguiremos dois passos:
1. ​ ara acessar as instâncias:
Criação de uma ​key-pair p

1.1. Siga para o painel da EC2 (Figura 11);

1.2. ​ m “Network & Security” (Figura 12):
Escolha ​key-pairs e
1.3. Clique em ​Create Key Pair​ (Figura 13);
1.4. Escolha um nome para a chave e clique em criar (Figura
14);
1.5. Após criação será feito o download automático da chave
(Figura 15):

40
 2. Criar uma chave de acesso para acesso IAM na plataforma:

2.1. No seu usuário clique e escolha “Minhas credenciais de

segurança” (Figura 16);
2.2. Clique em “Criar chave de acesso” (Figura 17);
2.3. Uma chave será gerada, clique em “fazer download do
arquivo .csv” para guardá-la (Figura 18).

4.4.3 Criando scripts para IaC

Nesta etapa criaremos os scripts que serão executados para criar as

máquinas (Terraform) e fazer a devidas configurações e instalações (Ansible):

1. Criando script Terraform:

1.1. Sete variáveis que iremos utilizar (Figura 19):

1.2. Crie script da VPC (Figura 20):
1.3. Crie script do provider (Figura 21):
1.4. Crie script do route (Figura 22):
1.5. Crie script da instância EC2 (Figura 23):
1.6. Finalizando, crie script de retorno para checar informações a
infra construída (Figura 24):

2. Criando script Ansible:

Para a instalação do Docker [35] e pip [36]. Utilizaremos as
bibliotecas de Jeff Geerling [37].

2.1. Edite o arquivo hosts dentro de /etc/ansible/hosts com o ip da

máquina, sentando onde está instalado o python e onde se
encontra a ​key-pair.

41
 2.2. Teste a conexão
2.3. Crie um arquivo main.yml, nele setaremos todas as roles e
ordem de instalação
2.4. Crie uma pasta para cada ferramenta e iremos seguir a
estrutura de pastas recomendadas pela documentação do
Ansible.
2.5. Crie o script do Jenkins
2.6. Crie o script do Phabricator e MariaDB
2.7. Crie o script do Nexus
2.8. Crie o script do Spring PetClinic
2.9. E por fim crie os scripts das ferramentas de monitoramento
contendo Prometheus e Grafana

4.5 Hipóteses de Pesquisa

Essas hipóteses foram levantadas a partir dos cenários encontrados durante

o processo de construção de infraestruturas CI/CD nas organizações nas quais
integrei o time DevOps.

● HP01 - Infraestruturas DevOps no processo CI/CD possuem uso de

ferramentas com papéis similares.
Durante a pesquisa essa hipótese foi comprovada, visto que os
projetos possuíam o mesmo fluxo de entrega, mas com muitos
atividades sendo executadas por ferramentas distintas.

● HP02 - A não adoção de um modelo de arquitetura de referência pode

acabar gerando uma utilização ineficiente de ferramentas.
O que valida essa hipótese é que nos dois projetos (Instituição
Financeira e Empresa de Telecomunicação) nos quais compus o time,
por não se ter uma referência de partida houveram ferramentas

42
 inutilizadas. No projeto bancário tivemos a adoção do Jira, na qual foi
preciso ser feita uma automação para migrar via API as tasks contidas
no phabricator.

● HP03 - Usar IaC na para replicação de Infraestrutura DevOps aumenta

o produtividade.
Durante a fase de desenvolvimento deste capítulo foi utilizado
IaC (Ansible e Terraform), cronometricamente tivemos:
● Provisionamento de Instâncias: Em média leva-se em
todo de 5-10 minutos para uma pessoa experiente
configurar manualmente uma VPC na AWS. Utilizando
Terraform obtivemos uma VPC configurada em 45
(quarenta e cinco) segundos

● Configuração das Instâncias: Em média para executar

processos de instalação das ferramentas leva-se no
mínimo um dia (8h trabalhadas). Utilizando um script
pré-configurado além dele ser idempotente demorou de 4
(quatro) a 6 (seis) minutos, variando de acordo com a
conexão e capacidade de processamento da máquina.

43
5. Conclusão

A adoção de infraestrutura CI/CD DevOps está cada vez mais presente em

projetos de software, tanto nas empresas mais novas, como nas mais antigas, para
que a indústria de software tenha a capacidade de acompanhar a crescente
demanda do mercado. Porém, adotar um conjunto de ferramentas DevOps não
garante a qualidade de entrega ou o aumento dela.

Foi constatado na presente pesquisa que está ocorrendo em projetos a

adoção do paradigma DevOps como agente de transformação em projetos ágeis.
Porém, ainda perdura o surgimento de problemas referentes implementação e a não
adoção de padrões ou modelos arquiteturais.

Além disso, transtornos relacionados à comunicação com o cliente, validação

de requisitos, falhas na documentação, falhas contratuais e nas escolhas das
ferramentas são frequentes nas organizações e necessitam ser analisados e
combatidos. Para que assim os prazos e os custos planejados sejam cumpridos,
proporcionando benefícios para as organizações e seus projetos.

5.1 Contribuições

A presente pesquisa proporcionou um panorama geral sobre arquiteturas de

referência para infraestrutura DevOps em consonância com os métodos de adoção

Desta forma, pôde-se obter uma visão geral que tange a criação de uma
pipeline CI/CD e quais papéis devem ser desempenhados pelas ferramentas em
cada fase do ​workflow.​

44
 Com essa pesquisa não pretendemos propor um modelo ideal e sim um ponto
de partida para todo time, projeto ou organização que tenha como objetivo aderir
uma infraestrutura DevOps.

5.2 Limitações e Trabalhos Futuros

O presente estudo enfrentou o desafio de mapear uma quantidade maior de

projetos. Para alcançar os objetivos deste trabalho, foram realizadas mapeamentos
em projetos nos quais compus o time DevOps. Porém, infelizmente, houveram
projetos que por motivos corporativos não puderam ser utilizados como referência.

Salienta-se ainda que os dados adquiridos foram bastante significativos e

ainda poderiam ser utilizados de diversas formas, como para saber quais as
vantagens ou problemáticas em adotar ferramentas open-source para compor uma
infraestrutura DevOps CI/CD. Porém, essa análise foge ao escopo inicialmente
traçado para este trabalho.

Os dados qualitativos oriundos dos projetos corporativos, em alguns casos,

foram bastante gerais ou sucintos, impossibilitando assim obter alguma conclusão
sobre o assunto. Como sugestão para futuras pesquisas, pode-se ainda realizar
estudos que estejam focados em apenas uma arquitetura de referência específica,
mais precisamente as que foram mais evidenciadas nesta pesquisa (projetos
legados), para que assim seja possível aprofundar os conhecimentos individuais
sobre os seus pontos fortes e fracos. Isto possibilitaria que fossem gerados materiais
base para uma possível viabilização da criação de uma arquitetura de referência
para projetos legados.

45
Referências

[1] ​Manifesto for Agile Software Development​. 2001 <​http://agilemanifesto.org/​>

Acessado em 4 de Abril de 2018

[2] Bass, Len; Weber, Ingon; Zhu, Liming. DevOps: A software architecture
perspective, May 2015.

[3] Kim, Gene; Debois, Patrick; Willis, John; Humble, Jez; John Allspaw. The DevOps
Handbook: How to Create World-Class Agility, Reliability, and Security in Technology
Organizations, October 2016.

[4] M. Rajkumar., Pole AN., Adige V., Mahanta P. DevOps culture and its impact on
cloud delivery and software development. International Conference on Advances in
Computing, Communication & Automation (ICACCA), 2016.

[5] Willis, John. Docker and The Three Ways of DevOps, 2015.

[6] Anderson, Charles. Docker [Software engineering], IEEE Software (ISSN

0740-7459), 23 April 2015.

[7] Verma, Abhishek; Pedrosa, Luis; Korupolu, R. Madhukar, Oppenheimer, David;

Tune, Eric; Wilkes, John. Large-scale cluster management at Google with Borg,
2015.

[8] Kubernetes Documentation <​https://kubernetes.io/docs/​> Acessado em 5 Abril de

2018.
[9] Mell, Peter, and Tim Grance. "The NIST definition of cloud computing." National
institute of standards and technology 53.6 (2009).

46
[10] Sheafer A., Reichenbach M., Fey D., “Continuous Integration and Automation for
DevOps”, H. K. Kim et al. (eds.), IAENG Transactions on Engineering Technologies,
Lecture Notes in Electrical Engineering 170, DOI: 10.1007/978-94-007-4786-9_28,
Springer Science+Business Media Dordrecht 2013.

[11] Bou Ghantous, G. and Gill, A.Q. “DevOps: Concepts, Practices, Tools, Benefits
and Challenges”. University of Technology Sydney, Broadway Ultimo NSW,
Australia. PACIS 2017 Proceedings 96 2017.

[12] Virmani M., “Understanding DevOps & Bridging the gap from Continuous
Integration to Continuous Delivery”, Fifth international conference on Innovative
Computing Technology (INTECH 2015), 978-1-4673-7551- 1/15 © 2015 IEEE.

[13] Nakagawa, Elisa Yumi, Flavio Oquendo, and Martin Becker. "Ramodel: A
reference model for reference architectures." Software Architecture (WICSA) and
European Conference on Software Architecture (ECSA), 2012 Joint Working
IEEE/IFIP Conference on. IEEE, 2012.

[14] WOMACK, James P.; JONES, Daniel T.; ROOS, Daniel. A máquina que mudou
o mundo: baseado no estudo do Massachusetts Institute of Technology sobre o
futuro do automóvel. Rio de Janeiro: Campus, 2004.

[15] HUMBLE, Jez; FARLEY, David. Continuous delivery: reliable software releases
through build, test, and deployment automation. Pearson Education, 2010.

[16] FOWLER, Martin; FOEMMEL, Matthew. Continuous integration. Thought-Works)

http://www. thoughtworks. com/Continuous Integration. pdf, v. 122, p. 14, 2006.

[17] BECK, Kent et al. Manifesto for agile software development. 2001.

47
[18] FOWLER, Martin et al. Continuous delivery. martinfowler. com, 2013.

[19] The LeSS Company B.V. Disponível em

<​https://less.works/less/technical-excellence/continuous-integration.html​>

[20] BECK, Kent; GAMMA, Erich. Extreme programming explained: embrace change.
addison-wesley professional, 2000.

[21] DUVALL, Paul. Continuous Integration: Improving Software Quality and

Reducing​ ​Risks​. Addison-Wesley, 2007.

[22] BUCENA, Ineta; KIRIKOVA, Marite. Simplifying the DevOps Adoption Process.
In: BIR Workshops. 2017.

[23] HAMUNEN, Joonas et al. Challenges in adopting a Devops approach to

software development and operations. 2016.

[24] AMARADRI, Anand Srivatsav; NUTALAPATI, Swetha Bindu. Continuous

Integration, Deployment and Testing in DevOps Environment. 2016.

[25] SOMMERVILLE, I. Engenharia de Software. 9 Ed. São Paulo, 2011.

[26] SBROCCO, J. H. T. C.; MACEDO, P. Metodologias ágeis: engenharia de

software sob medida. São Paulo: Érica, 2012.

[27] VIRMANI, Manish. Understanding DevOps & bridging the gap from continuous
integration to continuous delivery. In: Fifth International Conference on the Innovative
Computing Technology (INTECH 2015). IEEE, 2015. p. 78-82.

48
[28] HÜTTERMANN, M. DevOps for developers (expert’s voice in Web
development). 2012.

[29] WIKIPÉDIA. Toyota Production System Disponível em:

https://en.wikipedia.org/wiki/Toyota_Production_System. Acesso em 15 jun 2019

[30] SUGIMORI, Y. et al. Toyota production system and kanban system

materialization of just-in-time and respect-for-human system. The international
journal of production research, v. 15, n. 6, p. 553-564, 1977.

[31] POPPENDIECK, Mary et al. Principles of lean thinking. IT Management Select,

v. 18, n. 1, p. 1-7, 2011.

[32] GIL, Antonio Carlos. Como elaborar projetos de pesquisa. São Paulo, v. 5, n. 61,
p. 16-17, 2002.

[33] CLOUTIER, Robert et al. The concept of reference architectures. Systems

Engineering, v. 13, n. 1, p. 14-27, 2010.

[34] BOU GHANTOUS, G.; GILL, Asif. DevOps: Concepts, Practices, Tools, Benefits
and Challenges. PACIS2017, 2017.

[35] Ansible Docker Playbook. <​https://galaxy.ansible.com/geerlingguy/docker​>

[36] Ansible Pip Playbook. <​https://galaxy.ansible.com/geerlingguy/pip​>

[37] Jeff Geerling, Ansible Galaxy website <​https://galaxy.ansible.com/geerlingguy​>

49
[38] Ansible Best Practices
<​https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#d
irectory-layout​>

50
Apêndice A

Figura 12. Criação de key-pair, part. I

Figura 13. Criação de key-pair, part. II

51
Figura 14. Criação de key-pair, part. III

Figura 15. Criação de key-pair, part. IV

52
 Figura 16. Criação de key-pair, part. V

Figura 17. Criação de secret key e access key, part. I

53
Figura 18. Criação de secret key e access key, part. II

Figura 19. Criação de secret key e access key, part. III

54
Figura 20. Criação de variáveis terraform

55
56
 Figura 21. Criação do script Terraform da VPC.

Figura 22. Criação do script Terraform do Provider AWS.

57
Figura 23. Criação do script Terraform do Route.

58
Figura 23. Criação do script Terraform da instância EC2.

Figura 24. Criação do script Terraform de output.

59
 Figura 25. Criação de script principal.

Figura 26. Editando ansible hosts.

Figura 27. Verificando conexão com hosts

60
Figura 28. Estrutura de diretórios Ansible [38].

61
Figura 29. Criação de script Jenkins

62
Figura 30. Criação de script Phabricator e MariaDB

63
Figura 31. Criação de script Nexus

64
Figura 32. Criação de script Spring PetClinic

65
66
Figura 33. Criação de script Prometheus e Grafana


67