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!

Como resolver o erro "boot failed to start gdm.service" no Ubuntu

Se ao iniciar o Ubuntu você se deparou com a mensagem "boot failed to start gdm.service", é bem provável que o problema esteja relacionado à partição raiz (/) cheia. Quando o sistema atinge 100% de uso da partição principal, diversos serviços deixam de funcionar corretamente — entre eles, o GDM, responsável pela tela de login gráfico.

A seguir, veja como corrigir esse problema de forma segura e eficiente.

1. Acesse o terminal virtual (TTY)

Como o ambiente gráfico não está inicializando, é necessário usar o terminal virtual.

Pressione Ctrl + Alt + F2 (ou F3, F4...) para abrir o TTY.

Em seguida, faça o login com seu nome de usuário e senha.

2. Verifique o uso da partição raiz

Depois de acessar o terminal, digite:

df -h

Esse comando mostra o uso de cada partição. Verifique se a partição / (raiz) está com 100% de utilização. Se estiver, é hora de liberar espaço.

3. Limpe o cache de pacotes APT

O cache do APT pode ocupar bastante espaço, especialmente se você realiza muitas atualizações. Execute:

sudo apt clean
sudo apt autoremove

Esses comandos removem pacotes e dependências que não são mais necessários.

4. Remova versões antigas do kernel

Versões antigas do kernel podem consumir vários gigabytes. Para removê-las, execute:

sudo apt autoremove --purge

Isso limpa completamente pacotes antigos e libera espaço de forma significativa.

5. Limpe arquivos de log antigos

Os logs do sistema também podem crescer rapidamente. Para mantê-los sob controle, use:

sudo journalctl --vacuum-size=50M

Esse comando limita o tamanho dos logs a 50 MB, descartando os mais antigos.

6. Confirme se o espaço foi liberado

Execute novamente:

df -h

Se o uso da partição diminuiu, ótimo, o problema provavelmente foi resolvido. Caso ainda esteja cheia, siga para as próximas etapas.

7. Reinstale o ambiente gráfico (se necessário)

Se mesmo após liberar espaço o erro persistir, talvez o GDM ou o pacote do ambiente gráfico tenha sido corrompido. Nesse caso, reinstale-os:

sudo apt install --reinstall ubuntu-desktop
sudo apt purge gdm3
sudo apt install gdm3

Isso garante que todos os componentes necessários para o login gráfico estejam restaurados.

8. Reinicie o sistema

Por fim, reinicie o computador:

sudo reboot

Após o reinício,o erro "boot failed to start gdm.service" desaparecerá e o sistema deve carregar o ambiente gráfico normalmente.

Dica final: mantenha sempre um controle do uso de espaço em disco. Você pode usar ferramentas como o Baobab (Analisador de uso de disco) para identificar rapidamente o que está ocupando espaço e evitar que o problema volte a ocorrer.

Feito!