C# प्रोजेक्ट्स के लिए CI/CD: GitHub Actions A से Z तक

परिचय: C# प्रोजेक्ट्स को CI/CD की आवश्यकता क्यों?

C# और .NET प्लेटफॉर्म पर आधुनिक एप्लिकेशन विकसित करने के लिए न केवल गुणवत्तापूर्ण कोड की आवश्यकता होती है, बल्कि उपयोगकर्ता तक उसे पहुँचाने की एक विश्वसनीय प्रक्रिया की भी आवश्यकता होती है। मैन्युअल बिल्ड, टेस्टिंग और डिप्लॉयमेंट न केवल धीमे होते हैं, बल्कि त्रुटियों से भरे हो सकते हैं। यहाँ CI/CD (Continuous Integration / Continuous Deployment) मदद करता है - यह एक अभ्यास है जो सॉफ्टवेयर जीवनचक्र के सभी चरणों को स्वचालित करता है।

GitHub Actions GitHub का एक अंतर्निहित टूल है जो आपको रिपॉजिटरी में ही शक्तिशाली पाइपलाइन बनाने की अनुमति देता है। इस लेख में, हम जानेंगे कि GitHub Actions का उपयोग करके C# प्रोजेक्ट्स के लिए पूर्ण CI/CD कैसे सेटअप करें: सरल बिल्ड से लेकर स्वचालित डिप्लॉयमेंट तक। आप सीखेंगे कि YAML कॉन्फ़िगरेशन कैसे लिखें, टेस्टिंग को कैसे ऑप्टिमाइज़ करें और सामान्य गलतियों से कैसे बचें।

.NET के लिए GitHub Actions की मूल बातें

Workflow और Job क्या हैं?

Workflow (कार्य प्रक्रिया) एक स्वचालित प्रक्रिया है जो किसी विशिष्ट घटना (push, pull request, रिलीज़ निर्माण) पर शुरू होती है। इसे .github/workflows/*.yml फ़ाइल में वर्णित किया जाता है। Workflow में एक या अधिक job (कार्य) होते हैं, जो रनर्स (वर्चुअल मशीनों) पर निष्पादित होते हैं। प्रत्येक job में steps (चरणों) का एक क्रम हो सकता है।

C# प्रोजेक्ट्स के लिए मुख्य चरण हैं: निर्भरताओं को पुनर्स्थापित करना (dotnet restore), बिल्ड करना (dotnet build), टेस्ट चलाना (dotnet test) और प्रकाशित करना (dotnet publish)।

.NET के लिए बेसिक Workflow टेम्पलेट

नीचे C# प्रोजेक्ट के बिल्ड और टेस्टिंग के लिए एक न्यूनतम workflow दिया गया है। इस कोड को .github/workflows/dotnet-ci.yml फ़ाइल में सेव करें।

name: .NET CI\n\non:\n  push:\n    branches: [ main, develop ]\n  pull_request:\n    branches: [ main ]\n\njobs:\n  build-and-test:\n    runs-on: ubuntu-latest\n\n    steps:\n    - name: Checkout repository\n      uses: actions/checkout@v4\n\n    - name: Setup .NET\n      uses: actions/setup-dotnet@v4\n      with:\n        dotnet-version: '8.0.x'\n\n    - name: Restore dependencies\n      run: dotnet restore\n\n    - name: Build\n      run: dotnet build --no-restore --configuration Release\n\n    - name: Run tests\n      run: dotnet test --no-build --configuration Release --verbosity normal

मुख्य पंक्तियों का विश्लेषण:

\n
• actions/checkout@v4 — रिपॉजिटरी को निष्पादन वातावरण में क्लोन करता है।
\n
• actions/setup-dotnet@v4 — .NET SDK के निर्दिष्ट संस्करण को स्थापित करता है।
\n
• dotnet restore — NuGet पैकेज डाउनलोड करता है।
\n
• dotnet build --configuration Release — प्रोजेक्ट को Release मोड में बनाता है।
\n
• dotnet test — समाधान के सभी टेस्ट चलाता है।
\n

उन्नत सेटअप: कैशिंग और मैट्रिक्स बिल्ड

NuGet पैकेज कैशिंग

प्रत्येक workflow रन एक साफ वातावरण से शुरू होता है। प्रक्रिया को तेज़ करने के लिए, ~/.nuget/packages फ़ोल्डर को कैश किया जा सकता है। यह दर्जनों निर्भरताओं वाले बड़े प्रोजेक्ट्स के लिए विशेष रूप से उपयोगी है।

steps:\n  - uses: actions/cache@v4\n    with:\n      path: ~/.nuget/packages\n      key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}\n      restore-keys: |\n        ${{ runner.os }}-nuget-\n  - run: dotnet restore

कैश की कुंजी प्रोजेक्ट फ़ाइलों (.csproj) के हैश पर आधारित होती है। यदि निर्भरताएँ नहीं बदली हैं, तो कैश सेकंडों में पुनर्स्थापित हो जाएगा।

मैट्रिक्स बिल्ड (Matrix Strategy)

यदि आपका एप्लिकेशन .NET के विभिन्न संस्करणों या ऑपरेटिंग सिस्टम पर काम करना चाहिए, तो मैट्रिक्स का उपयोग करें। GitHub Actions स्वचालित रूप से प्रत्येक संयोजन के लिए एक अलग job बनाएगा।

jobs:\n  build:\n    strategy:\n      matrix:\n        os: [ubuntu-latest, windows-latest]\n        dotnet: ['6.0.x', '8.0.x']\n    runs-on: ${{ matrix.os }}\n    steps:\n      - uses: actions/checkout@v4\n      - name: Setup .NET\n