5 dicas para entregar código mais rápido sem quebrar a produção

Todo desenvolvedor quer entregar tarefas rapidamente, mas sem comprometer a qualidade em produção.

Velocidade no desenvolvimento não se resume ao tempo gasto, mas à percepção de velocidade. Ferramentas ajudam, mas o verdadeiro ganho vem de otimizar o trabalho diário.

Muitos culpam burocracia, falta de conhecimento ou ferramentas ruins, mas os vilões principais são:

• Bugs e retrabalho:

Consomem tempo ao normalizar entregas com erros.

• Preciosismo técnico:

Foco excessivo em detalhes desnecessários.

• Estimativas erradas:

Criam percepção de lentidão.

Melhorar esses pontos faz você parecer mais rápido e confiável.

Dica 1: Entenda o problema antes de programar

Não corra na direção errada.

Faça análise de requisitos: Converse com o usuário para explorar o problema real, sem documentações gigantes.

Evite resolver o problema errado, que gera bugs, retrabalho e perda de confiança.

Resolver o problema errado gera muito mais transtorno.

Dica 2: Monte um planejamento claro

Organização não é burocracia, é investimento.

Crie lista de tarefas: Tire tudo da cabeça (Excel, Word, Trello).

Defina orçamentos: Estimativas por tarefa para saber o prazo total.

Ganhe foco: Saiba o que fazer agora, sem distrações.

Planejamento mostra a luz no fim do túnel.

Dica 3: Priorize a solução, não os detalhes

Resolva o problema primeiro, melhore depois.

Evite:

• Perfeccionismo técnico e overengineering.
• Priorizar como dev: Foque em regras de negócio, não em telas ou banco logo de cara.

Entregue resultado cedo para aumentar a percepção de velocidade, como nos métodos ágeis.

Dica 4: Faça testes consistentes

Teste contra requisitos, não contra sua memória.

Crie roteiros de teste: Descreva ações e resultados esperados.

Use testes unitários: Rápidos, repetíveis e rede de proteção.

Evite teste viciado (debugando apenas o que lembra), que cria falsa segurança.

Dica 5: Refatore sem dó (com jogo ganho)

Melhore o código após resolver o problema.

No início, priorize funcionalidade; no final, clareza e performance.

Testes protegem: Quebre e reconstrua com segurança.

Exemplos: Como time de futebol com placar favorável ou compras no mercado sem fome.

Passo a Passo para aplicar

Os ajustes a seguir são um passo a passo para melhorar a entrega sem depender de ferramentas ou IA

Siga na sequência para máximo impacto:

Dica extra: Vá devagar e sempre. Ferramentas e IAs potencializam, mas não substituem maturidade.

Considerações finais

Vá devagar e sempre: Resultados pequenos não desanimem; dificuldades não parem o progresso.

Ferramentas potencializam, não substituem: Sem base sólida, IAs e ferramentas entregam "esgoto".

Maturidade é o segredo: Velocidade real vem de prática e processo, não de fórmulas mágicas.

Aplique em uma demanda e veja a diferença na percepção de velocidade!

Feito!

3 dicas essenciais para resolver bugs como um Dev Sênior

Já parou para pensar por que alguns colegas sênior resolvem bugs em minutos, enquanto você fica horas (ou dias) preso no mesmo problema? A experiência conta, mas há estratégias simples que fazem toda a diferença. No presente artigo, vou compartilhar essas abordagens práticas para você elevar seu jogo. Não precisa ser expert em testes unitários para aplicar isso, vamos focar no essencial.

Por que resolver bugs é um desafio comum?

Muitas empresas priorizam velocidade sobre qualidade, resultando em testes superficiais ou inexistentes. Isso forma devs que não dominam testes, mesmo pedindo testes unitários nas vagas. Testes unitários são cruciais para sênior, mas se você ainda não os usa, há maneiras de ser eficiente sem eles.

O problema? Devs correm para alterar código no palpite, sem simular ou entender o erro, o que leva a correções superficiais e novos bugs. Vamos mudar isso com três dicas acionáveis.

• Dica 1: Simule o erro antes de mexer no código

Parece óbvio, mas a maioria ignora: antes de alterar qualquer linha, reproduza o bug exatamente como o usuário relatou. Isso direciona você à causa raiz, não ao sintoma.

Por que isso funciona?

Logs ou debugs mostram sintomas (ex.: "null reference"), mas o problema pode estar upstream, como uma consulta retornando dados errados.

Simulando, você cria um "gabarito" para validar a correção: repita os passos e veja se o erro some. Se persistir, você alterou o lugar errado.

Como aplicar no dia a dia?

Colete evidências concretas: Peça screenshots de tela, logs ou dados do usuário. Sem acesso a produção? Insista, é essencial.

Rastreie o caminho inverso: Comece pelo erro (ex.: busque a mensagem no código via Ctrl+Shift+F) e volte até a origem.

Simule como usuário: Imitar ações com os dados problemáticos revela o fluxo real, evitando desculpas como "não tenho permissão".

• Dica 2: Divida o erro em partes menores

Bugs grandes assustam (ex.: impacto em 350 mil registros), mas lembre: a maioria é pequena na correção, mesmo que demore para diagnosticar. Divida para conquistar.

O Erro comum dos iniciantes

Olhar o "tudão" (ex.: rotina que faz 350 coisas) causa paralisia e alterações aleatórias, corrigindo sintomas e criando novos problemas. Respire e fatiar: problemas pequenos são fáceis de resolver.

Estratégias práticas

Mapeie fluxos principais: Liste fluxos do sistema (em wiki ou Excel, não na cabeça). Elimine os irrelevantes para focar.

Encontre o ponto exato: Use evidências da simulação para isolar (ex.: um if errado em lógica de data pode levar horas para achar, mas 5 minutos para fixar).

Crie lista de tarefas: Anote candidatos a correção (ex.: "analisar ponto X"). Divida análises grandes, não confie na memória.

Exemplo real: Um bug de validação de data (período >1 ano) veio de contagem errada no componente (meses zerando dias). Demorou para achar, mas corrigiu rápido com teste unitário. s s Bugs tendem a ser "pequenos", foque nisso para calma e velocidade.

• Dica 3: Aprenda a mexer no software que você trabalha

Conhecer o software além do código (regras de negócio, fluxos de uso) é subestimado, mas valorizado pelas empresas, mais que tecnologia em alguns casos.

Benefícios para resolver bugs

Levante hipóteses: Saiba perfis de uso para prever problemas (ex.: loop em pedidos grandes causando performance).

Ganhe autonomia: Decida se uma alteração faz sentido sem pedir aprovação constante, acelerando correções.

Valor no mercado: Devs "dinossauros" ficam sênior por conhecer legados; some isso a tecnologia e você brilha.

