O documento apresenta a estrutura de times da empresa Geofusion e discute a abordagem #noOps para entrega contínua de software. A empresa possui um Delivery Engineering Team responsável por fornecer infraestrutura como código para permitir que outros times implementem e executem o código de forma autônoma através de ferramentas como Docker e Kubernetes. A abordagem #noOps visa eliminar gargalos e permitir que cada time tenha autonomia na escolha e gestão de suas próprias instâncias.
3. Quem Somos?
Wagner Hitomi
• Primeiro programa aos 16
• Trabalha na Geofusion desde 2015
• Delivery Engineer
• Empreendedor quando da tempo
• Quase casando! o/
Evandro Silvestre
• Primeiro código aos 15 anos, agilista desde 2003
• Trabalha na Geofusion há 8 anos
• Responsável pela Engenharia e Infraestrutura
• Gamer nas horas vagas
• Futuro pai de primeira viagem :)
4. E a Geofusion?
“Somos uma empresa de Location
Analytics, que facilita a tomada de
decisões por meio de tecnologia e
dados de mercado”
5. Nossa Estrutura de Times
GP
UX
LT
Dev
QA
GP
UX
LT
Dev
QA
GP
UX
LT
Dev
QA
GP
UX
LT
Dev
QA
GP
LT
Dev
Vamos falar desse time!
O Delivery Engineering Team
9. DevOps se Deriva do padrão The Three Ways
• Conceito apresentado em The Phoenix Project
• Fortemente baseado em:
○ Lean
○ Improvement Kata
○ Continuous Delivery
○ Teoria das Restrições
• Descreve o valor e a filosofia que guia processos e
práticas de DevOps
10. • Fluxo e feedback constante da esquerda para direita (Dev => Ops)
• Pequena quantidade de trabalho em intervalos curtos
• Entrega constante de valor para o cliente
• Só está pronto quanto está em produção
• Nunca passar problemas para frente
• Práticas necessárias:
○ Integração, Deploy e Entrega Contínua (Delivery Pipeline)
○ Devs e Ops em constante interação
The First Way
Dev Ops
11. The Second Way
Dev Ops
• Fluxo e feedback constante da direita para esquerda (Dev <= Ops)
• Permitir detecção de problemas rápido e aprender com eles
• Práticas necessárias:
○ Stop the Production Line (quando o build ou teste quebrar, tudo deve parar)
○ Bateria de testes automatizadas rápidas
○ O código sempre deve estar em estado “deployable”
○ Dor compartilhada entre Dev e Ops
○ Telemetria onde todos possam ver o que está acontecendo
nos ambientes
12. The Third Way
Dev Ops
• Criação de uma cultura que foca em dois pontos:
○ Experimentação e Aprendizado Contínuo
○ Repetição e prática são pré-requisitos para maestria
• Práticas necessárias:
○ Cultura de inovação e tolerante a erros
○ Alocar pelo menos 20% dos times em requisitos não funcionais
○ PDCA e Improvement Kata
○ Confiança!
16. Como fazemos?
Delivery Engineer Team
• Time multidisciplinar responsável por um conjunto de ferramentas de Entrega Contínua
• Nós pavimentamos o caminho para produção, permitindo os outros times seguirem por ele
• Orientamos e damos suporte aos times, mas não administramos ambientes e nem fazemos
deploy
20. #noOps?
• Ainda estamos descobrindo o que é isso, ok!?
• O modelo de DevOps atual tem o Delivery Engineer Team como gargalo
• Nosso objetivo é Infraestrutura Self Service
○ Através de uma ferramenta de Entrega Contínua cada time pode escolher como
rodar seu código (quantas máquinas? tamanho?)
• Source-to-Container => Container Imutáveis gerados diretamente pelo processo de
build
• Telemetria, logs, load balance, etc => Centralizados e Não invasivos
27. Infrastructure As Code
class new_host{
include firewall
include users
include docker-host
include default_folders
include consul_stack
include elk_stack
# mount_points
gfn::mounttab{ "/earth" :
device => "/dev/vg-app/lv-app",
owner => 'god',
group => 'universe',
checkDir => 'false',
options => "defaults"
}
}