Embora não exista um corpo fechado de práticas técnicas DevOps, proponho aqui uma lista de práticas básicas para a implantação desta cultura. A lista aqui apresentada não possui uma ordem de prioridade, que depende da realidade de cada organização e da cultura já instalada nos seus times de desenvolvimento, qualidade e operações.

As práticas DevOps buscam endereçar as melhorias em atributos de qualidade tais como a manutenibilidade, testabilidade, implantabilidade e recuperabilidade. Com estas práticas implementadas, teremos maior garantia que minimizaremos o débito técnico dos produtos de software sendo construídos e aceleraremos a entrega para produção dos produtos.

1.Comunicação Técnica Automatizada

A cultura DevOps busca aproximar pessoas dos times de desenvolvimento, qualidade e operações. E essa aproximação pode ser facilitada com ferramentas de comunicação que aliam o melhor da mensagem instantânea e canais de times com alarmes técnicos automatizados. Por exemplo, ferramentas como o Slack ou HipChat permitem que times com pessoas de desenvolvimento, qualidade e operações possam:

1. estabelecer conversas texto, aúdio e vídeo em canais privativos e focados;
2. receber notificações de ferramentas tais como a disponibilização de builds, aprovação de releases ou problemas em produção;
3. disparar comandos através de bots para a abertura de defeitos, escalonamento de builds ou releases.

2. Qualidade contínua do código

Em muitas empresas, é muito fácil que uma arquitetura definida pelo time de arquitetura seja continuamente violada pelo time de desenvolvimento. O arquiteto normalmente não tem tempo e dedicação para “vigiar” o código fonte e realizar a aderência arquitetural do código ou observar o uso de práticas apropriadas de codificação. O efeito é que a arquitetura executável colocada em produção é muito diferente da arquitetura imaginada pelo arquiteto.

No sentido de minimizar esta lacuna, esta primeira prática lida com a automação da verificação da qualidade de código por ferramentas. Existem atualmente ferramentas sólidas que permitem avaliar o uso das melhores práticas de programação no seu ambiente (Code Metrics Tools) e avaliar a aderência do seu código a uma arquitetura de referência (Architectural Analysis Tools). E essas ferramentas podem ser programadas para rodar a noite ou até mesmo durante o momento do checkin do código pelo desenvolvedor. Existem ainda ferramentas que facilitam o processo de revisão por pares dos códigos fontes (Code Reviews), estabelecendo workflows automatizados e trilhas de auditoria. O recurso de Pull Requests do Git é um exemplo deste mecanismo.

Com esta prática, temos robôs que atuam continuamente para facilitar a análise do código fonte, educar desenvolvedores e estabilizar ou mesmo reduzir o débito técnico instalado.

3. Configuração como Código

Em muitos times, é comum que desenvolvedores façam muitas tarefas manualmente. Exemplos incluem cópias de arquivos entre ambientes, configuração destes ambientes, configuração de senhas, geração de release notes ou a parametrização de aplicações. Esses trabalhos manuais são propensos a erros e podem consumir tempo valioso do seu time com tarefas braçais.

Times atentos devem observar quando algum tipo de trabalho manual e repetitivo começa a acontecer e buscar automatizar isso. A automação da configuração através da escrita de códigos de scripts é um instrumento DevOps importante para acelerar o trabalho de times de desenvolvimento, reduzir erros e garantir consistência do trabalho.

No mundo DevOps, tudo é código!

4. Gestão dos Builds

A gestão de builds (ou Build Management) é prática essencial para garantir que os executáveis da arquitetura sejam gerados de forma consistente, em base diária. Esta prática busca evitar o problema comum do código funcionar na máquina do desenvolvedor e ao memo tempo quebrar o ambiente de produção.

A automação de builds externaliza todas as dependências de bibliotecas e configurações feitas dentro de uma IDE para um script específico e que possa ser consistentemente movida entre máquinas. Embora a automação de builds, na sua definição formal, lide apenas com a construção de um build, a prática comum de mercado é que builds devam executar um conjunto mínimo de testes de unidade automatizados para estabelecerem confiabilidade mínima ao executável sendo produzido.

Esta prática lida ainda com o estabelecimento de repositórios confiáveis de bibliotecas, o que garante governança técnica sobre o conjunto de versões específicas de bibliotecas que estejam sendo usadas para montar uma aplicação.

5. Gestão dos Testes

