Trabalho de Graduação
1
Júlio Alexandre Pedrosa de Melo
___________________________________________________________________
Henrique Rebêlo
___________________________________________________________________
2
Agradecimentos
3
por ser um mentor que me ajudou a ser o profissional que sou hoje e pelos
conselhos cristãos.
Provérbios 3:13,14
4
Resumo
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.
7
Lista de Figuras
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
10
Lista de Abreviaturas e Siglas
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
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
1.1 Contexto
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
1.2 Motivação
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.
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
18
Figura 1. Casa do Sistema Toyota de Produção [30]
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].
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.]
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].
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]
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].
24
2.6 DevOps
25
2.7 Arquitetura de Referência
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.
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.
28
4. Proposta de Arquitetura de Referência para
DevOps
29
Figura 5. Modelo Físico de Grande Instituição Financeira no Brasil
30
Figura 6. Modelo Físico de Grande Empresa de Telecomunicação no Brasil.
31
de como a comunicação e a colaboração devem ser conduzidas no nível
profissional.
32
Figura 7. Modelo Conceitual de DevOps
34
Figura 10. Modelo Lógico
35
Tabela I.
Atividades Ferramentas
M1 ➔ Sincronização de ➔ GitHub
Código ➔ Bitbucket
➔ Push automático ➔ Gitlab
➔ Relatório de logs ➔ Phabricator
automáticos
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
37
Figura 11. Modelo Físico
Tabela II.
Atividades Ferramentas
38
CI/CD e integrar com Slack
plugin de notificação.
4.3 Proposta
4.4.1 Pré-requisitos
40
2. Criar uma chave de acesso para acesso IAM na plataforma:
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
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.
43
5. Conclusão
5.1 Contribuições
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.
45
Referências
[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.
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.
[17] BECK, Kent et al. Manifesto for agile software development. 2001.
47
[18] FOWLER, Martin et al. Continuous delivery. martinfowler. com, 2013.
[20] BECK, Kent; GAMMA, Erich. Extreme programming explained: embrace change.
addison-wesley professional, 2000.
[22] BUCENA, Ineta; KIRIKOVA, Marite. Simplifying the DevOps Adoption Process.
In: BIR Workshops. 2017.
[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.
[32] GIL, Antonio Carlos. Como elaborar projetos de pesquisa. São Paulo, v. 5, n. 61,
p. 16-17, 2002.
[34] BOU GHANTOUS, G.; GILL, Asif. DevOps: Concepts, Practices, Tools, Benefits
and Challenges. PACIS2017, 2017.
49
[38] Ansible Best Practices
<https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#d
irectory-layout>
50
Apêndice A
51
Figura 14. Criação de key-pair, part. III
52
Figura 16. Criação de key-pair, part. V
53
Figura 18. Criação de secret key e access key, part. II
54
Figura 20. Criação de variáveis terraform
55
56
Figura 21. Criação do script Terraform da VPC.
57
Figura 23. Criação do script Terraform do Route.
58
Figura 23. Criação do script Terraform da instância EC2.
59
Figura 25. Criação de script principal.
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