DevOps बूटकैंप · पाठ

कमांड का मॉक बनाना और बाहरी टूल के स्टब तैयार करना

वास्तविक सिस्टम को छुए बिना स्क्रिप्ट की जाँच करने के लिए PATH को ओवरराइड करें और नकली बाइनरी परिभाषित करें।

पाठ 2, कुल 4 में से13 चरण

कमांड का मॉक बनाना और बाहरी टूल के स्टब तैयार करना, CoddyKit पर DevOps बूटकैंप का एक निःशुल्क पाठ है। यह 4 में से 2वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह DevOps बूटकैंप सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। DevOps बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

Bash परीक्षणों में कमांड का नकलीकरण क्यों करें

जब आप ऐसी Bash स्क्रिप्ट का परीक्षण करते हैं जो curl, aws, git या किसी बाहरी उपकरण को कॉल करती है, तो एक समस्या सामने आती है: वास्तविक कॉल नेटवर्क तक पहुँचती हैं, स्थिति में बदलाव करती हैं, पैसे खर्च करती हैं या ऐसे CI वातावरण में विफल हो जाती हैं जहाँ वे उपकरण इंस्टॉल नहीं होते।

नकलीकरण का अर्थ है वास्तविक कमांड को अपने नियंत्रण वाले नकली कमांड से बदल देना। आपका नकली कमांड ( स्टब ) अनुमानित आउटपुट और निकास कोड लौटाता है, इसलिए आपका परीक्षण तेज़, पृथक और पुनरुत्पाद्य होता है।

  • नेटवर्क या क्लाउड पहुँच की आवश्यकता नहीं
  • परीक्षण सेकंडों के बजाय मिलीसेकंडों में चलते हैं
  • आप ऐसी त्रुटियों का अनुकरण कर सकते हैं जिन्हें वास्तविक प्रणालियों पर उत्पन्न करना कठिन होता है
  • CI पाइपलाइन साफ़ और निर्भरता-मुक्त रहती हैं

Bash यह करने के लिए आश्चर्यजनक रूप से सरल तंत्र देता है: अपनी नकली बाइनरी को वास्तविक बाइनरी की तुलना में $PATH में पहले आने वाले किसी स्थान पर रखें।

PATH खोज कैसे काम करती है

जब शेल curl जैसे कमांड को चलाता है, तो वह $PATH में दी गई प्रत्येक निर्देशिका को बाएँ से दाएँ खोजता है और मिलने वाले पहले मिलान को चलाता है।

इसका अर्थ है कि यदि आप अपनी curl स्क्रिप्ट वाली निर्देशिका को सबसे आगे जोड़ दें, तो शेल कभी /usr/bin/curl तक नहीं पहुँचेगा।

ओवरराइड तरीका:

  1. एक अस्थायी निर्देशिका बनाएँ (आपकी स्टब बिन)
  2. वास्तविक कमांड के समान नाम वाली नकली निष्पादन योग्य फ़ाइल लिखें
  3. उस निर्देशिका को PATH में सबसे आगे जोड़ें
  4. परीक्षणाधीन स्क्रिप्ट चलाएँ — वह वास्तविक बाइनरी के बजाय आपके स्टब को कॉल करेगी
  5. परीक्षण के बाद अस्थायी निर्देशिका साफ़ करें

यह रूट पहुँच के बिना, सिस्टम फ़ाइलों में बदलाव किए बिना और किसी विशेष ढाँचे के बिना काम करता है।

स्टब निर्देशिका बनाना

मानक तरीके में स्टब के लिए एक पृथक अस्थायी निर्देशिका बनाने हेतु mktemp -d का उपयोग किया जाता है। प्रत्येक परीक्षण या परीक्षण-संग्रह को अपनी निर्देशिका मिलती है, जिससे परीक्षणों के बीच अवांछित प्रभाव रुकता है।

परीक्षण पूरा होने के बाद rm -rf से निर्देशिका हटाएँ। trap का उपयोग करने पर परीक्षण किसी त्रुटि के कारण समय से पहले समाप्त होने पर भी सफ़ाई सुनिश्चित होती है।

#!/usr/bin/env bash
# Setup a stub bin directory for testing

# Create the temp dir
STUB_BIN=$(mktemp -d)

# Always clean up on exit (success, error, or signal)
trap 'rm -rf "$STUB_BIN"' EXIT

# Prepend it to PATH so our stubs take priority
export PATH="$STUB_BIN:$PATH"