Organizações de baixa maturidade em automação de testes tem muito mais retrabalho ao longo de um projeto e geram muito mais incidentes em ambientes de produção. Esta prática DevOps buscar melhorar a testabilidade de aplicações e envolve:

• a criação de testes de unidade de código para as regras de negócio não triviais do sistema e também pontos críticos do código fonte tais como repositórios de dados complexos, controladores de negócio e interfaces com outros sistemas e empresas;
• a automação da interação com telas com testes funcionais automatizados;
• testes automatizados de aspectos não-funcionais, como segurança, acessibilidade, performace ou carga.

6. Gestão de Configuração

Muito times já usam ferramentas de controle de versão para organizar o seu código fonte, tais como o SVN, GIT ou Mercurial. Ao mesmo tempo, existem outras preocupações associadas ao trabalho feito por times em uma mesma linha de código. A ausência de políticas automatizadas de gestão de configuração digo aumenta a chance que desenvolvedores desestabilizem os troncos principais dos repositórios e gerem fricção e retrabalho para seus pares.

Neste contexto, as ferramentas de gestão de configuração de código permitem que os repositórios sejam mantidos em estado confiável e que erros comuns sejam evitados através da automação de políticas. Tarefas de gestão de configuração de código tais como a criação de rótulos (labels), geração de versões, mesclagem de troncos de desenvolvimento e a manutenção de repositórios podem ser aceleradas e tornadas mais consistentes com o uso destes recursos.  Como exemplo, o Git suporta o conceito de hooks[1], mecanismo extensível de automação de políticas de gestão de código. Outras ferramentas como o GitLab, VSTS ou Atlassian Bamboo já possuem estes mecanismos embutidos.

7.Gestão dos Releases

A gestão dos releases (Release Management) é uma prática que buscar garantir que o processo de promoção do executável para os ambientes de testes, homologação e produção sejam automatizados e assim tornados consistentes. Isso é importante porque em muitas organizações é difícil colocar um produto em ambiente de produção. A demora para acesso aos ambientes, alto número de passos manuais, a complexidade e a dificuldade de analisar os impactos são comuns. Isso gera atritos, longas demoras e desgates entre times de QA, desenvolvimento e operações. E no fim isso também provoca erros nos ambientes de produção.

Esta prática tem como principais benefícios:

• reduzir o tempo para entregar um novo build em ambiente de produção através da automação da instalação e configuração de ferramentas e componentes arquiteturais;
• reduzir erros em implantação causadas por parâmetros específicos que não foram corretamente configurados pelos times de desenvolvimento e operações;
• minimizar a fricção entre os times de desenvolvimento, QA e operações;
• prover confiabilidade e segurança no processo de implantar aplicações.

Um ponto de atenção é que a automação de releases não deve recompilar a aplicação. Para garantir consistência, ela deve garantir que o mesmo executável que foi montado na máquina do desenvolvedor (mesmo conjunto de bits) esteja operando em outros ambientes. Ou seja, a automação de releases faz a movimentação dos executáveis entre os ambientes e modifica apenas os parâmetros da aplicação e variáveis de ambiente. Este processo pode também envolver a montagem de máquinas virtuais em tempo de execução do script.

8. Automação da Monitoração de Aplicações

Ao colocarmos um build em ambiente de produção, devemos buscar que o mesmo não gere interrupções nos trabalhos dos nossos usuários. Infelizmente, muitas empresas convivem com incidentes em ambientes de produção causados por falhas nos processos de entrega em produção e desconhecimento de potenciais problemas.

Uma forma de reduzir a chance de incidentes para os usuários finais é implementar a monitoração contínua de aplicações (Application Performance Monitoring). Esta prática permite que agentes sejam configurados para observar a aplicação em produção. Alarmes podem ser ativados para o time de operações se certas condições de uso forem alcançadas ou se erros inesperados surgirem. Isso permite ter ciência de eventuais incidentes com antecedência e tomar ações preventivas para restaurar o estado estável do ambiente de operações.

E, para melhorar a experiência, alguns times já fazem que estes alarmes sejam enviados através de bots para as ferramentas de comunicação tais como o HipChat ou Slack.

E você, que práticas DevOps está usando no seu dia a dia. Como está sendo a experiência com elas? Compartilhe aqui a sua experiência.

No proximo post, compartilho com vocês 12 práticas avançadas do mundo DevOps.