Graduação em Sistema de Informação

Uma proposta de Arquitetura de

Referência para DevOps

Júlio Alexandre Pedrosa de Melo

japm@cin.ufpe.br

Orientador: Prof. Dr. Vinicius Cardoso Garcia

Coorientador: José Fernando Carvalho
Agenda
◎ Motivação
◎ Objetivos
◎ Metodologia
◎ Proposta
◎ Conclusão

2
 “
DevOps is a set of practices
intended to reduce a the time
between committing a change to a
system and the change being
placed into normal production,
while ensuring high quality.
- Bass, Len. “DevOps: A Software
Architect’s Perspective.”

3
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 estão intimamente
relacionados com diferentes práticas, como
automação, monitoramento e configuração.
[HAMUNEN, Joonas et al. 2016]
◎ Os problemas ligados à implementação tecnológica
do DevOps são um dos que mais causam desperdícios.
[AMARADRI, Anand Srivatsav et al. 2016]
4
Objetivo Geral
◎ Identificar empiricamente em projetos
padrões suas infraestruturas de CI/CD
DevOps e propor um Modelo de Arquitetura
de Referência.

5
Objetivo Específicos
◎ Apresentar conceitos encontrados na literatura
que discorrem sobre DevOps e AR;
◎ Identificar papéis de cada ferramenta utilizada
na infraestrutura no pipeline DevOps desses
projetos;
◎ Modelar uma arquitetura de referências DevOps.

6
2.
Metodologia

7
Natureza da Pesquisa
◎ Abordagem qualitativa;
◎ Pesquisa exploratória;
◎ Objeto de Estudo, ferramentas utilizadas
em uma infraestrutura DevOps;
◎ Locus da Pesquisa, projetos que fazem uso
de infraestrutura DevOps.

8
Metodologia
◎ Observação participante
◎ Análise da literatura focando nas seguintes
áreas: Arquitetura de Referência e DevOps.
◎ Mapear dos papéis desempenhados pelas
ferramentas dentro do CI/CD DevOps.
◎ Modelar uma arquitetura de referência
baseada nas ferramentas mapeadas e suas
respectivas funcionalidades.

9
Hipóteses
◎ Infraestruturas DevOps no processo CI/CD
possuem uso de ferramentas com papéis
similares.
◎ A não adoção de um modelo de arquitetura
de referência pode acabar gerando uma
utilização ineficiente de ferramentas.
◎ Usar IaC na para replicação de
Infraestrutura DevOps aumenta o
produtividade.
10
3.
Fudamentação
Teórica

11
Evolução Histórica

12
Sistema Toyota de
Produção
◎ Just-in-time, entrega sob demanda;
◎ Jidoka, automação;
◎ Heijunka, lotes;
◎ Kaizen, melhoria contínua.

13
Movimento Lean
◎ Melhoria contínua;
◎ Redução de custos;
◎ Agilidade na produção;
◎ Maior capacidade produtiva;
◎ Melhorias do ambiente de trabalho para os
funcionários.

14
Manifesto Ágil
◎ 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.

15
Integração Contínua
◎ Manter um único repositório de código;
◎ Automatize a Build;
◎ Fazer a Build ser auto-testável;
◎ Modificações todos os dias.

16
Entrega Contínua
◎ Software implementável em todo o seu
ciclo de vida;
◎ Equipe prioriza manter o software
implantável em vez de trabalhar em novos
recursos;
◎ Qualquer pessoa pode obter feedback
rápido e automatizado sobre o estado de
produção, sempre que alguém fizer uma
alteração neles;
◎ Deploy pode ser feito a qualquer momento.
17
Implantação Contínua
◎ Evolução da Entrega Contínua;
◎ A cada commit uma nova versão gerada e
deployada;
◎ É exigido um nível extremamente alto de
maturidade.

18
DevOps
◎ Pilares DevOps:
○ Pessoas
○ Processos
○ Ferramentas
○ Culture
◎ DevOps Three Ways
○ First Way: Work always flows in one direction –
downstream
○ Second Way: Create, shorten and amplify feedback
loops
○ Third Way: Continued experimentation, in order to
learn from mistakes, and achieve mastery
○ 19
Arquitetura de
Referência
◎ Conceitos comprovados na prática onde a
maioria das arquiteturas precedentes é
extraída desses conceitos;
◎ Transformada em orientação para várias
organizações que evoluem ou criam novas
arquiteturas;
◎ O valor está em ambientes com alta
multiplicidade, criando complexidade
social, organizacional, de aplicação e
técnica.
20
3.
Desenvolvimento
da Proposta

21
Modelo Físico Financeiro

