Como pegar feedback no processo de DevOps - Parte 1
Sempre falam muito que devemos fazer ciclos rápidos e adotar melhores práticas na nossa empresa. Um dos pontos que não vejo é falarem sobre monitorar esse processo todo e o que extrair desses dados de feedback para a nossa aplicação e com isso melhorar nosso modo de desenvolver software e entregar valor para o cliente.
Nesse post vamos falar o que podemos utilizar para capturar essas informações desde da hora do commit, passando pelo processo de build e deploy até a aplicação em produção.
Quando pensamos em monitoramento, pensamos já na fase da aplicação em produção. Porém quando estamos falando do processo de desenvolvimento, nosso monitoramento deve iniciar muito antes. Devemos começar a monitorar nosso processo desde o commit, para conseguir identificar problemas o mais rápido possível.
Vamos ver quais são os tipos de técnicas e ferramentas que nos ajudam a monitorar nosso processo.
Pull Request
Aqui é a primeira técnica que já podemos utilizar para monitorar e entender como anda nosso processo. Através do pull request a equipe consegue fazer uma revisão do código que está indo para produção e nesse proesso, mesmo que ainda de forma manual, já conseguimos identificar algumas coisas:
- A equipe está seguindo os guidelines de nomenclatura de variáveis, métodos, classes e etc que foram definidos?
- A equipe está seguindo a arquitetura proposta?
- O time está seguindo as melhores práticas de desenvolvimento que definiram?
Através dessa análise já conseguimos identificar se o nosso modelo de desenvolvimento está bem inserido no time ou precisamos fazer algum treinamento para que a qualidade do código melhore e todos tenham a mesma visão do que tem que ser feito e como deve ser feito.
Build
Build Privada
O primeiro tipo de build que é importante acontecer é uma build local ou como alguns chamam uma build privada.
É importante garantirmos que o código que estamos realizando o commit não possua problemas, caso contrário iremos contaminar nosso repositório e isso poderá ser espalhado entre as pessoas que estão desenvolvendo o sistema em conjunto com a gente.
Inserir código quebrado no nosso repositório pode gerar problemas em alguém que estava trabalhando normalmente. Imagina que esse desenvolvedor resolve fazer uma atualização do repositório local. Ele vai trazer o código com problemas de outro membro do time e com isso não vai mais conseguir trabalhar e vai acabar perdendo tempo tentando arrumar o problema.
Idealmente, nessa build privada, para tentar diminuir a chance de inserir problemas no repositório o desenvolvedor deveria rodar:
-
Build local: Com isso vamos saber se a nossa alteração fez o sistema parar ou não de compilar.
-
Execução de testes de unidade: Com isso conseguiremos verificar se nossa alteração adicionou algum problema no sistema.
-
Execução de análise estática de código: Com isso vamos identificar se estamos seguindo as melhores práticas definidas pelo time, além de identificar se estamos trazendo problemas de segurança, possíveis bugs, duplicação de código ou débito técnicos. O time pode até definir várias regras na ferramenta, porém nessa primeira análise podemos executar apenas os mais críticos, deixando para um segundo momento uma validação mais completa.
Passando por todas essas validações o desenvolvedor já tem confiança que seu código não trará problemas para o time todo. Feito isso, seguimos para o segundo passo: monitoramento de build.
Build Automatizada
O próximo ponto de controle seria a criação de uma build automatizada.
Nesse momento iremos adicionar uma automação no repositório, através de uma branch policies ou até mesmo ligar o sistema de CI para uma branch ou branches do repositório, para quando alguém fizer um push nós iremos executar automaticamente uma build. Com isso iremos monitorar o processo de integração do código que acabamos de criar com o novo código dos outros desenvolvedores do time.
Nessa automação, podemos executar várias atividades que monitorarão nosso processo. No meu entender existem algumas principais que são importantes:
-
Compilação do código: Nesse momento vamos verificar se todos os artefatos necessários para compilar o projeto realmente estão versionados. Quando o desenvolvedor compila na própria máquina a build pode funcionar e não ter nenhum problema. Agora imagina que ele esqueceu de commitar algum arquivo novo que ele estava trabalhando. Nesse momento quando ele executar o push, a nossa automação será executada e quando tentar a compilação ela falhará já vamos pegar esse erro. Com isso o desenvolvedor pode rapidamente fazer um novo commit arrumando o problema e evitando que o erro seja introduzido na nossa base de código.
-
Execução de testes: Novamente vamos executar os testes de todo o time e garantir que esteja tudo funcionando de acordo com as premissas definidas. Nesse momento podemos executar mais testes além do de unidade. Podemos executar testes de componentes por exemplo para ver como está a interação dentro do nosso sistema.
-
Validação de dependências: Como estamos executando em um servidor novo e sem nenhuma configuração pré-existente do projeto, nós conseguimos identificar se todas as dependências que o projeto precisa estão versionadas ou configuradas para serem obtidas de repositórios externos, como o Nuget ou Azure Artifacts.
-
Validações de segurança: Podemos executar validações de segurança nos pacotes públicos que nossa aplicação utiliza e garantir que não existem vulnerabilidades conhecidas.
-
Análise estática de código: Nessa etapa podemos executar uma análise estática mais completa. Nela iremos identificar problemas de padrões que não estão sendo seguidos e potenciais problemas que estamos trazendo para o nosso repositório desde dificuldade de manutenção do sistema até problemas de segurança. Nesse momento podemos pensar em métricas que nos ajudarão a entender como está a qualidade do nosso código, como por exemplo complexidade ciclomática, dependência entre os objetos, cobertura de código entre outras. Essas métricas vamos nos dizer se é fácil ou complicado fazer alterações no nosso código. Quanto mais complicado fazer alterações, mais tempo levaremos para desenvolver e com isso mais tempo levaremos para entregar valor para os nossos clientes.
-
Empacotamento: Nessa etapa veremos se conseguimos empacotar a aplicação do jeito correto para que possamos fazer o deploy nos ambientes de não produtivos e produção. Esse nosso pacote deve contém todos os arquivos necessários, scripts de instalação e configuração e também informações de banco de dados.
Só com essas validações, já conseguimos ter um processo de monitoramento do nosso modelo de desenvolvimento bem sólido e com várias informações que podemos usar para melhorar nossa aplicação e garantir a qualidade do nosso sistema.
Conforme vimos, conseguimos identificar gaps de modo de desenvolvimento do time e já traçar estratégias para diminuir esses gaps, como por exemplo através de treinamentos para a sua equipe. Além de garantir qualidade através das validações automáticas e métricas extraídas no processo.
Como está ficando meio extenso, no próximo post eu vou falar dos próximos passos que seriam Release e monitoramento da aplicação em produção.
Espero que tenha gostado e se tiver alguma dúvida específica me manda um e-mail ou deixe nos comentários.
Até a próxima, Claudio Romão
11/02/2020 | Por Claudio Romão | Em Técnico | Tempo de leitura: 6 mins.