Como desenvolver esse conhecimento

Ponto de Vista do Usuário: Pergunte "por quê?" e "para quê?" em demandas, revela regras e negócio. Observe uso real (não só seus testes repetitivos).

Ponto de vista do Dev: Altere com atenção, note fluxos críticos (ex.: áreas com bugs recorrentes). Questione motivadores do código ("por que essa regra?").

Aproveite análises tranquilas: Em requisitos ou features novas, estude código e regras sem pressão de produção.

Isso enriquece seu currículo com conhecimento de negócio prático.

Considerações finais

Essas dicas, simular erros, dividir problemas e conhecer o software, são ajustes simples no seu processo, inspirados em análise de requisitos. Elas te levam à maestria sênior, mesmo sem testes avançados.

Dica Extra: Testes unitários aceleram tudo, crie um para validar correções e evite regressões. Comece devagar; os benefícios vêm com a prática.

Aplique isso no próximo bug e veja a diferença.

Feito!

O papel essencial do QA

Em muitos times de desenvolvimento, ainda é comum observar QAs que, ao encontrar um bug, simplesmente enviam uma mensagem rápida no Teams ou no WhatsApp: "Está com bug".

Mas esse tipo de comunicação, apesar de aparentemente ágil, causa retrabalho, atrasos, tensões desnecessárias entre Dev e QA e afeta diretamente a qualidade da entrega final.

Posso afirmar com segurança: achar o bug é apenas metade do trabalho. A outra metade é documentá-lo corretamente.

E é exatamente isso que diferencia um QA júnior de um QA profissional, maduro e reconhecido pelo time.

No presente artigo explica por que a documentação clara dos passos para reprodução do bug é essencial, como isso melhora a eficiência do time e como construir essa prática na rotina.

Por que só avisar que "tem bug" não funciona?

Quando o QA apenas informa verbalmente que encontrou um defeito, sem detalhar:

• O desenvolvedor não sabe exatamente como reproduzir o problema.
• O Dev tenta adivinhar o cenário ou pergunta várias vezes, gerando atrasos.
• A correção pode ser feita de forma errada ou incompleta.
• O time perde confiança nos resultados.
• O QA perde credibilidade e passa a ser visto como alguém que "só aponta erros", e não como alguém que aumenta qualidade.

Do ponto de vista técnico, isso quebra um dos pilares fundamentais da qualidade:

Rastreabilidade e repetibilidade do defeito.

Um bug sem passo a passo não é um bug: é uma suspeita.

O papel verdadeiro do QA: garantir que o bug seja 100% reproduzível

O QA especialista não entrega apenas um defeito.

Ele entrega uma evidência clara, passo a passo, ambiente, dados utilizados, resultado atual e resultado esperado.

Assim, quando o Dev pega a tarefa, ele consegue:

1. Reproduzir exatamente o mesmo comportamento.
2. Entender o contexto em que ocorre o problema.
3. Verificar o código enquanto compara com o cenário reproduzido.
4. Ajustar e testar novamente antes de enviar para revalidação.

Essa cadeia reduz drasticamente o tempo de correção.

Por que o Dev precisa dos passos de reprodução antes de ir para o código?

Porque nem todo bug é logicamente óbvio.

Alguns dependem de:

• condições específicas
• dados particulares
• combinações de ações
• tempos de resposta
• estados anteriores da aplicação
• permissões de usuário
• ambiente (homologação, dev, staging)

Sem isso, o Dev pode até olhar o código, mas não verá o problema.

E quando não vê o problema, surgem falas assim:

• "Aqui está funcionando normal."
• "Não consegui reproduzir."
• "Pode testar de novo?"

E o ciclo vicioso continua.

Documentar bem um bug acelera o trabalho do Dev

Muitos QAs acham que escrever passos é perda de tempo.

Na verdade, é o contrário.

Quando o QA registra o defeito de forma clara em ferramentas como:

• Jira
• Trello
• Redmine
• Ou qualquer plataforma definida pela empresa

ele está:

• economizando horas de retrabalho,
• reduzindo conversas paralelas desnecessárias,
• aumentando a assertividade,
• e tornando o time mais maduro.

Esse é o comportamento reconhecido em QAs certificados e seniores.

Como um QA especialista descreve um bug corretamente

Abertura profissional de bug inclui os itens abaixo:

1. Título claro

Exemplo:

"[Checkout] Sistema não aplica cupom de desconto válido"

2. Ambiente

Homologação

Develop

Staging

Navegador

Versão do app

3. Pré-condições

Usuário logado

Produto X no carrinho

Cupom ABC123 ativo

4. Passos para reproduzir

Acessar o carrinho.

Inserir o cupom “ABC123”.

Clicar em aplicar.

5. Resultado atual

O cupom não é aplicado e nenhuma mensagem é exibida.

6. Resultado esperado

O cupom deve ser aplicado e exibir o valor atualizado.

7. Evidências

Screenshots

Vídeo da execução

Logs (se houver)

A visão do QA profissional: qualidade é processo, não improviso

Um QA que deseja crescer na carreira, chegar a especialista, líder, analista sênior ou até automação, precisa demonstrar profissionalismo na forma como registra defeitos.

Qualidade não é só testar.

Qualidade é garantir que o time consiga reproduzir, corrigir e validar corretamente.

Se você quer trabalhar em empresas mais maduras, com cultura ágil e engenharia avançada, saiba:

reportar bug com qualidade é pré-requisito básico.

Nenhum QA certificado ou sênior abre bugs sem:

• passos de reprodução
• contexto
• evidência
• resultado atual x esperado

Considerações finais

QA não aponta problemas, QA resolve problemas junto com o time.

A real eficiência entre Devs e QAs acontece quando:

• QA documenta com clareza
• Dev consegue reproduzir sem dificuldade
• Correção é feita rapidamente
• Retrabalho é reduzido
• O time entrega com mais previsibilidade

Se você é QA e hoje apenas encontra bugs e avisa em grupos de chat, sem detalhar, saiba:

Essa prática pode estar prejudicando não apenas o time, mas sua evolução como profissional.

Adotar essa mudança coloca você em outro nível.

E o time inteiro sente a diferença.

Feito!

Guia completo das cerimônias Scrum

O Scrum é um dos frameworks ágeis mais adotados no mundo, mas muitos times ainda enfrentam dúvidas sobre como integrar corretamente as cerimônias da Sprint ao fluxo de preparação das estórias , especialmente no Backlog, no uso da Definition of Ready (DoR), Definition of Done (DoD) e na ordem certa dos status até chegar ao Refinamento e Planning.

No presente artigo você verá:

• Como funcionam todas as cerimônias do Scrum
• Como organizar o Backlog da forma correta
• Quais são os status ideais das estórias antes da Planning
• Como aplicar DoR e DoD

