हम कंटेनर को Azure DevOps (VSTS) में इकाई परीक्षणों के साथ लॉन्च करते हैं

.नेट कोर के आगमन के साथ, हमारे पास अलग-अलग ओएस पर न केवल अपना कोड चलाने का एक शानदार अवसर है, बल्कि विभिन्न ओएस पर भी इसका परीक्षण करें। और क्या अलग ओएस के साथ काम करते समय डॉकर से बेहतर हो सकता है?

परीक्षण अधिक मूल्यवान है जब आपके पास परीक्षण वातावरण और लक्ष्य वातावरण के बीच कोई अंतर नहीं है। कल्पना करें कि आप कई ऑपरेटिंग सिस्टम या ऑपरेटिंग सिस्टम के संस्करणों पर अपने एप्लिकेशन का समर्थन करते हैं। डॉकर के साथ, आप उनमें से प्रत्येक में अपने आवेदन का परीक्षण कर सकते हैं।

इस लेख में, हम देखेंगे कि एक अलग छवि कैसे बनाई जाए, जिसमें आपके एप्लिकेशन के यूनिट परीक्षण लॉन्च किए जाएंगे और VSTS में इस सभी CI / CD पाइपलाइन के लिए कॉन्फ़िगर किया जाएगा जो हाल ही में Azure DevOps है।

यदि आप डॉकर के साथ काम करते हैं, तो आप शायद अपने कंटेनरों के निर्माण के लिए मल्टी-स्टेज बिल्ड का उपयोग कर रहे हैं। इस स्थिति में, आप एक ही डॉकर फ़ाइल के भीतर बायनेरिज़ (बिल्ड छवि का उपयोग करके) और अंतिम छवि (रनटाइम छवि का उपयोग करके) के निर्माण को जोड़ते हैं।

यदि आपके सिस्टम में एक कंटेनर शामिल है, तो इस मामले में अंतिम छवि के निर्माण की प्रक्रिया के भाग के रूप में परीक्षण चलाने के लिए सबसे आम तरीका हो सकता है। यही है, डॉकरफाइल में परीक्षण चल रहा है।

मल्टी-स्टेप प्रक्रिया में ऐसा करने के लिए, जब आप docker build लॉन्च करते हैं, तो आप अंतिम छवि बनाने में एक और कदम के रूप में परीक्षण चलाते हैं। आइए एक साधारण उदाहरण देखें। मान लें कि हमारे पास दो प्रोजेक्ट हैं: वेब एप्लिकेशन और यूनिट टेस्ट:


