grafico com a estrutura de DevOps

Tudo sobre DevOps — para iniciantes

Bom dia galera do mal, nerds e nerdas, estamos aqui outra vez.  Bem, como todos sabem, a escrita de artigos é igual à Marvel: quando uma saga termina, outra inicia. Dessa vez, vamos iniciar uma nova: a saga DevOps.

Aqui vamos desmistificar esse profissional tão procurado no mercado de hoje. Uma das coisas que se deve ter em mente: Esses poderes todos nós tivemos, porém, criaram um termo específico pra isso, assim como ferramentas adequadas.

Sem mais delongas, vamos lá (não esqueça de dar sua estrelinha no final do post, para que eu possa dar o ar de minha graça por mais e mais vezes :p).

>>Leitura Recomendada:
Pilares DevOps: a carreira do profissional de infraestrutura

Como o DevOps surgiu

pessoas conversando em uma mesa

O movimento DevOps não começou em apenas um local, existem muitos lugares que se relacionam às origens do termo. Por volta de 2008 começaram a utilizar o termo infraestrutura ágil em algumas listas de discussão com foco em desenvolvimento ágil.

O evento Agile 2008 abriu caminho para o DevOps, desviando as direções das metodologias de desenvolvimento de software modelo cascata e indo em direção a um ciclo continuo de desenvolvimento.

O termo DevOps foi criado durante a conferência Velocity da O’Reilly em 2009, onde John Allspaw (Etsy.com) e Paul Hammond (Typekit) o apresentaram, com o objetivo de unir desenvolvedores (Dev) e administradores da infra de TI (Ops), promovendo a integração contínua até a entrega.

Um dos participantes foi grande entusiasta do assunto. Ele é Patrick Debois, que após ter visto a palestra ficou muito animado, tendo a grande ideia de criar um encontro chamado DevOpsDay.

Essa ideia saiu do papel e teve seu primeiro encontro em Ghent – Bélgica, no final de 2009 e durou 2 dias. Foi a partir daí que o assunto começou a ser conhecido pelo mundo.

>>Leitura Recomendada:
O que é Desenvolvedor full cycle?

Mas afinal, quais são os conceitos do DevOps?

tres homens em reuniao

O DevOps se mantêm em quatro pilares principais, conhecidos pelas siglas C.A.M.S, são eles:

Cultura

As equipes precisam ter colaboração, mudança de comportamento, flexibilidade, troca de ideia, manter uma relação saudável entre as áreas e, principalmente, trabalharem juntos, evitando responsabilidades centralizadas e incentivando a criação de equipes multidisciplinares.

Automação

Algumas ferramentas entram em cena para automatizar o maior número de processos, sendo eles: automação para liberação de versão, automação de build, provisionamento de ambientes para testes e monitoramento ou qualquer outro processo

O interessante é identificar os processos que sejam repetitivos ou que levem bastante tempo e buscar resolver o quanto antes, evitando que se torne algo mais difícil de alterar futuramente.

Medição/Avaliação

Deve-se medir tudo que possível: performance, processos, interações e até mesmo pessoas. Sem medir não se pode melhorar nem aperfeiçoar os processos.

Compartilhamento

Ter uma boa comunicação entre as equipes, incentivar as pessoas a se comunicarem e compartilharem ideias e problemas é um ponto crucial numa iniciativa do DevOps.

Histórias de sucesso atraem novos talentos para o movimento e criam um excelente canal de feedback, que fomentam um processo de melhoria contínua.

O DevOps é um movimento em constante construção e definição, seguir ou aplicar a cultura DevOps em uma empresa parte principalmente da mudança de cultura.

Ferramentas do DevOps

tela de computador com códigos de programaçao

Um dos principais princípios do DevOps é investir em automação. A automação permite executar tarefas ou processos mais rapidamente e diminuir a possibilidade de erros humanos e para isso podem ser citadas algumas ferramentas:

Vagrant

Ferramenta que permite a construção de ambientes virtualizados de desenvolvimento completos, com um fluxo de trabalho fácil e simples de usar e com foco na automação.

Docker

Docker é uma plataforma aberta para desenvolvedores e administradores de sistema, que ajuda na criação e execução de aplicações distribuídas.

>> Leitura Recomendada:
Leia nosso artigo sobre Docker na prática – como construir uma aplicação?

Puppet

Ferramenta de código aberto para gerenciamento de configuração. A ideia é ter a configuração centralizada e sendo distribuída pra várias maquinas ou servidores na rede.

Chef

Chef permite automatizar a forma como se constrói, implanta e gerencia a infraestrutura, tornando-a versionável e testável.

Composer

Gerenciador de dependências da aplicação, permite manter e incluir novos pacotes/bibliotecas necessários facilmente na aplicação.

New Relic

É uma ferramenta de monitoramento de aplicação que permite a análise da aplicação. Com isso, ajuda pessoas que constroem software a entender o que os históricos de dados estão tentando lhes dizer, através da coleta, armazenamento e análise deles.

Existem muitas ferramentas e a cada dia surgem mais, o ideal é analisar qual a necessidade real para cada caso.

>>Leitura Recomendada:
Leia nosso artigo sobre orquestração de contêineres — com Docker, Swarm e Portainer

Ainda sobre o DevOps, aqui está um spoiler sobre um possível novo post:

tela de computador com codigos de programaçao

“Quais são as maiores diferenças entre Entrega Contínua, Implantação Contínua e Integração Contínua e como os desenvolvedores podem melhor utilizá-las?”

Entrega contínua

“Entrega contínua é um pequeno ciclo de construção com sprints curtos…” onde o objetivo é manter o código em um estado implantável a qualquer momento.

Isso não significa que o código ou projeto estão 100% concluídos, mas os conjuntos de recursos disponíveis são verificados, testados, depurados e prontos para implantação, embora você não precise implantar naquele momento.

O foco e a chave aqui são manter a base de código em um estado implantável. Este é o projeto padrão do dia-a-dia que sai para o público ou está voltado para o consumidor.

No mundo de hoje, você não pode liberar um projeto cheio de erros, então sprints menores permitem tempos de turno mais rápidos para identificar bugs e, portanto, tempo mais rápido para corrigir esses bugs, criando uma base de código muito mais estável no início. Este é o nosso método preferido de trabalho.

Implantação contínua

Com a Implantação contínua, todas as alterações feitas são implantadas automaticamente na produção. Essa abordagem funciona bem em ambientes corporativos em que você planeja usar o usuário como o testador real e pode ser mais rápido de ser liberado.

Integração contínua

A Integração Contínua mescla o código inteiro de todos os desenvolvedores para uma ramificação central do repositório várias vezes por dia, tentando evitar conflitos no código no futuro.

O conceito aqui é ter vários devs em um projeto para manter a ramificação principal do repositório na forma mais atual do código-fonte, para que cada dev possa fazer check-out ou extrair o código mais recente, evitando assim conflitos.

E o principal de tudo: Isso deve ser feito através de sistemas automatizados, afinal, é uma premissa do DevOps.

>>Leitura Recomendada:
Kubernetes: a arquitetura de um cluster

Em conclusão

fundo verde escrito the end em preto

A ideia foi passar um overview sobre estas técnicas e a justificativa do devOps e quais seus princípios. Caso achem interessante um detalhamento maior sobre os conceitos de integração, delivery e etc, comentem que podemos ver isso em outro post.

Bem, esse foi o “migué” de hoje, e creio que agora vocês já conseguem me dar a resposta da pergunta deste post. Deixem seus comentários sobre o que acharam.

Compartilhar
You May Also Like