Monorepositorio con Kotlin: organización del código y mejores prácticas

Monorepositorio con Kotlin: organización del código y mejores prácticas

Con el crecimiento de los proyectos y el aumento del número de servicios, los desarrolladores se enfrentan a la pregunta: ¿cómo organizar el código para que siga siendo manejable, fácil de probar y rápido de implementar? Uno de los enfoques populares es el monorepositorio (monorepo). En este artículo, analizaremos cómo organizar eficazmente un monorepositorio en Kotlin usando Gradle, qué herramientas y patrones aplicar, y cómo evitar errores típicos.

¿Qué es un monorepositorio y para qué sirve?

Un monorepositorio es un enfoque en el que el código de varios proyectos (módulos, bibliotecas, servicios) se almacena en un único repositorio. En el contexto de Kotlin, esto significa que puede tener un proyecto Gradle común que contenga módulos para servicios backend, aplicaciones Android, bibliotecas compartidas e incluso documentación.

Ventajas del monorepositorio:

• Versionado unificado — todos los módulos usan la misma versión de Kotlin y dependencias comunes.
• Refactorización simplificada — los cambios en una biblioteca compartida son visibles inmediatamente para todos los consumidores.
• Configuración CI/CD compartida — un único pipeline para todos los módulos.
• Colaboración mejorada — los desarrolladores ven todo el código del proyecto.

Sin embargo, el monorepositorio requiere disciplina: sin una organización adecuada, puede convertirse en un "monolito" con dependencias enredadas. Kotlin y Gradle proporcionan excelentes herramientas para combatir esto.

Estructura del monorepositorio en Kotlin

Consideremos una estructura típica de proyecto que incluye un servicio backend con Ktor, una biblioteca compartida para modelos de datos y una aplicación Android:

my-monorepo/├── build.gradle.kts          # archivo de compilación raíz├── settings.gradle.kts       # inclusión de módulos├── gradle.properties         # versiones comunes├── common/│   ├── build.gradle.kts│   └── src/│       └── main/kotlin/│           └── com/example/common/│               └── Models.kt├── backend/│   ├── build.gradle.kts│   └── src/│       └── main/kotlin/│           └── com/example/backend/│               └── Application.kt├── android-app/│   ├── build.gradle.kts│   └── src/│       └── main/kotlin/│           └── com/example/android/│               └── MainActivity.kt└── ci/    └── build.sh

El archivo settings.gradle.kts incluye los módulos:

rootProject.name = "my-monorepo"

include(":common")include(":backend")include(":android-app")

El build.gradle.kts raíz normalmente contiene solo los plugins comunes y la configuración:

plugins {    kotlin("jvm") version "1.9.22" apply false    kotlin("android") version "1.9.22" apply false    id("org.jetbrains.kotlin.plugin.serialization") version "1.9.22" apply false}

allprojects {    group = "com.example"    version = "1.0.0"}

Importante: los plugins se especifican con apply false para que no se apliquen al proyecto raíz, sino que estén disponibles para los módulos hijos.

Gestión de dependencias en el monorepositorio

Una de las principales tareas es evitar la duplicación de versiones de dependencias. Para ello se utiliza el Gradle Version Catalog (archivo libs.versions.toml en la carpeta gradle). Ejemplo:

# gradle/libs.versions.toml[versions]kotlin = "1.9.22"ktor = "2.3.7"coroutines = "1.7.3"

[libraries]ktor-server-core = { module = "io.ktor:ktor-server-core", version.ref = "ktor" }ktor-server-netty = { module = "io.ktor:ktor-server-netty", version.ref = "ktor" }kotlinx-coroutines = { module = "org.jetbrains.kotlinx:kotlinx-coroutines-core", version.ref = "coroutines" }

[plugins]kotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }kotlin-serialization = { id = "org.jetbrains.kotlin.plugin.