सीआई/सीडी पाइपलाइन सर्वोत्तम अभ्यास: विश्वसनीय तैनाती के लिए अपना रास्ता स्वचालित करें

परिपक्व सीआई/सीडी पाइपलाइन वाली टीमें बिना सीआई/सीडी पाइपलाइन वाली टीमों की तुलना में 208 गुना अधिक बार तैनात होती हैं, जबकि परिवर्तन विफलता दर 7 गुना कम होती है। एक नाजुक "यह ज्यादातर काम करती है" पाइपलाइन और युद्ध-परीक्षणित तैनाती प्रणाली के बीच का अंतर मुट्ठी भर प्रथाओं के कारण होता है जो शौकिया स्वचालन को उत्पादन-ग्रेड बुनियादी ढांचे से अलग करते हैं।

यह मार्गदर्शिका उन ठोस प्रथाओं, कॉन्फ़िगरेशन और वास्तुशिल्प निर्णयों को शामिल करती है जो सीआई/सीडी पाइपलाइनों को बड़े पैमाने पर विश्वसनीय बनाती हैं।

मुख्य बातें

• पाइपलाइन निष्पादन समय सीधे डेवलपर उत्पादकता को प्रभावित करता है --- पूरे सुइट के लिए 10 मिनट से कम का लक्ष्य
• सीआई में सुरक्षा स्कैनिंग उत्पादन तक पहुंचने से पहले 85% कमजोरियों को पकड़ लेती है
• स्वचालित रोलबैक तंत्र पुनर्प्राप्ति के औसत समय को घंटों से घटाकर मिनटों में कर देता है
• शाखा सुरक्षा नियम और आवश्यक स्थिति जांच टूटे हुए कोड को मुख्य तक पहुंचने से रोकते हैं

---

पाइपलाइन वास्तुकला

पांच चरणों वाला मॉडल

प्रत्येक उत्पादन सीआई/सीडी पाइपलाइन को पांच चरणों को लागू करना चाहिए:

चरण 1: लिंट और वैलिडेट (लक्ष्य: <2 मिनट)

lint:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: 20
        cache: pnpm
    - run: pnpm install --frozen-lockfile
    - run: pnpm lint
    - run: pnpm typecheck

चरण 2: परीक्षण (लक्ष्य: <8 मिनट)

test:
  runs-on: ubuntu-latest
  services:
    postgres:
      image: postgres:17
      env:
        POSTGRES_PASSWORD: test
        POSTGRES_DB: test
      ports:
        - 5432:5432
      options: >-
        --health-cmd pg_isready
        --health-interval 10s
        --health-timeout 5s
        --health-retries 5
  steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-node@v4
      with:
        node-version: 20
        cache: pnpm
    - run: pnpm install --frozen-lockfile
    - run: pnpm test
      env:
        DATABASE_URL: postgresql://postgres:test@localhost:5432/test

चरण 3: निर्माण (लक्ष्य: <5 मिनट)

डॉकर छवियां बनाएं, संपत्तियां संकलित करें, उत्पादन बंडल बनाएं। कैश निर्भरताएँ आक्रामक रूप से।

चरण 4: मंचन पर तैनाती

मुख्य में विलय पर स्वचालित तैनाती। स्टेजिंग वातावरण के विरुद्ध धूम्रपान परीक्षण चलाएँ।

चरण 5: उत्पादन में परिनियोजन

चरणबद्ध सत्यापन पास के बाद मैन्युअल अनुमोदन गेट या स्वचालित।

---

गति अनुकूलन

धीमी पाइपलाइनें डेवलपर उत्पादकता को खत्म कर देती हैं। एक टीम में सीआई प्रतीक्षा समय के प्रत्येक मिनट को गुणा करने पर घंटों का खोया हुआ संदर्भ-स्विचिंग समय बनता है।

###समानांतरीकरण

स्वतंत्र कार्य एक साथ चलाएँ:

jobs:
  lint:
    runs-on: ubuntu-latest
    steps: [...]

  test-unit:
    runs-on: ubuntu-latest
    steps: [...]

  test-integration:
    runs-on: ubuntu-latest
    steps: [...]

  test-e2e:
    runs-on: ubuntu-latest
    steps: [...]

  build:
    needs: [lint, test-unit, test-integration, test-e2e]
    runs-on: ubuntu-latest
    steps: [...]

निर्भरता कैशिंग

- uses: actions/cache@v4
  with:
    path: |
      ~/.pnpm-store
      node_modules
      apps/*/node_modules
      packages/*/node_modules
    key: ${{ runner.os }}-pnpm-${{ hashFiles('pnpm-lock.yaml') }}
    restore-keys: |
      ${{ runner.os }}-pnpm-

डॉकर लेयर कैशिंग

- uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    tags: registry.example.com/app:${{ github.sha }}
    cache-from: type=gha
    cache-to: type=gha,mode=max

