C# के साथ मोनोरिपॉजिटरी: .NET प्रोजेक्ट्स में कोड का संगठन

C# के साथ मोनोरेपॉजिटरी: .NET प्रोजेक्ट्स में कोड को कैसे व्यवस्थित करें

C# और .NET में आधुनिक डेवलपमेंट तेजी से एक विकल्प का सामना कर रही है: सभी संबंधित प्रोजेक्ट्स को एक रेपॉजिटरी (मोनोरेपॉजिटरी) में रखना या उन्हें अलग-अलग रेपॉजिटरी (मल्टीरेपॉजिटरी) में विभाजित करना। मोनोरेपॉजिटरी एक दृष्टिकोण है जिसमें कई एप्लिकेशन, लाइब्रेरी, टेस्ट और कॉन्फ़िगरेशन का कोड एक Git रेपॉजिटरी में संग्रहीत किया जाता है। बड़े कॉर्पोरेट समाधानों, माइक्रोसर्विसेज या NuGet लाइब्रेरी के लिए, यह दृष्टिकोण डिपेंडेंसी प्रबंधन, रिफैक्टरिंग और डिप्लॉयमेंट को काफी सरल बना सकता है।

इस लेख में, हम चर्चा करेंगे कि .NET इकोसिस्टम में C# के साथ मोनोरेपॉजिटरी को ठीक से कैसे व्यवस्थित किया जाए, फ़ोल्डर संरचना, प्रोजेक्ट सेटअप, CI/CD और सर्वोत्तम प्रथाओं की समीक्षा करेंगे।

1. .NET में मोनोरेपॉजिटरी के लाभ और नुकसान

तकनीकी विवरणों में गहराई से जाने से पहले, यह समझना महत्वपूर्ण है कि मोनोरेपॉजिटरी कब वास्तव में उपयोगी है और कब यह समस्या बन सकती है।

लाभ:

• डिपेंडेंसी का एकीकृत संस्करण। रेपॉजिटरी के अंदर सभी प्रोजेक्ट पैकेज के समान संस्करणों का उपयोग करते हैं, जो संस्करण विरोध को समाप्त करता है।
• सरलीकृत रिफैक्टरिंग। किसी साझा इंटरफ़ेस या API लाइब्रेरी में बदलाव तुरंत उन सभी प्रोजेक्ट्स में दिखाई देता है जो इसका उपयोग करते हैं।
• कमिट की अखंडता। परमाणु कमिट जो लाइब्रेरी और एप्लिकेशन दोनों को बदलते हैं, अस्थायी अंतराल के बिना काम करते हैं।
• साझा सेटिंग्स। एक Directory.Build.props फ़ाइल सभी प्रोजेक्ट्स के लिए कंपाइलेशन सेटिंग्स, कोड विश्लेषण और संस्करण निर्धारित करती है।

नुकसान:

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

.NET प्रोजेक्ट्स के लिए, मोनोरेपॉजिटरी विशेष रूप से सुविधाजनक है जब आपके पास एक साझा क्लास लाइब्रेरी (जैसे, Domain या Common) और कई माइक्रोसर्विसेज या वेब-API हों जो इस पर निर्भर हों।

2. C# (.NET) के लिए मोनोरेपॉजिटरी संरचना

उचित फ़ोल्डर संरचना एक सफल मोनोरेपॉजिटरी की नींव है। आइए एक समाधान के लिए विशिष्ट संगठन पर विचार करें जिसमें कई माइक्रोसर्विसेज, एक लाइब्रेरी और टेस्ट शामिल हों।

MyApp/├── .github/│   └── workflows/│       └── ci.yml├── src/│   ├── MyApp.Common/          # साझा लाइब्रेरी│   │   ├── MyApp.Common.csproj│   │   └── ...│   ├── MyApp.Api.Orders/      # ऑर्डर के लिए माइक्रोसर्विस│   │   ├── MyApp.Api.Orders.csproj│   │   └── ...│   └── MyApp.Api.Users/       # उपयोगकर्ताओं के लिए माइक्रोसर्विस│       ├── MyApp.Api.Users.csproj│       └── ...├── tests/│   ├── MyApp.Common.Tests/│   │   ├── MyApp.Common.Tests.csproj│   │   └── ...│   └── MyApp.Api.Orders.Tests/│       ├── MyApp.Api.Orders.Tests.csproj│       └── ...├── Directory.Build.props       # सभी प्रोजेक्ट्स के लिए साझा सेटिंग्स├── MyApp.sln                   # Visual Studio के लिए समाधान└── README.md

मुख्य बिंदु:

• सभी प्रोजेक्ट src/ फ़ोल्डर में हैं, टेस्ट tests/ में हैं। यह .NET समुदाय में स्वीकृत मानक है।
• Directory.Build.props फ़ाइल साझा गुण निर्धारित करती है: TargetFramework, Nullable, ImplicitUsings, पैकेज संस्करण आदि।
• एक SLN फ़ाइल IDE में काम को सरल बनाती है, लेकिन बड़ी संख्या में प्रोजेक्ट्स के साथ, इसे कई समाधानों में विभाजित किया जा सकता है।

Directory.Build.props का उदाहरण:

<Project>  <PropertyGroup>    <TargetFramework>net8.0</TargetFramework>    <Nullable>enable</Nullable>    <ImplicitUsings>enable</ImplicitUsings>    <TreatW