--- title: "Kotlin e DevOps: CI/CD para Projetos Kotlin | Kotlin Brasil" url: "https://kotlin.dev.br/blog/kotlin-devops-ci-cd/" markdown_url: "https://kotlin.dev.br/blog/kotlin-devops-ci-cd.MD" description: "Kotlin e DevOps: como configurar CI/CD para projetos Kotlin. Pipelines, automação de testes, build e deploy com melhores práticas." date: "2025-08-12" author: "Karina Melo" --- # Kotlin e DevOps: CI/CD para Projetos Kotlin | Kotlin Brasil Kotlin e DevOps: como configurar CI/CD para projetos Kotlin. Pipelines, automação de testes, build e deploy com melhores práticas. DevOps e CI/CD não são mais diferenciais, são requisitos básicos em projetos profissionais. Para projetos Kotlin, montar pipelines de integração e entrega contínua garante qualidade, velocidade e confiança em cada deploy. Neste artigo, vamos explorar como configurar CI/CD eficaz para projetos Kotlin. ## O que é CI/CD e por que importa CI (Continuous Integration) é a prática de integrar código frequentemente, com verificações automáticas a cada push. CD (Continuous Delivery/Deployment) automatiza o processo de levar o código para produção. Para projetos Kotlin, isso significa: - Compilar e testar automaticamente a cada commit - Verificar qualidade de código com análise estática - Gerar artefatos (JARs, APKs, imagens Docker) automaticamente - Fazer deploy em ambientes de staging e produção ## Estrutura de Pipeline para Kotlin Um pipeline típico para um projeto Kotlin backend tem as seguintes etapas: ### 1. Build e Compilação ```kotlin // build.gradle.kts - Configuração otimizada para CI plugins { kotlin("jvm") version "2.1.0" kotlin("plugin.spring") version "2.1.0" id("org.springframework.boot") version "3.3.0" id("io.spring.dependency-management") version "1.1.4" id("org.jetbrains.kotlinx.kover") version "0.7.5" // Cobertura de código id("io.gitlab.arturbosch.detekt") version "1.23.4" // Análise estática } detekt { config.setFrom(files("config/detekt/detekt.yml")) buildUponDefaultConfig = true allRules = false } kover { reports { filters { excludes { classes("*.config.*", "*.Application*") } } verify { rule { minBound(80) // Mínimo 80% de cobertura } } } } ``` ### 2. Testes Automatizados ```kotlin // Testes bem estruturados são a base do CI @SpringBootTest class PedidoServiceIntegrationTest { @Autowired private lateinit var pedidoService: PedidoService @Autowired private lateinit var pedidoRepository: PedidoRepository @Test fun `deve criar pedido e persistir no banco`() = runTest { // Given val request = CriarPedidoRequest( clienteId = "cliente-1", itens = listOf( ItemRequest(produtoId = "prod-1", quantidade = 2), ItemRequest(produtoId = "prod-2", quantidade = 1) ) ) // When val pedido = pedidoService.criarPedido(request) // Then assertThat(pedido.id).isNotNull() assertThat(pedido.status).isEqualTo(PedidoStatus.CRIADO) val persistido = pedidoRepository.findById(pedido.id) assertThat(persistido).isNotNull() assertThat(persistido!!.itens).hasSize(2) } @AfterEach fun cleanup() = runBlocking { pedidoRepository.deleteAll() } } ``` ### 3. Análise Estática com Detekt Detekt é a ferramenta padrão para análise estática de código Kotlin: ```kotlin // config/detekt/detekt.yml (em formato YAML, referenciado pelo Gradle) // Configurações típicas incluem: // - Complexidade ciclomática máxima // - Tamanho máximo de funções // - Detecção de code smells // - Regras de formatação // Exemplo de código que detekt flagraria: // RUIM - Função muito complexa fun processarDados(dados: List): String { // detekt avisaria sobre complexidade excessiva var resultado = "" for (dado in dados) { when (dado) { is String -> resultado += dado.uppercase() is Int -> resultado += dado.toString() is List<*> -> resultado += dado.size.toString() else -> resultado += "unknown" } } return resultado } // BOM - Função simples e clara fun processarDados(dados: List): String { return dados.joinToString("") { dado -> formatarDado(dado) } } private fun formatarDado(dado: Any): String = when (dado) { is String -> dado.uppercase() is Int -> dado.toString() is List<*> -> dado.size.toString() else -> "unknown" } ``` ### 4. Build de Imagem Docker ```kotlin // Dockerfile para aplicacao Kotlin/Spring Boot // Multi-stage build para imagem otimizada // Usando Gradle para build // Stage 1: Build // FROM gradle:8.5-jdk21 AS build // COPY . /app // WORKDIR /app // RUN gradle bootJar --no-daemon // Stage 2: Runtime // FROM eclipse-temurin:21-jre-alpine // COPY --from=build /app/build/libs/*.jar app.jar // EXPOSE 8080 // ENTRYPOINT ["java", "-jar", "app.jar"] ``` Para otimizar o build Docker em CI, use cache de dependências Gradle: ```kotlin // build.gradle.kts - Task para copiar dependências (util para cache Docker) tasks.register("copyDependencies") { from(configurations.runtimeClasspath) into("$buildDir/dependencies") } ``` ## Ferramentas de CI/CD ### GitHub Actions A ferramenta mais popular para projetos open source e muitas empresas: O workflow típico inclui: - Checkout do código - Setup do JDK 21 - Cache de dependências Gradle - Execução de testes - Análise estática com detekt - verificação de cobertura com kover - Build da imagem Docker - Deploy para staging/produção ### GitLab CI Popular em empresas que usam GitLab para hospedagem de código. Oferece pipelines visuais e integração nativa com Kubernetes. ### Jenkins Ainda muito usado em empresas enterprise, especialmente bancos e fintechs. Oferece maxima flexibilidade mas exige mais manutenção. ## Pipeline para Projeto Android Para projetos Android com Kotlin, o pipeline tem particularidades: ```kotlin // Pipeline Android típico: // 1. Build do APK/AAB // 2. Testes unitários // 3. Testes instrumentados (opcional, com emulador) // 4. Lint e detekt // 5. Publicação na Play Store (via Fastlane ou Gradle Play Publisher) // build.gradle.kts (app module) android { lint { abortOnError = true warningsAsErrors = true xmlReport = true } testOptions { unitTests.all { it.useJUnitPlatform() } } } // Plugin para publicação automática plugins { id("com.github.triplet.play") version "3.9.0" } play { serviceAccountCredentials.set(file("play-service-account.json")) track.set("internal") // internal -> alpha -> beta -> production defaultToAppBundles.set(true) } ``` ## Melhores Práticas de CI/CD para Kotlin ### Cache de Dependências Gradle downloads podem levar minutos. Configurar cache e essencial: ```kotlin // Configuração de cache no build.gradle.kts buildCache { local { isEnabled = true directory = File(rootDir, ".gradle/build-cache") } } ``` ### Testes Paralelos ```kotlin // Executar testes em paralelo para reduzir tempo de CI tasks.withType { maxParallelForks = Runtime.getRuntime().availableProcessors() / 2 forkEvery = 100 // Reinicia JVM a cada 100 testes para evitar memory leaks } ``` ### Build Incremental ```kotlin // Habilitar compilacao incremental kotlin { compilerOptions { freeCompilerArgs.add("-Xuse-k2") // Compilador K2 mais rapido } } ``` ### Segredos e Configuração Nunca coloque segredos no código. Use variaveis de ambiente ou vault: ```kotlin // Acessar configurações de forma segura @Configuration class DatabaseConfig( @Value("\${DATABASE_URL}") private val databaseUrl: String, @Value("\${DATABASE_USERNAME}") private val username: String, @Value("\${DATABASE_PASSWORD}") private val password: String ) { @Bean fun dataSource(): HikariDataSource { return HikariDataSource().apply { jdbcUrl = databaseUrl this.username = this@DatabaseConfig.username this.password = this@DatabaseConfig.password maximumPoolSize = 10 } } } ``` ## Monitoramento do Pipeline Acompanhe métricas do seu pipeline: - **Tempo médio de build:** Deve ficar abaixo de 10 minutos para feedback rápido - **Taxa de falha:** Acima de 10% indica problemas no processo - **Cobertura de testes:** Mantenha acima de 80% para o core business - **Tempo de deploy:** Do merge à produção, idealmente menos de 30 minutos ## Estratégias de Deploy ### Blue-Green Deployment Mantém duas versões do ambiente (blue e green). O deploy vai para o ambiente inativo, e após validação, o tráfego é direcionado para ele. ### Canary Release Direciona uma pequena porcentagem do tráfego (1-5%) para a nova versão. Se tudo estiver bem, aumenta gradualmente até 100%. ### Rolling Update Atualiza instâncias gradualmente, substituindo uma por vez. É a abordagem padrão no Kubernetes. ## Argo CD com Kotlin: quando usar GitOps A consulta de Search Console que motivou esta atualização foi **"argocd vs kotlin"**. A comparação literal não faz sentido: Argo CD não compete com Kotlin. Argo CD é uma ferramenta de GitOps para publicar aplicações em Kubernetes; Kotlin é a linguagem usada para escrever a aplicação. Ainda assim, a busca revela uma dúvida real de quem trabalha com stacks modernas: como um serviço Kotlin entra em um fluxo GitOps? O desenho mais comum é: 1. o repositório da aplicação Kotlin roda testes, detekt, lint, cobertura e build; 2. a pipeline gera uma imagem Docker versionada, por exemplo `registry.exemplo.com/pedidos:1.42.0`; 3. a pipeline atualiza um repositório de manifests, Helm chart ou Kustomize com a nova tag; 4. o Argo CD observa esse repositório de configuração e sincroniza o cluster; 5. métricas, logs e health checks confirmam se o deploy ficou saudável. Nesse modelo, a pipeline de CI continua responsável por qualidade do código Kotlin. O Argo CD entra no CD operacional: ele garante que o estado do Kubernetes siga o que está declarado no Git. Isso reduz deploy manual, facilita rollback e cria uma trilha de auditoria clara para cada versão. Um exemplo simplificado de manifest para um serviço Kotlin/Spring Boot: ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: pedidos-api spec: replicas: 3 selector: matchLabels: app: pedidos-api template: metadata: labels: app: pedidos-api spec: containers: - name: pedidos-api image: registry.exemplo.com/pedidos:1.42.0 ports: - containerPort: 8080 readinessProbe: httpGet: path: /actuator/health/readiness port: 8080 livenessProbe: httpGet: path: /actuator/health/liveness port: 8080 ``` A aplicação Kotlin precisa colaborar com esse fluxo. Em backend, exponha endpoints de health check com Spring Actuator ou Ktor; configure shutdown gracioso; não faça migração destrutiva de banco dentro do startup sem controle; e separe configuração por variável de ambiente ou Secret do Kubernetes. ## Jenkins, GitHub Actions ou Argo CD? Uma dúvida comum em buscas de "Jenkins vs Kotlin" ou "ArgoCD vs Kotlin" é misturar linguagem com ferramenta de entrega. A tabela abaixo ajuda a organizar: | Ferramenta | Papel no projeto Kotlin | Quando escolher | |---|---|---| | GitHub Actions | CI/CD integrado ao GitHub | Projetos pequenos e médios, open source, times que já usam GitHub | | GitLab CI | CI/CD integrado ao GitLab | Empresas com GitLab, runners internos e controle forte de pipeline | | Jenkins | Orquestração flexível de pipelines | Ambientes legados, integrações internas complexas, bancos e grandes empresas | | Argo CD | GitOps e sincronização Kubernetes | Deploy declarativo em cluster, múltiplos ambientes, rollback por Git | | Fastlane | Publicação mobile | Apps Android Kotlin com Play Store e esteiras mobile | Para um backend Kotlin moderno, uma combinação muito saudável é **GitHub Actions ou GitLab CI para build/teste** e **Argo CD para deploy Kubernetes**. Para Android, Argo CD quase nunca é a peça principal; o foco costuma ser Gradle, emuladores, testes instrumentados, assinatura e Play Store. ## Checklist prático para CI/CD Kotlin em 2026 Use este checklist para revisar um projeto real: - `./gradlew test` roda em toda alteração; - dependências Gradle são cacheadas, mas sem esconder falhas de lockfile; - detekt ou ktlint rodam antes do merge; - cobertura é medida com Kover nos módulos críticos; - builds Android geram APK/AAB de forma reproduzível; - backends Kotlin geram imagem Docker com tag imutável; - secrets ficam em vault, variável de ambiente ou Secret, nunca no repositório; - health checks existem antes de usar rolling update, canary ou Argo CD; - migrations têm estratégia de rollback ou compatibilidade entre versões; - logs e métricas permitem saber se o deploy piorou latência, erro ou uso de memória. Se você ainda está começando, não tente implantar tudo no primeiro dia. O maior ganho inicial costuma vir de build, testes e análise estática confiáveis. Depois acrescente Docker, ambientes de staging, deploy automatizado e observabilidade. ## Conclusão CI/CD bem implementado transforma a forma como você desenvolve e entrega software Kotlin. Automação de testes, análise estática, builds reprodutíveis e deploys automatizados criam um ciclo de feedback rápido que aumenta a qualidade e a velocidade de entrega. Comece com o básico (build e testes automáticos) e evolua gradualmente para um pipeline completo com análise de código, cobertura de testes e deploy automatizado. Vale saber que muitas ferramentas de CI/CD como Docker, Kubernetes e Terraform são escritas em Go, e scripts de automação frequentemente usam Python. O investimento em CI/CD se paga rapidamente em menos bugs, menos trabalho manual e mais confiança em cada release.