HOME

Compartilhe este artigo

Facebook
Twitter
LinkedIn

Pipeline de DevOps

Portal Atlassian – Pipeline de DevOps

O DevOps é um movimento revolucionário, pois revoluciona a estrutura organizacional em silos que separava o desenvolvimento e as operações. O resultado é uma mudança cultural em que desenvolvedores e profissionais de operações trabalham juntos, adotam a automação, aumentam a velocidade de implementação e são mais flexíveis.

A estrutura de DevOps resultante tem benefícios claros: as equipes que adotam práticas de DevOps conseguem melhorar e simplificar o pipeline de implementação, o que reduz a frequência e o impacto dos incidentes. A adoção do princípio de DevOps “you build it, you run it” está se tornando a regra, e com bons motivos. Quase todos os entrevistados (99%) da Pesquisa de tendências de DevOps de 2020 disseram que o DevOps teve um impacto positivo em sua empresa, e quase metade deles registraram tempo de lançamento no mercado mais rápido e melhor frequência de implementação.

No entanto, é mais fácil falar sobre como implementar o DevOps do que fazer. É preciso ter as pessoas, os processos e as ferramentas certas para a implementação bem-sucedida do DevOps.

O  que é Pipeline de DevOps?

Um pipeline de DevOps é um conjunto de processos e ferramentas automatizados que permite que desenvolvedores e profissionais de operações trabalhem de maneira coesa na criação e implementação de código em um ambiente de produção. Embora o pipeline de DevOps possa ter diferenças de acordo com a empresa, em geral ele inclui automação de build/integração contínua, testes de automação, validação e geração de relatórios. Ele também pode incluir um ou mais portões manuais que exijam intervenção humana antes que o código tenha permissão para prosseguir.

A continuidade é uma característica diferenciada de um pipeline de DevOps. Isso inclui integração contínua, entrega/implementação contínua (CI/CD), feedback contínuo e operações contínuas. Em vez de testes pontuais ou implementações agendadas, cada função ocorre de forma contínua.

Considerações para construir um pipeline de DevOps

Como não existe um pipeline de DevOps padrão, o design e a implementação de um pipeline de DevOps em uma empresa dependem da pilha de tecnologia, do nível de experiência do engenheiro de DevOps, do orçamento e de muitos outros fatores. Um engenheiro de DevOps deve ter um amplo conhecimento das áreas de desenvolvimento e operações, incluindo codificação, gerenciamento de infraestrutura, administração de sistemas e cadeias de ferramentas de DevOps.

Além disso, cada empresa tem uma pilha de tecnologia diferente que pode impactar o processo. Por exemplo, se sua base de código for node.js, alguns fatores podem ser o fato de você usar um registro npm de proxy local, baixar o código-fonte e executar “npm install” em cada estágio do pipeline ou fazê-lo uma vez e gerar um artefato que se move pelo pipeline. Ou, se o aplicativo for baseado em contêiner, você vai precisar decidir entre usar um registro de contêiner local ou remoto, criar o contêiner uma vez e movê-lo pelo pipeline ou reconstruí-lo em todas as etapas.

Embora cada pipeline seja único, a maioria das empresas usa componentes fundamentais parecidos. Cada etapa é avaliada em relação ao sucesso antes de passar para o próximo estágio do pipeline. Em caso de falha, o pipeline é interrompido e um feedback é enviado ao desenvolvedor.

Componentes de um pipeline de DevOps

Integração contínua/entrega ou implementação contínua (CI/CD)

integração contínua é a prática de fazer commits frequentes em um repositório de código-fonte comum. Ela integra as alterações de código com continuidade na base de código existente para que os conflitos entre as diferentes alterações de código do desenvolvedor sejam identificados com rapidez e relativamente fáceis de corrigir. Essa prática é de grande importância para aumentar a eficiência da implementação.

Acreditamos que o desenvolvimento baseado em troncos é um requisito para a integração contínua. Se você não fizer commits frequentes em uma ramificação comum de um repositório de código-fonte compartilhado, não será integração contínua. Se os processos de compilação e teste forem automatizados, mas os desenvolvedores estiverem trabalhando em ramificações de recursos isoladas e de longa duração, que raramente são integradas a uma ramificação compartilhada, você também não estará fazendo implementação contínua.

entrega contínua garante que a ramificação “principal” ou “tronco” do código-fonte de um aplicativo esteja sempre pronta para o lançamento. Em outras palavras, se a gerência chegasse à sua mesa às 16h30 de uma sexta-feira e dissesse: “Precisamos da versão mais recente lançada agora mesmo”, essa versão poderia ser implementada com o toque de um botão, sem medo de falhas”.