Fluxo de Backlog e status das estórias antes da Sprint

Para garantir uma Sprint eficiente, o fluxo das estórias deve seguir uma linha clara antes de chegar ao Refinamento e, posteriormente, à Sprint Planning. Isso evita dúvidas, retrabalho e reuniões demoradas.

1. Product Backlog (Backlog Inicial)

Aqui ficam as estórias ainda não refinadas, recém-criadas pelo PO ou pelo time.

Status comuns:

- Novo Item / Ideia

- Rascunho

- Aguardando Detalhamento

- Aguardando Critérios de Aceite

Neste estado, a estória não deve ser estimada nem levada para Planning.

2. Pré-Refinamento

O PO estrutura a estória para apresentá-la ao time.

Status comuns:

-Em Pré-Refinamento

-Aguardando alinhamento com PO

-Aguardando estimativa

A estória já tem descrição e direção, mas ainda não está “pronta” para o time.

3. Definition of Ready (DoR): Pronta para Refinamento

Antes do Refinamento técnico, a estória deve cumprir a DoR (Definition of Ready).

Uma estória está Preparada para Refinamento quando:

- Tem descrição clara

- Possui critérios de aceite completos

- Possui regras de negócio definidas

- Tem protótipos ou telas (quando aplicável)

- Não há dúvidas básicas sobre o contexto

- O PO está disponível para tirar dúvidas

Esse passo evita Refinamentos improdutivos.

4. Refinada e Estimada: Pronta para Planning

Após o encontro de Refinamento com Devs, QA e PO, a estória ganha mais maturidade.

Status ideais:

-Refinada

-Estimada

Pronta para Sprint Planning

Ready for Sprint

Aqui ela já:

- Tem Story Points definidos

- Devs entendem como implementar

- QAs sabem como testar

- Dependências estão mapeadas

- Impacto e riscos estão claros

- Só depois disso a estória pode entrar na Sprint.

5. Definition of Done (DoD): Conclusão de estória

Quando implementada, testada e entregue, a estória precisa atender a DoD.

A Definition of Done pode incluir:

- Código revisado

- Testes unitários implementados

- QA validado

- Critérios de aceite cumpridos

- Deploy em ambiente de homologação

- Documentação atualizada

Esse checklist garante qualidade e previsibilidade no final da Sprint.

Cerimônias do Scrum com o fluxo de Backlog integrado

Agora que entendemos o ciclo completo das estórias, vamos para as cerimônias e onde cada etapa se encaixa.

1. Daily Scrum (Daily Stand-up)

A Daily mantém o time sincronizado diariamente.

Objetivo:

- Alinhar o andamento da Sprint

- Identificar impedimentos rapidamente

Ajustar o plano da Sprint

Responder as perguntas clássicas:

O que fiz ontem?

O que farei hoje?

Tenho impedimentos?

Duração: 15 minutos

Participantes: Devs, QA, Scrum Master, Coordenador de Projetos, PO (opcional), Gestor (opcional)

A Daily não é momento para debater soluções técnicas. Esses alinhamentos devem acontecer depois da reunião, entre quem realmente precisa participar.

2. Sprint Review

A Review é realizada no final da Sprint e serve para mostrar ao PO e stakeholders tudo o que foi concluído.

O que acontece na Review?

Os Desenvolvedores apresentam screenshots e/ou demonstrações reais das estórias que foram validadas pelos QAs

O Product Owner avalia, comenta e confirma a entrega

Caso sejam identificados ajustes, eles viram novas estórias para Sprints futuras

Por que é importante?

A Review comprova transparência e garante que todos estão alinhados sobre o incremento entregue.

Participantes: Devs, QAs, Scrum Master, Coordenador de Projeto, Gestor, PO

3. Sprint Retrospective

A Retrospectiva é uma das cerimônias mais importantes do Scrum, pois é nela que o time melhora o processo.

Estrutura recomendada:

O que não deu certo? 10 minutos

Time lista falhas, gargalos e dificuldades.

Geram-se pontos de ação para serem aplicados na próxima Sprint.

O que deu certo? 10 minutos

Celebrar conquistas

Valorização do trabalho

Reforço das boas práticas

Fechamento

Revisão dos pontos de ação

Compromisso de aplicar as melhorias na próxima Sprint

Participantes: Devs,QA, Scrum Master, Coordenador de Projetos, Gestor, PO

4. Refinamento (Grooming)

O Refinamento é essencial para que a Planning seja rápida, eficiente e objetiva.

Objetivos do Refinamento

Devs e QAs tiram dúvidas com o PO

Ajustes nos critérios de aceite

Estórias são estimadas antecipadamente

Identificação de riscos, dependências e complexidades

Por que isso é importante?

Quando as estórias já estão prontas, claras e estimadas, a Planning flui muito melhor e economiza tempo do time.

Participantes: Devs, QAs, Scrum Master, Coordenador de Projeto (opcional)

5. Sprint Planning

A Planning marca o início da Sprint e define o que o time vai entregar.

Etapas principais:

Revisar estórias refinadas

Selecionar o que cabe na Sprint usando a capacidade (velocidade) do time

Definir a Meta da Sprint

Quebrar em tasks técnicas, se necessário

Parcipantes: Devs,QA,Scrum Master, PO, Gestor, Coordenador de Projetos

A Sprint começa oficialmente após o término da Planning.

Duração: 15 dias

Considerações finais

Integrar o fluxo do Backlog, as definições de DoR e DoD e as cerimônias oficiais do Scrum garante organização, previsibilidade e qualidade contínua. Times que seguem esse fluxo:

• Entregam as estórias mais assertivas
• Evitam retrabalho
• Diminuem dúvidas
• Aumentam a qualidade do produto
• Alcançam maturidade ágil real

Feito!

3 dicas essenciais para fazer entregas mais previsíveis

A previsibilidade nas entregas é um fator crucial que separa um desenvolvedor júnior de um sênior, e um dev que apenas programa de um profissional que gera confiança na gestão. Se você é um dev que cumpre o que promete, você demonstra comprometimento e maturidade profissional, qualidades que o colocam em posição de subir de nível na carreira.

Mas o que é uma entrega previsível?

Uma entrega previsível é aquela que gera previsibilidade para a gestão, permitindo que eles façam um planejamento baseado naquilo que você informa.

Um dev que não tem essa noção de previsibilidade atrapalha o planejamento da equipe e o andamento do todo, o que é um sinal de imaturidade profissional. Para evitar isso e se tornar um profissional mais confiável, siga estas três dicas fundamentais:

1. Aprenda a planejar o seu trabalho

O planejamento é a base de tudo. Muitos devs, especialmente os iniciantes e plenos, cometem o erro de negligenciar essa etapa, muitas vezes por uma interpretação equivocada de metodologias ágeis.