echo "Stub bin: $STUB_BIN"
echo "PATH starts with: ${PATH%%:*}"

# Your tests would go here...
echo "Tests complete."

अपना पहला स्टब लिखना

स्टब उस कमांड के समान नाम वाली बस एक निष्पादन योग्य फ़ाइल है जिसे आप बदलना चाहते हैं। यह वही आउटपुट प्रिंट करती है जिसकी आपकी परीक्षणाधीन स्क्रिप्ट को अपेक्षा होती है और आपके चुने हुए कोड के साथ समाप्त होती है।

स्टब के मुख्य नियम:

  • फ़ाइल निष्पादन योग्य होनी चाहिए (chmod +x)
  • शेबैंग पंक्ति (#!/usr/bin/env bash) आवश्यक है
  • वह आउटपुट दिखाएँ जिसे आपकी वास्तविक स्क्रिप्ट पार्स करेगी
  • सफलता के लिए exit 0 और अनुकरण की गई विफलताओं के लिए गैर-शून्य निकास कोड का उपयोग करें
#!/usr/bin/env bash
# Create a stub for 'curl' that returns a fake HTTP response

STUB_BIN=$(mktemp -d)
trap 'rm -rf "$STUB_BIN"' EXIT
export PATH="$STUB_BIN:$PATH"

# Write the stub
cat > "$STUB_BIN/curl" << 'EOF'
#!/usr/bin/env bash
# Fake curl: always returns a 200 OK with a JSON body
echo '{"status": "ok", "version": "1.2.3"}'
exit 0
EOF
chmod +x "$STUB_BIN/curl"

# Verify the stub is found before the real curl
which curl
curl https://example.com/api/version

curl को कॉल करने वाली स्क्रिप्ट का परीक्षण

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

#!/usr/bin/env bash
# Script under test: check_health.sh
# It calls curl and checks the returned JSON

check_health() {
  local url="$1"
  local response
  response=$(curl -sf "$url")
  if [[ "$response" == *'"healthy":true'* ]]; then
    echo "Service is UP"
    return 0
  else
    echo "Service is DOWN" >&2
    return 1
  fi
}

# ---- Test harness ----
STUB_BIN=$(mktemp -d)
trap 'rm -rf "$STUB_BIN"' EXIT
export PATH="$STUB_BIN:$PATH"

# Happy path stub
cat > "$STUB_BIN/curl" << 'EOF'
#!/usr/bin/env bash
echo '{"healthy":true}'
EOF
chmod +x "$STUB_BIN/curl"

check_health "http://fake-host/health" && echo "PASS: healthy response"

कमांड की विफलताओं का अनुकरण

स्टब का सबसे उपयोगी उपयोग उन विफलताओं का अनुकरण करना है जिन्हें वास्तविक टूल से दोहराना कठिन होता है — नेटवर्क की समय-समाप्ति, अनुमति संबंधी त्रुटियाँ, डिस्क का भर जाना या किसी दूरस्थ API द्वारा 500 लौटाना।

विफलता का अनुकरण करने के लिए अपने स्टब को बस शून्येतर कोड के साथ बाहर निकलने दें। आप वास्तविक कमांड की तरह ही stderr में लिख भी सकते हैं, ताकि आपकी स्क्रिप्ट की त्रुटि-संभाल पूरी तरह जाँची जा सके।

#!/usr/bin/env bash
# Test that check_health handles a curl failure gracefully

check_health() {
  local url="$1"
  local response
  # -f makes curl exit non-zero on HTTP error; -s silences progress
  if ! response=$(curl -sf "$url" 2>/dev/null); then
    echo "ERROR: could not reach $url" >&2
    return 1
  fi
  echo "OK: $response"
}

STUB_BIN=$(mktemp -d)
trap 'rm -rf "$STUB_BIN"' EXIT
export PATH="$STUB_BIN:$PATH"

# Failure stub — simulates a network error (curl exit code 6 = could not resolve host)
cat > "$STUB_BIN/curl" << 'EOF'
#!/usr/bin/env bash
echo 'curl: (6) Could not resolve host: fake-host' >&2
exit 6
EOF
chmod +x "$STUB_BIN/curl"

if ! check_health "http://fake-host/health"; then
  echo "PASS: failure path handled correctly"
fi

सत्यापन के लिए स्टब कॉल दर्ज करना

कभी-कभी आपको केवल यह सत्यापित नहीं करना होता कि आपकी स्क्रिप्ट ने क्या आउटपुट दिया, बल्कि यह भी कि उसने किसी बाहरी टूल को कैसे कॉल किया — उसने कौन-से आर्ग्युमेंट दिए, उसे कितनी बार कॉल किया गया या किस क्रम में किया गया। एक स्पाई स्टब अपने आह्वानों को एक फ़ाइल में दर्ज करता है।

परीक्षण के बाद, आपका परीक्षण-ढाँचा रिकॉर्ड फ़ाइल को पढ़ता है और उसकी सामग्री पर दावे करता है। इससे आपको किसी विशेष ढाँचे के बिना आर्ग्युमेंट-स्तरीय सत्यापन मिलता है।

#!/usr/bin/env bash
# Spy stub: record every invocation of 'aws' to a log file

STUB_BIN=$(mktemp -d)
CALL_LOG=$(mktemp)
trap 'rm -rf "$STUB_BIN" "$CALL_LOG"' EXIT
export PATH="$STUB_BIN:$PATH"
export CALL_LOG   # make it available inside the stub

cat > "$STUB_BIN/aws" << 'EOF'
#!/usr/bin/env bash
# Append all arguments to the call log
echo "aws $*" >> "$CALL_LOG"
# Return fake S3 output
echo "upload: ./report.pdf to s3://my-bucket/report.pdf"
exit 0
EOF
chmod +x "$STUB_BIN/aws"

# Simulate the script under test calling aws s3 cp
aws s3 cp report.pdf s3://my-bucket/report.pdf
aws s3 cp logs.tar.gz s3://my-bucket/logs.tar.gz

# Verify calls were made with expected arguments
echo "--- Recorded calls ---"
cat "$CALL_LOG"
grep -q 's3://my-bucket/report.pdf' "$CALL_LOG" && echo "PASS: S3 upload verified"

एक साथ कई कमांड के लिए स्टब बनाना

वास्तविक स्क्रिप्ट अक्सर कई बाहरी टूल को कॉल करती है। आप उन सभी के लिए एक ही STUB_BIN डायरेक्टरी में स्टब बना सकते हैं। प्रत्येक स्टब फ़ाइल स्वतंत्र होती है और अलग-अलग आउटपुट तथा बाहर निकलने वाले कोड लौटा सकती है।

स्टब को न्यूनतम रखें: केवल वही लौटाएँ जिसे परीक्षणाधीन स्क्रिप्ट वास्तव में पार्स करती है। हर फ़्लैग का अनुकरण करने की कोशिश न करें — केवल उस छोटे समूह का करें जिसका आपकी स्क्रिप्ट उपयोग करती है।

#!/usr/bin/env bash
# Stub both 'git' and 'docker' for a release script test

STUB_BIN=$(mktemp -d)
trap 'rm -rf "$STUB_BIN"' EXIT
export PATH="$STUB_BIN:$PATH"

# Stub git: pretend we are on tag v2.1.0
cat > "$STUB_BIN/git" << 'EOF'
#!/usr/bin/env bash
case "$*" in
  *"describe --tags"*) echo "v2.1.0" ;;
  *"rev-parse HEAD"*)  echo "abc1234" ;;
  *) echo "[git stub] unhandled: $*" >&2 ; exit 1 ;;