अभी के लिए, आइए इस बारे में चिंता न करें कि वेब एप्लिकेशन क्या करता है। दूसरी ओर, हमारे पास एकमात्र परीक्षण है जो GuidProvider के व्यवहार की जांच करता है और इस तरह दिखता है:

 [Fact] public void Never_return_a_empty_guid() { // Arrange & Act var provider = new GuidProvider(); var id = provider.Id; // Assert Assert.NotEqual(Guid.Empty, id); } 

अब एक Dockerfile बनाएं जो WebApplication छवि बनाएगा और एक ही समय में परीक्षण चलाएगा:

 FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base WORKDIR /app EXPOSE 80 FROM microsoft/dotnet:2.1-sdk AS build WORKDIR /src COPY CiCd.sln . COPY WebApplication/WebApplication.csproj WebApplication/ COPY WebApplication.Test/WebApplication.Test.csproj WebApplication.Test/ RUN dotnet restore COPY . . WORKDIR /src/WebApplication RUN dotnet build --no-restore -c Release -o /app FROM build as test WORKDIR /src/WebApplication.Test RUN dotnet test FROM build AS publish WORKDIR /src/WebApplication RUN dotnet publish --no-build -c Release -o /app FROM base AS final WORKDIR /app COPY --from=publish /app . ENTRYPOINT ["dotnet", "WebApplication.dll"] 

इस डॉकरीफाइल को एक डायरेक्टरी में सॉल्यूशन फाइल (iCd.sln) के साथ रखा जाना चाहिए। एक छवि बनाने के लिए, कमांड का उपयोग करें:

 docker build -t webapplication . 

हमारा परीक्षण विफल हो जाता है ( GuidProvider में एक त्रुटि जो हमेशा Guid.Empty वापस कर Guid.Empty ), इसलिए छवि निर्माण विफल हो जाएगा:


अब देखते हैं कि Azure DevOps में इस प्रक्रिया को कैसे शुरू किया जाए।

फिलहाल हमारी बिल्ड परिभाषा एक डॉकर टाइप कार्य है:



लॉन्च के परिणामस्वरूप, निर्माण विफल हो जाता है क्योंकि हमारा परीक्षण गिर जाता है। इसके अलावा, हमारे पास परीक्षण के परिणाम नहीं हैं ("टेस्ट" टैब खाली है), क्योंकि परीक्षण VSTS की समझ में नहीं किया जाता है:



छवि असेंबली के भाग के रूप में चल रहे परीक्षण पूरी तरह से खराब नहीं हैं, लेकिन यह वीएसटीएस को यह जानने से रोक देगा कि परिणाम क्या था। यह डॉकर के "सीमा" के कारण है, जो docker build दौरान वॉल्यूम बनाने की अनुमति नहीं देता है, इसलिए हम परीक्षण के परिणाम (जो dotnet test का उपयोग करके उत्पन्न किया जा सकता है) के साथ एक फ़ाइल प्रदान नहीं कर सकते हैं, यह फ़ाइल एक मध्यवर्ती कंटेनर में बनी हुई है, और हम इसे आसानी से प्राप्त कर सकते हैं उसे वहाँ से।

हम एक अलग दृष्टिकोण लेंगे और docker run लिए एक बढ़िया विकल्प का उपयोग करेंगे। सबसे पहले, चलो एक अलग कंटेनर बढ़ाएं और उसमें परीक्षण चलाएं। दोनों कंटेनरों के लिए, हम एक ही डॉकरफाइल का उपयोग कर सकते हैं। सबसे पहले, हमें उस लाइन को हटाने की ज़रूरत है जो डॉकरफ़ाइल से डॉटनेट dotnet test चलाता है, क्योंकि अब हम उन्हें अलग से चलाएंगे। ठीक है, अब आइए docker docker run का उपयोग करते हैं, जो आपको Dockerfile को एक विशेष बिंदु पर चलाने की अनुमति देता है। हमारे मामले में, यह परीक्षण चरण है:

 docker build -t webapplication-tests . --target test 

-target पैरामीटर इंगित करता है कि किस चरण को इकट्ठा करना है। कृपया ध्यान दें कि उत्पन्न छवि को " वेबएपिसलेशन-परीक्षण " कहा जाएगा। अब हम अपने परीक्षण चला सकते हैं और कंटेनर में उनके निष्पादन के परिणामों के साथ फ़ाइल " test-results.trx " को बचा सकते हैं ।

 docker run -v/c/tests:/tests webapplication-tests --entrypoint "dotnet test --logger trx;LogFileName=/tests/test-results.trx" 

यहां हम पिछले चरण में बनाई गई छवि को चलाते हैं, और इसके माध्यम से हम कंटेनर " परीक्षण " निर्देशिका को मेजबान निर्देशिका (मेरे मामले में डी: \ सीईसीडी \ परीक्षण) में मैप करते हैं। परिणामस्वरूप, मुझे D: \ CiCD \ परीक्षण में परीक्षा परिणाम मिला।

अंतिम छवि बनाने के लिए, चलाएं:

 docker build -t webapplication . 

फायदा यह है कि डॉकर स्तर के मॉडल के लिए धन्यवाद, अन्य सभी चरणों को फिर से निष्पादित करने की आवश्यकता नहीं है (यानी आवेदन को फिर से शुरू करने की कोई आवश्यकता नहीं है)।

ठीक है, चलो अब यह सब Azure DevOps पाइपलाइनों पर लागू करें। विधानसभा को सरल बनाने और बड़ी संख्या में मापदंडों से बचने के लिए, हम डॉकटर-कंपोज का उपयोग करेंगे। हमारे docker-compose.yml में निम्नलिखित सामग्री है:

 version: '3.5' services: webapplication: image: webapplication build: context: . dockerfile: Dockerfile webapplication-tests: image: webapplication-tests build: context: . dockerfile: Dockerfile target: test 

यहां हम दो छवियों (वेबएपिसलेशन और वेबएपिसलेशन-परीक्षण) को परिभाषित करते हैं। ताकि सब कुछ कैनन के अनुसार हो जाए, आइए डॉकटर-कंपोज़.ओवर्राइड.माइल फ़ाइल जोड़ें:

 version: '3.5' services: webapplication: environment: - ASPNETCORE_ENVIRONMENT=Development ports: - "8080:80" webapplication-tests: entrypoint: - dotnet - test - --logger - trx;LogFileName=/tests/test-results.trx volumes: - ${BUILD_ARTIFACTSTAGINGDIRECTORY:-./tests/}:/tests 

महान, अब हम सिर्फ जरूरत परीक्षण चलाने के लिए:

 docker-compose run webapplication-tests 

यह कमांड परीक्षण चलाता है और पर्यावरण चर BUILD_ARTIFACTSTAGINGDIRECTORY या डिफ़ॉल्ट मान द्वारा निर्दिष्ट निर्देशिका में आउटपुट trx फ़ाइल बनाता ./tests । / ./tests । अंतिम छवि इस प्रकार की गई है:

 docker-compose build webapplication 

अब आप Azure DevOps में हमारी CI प्रक्रिया संपादित कर सकते हैं। ऐसा करने के लिए, हम निम्नलिखित चरणों को परिभाषित करते हैं:

1. सभी छवियों को इकट्ठा [निर्माण]
2. इकाई परीक्षण चलाएं [चलाएं]
3. परीक्षा परिणाम प्रकाशित करें [प्रकाशित करें]
4. रिपॉजिटरी (रजिस्ट्री) में चित्र चलाएँ [पुश]

आइए पहले चरण से शुरू करें, जो Azure में Docker Compose task (कार्य) है:



हम Action: Build service images डालते हैं Action: Build service images बनाते हैं और डॉकटर-कंपोज़.माइल को पथ निर्दिष्ट करते हैं।

अगला, कंटेनर को इकाई परीक्षणों से चलाएँ:



यहां आपको Action: Run a specific service image का चयन करने की आवश्यकता है Action: Run a specific service image और कंटेनर का नाम निर्दिष्ट करें Service Name: webapplication-tests । इसके अलावा, docker-compose.yml और docker-compose.override.yml के रास्ते के बारे में मत भूलना। Run in Background फॉर Run in Background का मान सेट नहीं होना चाहिए, अन्यथा कंटेनर "डिटैच मोड" में शुरू होगा और कार्य परीक्षणों के परिणामों की प्रतीक्षा नहीं करेगा और अगले चरण पर जाएगा। प्रकाशित परीक्षा परिणाम कार्य उन परिणामों को प्रकाशित करने का प्रयास करेगा जो अभी तक उपलब्ध नहीं हैं, क्योंकि परीक्षण चलाने में समय लगता है।

तीसरा चरण "टेस्ट परिणाम प्रकाशित करें" है:



Run this task: Even if a previous task has failed, unless the build was canceled लिए निर्दिष्ट करना महत्वपूर्ण है Run this task: Even if a previous task has failed, unless the build was canceled । यह विकल्प महत्वपूर्ण है क्योंकि परीक्षण विफल होने पर परिणाम कभी प्रकाशित नहीं होंगे। Search folder: $(Build.ArtifactStagingDirectory)

अंतिम चरण छवियों को भंडारण में धकेलना होगा। ऐसा करने के लिए, Azure सदस्यता, साथ ही Azure कंटेनर रजिस्ट्री निर्दिष्ट करें। नया निर्माण करने के लिए सब कुछ तैयार है। सहेजें। हम शुरू करते हैं। यदि परीक्षण विफल होते हैं, तो बिल्ड विफल हो जाएगा, लेकिन अब हम VSTS में परिणाम देखते हैं:



मुझे आशा है कि यह सामग्री सहायक थी। आप यहाँ मेरी असेंबली कॉन्फ़िगरेशन yml फ़ाइल पा सकते हैं।

आपका ध्यान के लिए धन्यवाद!