AUTORIA

Luiz Felipe Aiello

TRADUÇÃO

GERENTE RESPONSÁVEL

DIRETOR RESPONSÁVEL

Marcelo Pagoti

A prática de DevOps é utilizada em uma crescente desde 2010 e seus benefícios são amplamente conhecidos. Contudo, ainda é bem comum encontrar muitas equipes e projetos que não o utilizam em todo seu potencial, ou que encontram dificuldades ao tentar implantar partes de automação ou aumentar a colaboração entre as equipes de tecnologia.

Gráfico relatando a taxa de respostas positivas das empresas para a pergunta: "Você considera o seu time um 'time DevOps'?". As taxas são: 16% em 2014, 19% em 2015, 22% em 2016, 27% em 2017, 29% em 2018, 22% em 2019, 20% em 2021 e 21% em 2022. Fonte: State of DevOps Report 2021 by Puppet.

Existem muitas formas e cases bem estabelecidos para a implantação adequada de DevOps e isso pode variar dependendo do contexto e das limitações de cada projeto. Alguns princípios, como The Three Ways de Gene Kim, mesmo autor de The DevOps Handbook e Phoenix Project, são leituras fundamentais para quem quer entender a fundo essas práticas.

De forma complementar, esse artigo visa ser um ponto de partida para mostrar algumas dicas e pontos que podem ajudar a começar de forma prática a sair da estagnação e adotar a prática do DevOps.

O que é DevOps?

DevOps é a união das áreas de Desenvolvimento de Softwares e de IT Operations.​ Em resumo, é a junção de duas áreas diferentes com objetivos contrastantes.

Esse contraste e conflito de interesses das áreas, naturalmente, promovem a criação não intencional de silos de trabalho fazendo os times focarem na individualidade de seus escopos em um determinado projeto.​

De forma geral, no processo normal (Dev + Ops) cada área, após ter finalizado o seu escopo de trabalho, envia seu entregável para a área responsável, e, então, seu ciclo é finalizado.​

Mesmo em um time com uma equipe de QA (Quality Assurance) bem estruturada, o feedback da área de Testes para Dev pode demorar bastante para ocorrer.​ Então, erros não identificados pela área de Testes podem demorar semanas, ou meses, para serem encontrados e analisados pelo time de Desenvolvimento.​

O conceito de DevOps sugere uma ruptura dessa parede. Nesse quesito, duas das chaves dessa união são a colaboração dos times com integração de etapas e automação de processos de todas as áreas. Essas chaves visam atingir o sucesso organizacional através de dois objetivos que até então eram praticamente impossíveis de coexistirem em uma estrutura compartimentalizada:​

  • Responder rápido a mudanças​;
  • Realizar entregas seguras, confiáveis e estáveis em produção;

Um DevOps bem definido e estruturado capacita organizações a criar um sistema seguro de trabalho, fazendo com que pequenos times possam desenvolver de forma independente, testar, implantar de forma rápida, segura e confiável para os respectivos clientes.​

Como começar?

É importante destacar que o propósito não é definir arquiteturas específicas, nomes de ferramentas, ou plataformas, mas alguns exemplos podem ser considerados devido à facilidade de integração e automatização.

1. Pessoas

DevOps não é apenas sobre automação de processos e entregas, mas também sobre quebra de silos e estabelecer um fluxo melhor entre áreas. Em outras palavras, é também unir grupos de pessoas!

Por esse motivo, a implantação de DevOps exige mudança cultural das áreas envolvidas e utilização de ferramentas e plataformas que ajudam na colaboração dos times, integração e automação de processos. É importante que todo pessoal envolvido esteja alinhado quanto à necessidade da adoção da prática, mesmo que de forma gradual.

Isso parece algo simples, mas dependendo da cultura e silos pré-estabelecidos, quebrar paredes entre processos e pessoas pode ser uma ruptura caótica e desconfortável para indivíduos que estão acostumados à um mesmo modelo de trabalho definido há muito tempo.