esac
EOF
chmod +x "$STUB_BIN/git"

# Stub docker: pretend build and push succeed
cat > "$STUB_BIN/docker" << 'EOF'
#!/usr/bin/env bash
echo "[docker stub] $*"
exit 0
EOF
chmod +x "$STUB_BIN/docker"

# Simulate the release logic
VERSION=$(git describe --tags)
SHA=$(git rev-parse HEAD)
echo "Building image for version=$VERSION sha=$SHA"
docker build -t "myapp:$VERSION" .
docker push "myapp:$VERSION"

फ़ंक्शन को स्टब के रूप में उपयोग करना (फ़ाइलों की आवश्यकता नहीं)

सरल मामलों के लिए आपको फ़ाइलें बिल्कुल लिखने की आवश्यकता नहीं है। आप कमांड के समान नाम वाला एक शेल फ़ंक्शन परिभाषित कर सकते हैं। चूँकि बाहरी PATH खोज से पहले फ़ंक्शन खोजे जाते हैं, इसलिए उन्हें स्वतः प्राथमिकता मिलती है।

स्रोत की गई स्क्रिप्ट का इकाई-परीक्षण करने के लिए यह सबसे तेज़ तरीका है। हालाँकि, फ़ंक्शन स्टब केवल उसी शेल प्रक्रिया के भीतर काम करते हैं — स्पष्ट bash -c से शुरू की गई उप-शेल प्रक्रियाओं या पृष्ठभूमि में चलने वाली प्रक्रियाओं को वे दिखाई नहीं देंगे। उनके लिए फ़ाइल-आधारित तरीका अपनाएँ।

