Bem vindos. Hoje a gente vai mergulhar um
pouco no universo do DevOps. A nossa conversa vai ser guiada
pelo material do livro engenharia de software moderno.
A ideia aqui é, Hum, entender melhor o que é DevOps.
Sabe por que surgiu? Quais são as bases disso tudo?
No fundo, é sobre como a gente quebra aquele muro, né, que
sempre existiu entre criar o software.
E fazer ele rodar lá no mundo real, certo?
Pra começar, acho bom a gente na raiz do problema, né?
Historicamente, nas empresas de tecnologia, tinha aquela divisão
bem clara. Um time desenvolvia o software.
O pessoal de deve, né? Isso o deve e outro time, o de
operações ou Office era quem botava para funcionar e mantinha
no ar, e assim a comunicação entre eles muitas vezes era
quase zero. Não é?
E olha, essa falta de conversa trazia umas consequências bem
sérias, imagina só o pessoal de operações, o cisa de mins
recebendo um sistema totalmente novo assim na véspera de ir pro
ar? Nossa devia ser um caos.
Era o resultado, atraso em cima de atraso, problema de hardware
que ninguém previu, performance lá embaixo, um Monte de brecha
de segurança, incompatibilidade com ambiente de produção.
Com aqueles sistemas monolíticos enormes de antigamente, então,
nossa era um pesadelo. Podia até inviabilizar um
projeto inteiro, sabe? Os requisitos não funcionais,
tipo aguentar milhares de usuários ou resistir a ataques.
O pessoal de Office descobria que não dava ponta quando já era
tarde demais. Faz todo sentido.
E aí, nesse cenário de atrito, todo que o DevOps entra como
uma? Resposta, né?
É mais que ferramenta, é uma cultura mesmo.
Para juntar deve e Ops. A meta tem mais agilidade, mais
velocidade para entregar o software.
Isso. Tem até uma citação legal no
livro do Kim ramble, The Boys e Willis, que diz que o objetivo é
permitir que a organização como um todo tenha sucesso.
Quer dizer, a ideia é fazer a implantação parar de ser aquele
evento traumático. Chega daquelas sextas à noite,
virando o fim de semana inteiro, né?
Exato, chega disso. A implantação tem que ser algo
bom, rotineiro. Quase banal.
Isso quase banal. E o que é fascinante aqui é
justamente essa virada de chave cultural, sair daquele silo.
Sabe? Cada time no seu quadrado sem se
falar? Lembra das figuras no livro que
mostram isso, o antes e o depois?
Lembro sim. A figura 10.1 e 10.2, né?
Exatamente. A ideia é ir para uma
colaboração contínua desde o comecinho do projeto.
Na prática, isso significa o quê?
Significa ter gente de operações participando dos times agens
desde o início. Ah, interessante.
Eles trazem a visão do ambiente de produção lá para frente,
ajudam a prever gargalo de desempenho, problema de
segurança. E já vão tipo preparando os
scripts para automatizar a implantação, o monitoramento
enquanto o código ainda está sendo feito.
E essa colaboração toda, ela se apoia muito no outro Pilar, que
é onde o negócio fica realmente interessante, que é a automação,
né? Fundamental.
A ideia central do DevOps, automatizar tudo que der no
caminho do código até o usuário compilar o código rodatestes,
configurar servidor, atualizar banco de dados.
Tudo isso conecta direto com práticas como integração
contínua, né? Que é aquilo de juntar e testar
o código de todo mundo o tempo todo.
Várias vezes ao dia, se possível.
Isso para evitar aquele caos de integrar tução no finalzão e
também o diploma emite contínuo. Aí tem aquele detalhe histórico,
né? O termo DevOps começou a pegar
força lá por 2008 2009. Sim, por aí.
Muito por causa dessa frustração, mesmo desse conflito
deve, Ops. E a primeira conferência DevOps
days, que foi o Marco, rolou na Bélgica em 2009, organizada pelo
Patrick dubois. Exato.
E para fazer isso tudo funciona bem, o jazz, Rambo e o David
Farley definiram os princípios chave para entrega de software
que casam perfeitamente com o DevOps.
O primeiro é. Criar um processo que seja
repetível e confiável. O sonho de consumo é
implantação. Ser tão simples e segura quanto
apertar um botão, sabe? E.
Imagino que para chegar nesse apertar de botão, a automação
seja essencial, certo? Com certeza é o segundo
princípio, automatizar tudo que for humanamente possível.
Build, teste, configuração. Quanto menos gente mexendo
manualmente, menor a chance de erro e mais rápido fica.
Ok. Terceiro.
Manter tudo sob controle de versões e aí não é só o código,
tá? Script de automação,
documentação, arquivo de configuração, tudo tem que estar
versionado. Git é o mais popular hoje, né?
Isso é vital para rastrear o que mudou e, se der ruim, voltar
para uma versão anterior rapidinho, entendi.
Aí tem outro princípio que parece meio estranho no começo,
se alguma coisa dói, faça mais vezes.
E traga essa dor pra mais perto pra resolver logo.
Como assim? O exemplo clássico é integrar
código. Se juntar o trabalho de todo
mundo uma vez por mês é um parto cheio de conflito, então integre
várias vezes por dia. Isso força a resolver os
probleminhas na. Hora isso.
Outra coisa, a definição de concluído tem que ser séria,
software só tá pronto quando tá 100% pronto pra ir pra produção.
Testado, validado, sem essa de tá pronto, mas falta só.
Sem Pendências. Nenhuma.
E por último, que amarra tudo. Todos são responsáveis pela
entrega. Não é só culpa do deve se o
código quebrar em produção, nem só do Office.
Se o servidor cair, a responsabilidade é de todo mundo
e isso reforça a colaboração. Então, pra gente fechar a nossa
conversa, DevOps é essa mudança profunda na forma de trabalhar.
É quebrar as Barreiras entre desenvolvimento e operações.
Exato. E como se faz isso?
Com muita colaboração e, claro, muita automação.
E porque isso é importante? Porque, no final das contas,
resulta em software chegando mais rápido pro usuário, com
mais frequência e o principal com mais confiança, né?
Tanto pro usuário quanto pro negócio.
Muito obrigada por nos acompanhar nesta análise até o
próximo episódio.