Configurações Jenkins - Gitlab - Sonar

Olá Thalysson,

respondendo as duas primeiras dúvidas, você consegue configurar o Jenkins para ele automaticamente fazer push em repositório, mas ele interceptar um push antes de entrar no repositório remoto daria um baita trabalho.

O que eu te aconselho a fazer um sistema de duas branchs. A primeira é uma branch para os desenvolvedores fazerem o push automático no repositório remoto, por exemplo, uma branch work. E a segunda é a branch do código que vai para produção, por exemplo, master.

Toda vez que entra uma alteração na work o Jenkins pega as alterações e roda os testes. Se eles passarem, existem duas opções aqui:

1. O Jenkins faz um deploy num ambiente de homologação, que simula o de produção, mas serve para testes manuais. Ai se o cliente/usuário aprovarem as alterações neste ambiente de testes o time pode fazer o merge/rebase dos commits na work com a branch master.

2. O Jenkins faz o commit do que tem na work na master automaticamente. Aqui um link de como configurar o Jenkins para dar commits e push automaticamente.

Quanto as outras perguntas sonar, cucumber eu não manjo como faz no jenkins. Geralmente quando vou caçar algo novo no Jenkins eu dou uma olhada na wiki de plugins deles para ver se acho alguma coisa já pronta. Por exemplo, caçando rapidinho achei este link de um plugin do cucumber para gerar relatórios de acordo com a resposta que ele devolve quando você roda os teste.

Olá lucas, Boa noite!

Agradeço pela resposta, ajudou a esclarecer alguns pontos. Sobre o sonar, cucumber e etc, o Romulo poderia responder algo? No curso de jenkins ele trata sobre os assuntos que comentei.

Obrigado.

Oi Thalysson, tudo blz?

Deixa eu dar uma complementada na resposta do Lucas trazendo uma forma de trabalho que a gente costuma ver por aí de vez em quando, e que vai de encontro à necessidade que você descreveu.

Considerando uma prática bastante usada no mercado, para você fazer a checagem de qualidade de código antes de enviar o código para o seu branch principal você precisa ajustar um pouco o seu fluxo de trabalho.

a) Na hora de desenvolver uma nova funcionalidade ou corrigir um bug, cada desenvolvedor trabalha no seu próprio branch e você define um padrão de nomenclatura como, por exemplo: */features/NOME_DA_FEATURE ou */bugfix/DESCRICAO_DO_BUG

b) Daí você configura no seu arquivo de build (pom.xml, no caso do curso) as opções de análise estática que você deseja (findbugs, pmd e/ou checkstyle) e cobertura de testes (a gente tá usando o JaCoCo no curso).

Ainda sobre a análise estática, lembre-se de usar as configurações que falham o build em caso de não conformidade com algum critério, caso seja isso que você queira. O ideal, também, é sobreescrever/complementar as regras de cada ferramenta com as suas próprias regras.

c) Então você cria no Jenkins um job que vai fazer o quality enforcement em cima dos branches de features e bugfix. Nesse job você configura a seção SCM/GIT informando os branches conforme o padrão de nomenclatura que você definiu, no exemplo que eu dei ficaria assim: */features/* e */bugfix/*.

Plus 1: A gente costuma, também, configurar o Jenkins para notificar o repositório git se o build passou ou falhou - isso pode ser útil para bloquear o merge, por exemplo - mas essa configuração depende dos serviços que você está usando... no Github você consegue fazer tudo via plugins... no Gitlab eu já não sei como faz - sorry :(

d) Nesse mesmo job você configura o JaCoCo Plugin para checar a cobertura de testes conforme o threshold definido e falhar o build, se for o caso. JaCoCo Plugin

e) Com essa configuração feita, em todo push enviado para um branch de funcionalidade/bugfix o job de QE (quality enforcement) vai ser executado e você consegue saber (via notificações, preferencialmente) se algo está errado. Importante notar que, embora tenhamos um job só, ele executa em cima dos branches isoladamente.

f) Se tudo está ok e o trabalhado finalizado, o desenvolvedor está apto a fazer o merge para um branch de integração (que a gente costuma chamar de branch de desenvolvimento) - este branch é interessante porque nele você consegue checar se uma funcionalidade introduziu defeitos em outras.

Plus 2: Idealmente, esse merge só será feito após uma revisão de código via Pull Request.

Plus 3: Alguns times não gostam desse branch de integração e fazem o merge direto para o master, você vai ver isso referenciado como boa prática algumas vezes, mas eu, particularmente, não gosto.

Com isso, você tem um processo que garante que somente código-fonte dentro dos requisitos estabelecidos de qualidade vai passar adiante.

Desculpe a demora na resposta, Thalysson. Espero que chegue em tempo de ajudar.

Você conseguiu captar a ideia do fluxo que tentei passar acima? As configurações são bem específicas e dependem bastante dos fornecedores que você está usando, mas o mais importante é entender o fluxo. Se você precisar de ajuda com algum detalhe de configuração, posta aí que a gente te ajuda.

Grande abraço,

Romulo

Oi Thalysson,

"Sobre o sonar, cucumber e etc, o Romulo poderia responder algo?"

Sobre os relatórios, com o setup que a gente faz no curso os relatórios podem ser visualizados no Sonar. Para você ver os relatórios na sua pasta target, em formato html, você pode seguir os exemplos descritos na página do Plugin, mais especificamente esse pom.xml, para relatórios cobertura de testes unitários, e esse outro pom.xml, para relatórios de cobertura de testes unitários e de integração separados.

Sobre a sua questão quanto a identificação do usuário no Sonar, ele vai utilizar o usuário git, conforme você indicou, eu só não sei te dizer exatamente como vai ser o comportamento no Gitlab em relação ao link com o usuário LDAP.

Grande abraço, Romulo.

Olá Romulo,

Agradeço pela resposta. Irei realizar alguns testes e informo se funcionou. Como criei o usuário comum entre Gitlab, Jenkins e Sonar, quando o usuário faz o commit para o repositório o Jenkins identifica o usuário (LDAP). Porém, como é o próprio Jenkins que envia para o Gitlab (outro repositório), o sonar está visualizando apenas o usuário que de fato faz a autenticação. Vou tentar organizar o cenário seguindo a orientação que vocês passaram.

Obrigado.

Beleza, Thalysson.

Mantém a gente atualizado com seu progresso. Eu vou concluir essa thread, mas fica totalmente a vontade para abrir novamente se necessário.

Grande abraço, Romulo.