#!/usr/bin/env bash
# Source the script under test (a small helper library)
source_under_test() {
  # Inline the logic we want to test
  get_instance_id() {
    # Would normally call: curl http://169.254.169.254/latest/meta-data/instance-id
    curl -sf http://169.254.169.254/latest/meta-data/instance-id
  }
}
source_under_test

# Override curl with a shell function stub
curl() {
  echo "i-0abc123def456"
  return 0
}
# Export is NOT needed — function is visible in same shell

# Run the function under test
result=$(get_instance_id)
[[ "$result" == "i-0abc123def456" ]] && echo "PASS: instance ID returned" || echo "FAIL"

उप-शेल प्रक्रियाओं में फ़ंक्शन निर्यात करना

जब आपकी परीक्षणाधीन स्क्रिप्ट कोई उप-शेल प्रक्रिया शुरू करती है (जैसे bash script.sh या कोई कार्यप्रवाह), तो पैरेंट में परिभाषित शेल फ़ंक्शन स्टब डिफ़ॉल्ट रूप से विरासत में नहीं मिलते। आपके पास दो विकल्प हैं:

  • फ़ंक्शन निर्यात करने के लिए export -f function_name का उपयोग करें — यह चाइल्ड bash प्रक्रियाओं में उपलब्ध हो जाता है
  • या STUB_BIN डायरेक्टरी में फ़ाइल-आधारित स्टब का विकल्प अपनाएँ, जो प्रक्रिया सीमाओं के पार हमेशा काम करते हैं

export -f सुविधाजनक है, लेकिन यह केवल bash के साथ काम करता है (sh या अन्य शेल के साथ नहीं)। विभिन्न भाषाओं वाले CI वातावरण में फ़ाइल-आधारित स्टब को प्राथमिकता दें।

#!/usr/bin/env bash
# Demonstrate export -f for subshell-visible function stubs

# Define the stub in the current shell
curl() {
  echo '{"status":"ok"}'
  return 0
}
# Export the function so child bash processes inherit it
export -f curl

