CI/CD پائپ لائن کے بہترین طریقے: قابل اعتماد تعیناتیوں کے لیے اپنے راستے کو خودکار بنائیں

**بالغ CI/CD پائپ لائنوں والی ٹیمیں ان کے مقابلے میں 208 گنا زیادہ کثرت سے تعینات کرتی ہیں، جب کہ 7 گنا کم تبدیلی کی ناکامی کی شرح کا سامنا کرنا پڑتا ہے۔ ** ایک نازک "یہ زیادہ تر کام کرتا ہے" پائپ لائن اور جنگی تجربہ شدہ تعیناتی نظام کے درمیان فرق مٹھی بھر طریقوں پر آتا ہے جو شوقیہ آٹومیشن کو پروڈکشن گریڈ سے الگ کرتے ہیں۔

اس گائیڈ میں ٹھوس طریقوں، کنفیگریشنز، اور تعمیراتی فیصلوں کا احاطہ کیا گیا ہے جو CI/CD پائپ لائنوں کو پیمانے پر قابل اعتماد بناتے ہیں۔

اہم ٹیک ویز

• پائپ لائن پر عمل درآمد کا وقت براہ راست ڈویلپر کی پیداواری صلاحیت کو متاثر کرتا ہے --- مکمل سوٹ کے لیے 10 منٹ سے کم کا ہدف
• CI میں سیکیورٹی اسکیننگ پیداوار تک پہنچنے سے پہلے 85% خطرات کو پکڑتی ہے۔
• خودکار رول بیک میکانزم بحالی کے درمیانی وقت کو گھنٹوں سے منٹ تک کم کر دیتے ہیں۔
• برانچ کے تحفظ کے قواعد اور مطلوبہ حیثیت کی جانچ ٹوٹے ہوئے کوڈ کو مین تک پہنچنے سے روکتی ہے۔

---

پائپ لائن فن تعمیر

پانچ مراحل کا ماڈل

ہر پروڈکشن CI/CD پائپ لائن کو پانچ مراحل پر عمل درآمد کرنا چاہیے:

مرحلہ 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: پیداوار کے لیے تعینات کریں

دستی منظوری کا گیٹ یا سٹیجنگ توثیق گزرنے کے بعد خودکار۔

---

رفتار کی اصلاح

سست پائپ لائنز ڈویلپر کی پیداواری صلاحیت کو ختم کر دیتی ہیں۔ CI انتظار کے وقت کا ہر منٹ ایک ٹیم میں کئی گنا زیادہ سیاق و سباق کو تبدیل کرنے کا وقت بناتا ہے۔

متوازی

بیک وقت آزاد ملازمتیں چلائیں:

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

سیکیورٹی گیٹ پالیسی

| شدت تلاش کرنا | PR سلوک | پیداواری سلوک | |------|----------------------------| | تنقیدی | بلاک انضمام | بلاک تعیناتی | | ہائی | بلاک انضمام | بلاک تعیناتی | | میڈیم | انتباہ، انضمام کی اجازت دیں | انتباہ، تعیناتی کی اجازت دیں | | کم | صرف معلوماتی | صرف معلوماتی |

---

برانچ پروٹیکشن اور انضمام کی حکمت عملی

مطلوبہ اسٹیٹس چیک

مین برانچ پر مطلوبہ اسٹیٹس چیک کے طور پر ان کو کنفیگر کریں:

1. لنٹ اور ٹائپ چیک پاس ہونا ضروری ہے۔
2. تمام یونٹ ٹیسٹ پاس کرنا ضروری ہے۔
3. انضمام کے تمام ٹیسٹ پاس ہونے چاہئیں
4. سیکیورٹی اسکین میں کوئی اہم/اعلی نتائج نہیں ہونے چاہئیں
5. تعمیر کامیاب ہونا ضروری ہے

ضم کرنے کی حکمت عملی

صاف ستھری تاریخ کو برقرار رکھنے کے لیے فیچر برانچز کے لیے اسکواش انضمام کا استعمال کریں:

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

PRs کے لیے کم از کم ایک منظوری درکار ہے۔ اہم راستوں کے لیے (تصنیف، بلنگ، ڈیٹا بیس کی منتقلی)، دو منظوریوں کی ضرورت ہوتی ہے۔

---

تعیناتی کی حکمت عملی

بلیو گرین تعیناتی۔

دو یکساں پیداواری ماحول کو برقرار رکھیں۔ ٹریفک کو ایک کی طرف روٹ کریں جبکہ دوسرے پر تعینات کریں۔

#!/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

---

Monorepo پائپ لائن کی اصلاح

