Foi disponibilizada uma nova versão do Embrapa I/O (a 1.25.2) com algumas novidades. As principais, que serão detalhadas a seguir, são:
- A possibilidade de revalidação de uma build marcada como “inválida” por qualquer membro do projeto (e não apenas Arquitetos de Solução);
- A integração com o SonarQube para aprimoramento do monitoramento de qualidade de código (e, consequentemente, do ativo como um todo); e
- A integração com o Grafana Loki para logging em tempo real dos ativos instanciados nos clusters da plataforma.
I. Revalidação de builds
Uma demanda das equipes dos projetos era a possibilidade de membros comuns poderem disparar o processo de validação de uma build quando esta era marcada como “inválida” durante o processo de deploy. Quando isso ocorre, o pipeline fica parado, aguardando a eventual correção dos problemas apontados. Entretanto, para disparar novamente o processo de validação (e posterior deploy) era necessário que um “Arquiteto da Solução” da equipe do projeto refizesse os passos do wizard de configuração da build (ainda que nada fosse alterado).
Com esta mudança, qualquer membro do projeto pode agora efetuar a correção do erro, fazer o merge na branch de deploy e, em seguida, clicar sobre o ícone de “inválido” do status da build e selecionar a opção “revalidar”. Com isso os pipelines do Embrapa I/O voltam a ser executados, validando e fazendo o deploy automático da build (caso esteja tudo certo).
Observação: Os membros do projeto que não sejam “Arquitetos da Solução” conseguem utilizar este recurso apenas em builds em estágio de alpha e beta, ou seja, em release (produção) ainda será necessário a intervenção do Arquiteto.
II. Integração com o SonarQube
Foi realizada uma integração completa do Embrapa I/O com o SonarQube, que é uma ferramenta de análise estática de código que detecta bugs, vulnerabilidades e problemas de qualidade de software.
Ao acessar a dashboard da plataforma será mostrado agora, para cada aplicação de cada projeto, uma aba com scores:
Estes scores medem (da esquerda para a direita): manutenibilidade do código, confiabilidade, segurança, vulnerabilidade e, por fim, se sua versão mais nova foi “aprovada para entrega”. Este último score (chamado pelo SonarQube de Quality Gate) é um conjunto de regras que determina se um código-fonte enviado atende a determinado padrões de qualidade, podendo ser aprovado ou reprovado.
Ao clicar sobre qualquer um dos ícones, o desenvolvedor será levado à interface do SonarQube (disponível em https://code.embrapa.io), na qual pode autenticar utilizando a conta do GitLab do Embrapa I/O:
Ali será possível visualizar detalhes das issues e corrigí-las de forma apropriada.
Por padrão, o SonarQube está configurado para examinar todos os commits apenas na branch main, entretanto é possível estender para outras branches editando o arquivo .gitlab-ci.yml, presente na raiz do repositório da aplicação. O monitoramento de todo ativo digital no Embrapa I/O é automaticamente configurado pela plataforma e não demanda nenhuma ação dos desenvolvedores.
III. Logging utilizando o Grafana Loki
Outra integração realizada foi com o Grafana Loki, um sistema de logging escalável e eficiente, otimizado para armazenar e consultar logs de forma rápida, sem necessidade de indexação pesada, e integrado ao Grafana para visualização.
Toda stack de containers de aplicações instanciadas na rede de clusters do Embrapa I/O tem seus logs capturados, que podem ser visualizados em tempo real pela equipe do projeto. Há duas formas de acessar diretamente a dashboard no Grafana (disponível em https://log.embrapa.io) com os logs de determinada aplicação: diretamente pelo ícone no card do projeto (que mostrará todas as dashboards daquele projeto) ou no dialog de monitoramento da saúde da build:
O login no Grafana é realizado também utilizando a conta do GitLab do Embrapa I/O:
A plataforma configura automaticamente, para cada aplicação de cada projeto, as dashboards de visualização dos logs, não sendo necessário portanto nenhuma configuração pela equipe de desenvolvedores do projeto. Os logs serão exibidos da mesma forma que são gerados pelo comando docker compose logs [container] -f em ambiente de desenvolvimento. Portanto, para realizar o debug da aplicação, basta imprimir a saída no stdout.
Observação: Para que os logs passem a ser capturados é necessário que a stack de containers tenha passado pelo processo de build e deploy no cluster após a implantação do monitoramento. Se tiver dúvida quanto a isso, pode-se forçar um novo deploy criando uma nova tag de versão na branch correlata.