DevOps Professional

Módulo 1 - Introdução ao DevOps

Introdução ao DevOps 2
Infraestrutura Ágil / Infra como Código (Agile infrastructure) 2
Ferramentas de Infrastructure as code 2
Diferença entre Manual x Infra As Code 2
Controle de Versões 3
Entrega Contínua (Continuous Delivery) 3
O problema da Integração e a Integração Contínua 4
A solução é a Integração Contínua 5
Débito Técnico (Technical Debt) 5
Desenvolvimento (Dev) 5
A Integração e Teste de Código 5
Processo Manual 6
Integração contínua (CI) 6
Entrega Contínua (CD) 7
Utilizando a Entrega Contínua 7
A Entrega Contínua 8
Você está fazendo entrega contínua quando: 8
Para conseguir uma entrega contínua 8
Implantação contínua 9
Pipeline de Implantação (Deployment PIpeline) 9
Integração, Entrega e Implantação contínua (Diferença Geral) 10
Débito Técnico é tudo aquilo que reduz a velocidade do time e que aumenta o TCO
10
Introdução ao DevOps
Peso no exame: 2,5%

Infraestrutura Ágil / Infra como Código (Agile infrastructure)

● Infraestrutura ágil é basicamente aplicar princípios ágeis à infraestrutura
● Um dos pontos centrais deste movimento é tratar sua infraestrutura como código
(Infrastructure as code)
● É possível gerenciar e provisionar ambiente automaticamente por meio de código,
ao invés usar um processo manual

Ferramentas de Infrastructure as code

● Ansible
● Terraform
● Puppet
● Chef
● Saltstack
● Jenkins
● Docker
● Vagrant

Diferença entre Manual x Infra As Code

Controle de Versões
Tratar a infraestrutura no código permite que ambientes sejam criados a partir de um
repositório de código-fonte, um backup de dados e, claro, um servidor físico disponível
(“bare metal”)
● Tudo o que é necessário para gerar o software e ambiente estão no controle de
versão
● Ferramentas para Orquestração (Ansible, Terraform, etc) usam o código do controle
de versão para criar a infraestrutura em minutos ou até segundos

Para isso:
● Trabalhe com Infraestrutura como código
● Use Técnicas de virtualização (criação virtual de hardware, sistemas operacionais,
espaços de armazenamento ou recursos de rede)
● Use a nuvem (pública ou privada)

Entrega Contínua (Continuous Delivery)

“Software não entregue ao cliente é inútil. A melhor funcionalidade não
serve para nada se não estiver em uso pelo cliente”
● A entrega contínua existe para que as funcionalidades sejam liberadas
continuamente e de forma segura para o cliente
● A entrega contínua é uma disciplina de desenvolvimento de software na qual você
cria software de maneira que ele possa ser liberado para produção a qualquer
momento
Entrega contínua estende o conceito de integração contínua
Implantação contínua estende o conceito de entrega contínua
 ● Entregação contínua
● Entrega Continua
● Implantação Contrínua
○ São Operacionalizada / Orquestrada
■ Pipeline de Implantação

O problema da Integração e a Integração Contínua

● No controle de versionamento existe o Trunk, também conhecido com Master
● Branch são criadas a partir do Trunk
● Tanto o Trunk como as Branches evoluem por eles mesmo
● A branch devem ser integradas com o Trunk
● Quanto mais tempo a Branch passa sem o Merge/Integração com a Trunk, mais
problemas e mais chances de bugs entrarem em produção
A solução é a Integração Contínua
● A integração contínua, ou CI, é uma estratégia de fluxo de trabalho que ajuda a
garantir que as alterações de todos se integrem à versão atual do projeto
● Isso permite identificar erros, reduzir conflitos de merge e ter certeza de que seu
software está funcionando
● Na maioria dos cenários, uma equipe praticará o CI em conjunto com testes
automatizados
O Problema da Integração e a Integração Contínua

Débito Técnico (Technical Debt)

Desenvolvimento (Dev)
● A equipe de desenvolvimento é responsável por identificar e entender problemas de
negócio e desenvolver soluções, entregando com máxima qualidade e produtividade
as versões de software que deve ser colocadas em produção
● É composta normalmente por profissionais que desenvolvem as aplicações como
programadores, analistas de sistema, arquitetos de software, analistas de testes,
entre outros

A Integração e Teste de Código

A integração de código produzido por desenvolvedores sempre foi uma parte importante do
processo de desenvolvimento. Sem integração contínua, tudo é feito manualmente
Processo Manual
● Desenvolvedores fazem os commits no projeto
● Um Gestor ou Líder Técnico compila o software/monta o build
● Disponibiliza o Build
● Isso pode ser feito 1 vez por semana
● Leva tempo e necessita da disponibilidade de alguém para que o build seja gerado,
validado e disponibilizado

Integração contínua (CI)

● Pode ser utilizado Jenkins, GitLab (CI), GitHub (CI) entre outros
● Servidor de integração contínua é um software
● Ele fica monitorando os commits no projeto
● Quando houver commits o CI executa um script programado por vocês para fazer
teste, validar, gera relatório e disponibilizar o build do projeto para ser colocado em
produção
● Esse processo se repete a cada commit
● A configuração feita por você determina quantas vezes o build é gerado, a branch
que o build é executado e outras configurações possíveis
Entrega Contínua (CD)
● A integração contínua concentra-se principalmente nos times desenvolvedores
● A saída do sistema de CI normalmente forma a entrada para o processo de teste
manual e daí para o restante do processo de liberação
● Este processo manual resulta em um software que não pode ser implantado
rapidamente (Tempo de feedback entre a equipe de desenvolvimento e de teste é
longa por exemplo)
● A solução é adotada uma abordagem mais holística, de ponta a ponta, para entregar
software, ou seja, adota a Entrega Contínua (Continuous Delivery ou CD)

