DevOps Professional

Módulo 3 - A primeira maneira - Fluxo

A primeira maneira: Fluxo 3
O que é pipeline de implantação? 3
Benefícios do pipeline de implantação 3
Etapas do pipeline (funil) 3
Pipeline de implantação (deployment pipeline) 4
Feedback rápido 5
Pipeline de implantação (deployment pipeline) 6
Infraestrutura como código (infrastructure as code) 6
Situações problema 6
Recursos para automatizar a infraestrutura 7
Infraestrutura como código 8
Benefícios da infraestrutura self-service 8
Repositório único de gerenciamento de versão 9
O papel do repositório centralizado 10
Adaptar a definição de Pronto (DoD) 10
Por que otimizar o fluxo de valor? 11
Otimizar o fluxo de valor 12
Resumindo 13
Testes automatizados 13
Adicionando testes automatizados ao pipeline 14
Testes automatizados precisam ser rápidos 14
Pirâmide ideal de testes 15
Mantendo a execução rápida 15
Desenvolvimento orientado a teste (test driven development) 16
Linhas de Desenvolvimento 17
Integração (merges) de códigos 17
Estratégias de Ramificação (branching) 18
Desenvolvimento baseado no tronco (trunk) 19
Ajustando a definição de pronto 19
A influência do débitos técnico 19
Como resolver débitos técnicos? 20
Bliz de melhoria (improvement / kaizen blitz) 21
Lançamento (release) tradicional 21
Implantação vs Liberação (Deployment vs Release) 21
Implantação (deployment) 22
Liberação (Release) 22
Padrões de Lançamento (release) 23
Implantação azul-verde (blue-green deployments) 23
Lidando com mudanças na base de dados 24
Liberações Canarias (canary releases) 24
Padrões de Liberação baseado em aplicativos 25
Arquitetura de Software 26
Arquitetura monolítica (fortemente acoplada) 27
Arquitetura micro serviços (fracamente acoplada) 27
Escalabilidade 28
Monolítico x Microserviços (monolithic x microservices) 28
Qual a arquitetura certa? 29
A primeira maneira: Fluxo
O que é pipeline de implantação?
● Em um nível abstrato, um pipeline de implantação é uma manifestação automatizada
de seu processo para levar o software do controle de versão para as mãos de seus
usuários
● Em outras palavras: são todas as etapas do seu processo realizadas de forma
automatizada para levar o código para até a produção
● O principal objetivo do pipeline de implantação é fornecer para todos no fluxo de
valor um feedback rápido sobre a mudanças e se elas tiraram o software de um
estado implantável, permitindo assim a correção imediata do problema

Benefícios do pipeline de implantação

● Reduz o tempo de espera para que desenvolvedores tenham acesso a ambientes
semelhantes ao de produção
● Permite testes contínuos que dão a todos feedback rápidos sobre o seu trabalho
● Permite que pequenas equipes desenvolvam, testem e implementem com
segurança e autonomia
● Permite que sejam feitas implantações em produção como parte rotineira do trabalho
diário

Etapas do pipeline (funil)

Exemplo
Pipeline de implantação (deployment pipeline)

● Primeiros estágios são mais rápidos para dar feedback mas a confiança de entrar
em produção é menor
● Últimos estágios tem o feedback mais lento porém a confiança é maior
Feedback rápido
Finalmente, é importante lembrar que o objetivo de tudo isso é obter feedback o mais rápido
possível
Pipeline de implantação (deployment pipeline)
Não existe o pipeline “padrão”. Tipicamente ele incluirá os estágios de:
● Automação de build e integração contínua
● Automação de testes
● Automação da implantação
Necessidade básica para um pipeline
1. Fluxo de valor mapeado
2. Orquestração de release e pipeline (continuous integration)
3. Infraestrutura como código (automatizada e self-service)
4. Testes automatizados (unidade, integração, funcionais)

Infraestrutura como código (infrastructure as code)

Situações problema
● Ao solicitar um ambiente de teste para operações, demora-se de ter o ambiente
● Quando recebe, o ambiente de teste é diferente do ambiente de produção
● Sem o teste acontecendo em um ambiente semelhante da produção, possibilidade
de erro é muito grande
O que precisamos fazer
● Garantir o uso de ambientes semelhantes ao de produção (production-like) em todos
os estágios do fluxo de valor (para todos os ambientes)
● Esse ambiente deve ser criado de maneira automatizada, idealmente sob demanda,
a partir de scripts e informações de configuração armazenadas no controle de
versão, inclusive para o ambiente de produção
● Deve ser preferencialmente no formato de autoatendimento (self-service), sem
qualquer trabalho manual exigido de Operações
● O objetivo é garantir que seja possível recriar todo o ambiente de produção com
base no que está no controle de versão

Recursos para automatizar a infraestrutura

