Como fazer DevOps

Passo 1 — Escolha o componente

O primeiro passo é iniciar com algo pequeno. Escolha algum componente que já esteja em produção. O componente ideal deve ter base de código simples com poucas dependências e infraestrutura mínima. Esse componente vai servir como o campo de provas para que a equipe faça os primeiros experimentos de implementação do DevOps.

Passo 2 — Considere a adoção de alguma metodologia ágil como o Scrum

O DevOps costuma funcionar com alguma metodologia de desenvolvimento ágil, como o Scrum. Não é preciso adotar todos os rituais e práticas de um método como o Scrum. Os três elementos do Scrum que, em geral, têm adoção fácil e agregam valor com rapidez são o backlog, o sprint e o planejamento do sprint.

A equipe de DevOps pode adicionar e priorizar as atividades no backlog do Scrum para, em seguida, extrair um subconjunto das atividades para o sprint, um prazo fixo para realizar um grupo de tarefas específico. O planejamento do sprint é o processo de escolha das tarefas que vão passar do backlog para o próximo sprint.

Passo 3 — Utilize controle do código-fonte baseado em Git

O controle de versão é a prática recomendada de DevOps para promover maior colaboração e ciclos de lançamento de versão mais rápidos. Ferramentas como o Bitbucket dão aos desenvolvedores a capacidade de compartilhar, colaborar, fazer o merge e o backup do software.

Escolha o modelo de ramificação. Este artigo apresenta a visão geral do conceito. O fluxo do GitHub é o ponto de partida das equipes recém-chegadas ao Git, pois é simples de entender e fácil de implementar. O desenvolvimento baseado em troncos é a preferência padrão, mas exige mais disciplina e dificulta essa primeira incursão no Git.

Passo 4 — Integre o controle do código-fonte ao rastreamento do trabalho

Integre o controle do código-fonte à ferramenta de rastreamento do trabalho. A capacidade de visualizar tudo do projeto no mesmo lugar poupa tempo considerável dos desenvolvedores e da equipe de gerenciamento. O exemplo abaixo mostra um item do Jira com atualizações provenientes do repositório de controle do código-fonte baseado em Git. Os itens do Jira têm uma seção de desenvolvimento que agrega o trabalho feito pelo item do Jira na ferramenta de controle do código-fonte. Esse item tinha apenas uma ramificação, seis confirmações, uma pull request e apenas um build.

Passo 5 — Escreva os testes

Os pipelines de IC/CD (Integração/Implementação contínuas) precisam de testes que validem o funcionamento correto do código implementado em diversos ambientes. Comece escrevendo os testes de unidade do código. A meta ambiciosa é que a forma de verificação do código alcance 90%, mas é algo impraticável no começo. Defina uma linha de base baixa para a forma de verificação do código e, com o passar do tempo, aumente por incrementação a cobertura dos testes de unidade. Você pode adicionar itens de trabalho ao backlog para lidar com essa questão.

Use o desenvolvimento orientado por testes para fazer a atualização de segurança dos bugs encontrados no código de produção. Quando achar algum bug, escreva testes de unidade, testes de integração e testes de sistema que falhem nos ambientes em que o bug existe. Corrija o bug e observe que agora os testes são validados. Esse processo vai produzir o aumento orgânico da forma de verificação do código com o passar do tempo. Se o bug foi detectado em um teste ou ambiente de staging, os testes vão trazer segurança sobre o funcionamento adequado do código ao passar para a produção.

Esse passo é trabalhoso quando feito desde o início, mas ele é importante. Os testes dão às equipes visibilidade dos efeitos de alterações do código sobre o sistema antes da exposição dos usuários finais a essas alterações.

Testes de unidade

Os testes de unidade verificam se o código-fonte está correto e devem ser realizados durante as primeiras fases do pipeline de IC/CD (Integração/Implementação contínuas). Os desenvolvedores devem escrever testes de caminho feliz, de entradas inválidas e para outros casos conhecidos de exceção. Ao escrever os testes, os desenvolvedores podem fazer a simulação (mock) das entradas e saídas esperadas.

Testes de integração

