Azure Pipelines से CI पाइपलाइन बनाना
एक YAML पाइपलाइन परिभाषित करें जो पुल अनुरोधों पर शुरू हो, यूनिट परीक्षण चलाए और बिल्ड आर्टिफैक्ट बनाए; फिर पोर्टल में परीक्षण परिणाम और कोड कवरेज की समीक्षा करें।
Azure Pipelines से CI पाइपलाइन बनाना, CoddyKit पर Azure Fundamentals का एक निःशुल्क पाठ है। यह 4 में से 2वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Azure Fundamentals सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Azure Fundamentals पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
सतत एकीकरण क्या है
सतत एकीकरण (CI) कोड में किए गए बदलावों को बार-बार साझा Branch में मिलाने की प्रक्रिया है, जिसमें हर विलय अपने-आप Build और परीक्षण चलाता है। इसका उद्देश्य एकीकरण की विफलताओं का जल्दी पता लगाना है — इससे पहले कि वे बढ़कर बड़ी और ठीक करने में कठिन समस्याएँ बन जाएँ। एक अच्छी CI Pipeline कोड बनाती है, यूनिट परीक्षण चलाती है, कोड कवरेज मापती है, स्थैतिक विश्लेषण करती है और कुछ ही मिनटों में परिनियोजित किए जा सकने वाले आर्टिफैक्ट का निर्माण करती है। Azure Pipelines इस प्रक्रिया के लिए स्वचालन इंजन प्रदान करता है।
YAML Pipeline की संरचना
Azure Pipelines CI Pipelines आपके रिपॉज़िटरी के मूल स्थान पर मौजूद azure-pipelines.yml फ़ाइल में परिभाषित की जाती हैं। YAML फ़ाइल ट्रिगर (कब चलाना है), एक पूल (किस प्रकार के Agent का उपयोग करना है) और चरणों, जॉब तथा स्टेप का पदानुक्रम निर्दिष्ट करती है। डिफ़ॉल्ट रूप से चरण क्रमिक रूप से चलते हैं। किसी चरण के भीतर जॉब डिफ़ॉल्ट रूप से समानांतर चलते हैं। किसी जॉब के भीतर स्टेप क्रमिक रूप से चलते हैं। यह संरचना Pipeline के निष्पादन प्रवाह पर सूक्ष्म नियंत्रण देती है।
# azure-pipelines.yml skeleton
trigger:
branches:
include:
- main
- 'feature/*'
paths:
exclude:
- docs/**
- '*.md'
pool:
vmImage: ubuntu-latest
variables:
buildConfiguration: Release
nodeVersion: '18.x'
stages:
- stage: CI
displayName: 'Build and Test'
jobs:
- job: Build
displayName: 'Build Application'
steps: []ट्रिगर कॉन्फ़िगरेशन
Azure Pipelines कई प्रकार के ट्रिगर का समर्थन करता है। Branch ट्रिगर तब Pipeline चलाते हैं, जब निर्दिष्ट Branch में कोड पुश किया जाता है। Pull request ट्रिगर (PR ट्रिगर) तब चलते हैं, जब लक्षित Branch के विरुद्ध PR खोला या अपडेट किया जाता है — विलय से पहले कोड का सत्यापन करने के लिए यह आवश्यक है। Scheduled ट्रिगर किसी निश्चित समय पर चलते हैं (जैसे, हर रात के Build)। Pipeline ट्रिगर Pipelines को एक-दूसरे से जोड़ते हैं। स्वचालित रन बंद करने और केवल मैन्युअल निष्पादन की अनुमति देने के लिए trigger: none निर्दिष्ट करें।
# Branch trigger
trigger:
branches:
include: [main, develop]
# Pull request trigger
pr:
branches:
include: [main]
autoCancel: true # Cancel previous runs when PR is updated
# Scheduled trigger (nightly build at 02:00 UTC)
schedules:
- cron: '0 2 * * *'
displayName: 'Nightly Build'
branches:
include: [main]
always: true # Run even if no new commitsस्टेप: स्क्रिप्ट और कार्य
Pipeline स्टेप या तो स्क्रिप्ट (bash या PowerShell कमांड) होते हैं या कार्य (Azure DevOps marketplace से मिले पहले से निर्मित, पैरामीटरयुक्त घटक)। NodeTool@0, DotNetCoreCLI@2 और Maven@3 जैसे कार्य सामान्य Build प्रक्रियाओं को समाहित करते हैं। पठनीय Pipeline लॉग के लिए हर स्टेप पर displayName का उपयोग करें। प्रत्येक स्टेप क्रम से चलता है और यदि कोई स्टेप शून्य से अलग कोड के साथ समाप्त होता है, तो Pipeline विफल हो जाती है, जब तक कि आप continueOnError: true सेट न करें।
steps:
- task: NodeTool@0
displayName: 'Install Node.js 18'
inputs:
versionSpec: '18.x'
- script: npm ci
displayName: 'Install dependencies (clean install)'
- script: npm run lint
displayName: 'Run ESLint'
- script: npm run build
displayName: 'Build production bundle'
- script: npm test -- --ci --coverage
displayName: 'Run unit tests with coverage'परीक्षण परिणाम प्रकाशित करना
परीक्षण चलाने के बाद, PublishTestResults कार्य का उपयोग करके परिणाम Azure DevOps में प्रकाशित करें। Azure Pipelines JUnit, NUnit, XUnit या VSTest परिणाम फ़ाइलों को पार्स करता है और Pipeline रन के UI में सफल/विफल गणना, परीक्षण रन की अवधि और प्रत्येक परीक्षण का विवरण दिखाता है। परीक्षण इतिहास समय के साथ सुरक्षित रखा जाता है, जिससे आप अस्थिर परीक्षणों और प्रतिगमन का पता लगा सकते हैं। पूरी टीम में कोड गुणवत्ता की दृश्यता के लिए यह आवश्यक है।
# Example: Node.js project with Jest tests
steps:
- script: npm test -- --ci --reporters=jest-junit
displayName: 'Run tests with JUnit reporter'
env:
JEST_JUNIT_OUTPUT_DIR: '$(Agent.TempDirectory)/test-results'
- task: PublishTestResults@2
displayName: 'Publish test results'
inputs:
testResultsFormat: JUnit
testResultsFiles: '$(Agent.TempDirectory)/test-results/**/*.xml'
condition: succeededOrFailed() # Publish even if tests failकोड कवरेज प्रकाशित करना
कोड कवरेज रिपोर्ट प्रकाशित करें, ताकि Azure Pipelines Pipeline UI में कवरेज प्रतिशत और रुझान दिखा सके। PublishCodeCoverageResults कार्य Cobertura या JaCoCo प्रारूप वाली रिपोर्ट स्वीकार करता है। इसे Branch कवरेज द्वारों के साथ जोड़ें — न्यूनतम कवरेज सीमा कॉन्फ़िगर करें और यदि कवरेज उससे नीचे गिर जाए, तो Build विफल करें। कवरेज के रुझान यह पहचानने में सहायता करते हैं कि संबंधित परीक्षणों के बिना नया कोड कब जोड़ा जा रहा है।
# Jest + coverage
- script: npm test -- --ci --coverage --coverageReporters=cobertura
displayName: 'Run tests with coverage'
- task: PublishCodeCoverageResults@1
displayName: 'Publish code coverage'
inputs:
codeCoverageTool: Cobertura
summaryFileLocation: '$(System.DefaultWorkingDirectory)/coverage/cobertura-coverage.xml'
reportDirectory: '$(System.DefaultWorkingDirectory)/coverage'Pipeline चर और चर समूह
YAML में Pipeline, चरण या जॉब स्तर पर परिभाषित चर में Pipeline कॉन्फ़िगरेशन रखें। संवेदनशील मानों (API कुंजी, पासवर्ड) के लिए गुप्त चर का उपयोग करें — इन्हें Pipeline लाइब्रेरी (UI) या चर समूहों में सेट करें और YAML में संदर्भित करें। चर समूह कई Pipelines में साझा किए जाने वाले चरों के पुनः उपयोग योग्य संग्रह होते हैं। Key Vault से एक चर समूह लिंक करें, ताकि Key Vault से गुप्त मान अपने-आप Pipeline चरों में समकालित हो जाएँ।
# Reference a variable group in a pipeline
variables:
- group: 'Production-Secrets' # Linked to Azure Key Vault
- name: buildConfiguration
value: Release
# Use a variable
steps:
- script: echo 'Building $(buildConfiguration) configuration'
- script: az webapp deploy --src-path drop.zip
env:
AZURE_SUBSCRIPTION_ID: $(AZURE_SUBSCRIPTION_ID) # From Key Vault
APP_API_KEY: $(APP_API_KEY) # Secret, not printed in logsआर्टिफैक्ट: Build आउटपुट को पैकेज करना
सफल Build के बाद, आउटपुट को Pipeline आर्टिफैक्ट में पैकेज करें, ताकि बाद के चरण (जैसे परिनियोजन) उस तक पहुँच सकें। Build Agent से Azure DevOps आर्टिफैक्ट संग्रहण में फ़ाइलें अपलोड करने के लिए PublishPipelineArtifact का उपयोग करें। बाद के चरण या जॉब में आर्टिफैक्ट प्राप्त करने के लिए DownloadPipelineArtifact का उपयोग करें। इससे Build जॉब और परिनियोजन जॉब अलग हो जाते हैं, जिन्हें अलग-अलग Agent या चरणों में चलाया जा सकता है।
# Publish build artifact
- task: PublishPipelineArtifact@1
displayName: 'Publish build artifact'
inputs:
targetPath: '$(System.DefaultWorkingDirectory)/dist'
artifactName: webapp-drop
publishLocation: pipeline
# In a later deployment job, download the artifact
- task: DownloadPipelineArtifact@2
inputs:
artifactName: webapp-drop
targetPath: '$(Pipeline.Workspace)/drop'
- script: ls -la $(Pipeline.Workspace)/dropतेज़ Build के लिए समानांतर जॉब
किसी चरण के भीतर कई जॉब परिभाषित करके स्वतंत्र कार्यों को समानांतर चलाएँ। उदाहरण के लिए, यूनिट परीक्षण और सुरक्षा स्कैनिंग को क्रमिक रूप से चलाने के बजाय एक साथ चलाएँ। समानांतर जॉब के लिए अलग Build मिनट चाहिए होते हैं, लेकिन वे कुल Pipeline अवधि को काफ़ी कम कर सकते हैं। किसी जॉब को शुरू होने से पहले एक या अधिक अन्य जॉब के पूरा होने तक प्रतीक्षा कराने के लिए dependsOn प्रॉपर्टी का उपयोग करें। इससे एक चरण के भीतर निर्भरता ग्राफ़ बनता है।
stages:
- stage: CI
jobs:
- job: UnitTests
displayName: 'Run unit tests'
steps:
- script: npm test
- job: LintAndSecurity
displayName: 'Lint and security scan'
steps:
- script: npm run lint
- script: npm audit --audit-level=high
- job: BuildArtifact
displayName: 'Build and publish artifact'
dependsOn: [UnitTests, LintAndSecurity]
condition: succeeded('UnitTests') and succeeded('LintAndSecurity')
steps:
- script: npm run buildBranch नीतियों से Build सत्यापन
अपनी CI Pipeline को Azure Repos में मौजूद Branch नीति से लिंक करें, ताकि main को लक्षित करने वाले Pull request पर यह अपने-आप Build सत्यापन जाँच के रूप में चल सके। Pipeline के सफल होने तक विलय रोक दिया जाता है। कई जाँचों को मिलाएँ: CI Pipeline सफल हो, कम से कम 2 समीक्षक अनुमोदन दें, सभी टिप्पणियाँ हल की गई हों और एक लिंक किया हुआ कार्य आइटम मौजूद हो। इससे एक गुणवत्ता द्वार बनता है, जो टूटे हुए कोड को main Branch में विलय करना असंभव बना देता है।
# Add build validation via CLI
az repos policy build create \
--blocking true \
--branch main \
--branch-match-type exact \
--build-definition-id <pipeline-id> \
--display-name 'CI Build Validation' \
--enabled true \
--project MyProject \
--repository-id <repo-id> \
--queue-on-source-update-only true \
--manual-queue-only false \
--valid-duration 720 # Pipeline result expires after 12 hoursPipeline रन के परिणाम पढ़ना
Pipeline रन पूरा होने के बाद, Azure DevOps पोर्टल में परिणामों की समीक्षा करें। सारांश टैब समग्र सफलता/विफलता और समय दिखाता है। परीक्षण टैब सभी परीक्षण परिणामों को परिणाम के आधार पर फ़िल्टर करने की सुविधा के साथ सूचीबद्ध करता है। कोड कवरेज टैब कवरेज प्रतिशत दिखाता है और उन पंक्तियों को उजागर करता है जिनका परीक्षण नहीं हुआ है। चरण-दर-चरण लॉग आउटपुट देखने के लिए किसी भी जॉब पर क्लिक करें। विफल Pipelines में विफल स्टेप लाल रंग में उजागर होता है और त्वरित निदान के लिए पूरा त्रुटि आउटपुट दिखाता है।
# View pipeline run results via CLI
az pipelines runs list \
--pipeline-ids <pipeline-id> \
--project MyProject \
--query '[].{id:id, status:status, result:result, startTime:startTime}' \
-o table
# View logs from a specific run
az pipelines runs logs list \
--run-id <run-id> \
--project MyProjectत्वरित जाँच
इस पाठ में Microsoft Azure Fundamentals (AZ-900) की अवधारणाओं की अपनी समझ जाँचें।
पाठ का पुनरावलोकन
इस पाठ में आपने सीखा: Azure Pipelines YAML Build, परीक्षण और आर्टिफैक्ट निर्माण के लिए चरणों, जॉब और स्टेप वाली CI Pipelines परिभाषित करता है; PR ट्रिगर और Branch नीतियाँ गुणवत्ता द्वार लागू करती हैं, जो टूटे हुए कोड का विलय रोकते हैं; और PublishTestResults तथा PublishCodeCoverageResults कार्य पूरी टीम में परीक्षण गुणवत्ता को दृश्य बनाते हैं। अब हम Azure में सतत परिनियोजन सीखेंगे।
एआई शिक्षक के साथ Azure Fundamentals सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 30
- पाठ
- 120
अक्सर पूछे जाने वाले प्रश्न
क्या “Azure Pipelines से CI पाइपलाइन बनाना” पाठ निःशुल्क है?
हाँ—“Azure Pipelines से CI पाइपलाइन बनाना” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Azure Fundamentals पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Azure Fundamentals पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“Azure Pipelines से CI पाइपलाइन बनाना” में मैं क्या सीखूँगा?
एक YAML पाइपलाइन परिभाषित करें जो पुल अनुरोधों पर शुरू हो, यूनिट परीक्षण चलाए और बिल्ड आर्टिफैक्ट बनाए; फिर पोर्टल में परीक्षण परिणाम और कोड कवरेज की समीक्षा करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Azure Fundamentals का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Azure Fundamentals शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Azure Fundamentals शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 2वाँ पाठ है।
“Azure Pipelines से CI पाइपलाइन बनाना” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Azure Fundamentals पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Azure Fundamentals पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- Azure DevOps Services का अवलोकन
- Azure Pipelines से CI पाइपलाइन बनाना
- Azure पर सतत परिनियोजन
- Azure पर GitHub Actions