Isso significa ter um ambiente de pré-produção o mais parecido possível com o ambiente de produção e garantir que os testes automatizados sejam executados, de modo que todas as variáveis que possam causar falhas sejam identificadas antes que o código seja mesclado na ramificação principal ou de tronco.

implementação contínua envolve um nível de testes e operações contínuos tão robusto que novas versões do software são validadas e implementadas em um ambiente de produção sem exigir nenhuma intervenção humana.

Isso é raro e, na maioria dos casos, desnecessário. Em geral, apenas empresas unicórnio, que têm centenas ou milhares de desenvolvedores e muitos lançamentos todos os dias, exigem, ou até mesmo querem ter, esse nível de automação.

Para simplificar a diferença entre entrega e implementação contínuas, pense na entrega como o funcionário da FedEx entregando uma caixa para você e na implementação como o processo de abrir essa caixa e usar o que está dentro dela. Caso seja necessária uma alteração no produto entre o momento em que você recebe a caixa e o momento em que você a abre, o fabricante vai ter problemas!

Feedback contínuo

O maior problema do antigo método de desenvolvimento de software em cascata – e, como consequência, o motivo para as metodologias ágeis terem sido criadas – era a falta de feedback em tempo hábil. Quando os novos recursos levavam meses ou anos para ir da ideia à implementação, era quase certo que o resultado final seria algo diferente do que aquilo que o cliente esperava ou queria. Os processos ágeis tiveram sucesso ao garantir que os desenvolvedores recebessem feedback mais rápido dos stakeholders. Hoje, com o DevOps, os desenvolvedores recebem feedback contínuo não só dos stakeholders, mas de testes sistemáticos e monitoramento do código no pipeline.

teste contínuo é um componente fundamental de todo pipeline de DevOps e um dos principais facilitadores do feedback contínuo. Em um processo de DevOps, as mudanças passam continuamente do desenvolvimento para o teste e a implementação, o que gera não só a lançamentos mais rápidos, mas um produto de maior qualidade. Isso significa ter testes automatizados em todo o pipeline, inclusive testes de unidade executados em cada alteração do build, testes de sanidade, testes funcionais e testes de ponta a ponta.

monitoramento contínuo é outro componente importante do feedback contínuo. Uma abordagem de DevOps envolve o uso de monitoramento contínuo nos ambientes de staging, testes e até desenvolvimento. Às vezes pode ser útil monitorar ambientes de pré-produção em busca de comportamentos anômalos, mas, em geral, essa é uma abordagem usada para avaliar com continuidade a integridade e o desempenho dos aplicativos em produção.

Existem várias ferramentas e serviços para garantir essa funcionalidade, e elas podem envolver qualquer coisa, desde o monitoramento da infraestrutura local ou na nuvem, como recursos de servidor, rede etc., até o desempenho do aplicativo ou das interfaces de API.

Operações contínuas

O termo operações contínuas é relativamente novo e menos comum, e as definições variam. Uma forma de interpretá-lo é como o “tempo de operação contínuo”. Por exemplo, o caso de uma estratégia de implementação azul/verde em que você tem dois ambientes de produção separados, um “azul” (acessível publicamente) e outro “verde” (não acessível publicamente). Nessa situação, um novo código seria implementado no ambiente verde e, quando houvesse a confirmação do status de funcional, um switch seria invertido (em geral em um balanceador de carga) e o tráfego mudaria do sistema “azul” para o “verde”. O resultado é a ausência de tempo de inatividade para os usuários finais.

Outra forma de pensar em operações contínuas é como um alerta contínuo. Essa é a noção de que a equipe de engenharia está de plantão e é notificada quando ocorrem anomalias de desempenho no aplicativo ou na infraestrutura. Na maioria dos casos, o alerta contínuo vem acompanhado do monitoramento contínuo.

Conclusão

O DevOps tem o objetivo de simplificar o desenvolvimento, a implementação e as operações de software. O pipeline de DevOps é o modo com que essas ideias são implementadas na prática e “continuous everything” é o xis da questão, desde a integração do código até as operações de aplicativos.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Posts relacionados

Escalabilidade com DevOps na Pakman

A Pakman é uma Loghtech especializada em serviços de Last Mile. Desde desenvolvimento à execução de soluções para empresas que possuem necessidade

Quer Conhecer mais?
Nuvem AWS é com dataRain.
ENTRE EM CONTATO