Os testes de integração verificam se há comunicação correta entre dois componentes. Crie as simulações das entradas e saídas esperadas. Esses testes constituem uma das primeiras fases do pipeline de IC/CD (Integração/Implementação contínuas) antes da implementação em qualquer ambiente. Eles exigem uso mais extenso de simulações, em comparação com testes de unidade, para que funcionem.

Testes de sistema

Os testes de sistema servem para verificar o desempenho integral do sistema e assegurar que o sistema está funcionando como deve em cada ambiente. Simule as entradas que o componente pode receber e execute o sistema. Em seguida, verifique se o sistema retorna os valores necessários e atualiza o restante do sistema com exatidão. Esses testes devem ser realizados antes da implementação em cada ambiente.

Passo 6 — Crie o processo de IC/CD (Integração/Implementação contínuas) para implementar o componente

Considere a implementação em vários ambientes ao desenvolver o pipeline de IC/CD (Integração/Implementação contínuas). O código pode ficar muito inflexível se a equipe desenvolver o pipeline de IC/CD (Integração/Implementação contínuas) para que seja implementado em apenas um ambiente. É importante criar pipelines de IC/CD (Integração/Implementação contínuas) para a infraestrutura e para o código. Comece com a criação do pipeline de IC/CD (Integração/Implementação contínuas) para implementar a infraestrutura necessária em cada ambiente. Depois, crie outro pipeline de IC/CD (Integração/Implementação contínuas) para implementar o código.

Estrutura do pipeline

Esse pipeline começa com a realização de testes de unidade e testes de integração antes da implementação no ambiente de teste. Os testes de sistema são realizados após a implementação no ambiente.

Infraestrutura

As diferenças nas infraestruturas de ambientes distintos dificultam a execução correta do software nesses ambientes. Regras de firewall, permissões de usuário, acesso ao banco de dados e outros componentes no nível da infraestrutura devem ter configurações conhecidas para que o software seja executado como esperado. A implementação manual da infraestrutura pode ser difícil de repetir sem erros. Como esse processo tem muitas etapas, depender da lembrança para executar cada etapa na ordem correta e com os parâmetros corretos pode levar a erros. A infraestrutura deve ser definida no código sempre que possível para aliviar esses e outros problemas.

A infraestrutura pode ser definida no código por meio de diversas ferramentas como AWS CloudFormation, Terraform, Ansible, Puppet ou Chef.

Escreva vários pipelines para implementar a infraestrutura. Assim como a escrita de código, é útil manter a modularidade da implementação da infraestrutura. Divida a infraestrutura necessária em subconjuntos separados sempre que possível. Suponha que A, B, C e D sejam abstrações de componentes de infraestrutura que podem depender uns dos outros. Por exemplo, A pode ser uma caixa EC2 e B pode ser um bucket do S3. As dependências nas quais o componente da infraestrutura A — e apenas A — dependem do componente B quase sempre devem ser mantidas juntas no mesmo pipeline de IC/CD (Integração/Implementação contínuas). As dependências nas quais A, B e C dependem de D — mas A, B e C são independentes — devem ser divididas em diferentes pipelines de IC/CD (Integração/Implementação contínuas). Nesse caso, quatro pipelines independentes. Nessa instância, você deve criar um pipeline para D do qual todos os outros três componentes dependam e um pipeline para cada um dos componentes A, B e C.

Código

Os pipelines de IC/CD (Integração/Implementação contínuas) são criados para implementar o código. Em geral, esses pipelines são fáceis de implementar, pois a infraestrutura já foi criada em trabalhos anteriores. Considerações importantes aqui são os testes, a repetibilidade e a capacidade de recuperação de implementações inadequadas.

A repetibilidade é a capacidade de implementar a mesma alteração inúmeras vezes sem causar danos ao sistema. A implementação deve ser reentrante e idempotente. As implementações devem definir o estado do sistema usando alguma configuração conhecida, em vez de aplicar um modificador ao estado existente. A aplicação de um modificador não pode ser repetida, pois, depois da primeira implementação, o estado inicial necessário para que o modificador funcione como esperado foi alterado.