Planejar não é burocracia inútil é uma etapa essencial (o próprio Scrum tem a reunião de Planning). Sem planejamento, tudo o que você faz é baseado em um eu acho ou em um sentimento (feeling).

Riscos da falta de planejamento

Esquecimento: Você foca em um ponto e esquece de outras coisas importantes que estavam "só na sua cabeça".

Acúmulo de trabalho: O trabalho que faltou se acumula para o final do prazo, resultando em trabalho mal feito ou gambiarra.

Como planejar de forma eficaz

Um planejamento bem feito permite que você entenda o tamanho das encrencas e tenha uma visão geral do que precisa ser feito.

1. Defina um tempo fixo (time box):

Estabeleça um limite de tempo (ex: um dia) para o planejamento. Isso é crucial para evitar que você se afogue em planejamento e esqueça de trabalhar.

2. Entenda o problema e o requisito:

Antes de escrever código, pare para entender o porquê da alteração e a necessidade do usuário. Entender o problema é o primeiro passo antes de discutir esforço ou tempo.

3. Divida o problema em etapas:

Toda solução pode ser dividida em partes menores. Essa divisão ajuda a enxergar o trabalho, identificar o que pode ser feito em paralelo e o que é pré-requisito.

4. Crie uma lista de tarefas:

Transforme as etapas divididas em pequenas tarefas de desenvolvimento (ex: falar com o arquiteto, alterar sistema de cadastro, fazer cálculo no relatório).

Ter uma lista de tarefas é essencial; sem ela, você vai esquecer alguma coisa e terá retrabalho no final.

2. Aprenda a orçar o esforço

O orçamento de esforço é uma cobrança que acompanhará o dev por toda a carreira. A empresa precisa dessa previsibilidade para Time to Marketing (não perder o bonde da venda), questões regulatórias e para o gestor administrar o budget (gerenciar o pagamento da equipe).

Orçamento é palpite, não premonição

É fundamental entender que o orçamento sempre será um palpite (chute), independentemente da metodologia (pontos, Fibonacci, etc.).

Previsão é diferente de premonição. Você não está adivinhando o futuro, mas sim dando uma expectativa baseada nas informações que possui.

Orçar é uma habilidade que exige treino e prática constante, como chutar no futebol.

Como orçar com mais precisão

1. Tenha um planejamento:

Não existe orçamento sem planejamento e sem uma lista de tarefas. Tentar orçar uma "coisona" (tarefa gigante) é como chutar em um gol pequeno, a chance de erro é altíssima.

2. Garanta a granularidade:

Quanto mais detalhe e mais granular forem as tarefas, maior será a chance de acertar e, geralmente, maior será o orçamento (podendo ser 2x ou mais que o chute inicial).

3. Orce em grupo (sempre que possível):

Fazer orçamentos em grupo (como na Planning do Scrum) é muito mais eficiente do que fazer sozinho, pois permite um duplo check e a comparação de diferentes pontos de vista.

4. Conheça sua capacidade atual:

O autoconhecimento é vital. Se você não tem noção do quanto consegue produzir, você sempre errará o orçamento, superestimando ou subestimando o esforço necessário.

3. Comunique o status sempre que puder

Este é um erro comum de iniciantes: o medo de incomodar o gestor ou de dar a má notícia de um atraso.

O verdadeiro problema não é o atraso em si (a empresa tem tolerância), mas sim não avisar sobre o atraso com antecedência.

Se você avisa com dias ou semanas de antecedência, o gestor consegue negociar e tomar uma atitude. Se você avisa na véspera, não há mais tempo para nada.

A maior força de um profissional é conseguir assumir os seus erros e enxergar onde errou. Esconder a informação é agir como criança, não como adulto.

Comunicação em tarefas críticas

Quanto mais crítico é o que você faz, maior é a pressão e mais necessária se torna a sua comunicação. Sumir com uma tarefa crítica pode levar à sua substituição ou demissão. Se você não sabe se algo é crítico, pergunte; é sua obrigação buscar essa informação.

Estrutura da comunicação de status

Crie um ritual de comunicação, seja uma daily de 10-15 minutos ou um e-mail/mensagem diário, para manter o alinhamento e evitar surpresas.

A pauta da sua comunicação deve incluir:

• Visão Geral do andamento do trabalho.
• Progresso da atividade (o que avançou ou não).
• Possíveis atrasos (comunique com antecedência).
• Previsões novas (quanto tempo mais você precisa?).
• Bloqueios/Impedimentos (coisas que estão impedindo seu trabalho, como falta de acesso ou resposta), o gestor pode ajudar a resolver.

Considerações finais

Para colocar tudo isso em prática, comece a planejar e orçar suas atividades hoje, mesmo que a empresa não exija. Isso é um conhecimento que melhora sua empregabilidade e afeta diretamente sua carreira.

Além disso, facilite a vida do seu chefe ao invés de levar apenas um problema, leve o problema junto com uma solução proposta. Isso demonstra maturidade e comprometimento.

Todas essas habilidades de previsibilidade estão ligadas à Análise de Requisitos, que é tão fundamental para o dev quanto programar ou fazer testes unitários. Ao juntar a análise com a programação na sequência correta, você se torna um dev imparável que entrega qualidade e cumpre prazos na maioria das vezes.

Feito!

Workflow de branches em projetos ágeis: Boas práticas com Git Flow

Gerenciar branches de forma organizada é uma das práticas mais importantes em qualquer equipe de desenvolvimento. Um bom fluxo de versionamento garante rastreabilidade, previsibilidade nas entregas e reduz conflitos durante o ciclo de vida de cada Sprint.

Baseado no modelo Git Flow, o workflow que apresento aqui é uma adaptação moderna e prática, utilizada amplamente no mercado em equipes que trabalham com metodologias ágeis e ferramentas como Redmine, Jira, Trello ou GitHub/GitLab Issues.

1. Estrutura principal do repositório

O repositório segue duas principais linhas de desenvolvimento:

• master ou main:

contém o código estável e homologado, pronto para produção.

• develop:

linha de integração onde as novas funcionalidades e correções de Sprint são validadas antes da liberação.

A partir dessas duas branches centrais, todo o ciclo de desenvolvimento é organizado.

2. Criando branches de task (feature)

Cada nova task atribuída no sistema de gestão deve originar uma branch seguindo um padrão de nomenclatura padronizado. Isso facilita a rastreabilidade da entrega, especialmente quando o time é grande ou o projeto possui várias sprints paralelas.

O padrão recomendado é:

feature/sprintX/RTCY/TituloDaTask

Essa branch deve sempre ser criada a partir da branch develop atualizada, garantindo que a task comece sobre a base mais recente do projeto:

git checkout develop
git pull origin develop
git checkout -b feature/sprint5/RTC102/ImplementarAutenticacaoOAuth