Em vez de as Operações criarem e configurar manualmente o ambiente, podemos usar a
automação para qualquer um ou todos os itens a seguir:
Infraestrutura como código
● A infraestrutura como código faz com que reconstruir o ambiente seja tão fácil
quanto repará-lo
● Ambientes em larga escala trabalham desta forma, deixando de gerenciar servidores
e passando a gerenciar a infraestrutura como um todo
● Benefícios
○ Conseguimos ter um ambiente elástico
○ Método consistente de disaster-recovery
○ Infraestrutura imutável (componentes são substituídos, em vez de serem
alterados)
○ Ambientes de DeV, Homolog e Produção idênticos (ou ao menos
semelhantes ao ambiente de produção)
○ Tudo armazenado no sistema de versionamento
○ Mudanças automaticamente replicáveis

Benefícios da infraestrutura self-service

● Usamos o know-how da organização para criar ambientes estáveis, seguros,
consistentes e confiáveis
● Criação rápida de ambientes
● Evitamos erro humano
● Desenvolvedores validam seu código mais cedo, evitando que erros cheguem à
produção
Repositório único de gerenciamento de versão

● O objetivo é possibilitar a reprodução de forma repetida e confiável de todos os

componentes do sistema de software - isso inclui aplicativos e ambientes de
produção
● Benefícios de um repositório único
○ Restaurar o serviço de produção repetidamente e de forma previsível (e,
idealmente de modo rápido) mesmo quando ocorrerem eventos catastróficos
○ Permite ver rapidamente toda as mudanças que podem ter contribuído para
um problema
○ Fornece meios para reverter para um estado de execução anterior conhecido
(rollback), permitindo recuperar-se mais rapidamente de falhas
● Para garantir a restauração do serviço de produção repetidamente, de forma
previsível e rapidamente, os seguintes recursos devem ser versionados:
O papel do repositório centralizado

Adaptar a definição de Pronto (DoD)

● O objetivo é garantir que Desenvolvimento e QA estejam rotineiramente integrando o
código com ambiente semelhantes ao de produção em intervalos cada vez mais
frequentes
● Isso é feito expandindo a definição de “pronto” para além da entrega de código
correto
● DoD “Padrão”
○ No final de cada intervalo de desenvolviment, temos código integrado,
testado, funcional e potencialmente utilizável
● DoD estendida
○ No final de cada intervalo de desenvolvimento, temos código integrado,
testado, funcional e potencialmente utilizável demonstrado em um ambiente
semelhante ao de produção
● Com o domínio compartilhado de como o código e o ambiente interagem, são
reduzidos significativamente os riscos de implantação
Por que otimizar o fluxo de valor?
Otimizar o fluxo de valor
Resumindo
● Reduza o lead time para obter ambientes semelhantes ao de produção
● Permita testes contínuos que dêem a todos feedback rápido sobre o trabalho
● Permita que pequenas equipes desenvolva, testem e implemente com segurança e
independentemente seu código em produção
● Faça de implantações frequentes uma parte rotineira do trabalho diário

Testes automatizados
Automação de testes é parte primordial de uma iniciativa DevOps
● Testes não podem ser realizados como uma fase executada por um departmaneot
de QA separado e somente após todo o desenvolvimento ter sido concluído
○ Feedback lento
○ Aprendizado lento
○ Capacidade de aprender com o erro é significamente diminuída
● “Sem testes automatizados, quanto mais código escrevemos, mais tempo e dinheiro
são necessários para testar nosso código - na maioria dos casos, esse é um modelo
de negócio totalmente não escalável para qualquer organização de tecnologia” -
Gary Gruver
Adicionando testes automatizados ao pipeline
● Testes automatizados aumenta a frequência de integração e de teste do código e de
ambientes, de periódico para contínuo
● Testes automatizados são parte fundamental para permitir que possa haver vários
deploys ao longo de um mesmo dia
● Isso é feito construindo o pipeline de implantação, que realizará a integração do
código e dos ambientes e acionar uma série de testes toda vez que uma nova
alteração for colocada no controle de versão

Testes automatizados precisam ser rápidos

Pirâmide ideal de testes

Mantendo a execução rápida

Desenvolvimento orientado a teste (test driven development)
● Uma das maneiras mais eficazes de garantir que haja testes automatizados
confiáveis é escrever esses testes como parte de trabalho diário, usando técnicas
como o desenvolvimento orientado a testes (test driven development -TDD)
1. Escrever um teste, veja falhar
2. Escreva só o código suficiente para passar no teste
3. Melhore o código sem alterar seu comportamento
Linhas de Desenvolvimento
● Times de desenvolvimento são acostumados a trabalharem com branches
(ramificações) para organizarem seus desenvolvimentos
○ Trunk / Master / Main é a branche principal
○ Branch é a cópia do trunk criado para fazer mudanças no código
○ Tag é um marcador de um estado do código em um determinado momento.
É um ponto no tempo do trunk ou em um branch que você deseja preservar,
podendo recuperar.

Integração (merges) de códigos