पाइपलाइन स्पीड बेंचमार्क

---

सुरक्षा स्कैनिंग

निर्भरता भेद्यता स्कैनिंग

security:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    - name: Run Snyk to check for vulnerabilities
      uses: snyk/actions/node@master
      env:
        SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
      with:
        args: --severity-threshold=high

    - name: Run Trivy vulnerability scanner
      uses: aquasecurity/trivy-action@master
      with:
        scan-type: fs
        scan-ref: .
        severity: CRITICAL,HIGH
        exit-code: 1

गुप्त स्कैनिंग

    - name: Detect secrets
      uses: trufflesecurity/trufflehog@main
      with:
        extra_args: --only-verified

SAST (स्टेटिक एप्लिकेशन सुरक्षा परीक्षण)

    - name: CodeQL Analysis
      uses: github/codeql-action/analyze@v3
      with:
        languages: javascript-typescript

सुरक्षा द्वार नीति

---

शाखा संरक्षण और विलय रणनीति

आवश्यक स्थिति जांच

इन्हें मुख्य शाखा पर आवश्यक स्थिति जांच के रूप में कॉन्फ़िगर करें:

1. लिंट और टाइपचेक पास होना चाहिए
2. सभी यूनिट परीक्षण उत्तीर्ण होने चाहिए
3. सभी एकीकरण परीक्षण उत्तीर्ण होने चाहिए
4. सुरक्षा स्कैन में कोई गंभीर/उच्च निष्कर्ष नहीं होना चाहिए
5. निर्माण सफल होना चाहिए

मर्ज रणनीति

स्वच्छ इतिहास बनाए रखने के लिए फीचर शाखाओं के लिए स्क्वैश मर्ज का उपयोग करें:

main: A --- B --- C --- D (each is a squashed feature)

पीआर के लिए कम से कम एक अनुमोदन की आवश्यकता है। महत्वपूर्ण पथों (प्रमाणीकरण, बिलिंग, डेटाबेस माइग्रेशन) के लिए, दो अनुमोदन की आवश्यकता होती है।

---

परिनियोजन रणनीतियाँ

नीला-हरा परिनियोजन

दो समान उत्पादन वातावरण बनाए रखें। ट्रैफ़िक को दूसरे की ओर तैनात करते हुए एक की ओर रूट करें।

#!/bin/bash
# blue-green-deploy.sh

CURRENT=$(kubectl get service production -o jsonpath='{.spec.selector.version}')

if [ "$CURRENT" == "blue" ]; then
  TARGET="green"
else
  TARGET="blue"
fi

echo "Current: $CURRENT, deploying to: $TARGET"

# Deploy to inactive environment
kubectl set image deployment/$TARGET-app app=registry.example.com/app:$TAG

# Wait for rollout
kubectl rollout status deployment/$TARGET-app --timeout=300s

# Run smoke tests against target
curl -sf "http://$TARGET.internal/health" || exit 1

# Switch traffic
kubectl patch service production -p "{\"spec\":{\"selector\":{\"version\":\"$TARGET\"}}}"

echo "Traffic switched to $TARGET"

रोलिंग परिनियोजन

पॉड्स को क्रमिक रूप से अपडेट करें:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%
    maxUnavailable: 0

maxUnavailable: 0 तैनाती के दौरान कोई क्षमता हानि सुनिश्चित नहीं करता है।

कैनरी परिनियोजन

ट्रैफ़िक का एक छोटा प्रतिशत नए संस्करण पर रूट करें:

# Using Istio for traffic splitting
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: app-canary
spec:
  hosts:
    - app.example.com
  http:
    - route:
        - destination:
            host: app-stable
          weight: 95
        - destination:
            host: app-canary
          weight: 5

अधिक परिनियोजन रणनीतियों के लिए, शून्य-डाउनटाइम परिनियोजन पर हमारी समर्पित मार्गदर्शिका देखें।

---

रोलबैक स्वचालन

स्वास्थ्य जांच विफलता पर स्वचालित रोलबैक

deploy-production:
  runs-on: ubuntu-latest
  steps:
    - name: Deploy
      run: |
        kubectl set image deployment/app app=${{ env.IMAGE }}
        kubectl rollout status deployment/app --timeout=300s

    - name: Smoke tests
      run: |
        sleep 30
        STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://app.example.com/health)
        if [ "$STATUS" != "200" ]; then
          echo "Health check failed with status $STATUS"
          kubectl rollout undo deployment/app
          exit 1
        fi

    - name: Monitor error rate
      run: |
        # Check error rate over 5 minutes
        ERROR_RATE=$(curl -s "http://prometheus:9090/api/v1/query?query=rate(http_requests_total{status=~'5..'}[5m])/rate(http_requests_total[5m])" | jq '.data.result[0].value[1]' -r)
        if (( $(echo "$ERROR_RATE > 0.01" | bc -l) )); then
          echo "Error rate $ERROR_RATE exceeds threshold"
          kubectl rollout undo deployment/app
          exit 1
        fi