Isso cria a branch da task a partir da develop atualizada.

3. Commits e Pull Request (PR)

Durante o desenvolvimento da task, os commits devem ser claros e objetivos, refletindo o progresso da implementação e dos testes unitários.

Ao concluir a task, realize o commit e o push final:

git add .
git commit -m "Finaliza implementação e testes unitários da autenticação OAuth"
git push origin feature/sprint5/RTC102/ImplementarAutenticacaoOAuth

Em seguida, abra um Pull Request (PR) para a branch develop e utilize o seguinte padrão de comentário:

[SPRINT5][RTC102][ImplementarAutenticacaoOAuth][feature]

Isso ajuda o time de revisão e o QA a identificar rapidamente o contexto da entrega.

4. Correção de bugs encontrados pelo QA

Caso o QA identifique algum bug durante os testes da Sprint, o desenvolvedor deve corrigir o problema na mesma branch da feature, mantendo o histórico da entrega.

Ao abrir um novo Pull Request ou atualizar o existente, utilize o seguinte padrão de comentário:

[SPRINT5][RTC102][ImplementarAutenticacaoOAuth][bug] Correção na validação do token

Esse formato indica que a PR refere-se a uma correção derivada da mesma task principal, mantendo o controle e a rastreabilidade no fluxo da Sprint.

5. Correções de bugs em produção

Para bugs que ocorrem em produção, a abordagem é diferente.

Essas correções devem ser baseadas diretamente na branch master ou main, garantindo que a correção seja aplicada sobre o código em execução.

A nomenclatura segue o padrão:

feature/bugfix/RTCX

Por exemplo:

feature/bugfix/RTC240

Crie a branch, aplique a correção, teste e envie o Pull Request de volta para a branch principal (master ou main).

Após aprovação e merge, é possível gerar uma tag de hotfix, caso necessário.

6. Encerramento da Sprint e versionamento

Ao final de cada Sprint, com todas as tasks revisadas e integradas à develop, é hora de gerar uma tag de versão.

A tag identifica o encerramento formal da Sprint e serve como ponto de referência no histórico do repositório.

O padrão sugerido é:

git tag -a v1.5 -m "Sprint 5 concluída"
git push origin v1.5

Esse versionamento facilita auditorias, rollback e acompanhamento de evolução entre as versões.

7. Benefícios desse workflow

Seguir esse modelo de workflow traz diversas vantagens:

• Clareza e rastreabilidade das entregas por Sprint.
• Redução de conflitos de merge.
• Facilidade na revisão de Pull Requests.
• Histórico limpo e versionamento controlado.
• Organização entre desenvolvimento, QA e deploy.

Bugfix Branch: Deve ir apenas para main ou também para develop?

Na maioria dos fluxos Git profissionais, incluindo Git Flow, GitHub Flow e variações híbridas bastante usadas em equipes Java/Spring/Quarkus, existe uma regra importante:

Todo bugfix criado a partir da main deve ser incorporado também à develop, caso ela exista.

Por quê?

Porque a branch develop geralmente contém novas features ainda não liberadas.

Se você corrigir o bug apenas na main, o problema voltará a aparecer quando a develop for integrada no futuro release, causando regressão.

Isso significa:

Criar a branch de bugfix a partir da main atualizada

Porque o bug ocorre na versão em produção.

Porque main representa o código estável.

Abrir Pull Request para main

A hotfix corrige imediatamente a versão produtiva.

Depois da aprovação, fazer merge dessa correção também para develop

Existem duas formas comuns:

PR automático do GitHub (bot cria PR de main -> develop)

Ou o desenvolvedor abre manualmente um PR de sincronização

Isso é opcional?

Não, é considerado convencional e altamente recomendado sempre que o time utiliza uma branch develop.

Ignorar isso pode gerar os seguintes problemas:

Reintrodução do bug ao fazer merge de develop em release futuro.

Divergência de código entre main e develop.

Dificuldade de rastreamento, pois hotfixes não aparecem no histórico da release em desenvolvimento.

Considerações finais

Um bom gerenciamento de branches é mais do que uma convenção, é parte essencial da cultura de engenharia de software madura.

Trabalhar com um workflow bem definido baseado no Git Flow permite que o time mantenha consistência, colabore com eficiência e entregue software de qualidade em ciclos ágeis.

Ao aplicar esse processo com disciplina, cada Sprint se torna mais previsível, e o código entregue ganha estabilidade e confiabilidade, o que é o verdadeiro objetivo de um ciclo de desenvolvimento profissional.

Feito!

Sincronizando o seu projeto backend Java (Spring/Quarkus) com JUnit e Mockito no SonarQube

Manter a qualidade de código e medir a cobertura de testes é uma prática essencial em projetos backend modernos. O SonarQube é uma ferramenta robusta para essa finalidade, oferecendo relatórios de bugs, vulnerabilidades, code smells e cobertura de testes unitários.

No presente artigo, vamos configurar o SonarQube para um projeto Java (Spring ou Quarkus) que utiliza JUnit e Mockito, e entender como ignorar pacotes que não envolvem regras de negócio, como Entity, Dto e Repository.

A premissa é ter o Docker e Docker-Compose instalados, caso ainda não tenha, verifique Instalando Docker e Docker Compose no Linux (qualquer distro) ou Instalando Docker no Windows 10

1. Subindo o SonarQube com Docker

O primeiro passo é subir o SonarQube localmente com o container oficial:

docker run -d --name sonarqube-backend -p 9000:9000 sonarqube:latest

Após iniciar, acesse o painel em: http://localhost:9000

O login padrão é admin / admin.

Altere a senha e gere um token de autenticação em:

My Account → Security → Generate Tokens

Copie e guarde o token, pois ele será utilizado na integração do projeto.

2. Configurando o projeto backend

   O projeto backend pode ser utilizando o framework Spring Boot ou Quarkus, ambos utilizando Maven como ferramenta de build.

   Certifique-se de que o projeto possui testes unitários configurados com JUnit 5 e Mockito, caso ainda não implementou os testes unitários utilizando JUnit e Mockito (InjectMocks e Mock), implemente para poder continuar com os demais procedimentos a seguir.

3. Configuração no application.properties

Para que o SonarQube consiga autenticar e se comunicar com o projeto, adicione as propriedades de configuração no application.properties:

sonar.host.url=http://localhost:9000 sonar.login=TOKEN_AQUI

Essas configurações permitem que o Maven utilize o token de autenticação diretamente.

4. Arquivo sonar-project.properties

Crie o arquivo sonar-project.properties na raiz do projeto com o seguinte conteúdo:

sonar.projectKey=Projeto-Backend
sonar.projectName=Projeto-Backend
sonar.projectVersion=1.0
sonar.sources=src/main/java
sonar.tests=src/test/java
sonar.language=java
sonar.sourceEncoding=UTF-8
sonar.host.url=http://localhost:9000
sonar.login=TOKEN_AQUI
sonar.branch.name=develop