Essa mudança não é algo que pode ser estabelecida do dia para a noite. Uma boa estratégia é começar com projetos pequenos e estabelecer pessoas específicas para a criação de equipes (os “campeões”) que estejam dispostas a adotar o processo. O resultado poderá ser um case para implantação em outras áreas maiores com outras equipes.

2. Assessment tecnológico

É importante entender o estado atual das áreas e ferramentas envolvidas, além das limitações tecnológicas, para saber priorizar as melhorias e definir o que pode ser feito com DevOps.

As equipes precisam escolher as metodologias de trabalho, ferramentas e tecnologias certas para apoiar suas operações. As ferramentas devem ser capazes de suportar os processos de desenvolvimento e operações, bem como a automação. É importante garantir que as ferramentas sejam integradas e se comuniquem de forma eficaz.

Como exemplo, caso hajam muitas restrições e inflexibilidade de infraestrutura na comunicação entre ferramentas e plataformas, será muito difícil (ou até impossível) uma automação completa dos pipelines. Alguns processos e validações podem ser automatizados para melhorar as etapas gradualmente. Porém, é importante que ferramentas sejam disponibilizadas e uma infraestrutura que permita a comunicação e integração de todas as etapas seja estabelecida.

Desta forma, podemos dizer que o sucesso do DevOps requer, na verdade, que toda a organização esteja ciente e dê o suporte para promover, não apenas a cultura, mas a infraestrutura tecnológica necessária.

3. Planejamento

A adoção de práticas ágeis é fundamental para a implementação de DevOps! A metodologia Agile, como Scrum e Kanban, ajudará a equipe a trabalhar de forma mais iterativa, colaborativa e responsiva às mudanças.

Para gerenciar o andamento do trabalho e dos ciclos, é muito importante escolher uma ferramenta, ou plataforma, que tenha capacidades de Agilidade e possibilite a integração com o repositório de código para rastreabilidade dos entregáveis.

Uma estruturação do processo de planejamento deve permitir:

  • Visibilidade em tempo real do trabalho de todo o processo até os estágios de entrega;
  • Granularizar o número de tarefas que caibam na Sprint (ou ciclo de entrega), para gerar menores entregáveis que possam ser implantados mais rapidamente;
  • Definir um limite na quantidade de tarefas baseado no esforço do time (de forma prática, humanamente não existe “multitasking”). Scrum Master pode ajudar a remover impedimentos e a manter o foco nas tarefas mais importantes;
  • Reduzir o número de “passagens” de trabalho para outros times;

4. Desenvolvimento

Assim como a parte de planejamento deve considerar o uso de plataformas e ferramentas que permitam uma integração, a escolha do repositório deve seguir o mesmo princípio. Não é necessário que todo o fluxo de DevOps esteja em uma única plataforma, porém é essencial existir esta conectividade entre cada etapa para garantir o fluxo do pipeline de forma contínua. Por exemplo, é possível utilizar apenas a função Boards do Azure DevOps, o integrando com um repositório do Github.

Pontos a considerar pré-CI:

  1. Definir uma estratégia de branching adequada para o tipo de entrega e fluxo de trabalho estabelecido para o time, que promova uma rotina de frequências altas de integrações de código e entregas rápidas;
  2. Linters de código: ajudam a manter a qualidade do código;
  3. Testes de desenvolvimento – ter uma cultura de desenvolver criando testes unitários (e os mantê-los atualizados). Ainda existem muitos métodos de trabalho que delegam toda a parte de testes para a equipe de QA Uma percentagem de cobertura de testes pode ser estabelecida no Definition of Done para ajudar a manter o padrão;
  4. Cultura de trabalho em débitos técnico​s;

Continuous Integration:

  • Configuração de validação de PRs: Muitos dos pontos citados anteriormente podem ser validados automaticamente em um pipeline de CI antes da criação do Pull-Request. Um pipeline básico ajuda a manter a qualidade dos entregáveis pode conter:
    • Validação de build: O código não pode estar quebrado;
    • Validação de testes unitários: Testes novos e existentes devem passar;
    • Validação de code coverage;
  • Code Review: uma prática importante que pode ajudar a aumentar a qualidade da entrega, disseminar conhecimento, reduzir o tempo de ciclo de feedback e melhorar a comunicação e colaboração da equipe.

