परिचय: बुनियादी CI/CD पर्याप्त क्यों नहीं है?
\n\nC# परियोजनाओं के लिए CI/CD का प्रारंभिक स्तर आमतौर पर dotnet build और dotnet test के सरल चलाने तक सीमित होता है। हालाँकि, जब प्रोजेक्ट माइक्रोसर्विस आर्किटेक्चर, मोनोरिपॉजिटरी में विकसित हो जाता है या .NET के कई संस्करणों के समर्थन की आवश्यकता होती है, तो मानक दृष्टिकोण अपर्याप्त हो जाता है। बिल्ड का समय बढ़ जाता है, परीक्षण दोहराए जाते हैं, और NuGet पैकेजों की तैनाती की प्रक्रिया एक दिनचर्या बन जाती है।
इस लेख में, हम C# (.NET) परियोजनाओं के लिए GitHub Actions को कॉन्फ़िगर करने की उन्नत तकनीकों पर चर्चा करेंगे। आप सीखेंगे कि कैशिंग के साथ पाइपलाइनों को कैसे तेज़ करें, समानांतर परीक्षण कैसे व्यवस्थित करें, मैट्रिक्स बिल्ड कैसे लागू करें और NuGet में स्वचालित प्रकाशन कैसे सेट करें। सभी कोड उदाहरण आपकी परियोजनाओं में उपयोग के लिए तैयार हैं।
\n\n1. .NET के कई संस्करणों की मैट्रिक्स बिल्ड और परीक्षण
\n\nमैट्रिक्स GitHub Actions का एक शक्तिशाली उपकरण है, जो आपको विभिन्न मापदंडों के साथ एक ही वर्कफ़्लो चलाने की अनुमति देता है। C# के लिए, यह अपरिहार्य है जब आपको .NET 6, .NET 8 और .NET 9 के साथ कोड की संगतता की जाँच करनी होती है।
\n\nमैट्रिक्स कॉन्फ़िगरेशन का उदाहरण
\n\nफ़ाइल बनाएँ .github/workflows/ci-matrix.yml:
name: Matrix Build and Test\n\non:\n push:\n branches: [ main, develop ]\n pull_request:\n branches: [ main ]\n\njobs:\n build:\n runs-on: ubuntu-latest\n strategy:\n matrix:\n dotnet-version: ['6.0.x', '8.0.x', '9.0.x']\n configuration: ['Release', 'Debug']\n fail-fast: false # बिल्ड जारी रखें, भले ही एक संस्करण विफल हो जाए\n\n steps:\n - uses: actions/checkout@v4\n \n - name: Setup .NET ${{ matrix.dotnet-version }}\n uses: actions/setup-dotnet@v4\n with:\n dotnet-version: ${{ matrix.dotnet-version }}\n \n - name: Restore dependencies\n run: dotnet restore\n \n - name: Build\n run: dotnet build --configuration ${{ matrix.configuration }} --no-restore\n \n - name: Run tests\n run: dotnet test --configuration ${{ matrix.configuration }} --no-build --verbosity normal\n\nमुख्य बिंदु:
\n- \n
fail-fast: false— आपको सभी संस्करणों के परिणाम देखने की अनुमति देता है, भले ही उनमें से एक विफल हो जाए। \n - मैट्रिक्स में न केवल .NET संस्करण, बल्कि OS भी शामिल हो सकते हैं (उदाहरण के लिए,
os: [ubuntu-latest, windows-latest])। \n - मोनोरिपॉजिटरी के लिए, आप पैरामीटर
project-pathजोड़ सकते हैं और विभिन्न मॉड्यूल का परीक्षण कर सकते हैं। \n
2. निर्भरता कैशिंग: बिल्ड को 3 गुना तेज़ करें
\n\nGitHub Actions का प्रत्येक रन एक साफ वातावरण से शुरू होता है। कैशिंग के बिना, dotnet restore हर बार सभी NuGet पैकेजों को फिर से डाउनलोड करेगा। बड़ी परियोजनाओं के लिए, इसमें 2-5 मिनट लग सकते हैं। समाधान ~/.nuget/packages फ़ोल्डर को कैश करना है।
कैश की उन्नत सेटिंग
\n\nलॉक फ़ाइल को ध्यान में रखते हुए सही कुंजी के साथ actions/cache एक्शन का उपयोग करें:
steps:\n - uses: actions/checkout@v4\n\n - name: Cache NuGet packages\n uses: actions/cache@v4\n with:\n path: ~/.nuget/packages\n # कुंजी: लॉक फ़ाइल का हैश + OS का नाम\n key: ${{ runner.os }}-nuget-${{ hashFiles('**/*.csproj') }}\n # पिछली कुंजी पर फ़ॉलबैक, यदि लॉक फ़ाइल नहीं बदली है\n restore-keys: |\n ${{ runner.os }}-nuget-\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सुझाव: यदि प्रोजेक्ट में कई .csproj फ़ाइलें हैं, तो अधिक सटीक हैश के लिए hashFiles('**/*.csproj', '**/packages.lock.json') का उपयोग करें।
3. समानांतर परीक्षण चलाना और रिपोर्ट तैयार करना
\n\nजब प्रोजेक्ट में सैकड़ों परीक्षण हों, तो अनुक्रमिक चलाने में दसियों मिनट लग सकते हैं। GitHub Actions जॉब स्तर पर समानांतरीकरण का समर्थन करता है। लेकिन