Kotlin के साथ मोनोरिपॉजिटरी: कोड का व्यावहारिक संगठन

परिचय: Kotlin में मोनोरिपॉजिटरी क्यों?

Kotlin में आधुनिक विकास में अक्सर एक दुविधा होती है: कई संबंधित प्रोजेक्ट्स (बैकएंड, माइक्रोसर्विसेज़, लाइब्रेरीज़, Android ऐप्स) को अलग-अलग रिपॉजिटरी (पॉलीरिपॉजिटरी) में रखें या उन्हें एक मोनोरिपॉजिटरी में मिला दें। मोनोरिपॉजिटरी कोड संग्रहण की एक रणनीति है जिसमें सभी घटक एक ही संस्करण नियंत्रण प्रणाली में होते हैं। Kotlin प्रोजेक्ट्स के लिए, यह Gradle की शक्तिशाली बिल्ड प्रणाली और मल्टी-मॉड्यूलरिटी के अंतर्निहित समर्थन के कारण विशेष रूप से प्रासंगिक है।

इस लेख में, हम Kotlin के साथ मोनोरिपॉजिटरी के आयोजन के व्यावहारिक पहलुओं पर चर्चा करेंगे: निर्देशिका संरचना से लेकर CI/CD सेटअप और निर्भरता प्रबंधन तक। आप सीखेंगे कि सामान्य गलतियों से कैसे बचें और एक एकीकृत कोड भंडार से अधिकतम लाभ कैसे प्राप्त करें।

1. मोनोरिपॉजिटरी संरचना: सिद्धांत से व्यवहार तक

सही संरचना एक सफल मोनोरिपॉजिटरी की नींव है। एक विशिष्ट प्रोजेक्ट पर विचार करें जिसमें Ktor पर REST API, डेटाबेस के साथ काम करने के लिए एक लाइब्रेरी और एक Android ऐप शामिल है। यहाँ अनुशंसित पदानुक्रम है:

my-monorepo/\n├── build.gradle.kts          # रूट बिल्ड फ़ाइल\n├── settings.gradle.kts       # मॉड्यूल कॉन्फ़िगरेशन\n├── gradle.properties         # सामान्य गुण\n├── gradle/\n│   └── libs.versions.toml    # संस्करण सूची (Version Catalog)\n├── libs/                     # साझा लाइब्रेरीज़\n│   ├── common-utils/         # उपयोगिताएँ, एक्सटेंशन\n│   ├── common-db/            # DB कार्य (Exposed)\n│   └── common-dto/           # डेटा ट्रांसफर ऑब्जेक्ट\n├── services/                 # सर्वर एप्लिकेशन\n│   ├── user-service/         # उपयोगकर्ता माइक्रोसर्विस\n│   └── order-service/        # ऑर्डर माइक्रोसर्विस\n└── apps/                     # क्लाइंट एप्लिकेशन\n    └── android-app/          # Android एप्लिकेशन\n

मुख्य तत्व settings.gradle.kts है। यह सभी मॉड्यूल शामिल करता है:

rootProject.name = "my-monorepo"\n\ninclude("libs:common-utils")\ninclude("libs:common-db")\ninclude("libs:common-dto")\ninclude("services:user-service")\ninclude("services:order-service")\ninclude("apps:android-app")\n

ऐसी संरचना सेवाओं और क्लाइंट के बीच कोड को आसानी से पुन: उपयोग करने की अनुमति देती है, साथ ही निर्भरता संस्करणों को केंद्रीय रूप से प्रबंधित करती है।

1.1. संस्करण सूची: निर्भरता प्रबंधन

मोनोरिपॉजिटरी में लाइब्रेरी संस्करणों के दोहराव से बचना महत्वपूर्ण है। Version Catalog (फ़ाइल gradle/libs.versions.toml) का उपयोग करें:

[versions]\nkotlin = "2.0.21"\nktor = "3.0.3"\nexposed = "0.57.0"\n\n[libraries]\nktor-server-core = { module = "io.ktor:ktor-server-core", version.ref = "ktor" }\nexposed-core = { module = "org.jetbrains.exposed:exposed-core", version.ref = "exposed" }\n\n[plugins]\nkotlin-jvm = { id = "org.jetbrains.kotlin.jvm", version.ref = "kotlin" }\n

अब किसी भी मॉड्यूल में आप लिख सकते हैं:

dependencies {\n    implementation(libs.ktor.server.core)\n    implementation(libs.exposed.core)\n}\n

यह सुनिश्चित करता है कि सभी मॉड्यूल समान संस्करणों का उपयोग करते हैं, और बड़े पैमाने पर अपडेट को सरल बनाता है।

2. मॉड्यूल का व्यावहारिक संगठन: Gradle Multi-Project

मोनोरिपॉजिटरी का प्रत्येक मॉड्यूल अपने स्वयं के build.gradle.kts के साथ एक अलग Gradle उप-प्रोजेक्ट है। common-utils लाइब्रेरी के सेटअप पर विचार करें:

// libs/common-utils/build.gradle.kts\nplugins {\n    alias(libs.plugins.kotlin.jvm)\n}\n\ngroup = "com.mycompany.common"\nversion = "1.0.0"\n\ndependencies {\n    implementation(kotlin("stdlib"))\n    implementation(libs.kotlinx.coroutines)\n}\n

और यहाँ Ktor पर एक विशिष्ट माइक्रोसर्विस है:

// services/user-service/build.gradle.kts\nplugins {\n    alias(libs.plugins.kotlin.jvm)\n    alias(libs.plugins.ktor)\n}\n\ndependencies {\n    implementation(project(":libs:common-utils"))\n    implementation(project(":libs:common-dto"))\n    impl