5. Testes

Como pode ser observado nas etapas anteriores, os testes não passam a ser responsabilidade de apenas uma equipe, ou iniciados após o fim de ciclo de desenvolvimento, mas é incentivado desde as atividades iniciais de desenvolvimento até aos pipelines de CI/CD (Continuous Integration/Continuous Delivery).

Além dos testes unitários citados na etapa de Desenvolvimento (e de smoke tests manuais), outros testes automatizados podem ser integrados na etapa de CI, como:

  • Testes de integração: utilizados para verificar se os componentes individuais da aplicação funcionam bem juntos. Eles são executados em um ambiente de teste separado para simular o ambiente de produção;
  • Testes de aceitação: executados para verificar se o software atende às expectativas do cliente ou do usuário final. Eles são executados em um ambiente de teste que replica o ambiente de produção;
  • Testes de estresse: esses testes são executados para verificar se o aplicativo pode lidar com cargas de trabalho esperadas, ou em níveis máximos;
  • Testes de segurança: são executados para verificar se o aplicativo está seguro contra ameaças conhecidas;
  • Testes de regressão: são executados para verificar se as alterações recentes no código não afetaram o funcionamento da aplicação em áreas que anteriormente funcionavam bem;

Adicionalmente, com auxílio de ferramentas, uma equipe de QA pode monitorar os resultados das implantações de DevOps desde os estágios de Desenvolvimento até o ambiente Produtivo, identificando áreas de melhoria.

Existem muitas ferramentas que podem ser utilizadas e também automatizadas para executar diagnósticos esporádicos e gerar relatórios de forma proativa. O estudo desses feedbacks de monitoramento pode gerar novos itens de backlogs a serem priorizados e adicionados à novos ciclos de trabalho fazendo com que o processo de melhoria contínua seja constante.

6. Deploy/Delivery

Da mesma forma que uma estratégia de branching é necessária para organização do trabalho de desenvolvimento, uma estratégia de deploy também é importante para manter o fluxo de DevOps com o Continuous Delivery (CD).

Dividir a entrega em diferentes ambientes e stages garante um fluxo de validações antes de chegar ao ambiente de produção, isso aumenta efetivamente a qualidade e confiança de toda a equipe e redução do time to market.

Alguns exemplos de ambientes que podem ser considerados na utilização de DevOps:

  • Ambiente de desenvolvimento: é onde os desenvolvedores trabalham no código-fonte e testam suas alterações. É importante que o ambiente de desenvolvimento seja flexível e fácil de usar, permitindo que os desenvolvedores trabalhem de forma colaborativa e iterativa. De forma simplificada, esse ambiente pode ser definido e configurado para deploys automáticos a cada vez que um PR é aceito, permitindo a disponibilidade imediata para testes de desenvolvimento;
  • Ambiente de teste: é onde os testes automatizados e manuais são realizados para garantir que as alterações no código funcionem corretamente e atendam aos requisitos do usuário. É importante que o ambiente de teste seja uma réplica do ambiente de produção, para que os testes sejam realistas;
  • Ambiente de pré-produção: é onde as alterações no código são implantadas e testadas em um ambiente semelhante ao de produção, mas sem impactar os usuários finais. Isso permite que os testes finais sejam realizados antes da implantação completa;
  • Ambiente de produção: é onde a aplicação é implantada para os usuários finais. É importante garantir que a aplicação seja monitorada continuamente para garantir a estabilidade e o desempenho;

Apesar de muitos cases com dados de benefícios do Continuous Delivery, pipelines de testes estabelecidos, relatórios de mudanças disponibilizados por ferramentas e possibilidade de criação de trilhas de aprovação antes de um release, ainda existem muitas organizações que tem como premissa não permitir uma implantação automatizada no ambiente produtivo. Infelizmente isso acaba reduzindo a possibilidade de utilização total do DevOps e desencoraja o fluxo de pequenas entregas incrementais.