ge Stage
a na
M

Push Stage
Commit
it l rts
s
Com

og
mm po

s
o rt gs
Co to-re

p o
mu

- re st l Stage
to /Te
nic

Au

u
A ild
a

Bu
te

ATM/PROD
Auto-reports
deployment logs 22
 Modelo Físico Telecom

ge Stage
a na
M
y
e plo
D

GitLab CI
Push Stage
Commit
it l rts

De
s
Com

pl
og
mm po

s
o rt gs oy
Co to-re

p o
mu

- re st l Stage
to /Te
nic

Au

u
A ild
a

Bu
te

User
Auto-reports Device/PROD
deployment logs 23
Modelos de ARD
◎ DRA Conceptual Model
◎ DRA Logical Model
◎ DRA Physical Model

24
ARD Conceptual Model
Human Factor
and Cultural

Communication Manage

Collaboration DevOPs Monitoring

Sharing QA/Testing

Integration Planning

Automation

25
ARD Conceptual Model
Platform as a
Infrastructure as a
Service
Service

Monitoring and
Logging

Communication
Plataform Database as a
Service

Infrastructure as
Security and code
Privacy

Availability and Load

balancing
26
ARD - Modelo Conceitual

DevOPs
Conceptual
Model

Design
CI
Plan Test Broker Deploy Stage Deliver

Synchronize
Build Deploy

Platform
Conceptual
Model
27
 ARD - Modelo Lógico
M5: Base de
Dados

● Gerenciamento Exchange
Cloud DB. User
● NoSQL DB Device
● SQL DB
e
ag ● Shared
an Resources
M

Stage
M1: Repositório M2: Orquestrador M3: Plataforma CD

Synchronize Push Deploy ● Escalabilidade

● Sincronização ● Build
● Implantação
de Código automático
● Orquestração de
DevOps Team ● Push automático ● Teste
VM’s
● Relatório de logs automático
● Ambiente de
automáticos ● Pipeline script
Staging

Monitor Commit Logs gs

Lo
Com e st nt
T loyme
Col muni il d/
or Dep
lab cat u Monit Logs
ora e orB
te Gerenciamento nit
Mo
●
de Relatórios
● Integração com
ferramentas de
Comunicação
● Notificações
Automáticas

M4: Monitoramento
e Comunicação

28
ARD - Modelo Lógico
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 de → Bare Metal
Pacote
→ Instâncias na
Nuvem
→ Ambiente de Staging
ARD - Modelo Lógico

Modelo ARD Modelo Lógico

Atividades Ferramentas

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
 ARD - Modelo Físico

ge Stage
a na
M
y
e plo
D

Push Deploy Stage

Commit
it l rts

De
s
Com

pl
og
mm po

s
o rt gs oy
Co to-re

p o
mu

- re st l Stage
to /Te
nic

Au

u
A ild
a

Bu
te

User
Auto-reports Device/PROD
deployment logs 31
ARD - Modelo Físico
Modelo ARD Modelo Lógico

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 na Phabricator
nuvem e integrar Slack
notificação.

Orquestrador Configurar scripts de Jenkins

CI/CD e integrar com Slack
plugin de notificação.
 ARD - Modelo Físico
Modelo ARD Modelo Lógico

Atividades Ferramentas

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 se ELK
conectar as ferramentas
do pipeline.
Validação das Hipóteses
HP01 - Todos os pipelines CI/CD mapeados
durante a pesquisa seguem um mesmo
workflow
HP02 - Nos dois projetos que compõem essa
pesquisa, houveram ferramentas adotadas,
mas não utilizadas, gerando um budget extra.
HP03 - Foram feitos testes cronometrado entre
o provisionamento de uma infra CI/CD manual
e utilizando IaC.
34
3.
Conclusão

35
Conlusão
◎ Adoção de infraestrutura CI/CD DevOps está
cada vez mais presente em para que a
indústria de software tenha a capacidade de
acompanhar a crescente demanda do
mercado;
◎ Adotar um conjunto de ferramentas DevOps
não garante a qualidade de entrega;
◎ Constatado na presente pesquisa que o
paradigma DevOps como agente de
transformação em projetos ágeis.
36
Contribuições
◎ A pesquisa proporcionou um panorama
geral sobre arquiteturas de referência para
infraestrutura DevOps em consonância com
os métodos de adoção;
◎ 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.

37
Limitações e Trabalhos
Futuros
◎ Quantidade maior de projetos;
◎
◎ Uma possibilidade de trabalho futuro seira
vantagens ou problemáticas em adotar
ferramentas open-source em uma
infra-DevOps;

38
Obrigado.

39