Um exemplo simples de atualização que não pode ser repetida é a atualização de arquivos de configuração por meio da anexação de dados a ele. Não adicione linhas aos arquivos de configuração ou use qualquer técnica de modificação desse tipo. Os arquivos de configuração podem acabar com dezenas de linhas duplicadas se as atualizações forem feitas por anexação. Em vez disso, substitua o arquivo de configuração por um arquivo com escrita correta do controle do código-fonte.

Esse princípio também deve ser aplicado à atualização de bancos de dados. As atualizações do banco de dados podem ser problemáticas e exigem atenção aos detalhes. É essencial garantir a repetibilidade e a tolerância a falhas do processo de atualização do banco de dados. Faça backups no momento que antecede a aplicação das alterações para possibilitar a recuperação.

Outro fator a considerar é como fazer a recuperação de implementações inadequadas. Ou a implementação falhou e o sistema ficou em estado desconhecido ou a implementação foi bem-sucedida, mas alarmes são acionados e os tickets de problemas começam a chegar. Existem duas maneiras gerais de lidar com esse problema. A primeira é fazer o rollback. A segunda é usar sinalizadores de funcionalidade e desativar os sinalizadores necessários para retornar ao estado válido conhecido. Consulte a Etapa 8 deste artigo para ver mais informações sobre sinalizadores de funcionalidade.

O rollback implementa o estado válido anterior no ambiente após a detecção da implementação inadequada. Essa saída deve ser planejada desde o início. Antes de fazer alterações no banco de dados, faça o backup. Garanta que vai conseguir implementar com rapidez a versão anterior do código. Sempre teste o processo de rollback em ambientes de teste ou staging.

Passo 7 — Adicione monitoramento, alarmes e instrumentação

A equipe de DevOps precisa monitorar o comportamento do aplicativo em execução em cada ambiente. Há erros nos registros? As chamadas de APIs estão atingindo o tempo limite? Os bancos de dados estão falhando? Monitore cada componente do sistema para verificar se há problemas. Se o monitoramento detectar algum problema, crie o ticket do problema para que alguém resolva o problema. Como parte da resolução, escreva testes adicionais capazes de identificar o problema.

correção de erros

O monitoramento e a resposta a problemas são parte da execução do software de produção. A equipe que adota a cultura de DevOps é proprietária da operação do software e imita o comportamento de um Engenheiro de Confiabilidade do Site (SRE). Faça a análise da causa raiz do problema, escreva testes para sua detecção, corrija o problema e verifique se os testes são validados. Esse processo é trabalhoso no começo, mas vale a pena a longo prazo, porque reduz o débito técnico e a agilidade operacional é mantida.

Otimização de desempenho

Depois de implementar o monitoramento de saúde básico, o ajuste de desempenho costuma ser o passo seguinte. Analise como cada parte do sistema funciona e otimize as partes com lentidão. Como observou Knuth: "a otimização prematura é a raiz de todos os problemas". Não otimize o desempenho de tudo no sistema. Otimize apenas as partes com maior lentidão e consumo de recursos. O monitoramento ajuda na identificação dos componentes lentos e com muito consumo de recursos.

Passo 8 — Use sinalizadores de funcionalidade para implementar testes canário

Para possibilitar os testes canário, envolva cada novo recurso em um sinalizador de funcionalidade com uma lista de permissões que contenha usuários de teste. O novo código do recurso é executado apenas para os usuários na lista de permissões depois da implementação no ambiente. Deixe o novo recurso se estruturar em cada ambiente antes de passar para o próximo. Enquanto o novo recurso se estrutura em uma região, preste atenção nas métricas, alarmes e outros instrumentos em busca de sinais de problemas. Para ser mais específico, procure por aumentos de novos tickets de problemas.

Resolva os problemas no ambiente antes de passar para o próximo ambiente. Os problemas encontrados nos ambientes de produção devem receber o mesmo tratamento dado aos problemas em ambientes de teste ou de staging. Depois de identificar a causa raiz do problema, escreva testes para identificar o problema, implemente a correção, verifique se os testes foram validados e implemente a correção por meio do pipeline de IC/CD (Integração/Implementação contínuas). Os novos testes vão ser validados e a contagem de registros de problemas vai diminuir enquanto a alteração penetra no ambiente em que o problema foi detectado.