Essa “prevenção de riscos” de atualizações contínuas em produção, por sua vez, acaba promovendo o acúmulo de mudanças fazendo com que as entregas tenham um impacto muito maior do que se fossem feitas de forma contínua, porém menores e monitoradas.

Abordagens de Change Management por nível de automação e aprovação ortodoxa, com a abordagem de Engineering Driven sendo altamente automatizada e com aprovação pouco ortodoxa, a abordagem de Ad hoc sendo pouco automatizada e com aprovação pouco ortodoxa, a abordagem operacionalmente madura sendo altamente automatizada e com aprovação muito ortodoxa e a abordagem com foco em governança sendo pouco automatizada e com aprovação muito ortodoxa,

Independente do alcance de nível de maturidade para adoção do Continuous Delivery, até o estágio de produção, se for estabelecido a criação de ambientes básicos como Desenvolvimento e Testes e nestes estejam funcionando entregas automatizadas, já podemos considerar uma grande vitória e desfrutar de muitos benefícios do DevOps nesse estágio intermediário.

7. Monitoramento

O monitoramento permite que a equipe detecte e tome ações rápidas aos problemas em tempo real.

É importante definir quais métricas, eventos e logs precisam ser monitorados para a aplicação. Como em todas as etapas de DevOps, a utilização de ferramentas adequadas auxilia muito em todo o processo, podendo ser configuradas para monitorar não apenas o ambiente de produção, mas também serem integrados aos pipelines de CI/CD para garantir o acompanhamento em tempo real das entregas, como:

  • Tempo de build;
  • Tempo de execução dos testes automatizados;
  • Número de falhas de testes;
  • Tempo de implantação;
  • Tempo de resposta do servidor;

Adicionalmente, outras métricas que podem ser monitoradas independente do estágio são:

  • Desempenho;
  • Tempo de resposta do servidor;
  • Utilização de recursos do sistema;
  • Número de solicitações de usuário;
  • Tráfego de rede;

Analisar esses dados continuamente ajuda a entender cada vez onde estão as red flags e auxilia na constante melhoria das aplicações.

8. Sistemas legados

É possível a implantação de DevOps em Sistemas Legados? Acredito que a melhor resposta é que depende!

Sistemas legados geralmente significam tecnologias obsoletas, infraestrutura defasada, códigos sem boas práticas de desenvolvimento, entre outros problemas. Isso tudo pode dificultar a modernização e adoção de novas práticas.

Sala com monitores e mecanismos operacionais obsoletos

Então, depende dos obstáculos existentes e de quanto suporte existe para a atualização dessas aplicações. Por isso, existem alguns pontos de melhoria necessários que podem ser considerados para focar os esforços iniciais:

Refatoração: permite tornar o sistema mais fácil de manter e modificar. Isso pode incluir a eliminação de código morto, correção de bugs, melhoria da arquitetura do sistema e a adoção de práticas de codificação modernas. Mas lembre-se de que refatorar não é reconstruir. Algumas técnicas de refatoração ajudam a modificar o código mantendo as funcionalidades existentes.

Mudança de ambientes: Geralmente sistemas legados estão localizados em servidores on-premise que precisam de muita atenção e um conhecimento de configuração que geralmente não está bem documentado. Considerar mover esses sistemas gradualmente para ambientes virtualizados, por exemplo, ajuda na utilização de práticas mais modernas como utilização de CI/CD

Resumo

Em resumo, podemos considerar os seguintes pontos para o sucesso da implantação de DevOps:

  • Promover a cultura de colaboração e comunicação entre desenvolvedores e operações com apoio organizacional;
  • Mapear e entender o fluxo de trabalho e desafios tecnológicos;
  • Iniciar com projetos pequenos e de maior flexibilidade;
  • Automatizar processos de integração, entrega e implantação;
  • Utilizar ferramentas e plataformas para colaboração, monitoramento e gestão de projetos;
  • Implementar testes automatizados em todas as fases do ciclo de vida do software;
  • Fazer uso de métricas e análises para aprimorar o processo do todo, retroalimentando o ciclo de DevOps;

Leia Também