Todo time tem um estagiário

Durante uma apresentação sobre Microserviços, o meu amigo Fabricio Sanchez apresentava o ambiente de desenvolvimento do ARDA (https://github.com/dxbrazil/arda). Eu não estava nesse evento, mas soube que a demonstração falhou no momento da integração entre os microserviços. Naquele naquele dia, “por coincidência”, nosso estagiário fez um checkin de código. Não é uma afirmação, mas suspeito que esse commit tenha comprometido o ambiente de desenvolvimento.

Talvez eu tenha exagerado um pouco na história. O fato é que todo time tem um “estagiário” – seja ele um estagiário de verdade ou não.

Existem cuidados importantes a serem tomados para evitar problemas decorrentes de descuidos dos desenvolvedores. Qualquer um pode errar (embora a culpa seja sempre do estagiário).

Nunca faça commit de código quebrado

A regra é nunca fazer checkin de código que não possa ser compilado, ou seja, o código no repositório sempre gera um build válido.

Recentemente tivemos um problema assim. Houve um commit que impedia o build do sistema porque um dos arquivos tinha erros de sintaxe. Provavelmente o “estagiário” fez o commit sem fazer o build do projeto antes. Em seguida, duas pessoas do time continuaram o trabalho a partir desse commit que não fazia o build. Ambos corrigiram a sintaxe e trabalharam em suas features individuais. Entretanto, na hora do push para o repositório central, houve um conflito de versão, pois ambos mexeram no mesmo arquivo.

Logo no começo do projeto, implementamos os processos de Continuous Integration (CI) e Continuous Delivery (CD). A ideia era fazer o deploy rápido para o ambiente de produção, mas encontramos outros benefícios.

Continuous Integration (CI)

Configuramos o VSTS (www.visualstudio.com) para realizar o build sempre que houvesse um commit no repositório. O build demorava entre 2 a 8 minutos – isso variava muito com o número de projetos a serem compilados, as dependências e versão do .NET Core.

A melhor forma de se proteger contra estagiários criativos ou descuidados é ter um sistema de Continuous Integration (CI). Se o build fosse realizado com sucesso, então um relatório com sinal verde era apresentado. Caso contrário, o relatório teria sinais vermelhos (ou amarelo) e enviava um email de alerta.

Esse processo ajudava a evitar o problema do “projeto que só compila na máquina do fulano X”.

Continuous Delivery (CD)

Implementamos também o Continuous Delivery (CD), que é uma continuação do Continuous Integration (CI). Depois de finalizado o processo do Build, o deployment é feito em etapas para os diferentes ambientes.

Uma feature que adicionamos foi de rodar testes funcionais para detectar bugs de regressão. Colocamos um script Powershell para rodar no ambiente de staging.

Esse script era uma validação simples de bugs que afetava o ambiente. O script do Kanban corrigia uma falha introduzida após o upgrade de versão do .NET Core, que mudava a configuração padrão de serialização do JSON.

Services return JSON in Pascal Case instead of Camel Case
https://github.com/DXBrazil/Arda/issues/82

A fim de evitar que esse bug fosse reintroduzido no código, adicionamos essa validação funcional:

O tempo investido no nosso processo de CI/CD sempre teve retorno rápido.

Conclusão

O investimento nos processos de CI/CD tiveram retorno imediato, pois conseguimos manter a confiança de que o código no VSTS/GitHub sempre produz um build válido.

Planejando o time: para cada hora de desenvolvimento de código, dedique uma hora para DevOps.

Parece um desperdício de tempo, mas vale a pena!

Não se esqueça que todo time tem um “estagiário”.