# Caminho do relatório de cobertura
sonar.junit.reportPaths=target/surefire-reports
sonar.jacoco.reportPaths=target/jacoco.exec
sonar.java.binaries=target/classes

# Ignorar pacotes que não envolvem regra de negócio
sonar.exclusions=**/entity/**,**/model/**,**/dto/**,**/repository/**

A propriedade sonar.exclusions é fundamental para manter o foco da análise nos pacotes de serviços, regras de negócio e controladores, evitando que o SonarQube penalize a cobertura de testes em classes de domínio simples.

5. Configurando o plugin Sonar no Maven

Adicione o plugin SonarQube no arquivo pom.xml caso ainda não esteja presente:

<build>
  <plugins>
    <plugin>
      <groupId>org.sonarsource.scanner.maven</groupId>
      <artifactId>sonar-maven-plugin</artifactId>
      <version>3.10.0.2594</version>
    </plugin>
  </plugins>
</build>

6. Executando os testes e análise

Com tudo configurado, o fluxo para rodar os testes e enviar os resultados ao SonarQube é simples:

Execute os testes unitários:

mvn clean test

Se todos os testes passarem, execute a análise do Sonar:

mvn sonar:sonar

O Maven irá coletar os resultados de cobertura gerados pelo JUnit/Mockito e enviar para o servidor SonarQube, usando o token informado.

7. Visualizando os resultados

Acesse novamente o painel do SonarQube (http://localhost:9000) e verifique seu projeto.

Você verá:

Cobertura de testes unitários (Jacoco)

Code smells e bugs

Duplicações

Segurança e manutenibilidade do código

Os pacotes Entity, Dto e Repository estarão excluídos da cobertura, mantendo o foco nas classes com lógica de negócio.

Considerações finais

Integrar o JUnit + Mockito com o SonarQube é uma das práticas mais eficazes para manter um backend saudável e bem testado.

Ao utilizar o SonarQube em container Docker, a análise fica portátil e fácil de reproduzir em qualquer ambiente.

Essa configuração também é compatível com pipelines CI/CD, permitindo que a análise de qualidade seja automatizada em cada push, garantindo métricas consistentes e rastreabilidade da evolução do código.

Feito!

Sincronizando seu projeto frontend (Angular) com testes unitários (Jest) no SonarQube

Em ambientes corporativos, a análise de qualidade de código e cobertura de testes é essencial para garantir a confiabilidade das aplicações. O SonarQube é uma das ferramentas mais usadas para isso, e pode ser facilmente integrado a projetos Angular com Jest.

No presente artigo, vamos ver o passo a passo para configurar essa integração, incluindo o uso do SonarQube em container Docker, a execução dos testes unitários e a geração de relatórios de cobertura.

A premissa é ter o Docker e Docker-Compose instalados, caso ainda não tenha, verifique Instalando Docker e Docker Compose no Linux (qualquer distro) ou Instalando Docker no Windows 10

1. Subindo o SonarQube com Docker

Primeiro, vamos utilizar a imagem oficial do SonarQube. Execute o comando abaixo:

docker run -d --name sonarqube-frontend -p 9000:9000 sonarqube:latest

O SonarQube estará acessível em http://localhost:9000.

No primeiro acesso, o login padrão é admin / admin.

Após logar, altere a senha e gere um token de autenticação no menu:

My Account → Security → Generate Tokens

Guarde esse token, pois ele será utilizado no arquivo de configuração do scanner.

2. Instalando o Jest e o Sonar Scanner

No seu projeto Angular, instale o Jest e o Sonar Scanner globalmente e localmente para garantir compatibilidade:

Instalar o sonar-scanner globalmente

npm install -g sonar-scanner

Instalar o sonar-scanner como dependência de desenvolvimento

npm install --save-dev sonar-scanner

Se o Jest ainda não estiver configurado no projeto Angular:

npm install --save-dev jest @types/jest jest-preset-angular

Em seguida, adicione o script de testes no package.json:

"scripts": {
  "test": "jest --silent",
  "test:coverage": "jest --coverage",
  "sonar": "sonar-scanner"
}

3. Configurando o arquivo sonar-project.properties

   Crie o arquivo sonar-project.properties na raiz do projeto Angular com o seguinte conteúdo:

   
   sonar.projectKey=Nome-Projeto-Frontend
   sonar.projectName=Nome-Projeto-Frontend
   sonar.projectVersion=1.0
   sonar.sources=src
   sonar.language=ts
   sonar.sourceEncoding=UTF-8
   sonar.host.url=http://localhost:9000
   sonar.login=TOKEN_AQUI
   sonar.branch.name=develop
   
   # Diretório de relatórios do Jest
   sonar.javascript.lcov.reportPaths=coverage/lcov.info
   
   

   O campo sonar.javascript.lcov.reportPaths é essencial para que o SonarQube consiga ler a cobertura de testes gerada pelo Jest.

4. Executando os testes e enviando o relatório

Antes de executar o SonarQube, é necessário garantir que os testes unitários estão passando e que o relatório de cobertura foi gerado corretamente.

Execute os testes normalmente:

npx jest --silent

Se todos os testes passarem, gere o relatório de cobertura:

Isso criará uma pasta coverage na raiz do projeto com o arquivo lcov.info dentro de coverage/lcov-report.

5. Enviando os resultados ao SonarQube

Com os testes e cobertura prontos, execute o comando abaixo:

npm run sonar

O sonar-scanner lerá as configurações do arquivo sonar-project.properties e enviará o relatório para o servidor do SonarQube.

Ao finalizar, acesse o painel do SonarQube e verifique as métricas do seu projeto, incluindo:

Qualidade do código TypeScript

Cobertura de testes Jest

Bugs, vulnerabilidades e code smells

Dica: executando no Git Bash (Windows)

Se você estiver no Windows, use o Git Bash para simular um ambiente Linux.

O comando sonar-scanner funciona normalmente nesse terminal, o que facilita a integração em ambientes de desenvolvimento heterogêneos.

Considerações finais

Integrar o Jest com o SonarQube é uma prática que eleva o nível de qualidade do seu projeto Angular.

Essa integração permite visualizar métricas detalhadas, acompanhar a evolução da cobertura de testes e identificar pontos críticos no código.

Com essa configuração, seu pipeline local ou CI/CD estará preparado para medir qualidade de forma contínua, garantindo um código mais limpo, seguro e sustentável.

Feito!

Configurando o Personal Access Token (PAT) no Azure DevOps e GitHub

Quando você trabalha com integrações seguras entre pipelines, repositórios e automações, é comum precisar autenticar via Personal Access Token (PAT), uma chave de acesso pessoal que substitui a senha de login, garantindo mais segurança e controle sobre as permissões.

No presente artigo, você vai aprender como gerar, converter e configurar um PAT no Azure DevOps e também como usar o mesmo conceito no GitHub.

Gerando o Personal Access Token (PAT) no Azure DevOps

1. Acesse o portal do Azure DevOps https://azure.microsoft.com
2. Faça login com sua conta.
3. No canto superior direito, clique na sua foto de perfil e selecione Security (ou “Segurança”).
4. No menu lateral, escolha Personal Access Tokens.
5. Clique em New Token.
6. Dê um nome para identificar o token (ex: Token-Pipeline ou Token-Pessoal
7. Defina a data de expiração — prefira um período longo (como 1 ano) se for um uso contínuo.
8. Selecione os escopos (permissões) necessários, como:

Code (Read & Write) para acesso a repositórios;

Build (Read & Execute) para pipelines;

Packaging (Read) para artefatos.

9. Clique em Create.

Importante: copie o token gerado imediatamente, ele será exibido apenas uma vez.

Convertendo o PAT em Base64

Após gerar o token, será necessário convertê-lo para o formato Base64, que é o padrão usado em autenticação HTTP Basic.

Você precisará do seu login (e-mail ou nome de usuário) e do PAT gerado.

No PowerShell:

[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("LOGIN:PAT"))

Ou no Git Bash:

echo -n "LOGIN:PAT" | base64

Substituir o LOGIN e PAT, pelo seu login e token gerado, respectivamente.

Configurando o PAT no arquivo .gitconfig

Após obter o resultado em Base64, você pode configurar seu Git local para utilizar o token automaticamente nas conexões com o Azure DevOps.

Abra o arquivo de configuração global do Git: ~/.gitconfig

Adicione a seguinte linha dentro da seção [http]:

[http "https://dev.azure.com/"] extraHeader = Authorization: Basic PAT_BASE64

Substitua PAT_BASE64 pelo valor obtido na conversão em Base64.

E no GitHub?

O GitHub também utiliza Personal Access Tokens como método de autenticação em vez de senhas.

O processo é semelhante:

1. Acesse https://github.com/settings/tokens
2. Clique em Generate new token
3. Escolha o escopo (geralmente repo e workflow são os mais usados).
4. Copie o token gerado.
5. Converta-o da mesma forma:
echo -n "LOGIN:PAT" | base64
6. Adicione ao .gitconfig (substituindo o domínio pelo do GitHub):
[http "https://github.com/"] extraHeader = Authorization: Basic PAT_BASE64

Considerações finais

O uso do Personal Access Token (PAT) é uma prática recomendada para garantir segurança e controle de acesso em ambientes de integração contínua e repositórios Git.

Com ele, você:

Evita expor senhas reais;

Controla permissões específicas;

Automatiza autenticações em pipelines e scripts;

Pode revogar acessos rapidamente se necessário.

Manter o PAT seguro e criptografado é fundamental, trate-o como uma senha sensível e nunca o compartilhe em código público.

Feito!

Como adicionar o certificado de uma API de terceiros para testar localmente usando o Keytool

Ao integrar uma API de terceiros em um projeto Java, especialmente durante o desenvolvimento local, é comum encontrar erros relacionados a SSL, como:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException:
PKIX path building failed: unable to find valid certification path to requested target

Esse erro ocorre quando o certificado da API não é reconhecido pela JVM, geralmente porque é um certificado autoassinado ou emitido por uma autoridade que ainda não está no truststore padrão do Java.

Para resolver isso, é necessário importar o certificado no keystore de confiança da JVM, usando a ferramenta keytool.

O que é o Keytool

O keytool é uma ferramenta de linha de comando que faz parte do JDK.

Ele permite gerenciar keystores (repositórios de certificados e chaves) utilizados pela JVM para autenticação SSL/TLS.

Importante:

O keytool já está disponível nativamente tanto no Linux quanto no Git Bash no Windows (desde que o JDK esteja corretamente instalado e configurado no PATH).

Etapas para importar o certificado no ambiente local

1. Obtenha o certificado da API de terceiros

Você pode exportar o certificado diretamente pelo navegador.

No Google Chrome, por exemplo:

1. Acesse a URL da API (por exemplo: https://api.dominio.com)

2. Clique no cadeado ao lado da barra de endereço

3. Selecione "Detalhes do certificado"

4. Escolha um local para salvar com nome "nome-api-cert.cert" e no tipo selecionar "binário codificado por DER, certificado único" e clica no botão Exportar

2. Localize o cacerts da JVM

O arquivo cacerts é o truststore padrão do Java e fica dentro da pasta lib/security da sua instalação do JDK.

Windows com Git Bash: /c/Program Files/Java/jdk-17/lib/security/cacerts

Linux: /usr/lib/jvm/java-17-openjdk/lib/security/cacerts

Dica: se estiver usando o Git Bash, pode navegar até o diretório do JDK usando comandos Linux normalmente.

3. Execute o comando do Keytool para importar

No terminal (Git Bash ou Linux), rode o seguinte comando:

keytool -importcert -trustcacerts -alias api-terceiro -file /caminho/onde/salvou/nome-api-cert.cert -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit

Explicando os parâmetros:

Parâmetro	Descrição
-importcert	Indica que você quer importar um certificado
-trustcacerts	Confirma que é um certificado confiável
-alias	Nome de identificação do certificado dentro do keystore
-file	Caminho do arquivo .cer que será importado
-keystore	Caminho do keystore onde será armazenado (geralmente cacerts)
-storepass	Senha do keystore (padrão do Java é changeit)

Ao ser questionado se deseja confiar no certificado, digite yes e pressione Enter.

3. Validar se o certificado foi importado corretamente

Após a importação, verifique se o certificado está presente no keystore com:

keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" -alias api-terceiro -storepass changeit

Se aparecer o nome do certificado e o emissor (issuer), significa que a importação foi bem-sucedida.

4. Reinicie a aplicação

Depois de importar o certificado, reinicie a aplicação Java ou o servidor (por exemplo, Spring Boot, Quarkus ou Tomcat) para que as alterações entrem em vigor.

Boas práticas

Evite editar diretamente o cacerts da JVM de produção.

O ideal é criar um keystore separado, como custom-truststore.jks, e apontar para ele via propriedades de sistema:

-Djavax.net.ssl.trustStore=/caminho/custom-truststore.jks
-Djavax.net.ssl.trustStorePassword=changeit

Controle de versão:

Nunca coloque certificados ou arquivos .jks diretamente no repositório Git.

Guarde-os em local seguro e documente o procedimento de importação.

Ambiente limpo:

Caso use múltiplas versões do Java, verifique sempre o $JAVA_HOME correto antes de importar o certificado.

Considerações finais

Adicionar o certificado de uma API de terceiros no ambiente local é uma prática comum e necessária quando o SSL não é reconhecido pela JVM.

Usando o keytool, você pode facilmente importar o certificado e eliminar erros de handshake durante o desenvolvimento.

O Git Bash no Windows funciona exatamente como um terminal Linux, e como o keytool é nativo do JDK, o procedimento é o mesmo nos dois sistemas.

Com isso, você garante que sua aplicação consiga se comunicar com segurança com APIs externas, mesmo em ambiente de testes.

Feito!

Conectando ao MS SQL Server com autenticação do usuário do Windows (Windows Authentication) em Java

Ao trabalhar com sistemas corporativos que utilizam o Microsoft SQL Server, é comum encontrar ambientes configurados para autenticação integrada do Windows. Isso significa que o acesso ao banco de dados é feito com base nas credenciais do usuário logado no sistema operacional, dispensando o uso de nome de usuário e senha definidos diretamente no banco.

Quando desenvolvemos aplicações Java que precisam se conectar ao SQL Server usando esse tipo de autenticação, é necessário realizar uma configuração específica no driver JDBC. Caso contrário, a aplicação não conseguirá autenticar corretamente o usuário e a conexão falhará.

Por que é necessário o arquivo msql-jdbc_auth.dll?

O driver oficial do SQL Server para Java, conhecido como Microsoft JDBC Driver for MS QL Server, oferece suporte à autenticação integrada do Windows através de uma biblioteca nativa chamada msql-jdbc_auth.dll.

Essa DLL atua como uma ponte entre o Java e as APIs do Windows responsáveis pela autenticação. Sem ela, o Java não teria acesso ao contexto de segurança do sistema operacional, e a tentativa de conexão com autenticação integrada resultaria em erro.

Em resumo, o Java precisa desse componente nativo para poder "herdar" as credenciais do usuário logado e repassá-las ao SQL Server de forma segura.

Passo a passo para configurar

1. Download o driver JDBC oficial

Acesse o site oficial da Microsoft e baixe o driver JDBC mais recente.

No momento da escrita deste artigo, a versão disponível é a 12.8.1, e o link direto de download é: https://go.microsoft.com/fwlink?linkid=2283744

2. Descompactar o pacote

Após o download, descompacte o arquivo. Dentro da pasta extraída você encontrará o driver mssql-jdbc-12.8.1.jar (ou .jre11, .jre17, conforme sua versão do Java) e também a biblioteca nativa msql-jdbc_auth-12.8.1.x64.dll.

3. Copiar a DLL para o diretório correto

Copie o arquivo msql-jdbc_auth-12.8.1.x64.dll para o diretório bin da instalação do Java.

Exemplo de caminho no Windows:

C:\Program Files\Java\jdk-17\bin

Esse diretório faz parte do java.library.path, o que garante que a JVM consiga localizar a DLL durante a execução.

4. Configurar a string de conexão

A string de conexão deve informar que será usada a autenticação integrada.

Exemplo:

String connectionUrl = "jdbc:sqlserver://localhost:1433;"
+ "databaseName=MinhaBase;"
+ "integratedSecurity=true;";
Connection conn = DriverManager.getConnection(connectionUrl);

Para projetos Spring Boot, configure no arquivo application.properties:

spring.datasource.url=jdbc:sqlserver://IPSERVIDORDBMSSQLSERVER:1433;databaseName=MinhaBase;integratedSecurity=true;
spring.datasource.driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver

Caso use Quarkus, a configuração fica assim:

quarkus.datasource.jdbc.url=jdbc:sqlserver://IPSERVIDORDBMSSQLSERVER:1433;databaseName=MinhaBase;integratedSecurity=true;
quarkus.datasource.jdbc.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver

Observe o parâmetro integratedSecurity=true, que é o que ativa o uso da DLL para autenticação.

5. Executar a aplicação

Com a DLL no diretório correto e o driver JDBC configurado no classpath, sua aplicação Java será capaz de se conectar ao SQL Server utilizando as credenciais do usuário do Windows atual.

Configuração para Linux com Windows Authentication

Em sistemas Linux, a autenticação integrada não funciona nativamente com a DLL, pois ela é específica do Windows.

Nesse caso, o método recomendado é usar Kerberos, o mesmo protocolo que o Active Directory utiliza para autenticação entre domínios.

Passos para configurar no Linux

1. Instale os pacotes necessários

Em distribuições baseadas em Debian/Ubuntu:

sudo apt install krb5-user libsasl2-modules-gssapi-mit

No Fedora:

sudo dnf install krb5-workstation
2. Configure o arquivo /etc/krb5.conf

Adicione o domínio e o servidor KDC da sua rede corporativa.

Exemplo:

[libdefaults]
    default_realm = MINHAEMPRESA.LOCAL
    dns_lookup_kdc = true
    dns_lookup_realm = true

[realms]
    MINHAEMPRESA.LOCAL = {
        kdc = dc1.minhaempresa.local
    }

3. Obtenha um ticket Kerberos com seu usuário do domínio
kinit usuario@MINHAEMPRESA.LOCAL

Após autenticar, você pode confirmar o ticket com:

klist
4. Configure a conexão JDBC

No application.properties (Spring Boot ou Quarkus), a URL deve indicar o uso do principal Kerberos:

Spring

spring.datasource.url=jdbc:sqlserver://IPSERVIDORDBMSSQLSERVER:1433;databaseName=MinhaBase;authenticationScheme=JavaKerberos;
spring.datasource.driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver

Quarkus

quarkus.datasource.jdbc.url=jdbc:sqlserver://IPSERVIDORDBMSSQLSERVER:1433;databaseName=MinhaBase;authenticationScheme=JavaKerberos;
quarkus.datasource.jdbc.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver

A opção authenticationScheme=JavaKerberos instrui o driver JDBC a usar o ticket obtido via kinit.

Considerações finais

Essa configuração é especialmente útil em ambientes corporativos onde a política de segurança exige Single Sign-On (SSO) e o gerenciamento centralizado de permissões. Além disso, evita o armazenamento de senhas no código-fonte ou em arquivos de configuração, o que aumenta a segurança da aplicação.

Vale lembrar que a autenticação integrada funciona apenas quando a aplicação Java está sendo executada em um ambiente Windows. Para servidores Linux, é necessário configurar o Kerberos e utilizar parâmetros adicionais no driver.

Em resumo, a presença da DLL msql-jdbc_auth é fundamental para que o Java consiga usar a autenticação nativa do Windows ao se conectar ao MS SQL Server. Com ela corretamente posicionada e o driver JDBC configurado, o processo de autenticação se torna transparente e seguro, aproveitando os recursos já disponíveis no sistema operacional.

Feito!