مونوریپو پروجیکٹس کے لیے (جیسے ٹربورپو استعمال کرنے والے)، صرف وہی چلائیں جو بدلا ہے:

- 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]'

یہ ان تبدیلیوں کے لیے CI ٹائم کو 60-80% تک کم کر دیتا ہے جو ایک بڑے monorepo میں صرف ایک پیکج کو متاثر کرتی ہیں۔

---

اکثر پوچھے گئے سوالات

ہمیں پیداوار میں کتنی بار تعینات کرنا چاہیے؟

جتنی بار آپ کی پائپ لائن اجازت دیتی ہے تعینات کریں۔ اعلی کارکردگی کا مظاہرہ کرنے والی ٹیمیں دن میں متعدد بار تعینات ہوتی ہیں۔ مقصد چھوٹی، بڑھتی ہوئی تبدیلیاں ہیں جن کا جائزہ لینا، جانچنا، اور رول بیک کرنا آسان ہے۔ اگر تعیناتی خطرناک محسوس ہوتی ہے، تو یہ اس بات کا اشارہ ہے کہ آپ کی پائپ لائن کو زیادہ خودکار جانچ اور بہتر رول بیک میکانزم کی ضرورت ہے، کم تعیناتیوں کی نہیں۔

کیا ہمیں ٹرنک پر مبنی ڈیولپمنٹ یا فیچر برانچز استعمال کرنی چاہئیں؟

مختصر عمر (1-3 دن) والی نمایاں شاخیں زیادہ تر ٹیموں کے لیے بہترین کام کرتی ہیں۔ ٹرنک پر مبنی ترقی کے لیے زیادہ پختہ ٹیسٹنگ انفراسٹرکچر اور فیچر فلیگ کی ضرورت ہوتی ہے۔ اہم بات یہ ہے کہ شاخیں قلیل المدت ہیں --- طویل المدت خصوصیت والی شاخیں انضمام کے تنازعات پیدا کرتی ہیں اور رائے میں تاخیر کرتی ہیں۔

ہم CI/CD میں ڈیٹا بیس کی منتقلی کو کیسے ہینڈل کرتے ہیں؟

درخواست کی تعیناتی سے پہلے ہجرت کو ایک علیحدہ پائپ لائن مرحلے کے طور پر چلائیں۔ یقینی بنائیں کہ نقل مکانی پسماندہ مطابقت رکھتی ہے (پرانے ایپلیکیشن ورژن کو نئے اسکیما کے ساتھ کام کرنا چاہیے)۔ توسیع اور معاہدہ کا نمونہ استعمال کریں: پہلے نئے کالم شامل کریں، کوڈ متعین کریں جو پرانے اور نئے دونوں پر لکھتا ہے، ڈیٹا کو منتقل کریں، پھر بعد میں ریلیز میں پرانے کالموں کو ہٹا دیں۔

CI کے لیے صحیح ٹیسٹ پیرامڈ کیا ہے؟

ایک عام ویب ایپلیکیشن کے لیے: 70% یونٹ ٹیسٹ (تیز، الگ تھلگ)، 20% انٹیگریشن ٹیسٹ (API اینڈ پوائنٹس، ڈیٹا بیس کے سوالات)، 10% E2E ٹیسٹ (صارفین کا اہم بہاؤ)۔ یونٹ ٹیسٹ ہر کمٹ پر چلتے ہیں۔ انٹیگریشن ٹیسٹ PR پر چلتے ہیں۔ E2E ٹیسٹ مین یا پروڈکشن کی تعیناتی سے پہلے انضمام پر چلتے ہیں۔

---

آگے کیا آتا ہے۔

ایک اچھی طرح سے ڈیزائن کردہ CI/CD پائپ لائن دیگر تمام DevOps طریقوں کی بنیاد ہے۔ قابل اعتماد آٹومیشن کے ساتھ، آپ اعتماد کے ساتھ بطور کوڈ کے بنیادی ڈھانچے، پروڈکشن مانیٹرنگ، اور لوڈ ٹیسٹنگ کو آگے بڑھا سکتے ہیں۔

CI/CD پائپ لائن کے ڈیزائن اور نفاذ کے لیے ECOSIRE سے رابطہ کریں، یا مکمل انفراسٹرکچر روڈ میپ کے لیے ہماری DevOps گائیڈ برائے چھوٹے کاروبار کو دریافت کریں۔

---

ECOSIRE کے ذریعہ شائع کیا گیا -- کاروباروں کو اعتماد کے ساتھ سافٹ ویئر تعینات کرنے میں مدد کرنا۔