C# के लिए CI/CD: आलसी और व्यस्त लोगों के लिए स्क्रैच से पाइपलाइन सेटअप

C# के लिए CI/CD: मैन्युअल डिप्लॉय करना बंद करें और जीना शुरू करें

यदि आप अभी भी C# प्रोजेक्ट को लोकली बिल्ड करते हैं, FTP के माध्यम से बिल्ड अपलोड करते हैं और प्रार्थना करते हैं कि कुछ खराब न हो — तो मेरे पास आपके लिए खबर है। 2025 में ऐसा करना शर्मनाक है। छोटे pet-प्रोजेक्ट के लिए भी।

CI/CD — यह 300k के सीनियर्स का जादू नहीं है, बल्कि स्क्रिप्ट्स का एक सेट है जो आपके लिए रूटीन करता है। आज हम स्क्रैच से C# के लिए एक पूर्ण CI/CD पाइपलाइन सेटअप करेंगे। बिना पानी के, वास्तविक उदाहरणों और त्रुटियों के विश्लेषण के साथ।

वैसे, यदि आप Python में लिखते हैं — हमारे पास pythonlib.ru पर ऑटोमेशन के लिए गाइड भी हैं। लेकिन आज हम C# के साथ काम करेंगे।

CI/CD क्या है और यह C# डेवलपर के लिए क्यों ज़रूरी है

CI (Continuous Integration) — यह तब होता है जब आपका प्रत्येक Git कमिट स्वचालित रूप से बिल्ड और टेस्ट होता है। कोई "मेरे पास तो काम करता है" नहीं।

CD (Continuous Delivery/Deployment) — यह तब होता है जब सफल बिल्ड के बाद कोड स्वयं सर्वर (या क्लाउड) पर चला जाता है।

C# के लिए यह विशेष रूप से प्रासंगिक है: dotnet build के माध्यम से बिल्ड अलग-अलग मशीनों पर भिन्न हो सकता है, और टेस्ट चलाना लगभग सभी भूल जाते हैं। CI/CD दोनों समस्याओं का समाधान करता है।

टूल चुनना: GitHub Actions बनाम GitLab CI बनाम Jenkins

शुरुआत के लिए मैं GitHub Actions की सलाह देता हूँ। क्यों?

\n
• सार्वजनिक रिपॉजिटरी के लिए मुफ्त (हाँ, C# के लिए भी)
\n
• सर्वर स्थापित करने की आवश्यकता नहीं
\n
• .NET के लिए तैयार एक्शन
\n
• YAML — पढ़ने में आसान
\n

यदि आपके पास GitLab है — सिद्धांत वही है, सिंटैक्स समान है। Jenkins को कॉर्पोरेट नरक के लिए छोड़ दें।

C# प्रोजेक्ट के लिए पहली पाइपलाइन लिखना

रिपॉजिटरी की रूट में फ़ाइल .github/workflows/dotnet.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    - 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
• on: push — पाइपलाइन main या develop में push करने पर चलती है
\n
• runs-on: ubuntu-latest — Linux पर बिल्ड करते हैं (C# .NET Core/8+ पर हर जगह काम करता है)
\n
• setup-dotnet — .NET SDK का आवश्यक संस्करण स्थापित करता है
\n
• dotnet restore — NuGet पैकेज पुनर्स्थापित करता है
\n
• dotnet build — रिलीज़ संस्करण कंपाइल करता है
\n
• dotnet test — प्रोजेक्ट के सभी टेस्ट चलाता है
\n

Push करने के बाद अपने रिपॉजिटरी के Actions टैब पर जाएँ — आप पाइपलाइन को चलते हुए देखेंगे। यदि टेस्ट विफल होते हैं — आपको लाल स्थिति और ईमेल पर एक पत्र मिलेगा।

Code Coverage जोड़ना (क्योंकि बिना कवरेज के टेस्ट झूठ हैं)

एक अच्छी पाइपलाइन को दिखाना चाहिए कि कितना कोड टेस्ट द्वारा कवर किया गया है। C# के लिए हम coverlet का उपयोग ReportGenerator के साथ करते हैं।

पहले टेस्ट प्रोजेक्ट में NuGet पैकेज जोड़ें:

dotnet add YourTestProject.csproj package coverlet.collector\ndotnet add YourTestProject.csproj package coverlet.msbuild

अब पाइपलाइन में टेस्ट स्टेप अपडेट करें:

    - name: Run tests with coverage\n      run: |\n        dotnet test --no-build --configuration Release \\\n          /p:CollectCoverage=true \\\n          /p:CoverletOutputFormat=opencover \\\n          /p:CoverletOutput=./TestResults/coverage.xml\n\n    - name: Install ReportGenerator\n      run: dotnet t