● Quanto mais tempo os desenvolvedores puderem trabalhar em seus branchs
isoladamente, mais difícil será integrar e fazer o merge das alterações no tronco
(turnk)
● De fato, integrar essas mudanças se torna exponencialmente mais dificil à medida
que aumentamos o número de ramificações e o número de alterações em cada
ramificação de código (especialmente se não houver integração contínua)
Estratégias de Ramificação (branching)
Embora existam muitas estratégias de ramificação, todas elas podem ser colocadas no
seguinte espectro. Obs: Quanto mais branches existirem mais trabalho para o merge
● Otimizado para produtividade individual
● Otimizado para a produtividade do Time
○ Exige um time mais maduro
Desenvolvimento baseado no tronco (trunk)

Ajustando a definição de pronto

A influência do débitos técnico

Como resolver débitos técnicos?
Débito técnico influencia a efetividade dos codificadores
● Bugs
● Código não integrado
● Soluções “alternativas””
● Aquele jeitinho no ambiente
● Código não testado
● Solução paliativa
● Código mal escrito
● Ambiente não adequados

Algumas práticas podem ajudar a resolver débito técnicos, tais como:

● Integração Contínua
● Desenvolvimento baseado no tronco
● Investimento em automação de testes (Ver pirâmide de teste)
● Uso da infraestrutura como código e self-service
● Reprodução de erros nas estações de trabalho
● “One Piece Flow”
Também pode ser benéfico reservar tempo para melhorar o trabalho diário
● Kaizen: Blitz de melhoria (Improvement Blitz ou kaizen blitz)
○ Um grupo é reunido para se concentrar intensamente em um processo com
problemas
○ A blitz pode durar alguns dias. seu objetivo é melhorar o processo, resolver
um problema ou débito técnico
Bliz de melhoria (improvement / kaizen blitz)

Lançamento (release) tradicional

● Tradicionalmente liberações são conduzidas pelo marketing, especialmente no que
tange à estratégia de datas
● A questão é que nem sempre as coisas dão certo como planejado. Pode Acontecer:
○ Carga de dados acima da que era esperada
○ Dificuldade de acesso
○ Dificuldade de Operação por parte dos usuários
○ Dificuldade em fazer rollback
○ Paradas em produção
○ Entre tantas outras coisa

Implantação vs Liberação (Deployment vs Release)

● Sabemos que precisamos implantar com mais frequência para alvançar o resultado
desejado de fluxo suave e rápido e não com menos frequeência (redução de risco)
● O segredo está em separar reease (liberação) de deployment (implantação)

Implantação (deployment)
● É a instalação de uma versão do software um determinado ambiente (por exemplo,
implantação em um ambiente de teste ou implantação na produção)
 ● Especificamente, uma implantação pode ou não está associada a uma liberação de
um recurso para os clientes

Liberação (Release)
● A liberação ocorre quando disponibilizamo um recurso (ou conjunto de recursos) a
todos os nossos clientes ou a um segmento de clientes (por exemplo, permitimos
que o recurso seja usado por 5% da nossa base de clientes)
Padrões de Lançamento (release)
Existem duas grandes categorias de padrões de lançamento que podem usar:
● Padrões de liberação baseado em ambiente (Environment-based release patterns)
● Padrões de liberação baseado em aplicativos (application-based release patterns)

Implantação azul-verde (blue-green deployments)

● O mais simples dos dois padrões é chamado de implantação azul-verde (blue-
green). Nesse padrão, temos dois ambientes de produção:Azul e Verde
● A qualquer momento, apenas um deles está atendendo ao tráfego do cliente.
● Os usuários estão usando o Azul e a atualização está sendo feita no Verde
● Depois de estar tudo OK com a Verde, muda todos os usuários para a Verde.
Lidando com mudanças na base de dados
● Usando o Blue-Green, podemos ter um problema de banco de dados se for
necessário fazer um rollback, ou seja, voltar para o servidor azul com a versão
estável, mas o servidor verde já foi usado por um período

Liberações Canarias (canary releases)

● É uma variação do padrão azul-verde que melhora a segurança e reduz o lead time.
No entanto, traz alguma complexidade adicional
● Neste padrão, quando realizamos um lançamento, monitoramos o desempenho do
software em cada ambiente. Quando algo parece estar errado, nós retrocedemos;
caso contrário, implantamos no próximo ambiente.
Padrões de Liberação baseado em aplicativos
São padrões desenvolvidos no aplicativo (software), permitindo uma flexibilidade ainda
maior na forma como são liberados novos recursos como segurança para os usuários
● Implementar alternância de funcionalidades (feature toggles)
● Lançamentos escuros (Perform Dark Launches)
Arquitetura de Software
Com frequência, profissionais DevOps trabalham dentro de diversos tipos de arquitetura,
algumas menos acopladas outras nem tanto, tendo algumas sido criadas há anos (ou
décadas) atrás.
● Arquitetura fortemente acoplada (tightly-coupled architecture)
● Arquitetura fracamente acoplada (loosely-coupled architecture)
Arquitetura monolítica (fortemente acoplada)

Arquitetura micro serviços (fracamente acoplada)

Escalabilidade

Monolítico x Microserviços (monolithic x microservices)

Qual a arquitetura certa?