# Verify the stub works in a subshell
bash -c '
  response=$(curl -sf http://api.example.com/status)
  echo "Subshell got: $response"
'

# Without export -f, the subshell would call the real curl
# (or fail if curl is not installed)

परीक्षण-ढाँचे (BATS) के साथ स्टब का एकीकरण

जब आप BATS (Bash Automated Testing System) का उपयोग करते हैं, तो स्टब की स्थापना setup() हुक में और सफ़ाई teardown() में होनी चाहिए। BATS परीक्षणों के बीच वातावरण रीसेट करता है, इसलिए प्रत्येक परीक्षण को एक नई स्टब डायरेक्टरी मिलती है।

$BATS_TEST_TMPDIR जैसे BATS चर आपको प्रत्येक परीक्षण के लिए अस्थायी डायरेक्टरी स्वतः देते हैं — कोड को अधिक साफ़ रखने के लिए mktemp -d के बजाय इसका उपयोग करें।

#!/usr/bin/env bats
# File: test_deploy.bats
# Run with: bats test_deploy.bats

setup() {
  # BATS provides a unique tmpdir per test
  export STUB_BIN="$BATS_TEST_TMPDIR/stub_bin"
  mkdir -p "$STUB_BIN"
  export PATH="$STUB_BIN:$PATH"

  # Default stub: healthy service
  cat > "$STUB_BIN/curl" << 'EOF'
#!/usr/bin/env bash
echo '{"healthy":true}'
EOF
  chmod +x "$STUB_BIN/curl"
}

teardown() {
  # BATS auto-removes BATS_TEST_TMPDIR, but explicit is safer
  rm -rf "$STUB_BIN"
}

@test "deploy succeeds when service is healthy" {
  run bash deploy.sh
  [ "$status" -eq 0 ]
  [[ "$output" == *"Deploy complete"* ]]
}

@test "deploy aborts when service is down" {
  # Override the stub for this specific test
  echo -e '#!/usr/bin/env bash\nexit 1' > "$STUB_BIN/curl"
  chmod +x "$STUB_BIN/curl"

  run bash deploy.sh
  [ "$status" -ne 0 ]
}

ज्ञान-जाँच: Bash में कमांड का मॉक बनाना

Bash में कमांड का मॉक बनाने और स्टब पैटर्न की अपनी समझ जाँचें।

एक डेवलपर वास्तविक AWS CLI के लिए स्टब बनाने हेतु aws नाम का शेल फ़ंक्शन परिभाषित करके एक परीक्षण लिखता है। परीक्षण सीधे टर्मिनल में ठीक चलता है, लेकिन जब CI कार्यप्रवाह परीक्षणाधीन स्क्रिप्ट को bash deploy.sh के रूप में चलाता है, तो स्टब की अनदेखी होती है और वास्तविक aws कमांड कॉल की जाती है।

सही समाधान क्या है?

पुनरावलोकन: कमांड का मॉक बनाना और बाहरी टूल के लिए स्टब बनाना

आपने Bash स्क्रिप्ट के परीक्षण के दौरान वास्तविक कमांड को नियंत्रित नकली कमांड से बदलने के लिए आवश्यक पूरा टूलकिट सीख लिया है।

शामिल मुख्य तकनीकें:

  • PATH को आगे रखना — mktemp -d से STUB_BIN डायरेक्टरी बनाएँ, वहाँ निष्पादन योग्य स्टब फ़ाइलें लिखें और डायरेक्टरी को PATH में सबसे आगे रखें
  • स्टब के बाहर निकलने वाले कोड — सफलता के लिए 0 और विशिष्ट विफलताओं (नेटवर्क त्रुटियाँ, अनुमति अस्वीकृत होना आदि) का अनुकरण करने के लिए शून्येतर मान लौटाएँ
  • स्पाई स्टब — यह सत्यापित करने के लिए कि आपकी स्क्रिप्ट ने बाहरी टूल को कैसे कॉल किया, आर्ग्युमेंट को स्टब के अंदर एक लॉग फ़ाइल में जोड़ें
  • कई स्टब — एक साथ निर्भरताओं के पूरे पारिस्थितिकी तंत्र का मॉक बनाने के लिए कई स्टब फ़ाइलें उसी STUB_BIN में रखें
  • फ़ंक्शन स्टब — उसी प्रक्रिया में मॉक बनाने के लिए कमांड के समान नाम वाला शेल फ़ंक्शन परिभाषित करें; चाइल्ड bash प्रक्रियाओं तक पहुँचने के लिए export -f का उपयोग करें
  • BATS एकीकरण — प्रत्येक परीक्षण को साफ़ तौर पर अलग रखने के लिए setup()/teardown() हुक और $BATS_TEST_TMPDIR का उपयोग करें

परीक्षण के परिणाम की परवाह किए बिना स्टब की सफ़ाई सुनिश्चित करने के लिए हमेशा trap '...' EXIT का उपयोग करें। स्टब को न्यूनतम रखें — केवल वही लौटाएँ जिसे आपकी स्क्रिप्ट वास्तव में पार्स करती है। CI कार्यप्रवाहों के लिए फ़ाइल-आधारित स्टब सबसे अधिक पोर्टेबल विकल्प हैं।

शुरुआत निःशुल्क

एआई शिक्षक के साथ DevOps बूटकैंप सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम
142
पाठ
568

अक्सर पूछे जाने वाले प्रश्न

क्या “कमांड का मॉक बनाना और बाहरी टूल के स्टब तैयार करना” पाठ निःशुल्क है?

हाँ — DevOps बूटकैंप अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “कमांड का मॉक बनाना और बाहरी टूल के स्टब तैयार करना” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। DevOps बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“कमांड का मॉक बनाना और बाहरी टूल के स्टब तैयार करना” में मैं क्या सीखूँगा?

वास्तविक सिस्टम को छुए बिना स्क्रिप्ट की जाँच करने के लिए PATH को ओवरराइड करें और नकली बाइनरी परिभाषित करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ DevOps बूटकैंप का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या DevOps बूटकैंप शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर DevOps बूटकैंप शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 2वाँ पाठ है।

“कमांड का मॉक बनाना और बाहरी टूल के स्टब तैयार करना” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस DevOps बूटकैंप पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर DevOps बूटकैंप पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

  1. Bats-core से फ़ंक्शन की यूनिट जाँच
  2. कमांड का मॉक बनाना और बाहरी टूल के स्टब तैयार करना
  3. फ़िक्स्चर, अस्थायी परिवेश और कवरेज
  4. CI पाइपलाइनों में Shell जाँच चलाना
← DevOps बूटकैंप पर वापस जाएँ