---

मोनोरेपो पाइपलाइन अनुकूलन

मोनोरेपो परियोजनाओं के लिए (जैसे कि टर्बोरेपो का उपयोग करने वाले), केवल वही चलाएं जो बदल गया हो:

- name: Determine affected packages
  id: affected
  run: |
    AFFECTED=$(npx turbo run build --filter='...[HEAD~1]' --dry-run=json | jq -r '.packages[]')
    echo "packages=$AFFECTED" >> $GITHUB_OUTPUT

- name: Test affected packages
  if: steps.affected.outputs.packages != ''
  run: npx turbo run test --filter='...[HEAD~1]'

यह उन परिवर्तनों के लिए सीआई समय को 60-80% तक कम कर देता है जो बड़े मोनोरेपो में केवल एक पैकेज को प्रभावित करते हैं।

---

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

हमें उत्पादन में कितनी बार तैनात होना चाहिए?

जितनी बार आपकी पाइपलाइन अनुमति दे उतनी बार तैनाती करें। उच्च प्रदर्शन करने वाली टीमें प्रति दिन कई बार तैनात होती हैं। लक्ष्य छोटे, वृद्धिशील परिवर्तन हैं जिनकी समीक्षा करना, परीक्षण करना और वापस रोल करना आसान है। यदि तैनाती जोखिम भरी लगती है, तो यह एक संकेत है कि आपकी पाइपलाइन को अधिक स्वचालित परीक्षण और बेहतर रोलबैक तंत्र की आवश्यकता है, कम तैनाती की नहीं।

क्या हमें ट्रंक-आधारित विकास या फीचर शाखाओं का उपयोग करना चाहिए?

कम जीवनकाल (1-3 दिन) वाली फ़ीचर शाखाएँ अधिकांश टीमों के लिए सबसे अच्छा काम करती हैं। ट्रंक-आधारित विकास के लिए अधिक परिपक्व परीक्षण बुनियादी ढांचे और फीचर फ़्लैग की आवश्यकता होती है। महत्वपूर्ण बात यह है कि शाखाएँ अल्पकालिक होती हैं --- लंबे समय तक जीवित रहने वाली फ़ीचर शाखाएँ मर्ज संघर्ष पैदा करती हैं और प्रतिक्रिया में देरी करती हैं।

हम सीआई/सीडी में डेटाबेस माइग्रेशन को कैसे संभालते हैं?

एप्लिकेशन परिनियोजन से पहले माइग्रेशन को एक अलग पाइपलाइन चरण के रूप में चलाएँ। सुनिश्चित करें कि माइग्रेशन बैकवर्ड-संगत हैं (पुराने एप्लिकेशन संस्करण को नई स्कीमा के साथ काम करना चाहिए)। विस्तार-और-अनुबंध पैटर्न का उपयोग करें: पहले नए कॉलम जोड़ें, पुराने और नए दोनों को लिखने वाले कोड को तैनात करें, डेटा को माइग्रेट करें, फिर बाद के रिलीज में पुराने कॉलम हटा दें।

सीआई के लिए सही परीक्षण पिरामिड क्या है?

एक विशिष्ट वेब एप्लिकेशन के लिए: 70% यूनिट परीक्षण (तेज़, पृथक), 20% एकीकरण परीक्षण (एपीआई एंडपॉइंट, डेटाबेस क्वेरीज़), 10% E2E परीक्षण (महत्वपूर्ण उपयोगकर्ता प्रवाह)। प्रत्येक कमिट पर यूनिट परीक्षण चलते हैं। एकीकरण परीक्षण पीआर पर चलते हैं। E2E परीक्षण मुख्य में विलय पर या उत्पादन परिनियोजन से पहले चलते हैं।

---

आगे क्या आता है

एक अच्छी तरह से डिज़ाइन की गई CI/CD पाइपलाइन अन्य सभी DevOps प्रथाओं की नींव है। विश्वसनीय स्वचालन के साथ, आप आत्मविश्वास से कोड के रूप में बुनियादी ढांचे, उत्पादन निगरानी, और लोड परीक्षण का अनुसरण कर सकते हैं।

CI/CD पाइपलाइन डिजाइन और कार्यान्वयन के लिए ECOSIRE से संपर्क करें, या संपूर्ण बुनियादी ढांचे के रोडमैप के लिए हमारे छोटे व्यवसायों के लिए DevOps गाइड देखें।

---

ECOSIRE द्वारा प्रकाशित - व्यवसायों को आत्मविश्वास के साथ सॉफ़्टवेयर तैनात करने में मदद करना।