Utilizando a Entrega Contínua

● Feito a integração contínua (CI)
● Build Gerado através do CI
● Efetua deploy automatizado em ambiente de teste
● Efetua Testes Funcionais Automatizados
● Efetua testes Exploratórios
● Efetua deploy automatizado em ambiente de homologação
● Efetua teste de Aceitação
● Efetua Deploy Automatizado em ambiente de Produção
A Entrega Contínua
● A entrega contínua estende a integração contínua
● Além de automatizar seus testes, também é necessário automatizar o processo
de implantação, possibilitando a implantação com um simples cliques em um botão
● A entrega contínua garante que tanto o código (software) como a infraestrutura (“as
code”) estejam em um estado implantável a qualquer tempo no processo de
desenvolvimento e implantação

Você está fazendo entrega contínua quando:

● Seu software é implantável em todo o seu ciclo de vida
● Sua equipe prioriza manter o software em estado “implantável” em vez de trabalhar
em novos recursos
● Qualquer pessoa pode obter feedback rápido e automatizado sobre a prontidão de
produção de seus sistemas sempre que alguém fizer uma alteração
● Você pode realizar implantações de qualquer versão do software em qualquer
ambiente, sob demanda, com o simples apertar de um botão

Para conseguir uma entrega contínua

Você precisa:
● Um relacionamento ŕoximo e colaborativo entre todos os envolvidos na entrega
(desenvolvedor uma cultura DevOps)
● Automação extensiva de todas as partes possíveis do processo de entrega,
geralmente usando um pipeline de implantação
● Os principais benefícios da entrega contínua são:
 ○ Menor risco de implantação
○ Progresso confiável
○ Feedback do usuário

Implantação contínua
● A Entrega Contínua às vezes é confundida com a Implantação Contínua
● Implantação contínua significa que todas as alterações passam pelo pipeline de
implantação (Deployment Pipeline) e são automaticamente colocadas em produção,
resultantes em muitas implantações de produção todos os dias.
○ Sem necessidade de aprovação por exemplo
○ Ou seja, é feita a implantação sem necessidade de ação nenhuma de
alguém
○ A confiança deve estar muita alta no sistema e no ambiente
○ Geralmente é uma questão de cultura da empresa
● Entrega Contínua significa apenas que você é capaz de realizar implantações
frequentes, mas pode optar por não fazê-lo, geralmente devido a empresa que
preferem uma taxa mais lenta de implantação
● Para fazer a Implantação Contínua, você deve estar fazendo a Entrega Contínua

Pipeline de Implantação (Deployment PIpeline)

Em um nível abstrato, um pipeline de implantação é um manifestação automatizada de seu
processo levar o software do controle de versão para as mãos de seus usuários

● Normalmente, o primeiro estágio de um pipeline de implantação fará qualquer

compilaçao e fornecerá binários para as etapas posteriores
● As etapas posteriores podem incluir verificações manuais, como quaisquer testes
que não possa ser automatizados
● Etapas podem ser automáticas, ou exigirem autorização humana para prosseguir,
elas podem ser paralelizadas em muitas máquinas para acelerar a execução
● A implantação na produção é geralmente o estágio final de um pipeline
Integração, Entrega e Implantação contínua (Diferença Geral)

● Integração Contínua chega até a fase do Build, ou seja, empacotamento do software

● Já a Entrega Contínua vai além, temos stages de testes e após uma aprovação
manual, o deploy para a produção
● A Implantação Contínua é igual à entrega contínua, porém, o Deploy para a
produção é feita de forma automática, ou seja, sem necessidade de uma aprovação
Débito Técnico
● O custo implícito de retrabalho adicional causado pela escolha de uma solução fácil
agora, em vez de usar uma abordagem melhor que levaria mais tempo
○ É a famosa "Gambiarra", paliativo definitivo, etc
● O débito técnico descreve como as decisões que tomamos levam a problemas que
se tornam cada vez mais difíceis de consertar com o tempo, reduzindo
continuamente nossas opções disponíveis no futuro

Débito Técnico é tudo aquilo que reduz a velocidade do time e que

aumenta o TCO
● Erros no sistema, ausência de testes automatizados, alta complexidade do código,
ausência de teste unitário, arquitetura ruim, ausência de padrões de design e código,
entre outros
● É indispensável saber que Débito Técnico é algo inevitável, sempre vai existir algum
débito técnico, o importante é trabalhar para evitá-los o máximo possível, ou seja, o
Débito Técnico deve ser em baixo nível. E se não for pago, o Débito tente a
aumentar com o tempo
Entre o Custo Real da Mudança muito Caro e um Custo “Ótimo” da mudança, está o Débito
Técnico

Mais conhecido pela sigla em inglês TCO (Total Cost of Ownership), o Custo Total de
Propriedade representa uma análise de todos os custos envolvidos na aquisição de um
serviço ou ferramenta. É o custo de manutenção para que algum sistema ou recurso
continue funcionando adequadamente dentro da empresa.

Débito Técnico é causado por

● Definição Inicial Insuficiente
● Pressões do Negócio (Talvez um dos principais motivos)
● Ausência de processo ou compreensão
● Componentes fortemente acoplado
● Ausência de testes
● Ausência de documentação
● Ausência de colaboração (Silos Organizacionais)
● Desenvolvimento Paralelo
● Ausência de Refatoração Sistemática
Mini Simulado Final

Fim do Módulo