ثقافة DevOps وأساسياتها

دورة حياة تسليم البرمجيات

18 دقيقة الدرس 3 من 28

دورة حياة تسليم البرمجيات

في الدرسين السابقين تعرّفت على ماهية DevOps وكيف يصف إطار CALMS التحوّل الثقافي الذي يتطلّبه. الآن ستنغمس في قلب DevOps الميكانيكي: دورة حياة تسليم البرمجيات (SDLC) — كل مرحلة تمر بها التغييرات منذ اللحظة التي يدفع فيها المطوّر تعديلاً حتى اللحظة التي يخدم فيها هذا التعديل المستخدمين الفعليين في الإنتاج.

فهم هذه القناة من البداية إلى النهاية أمر غير قابل للتفاوض لمهندس DevOps. ستمتلك أجزاء كبيرة منها: بنية الأتمتة، وبوابات الجودة، وآلية النشر، وحلقات التغذية الراجعة التي تجعل النظام بأكمله مُصحِّحاً لنفسه.

المراحل السبع الأساسية

تتباين خطوط تسليم برمجيات الشركات الكبرى في أسمائها الدقيقة وخطواتها الفرعية، لكنها جميعاً تتوافق مع سبع مراحل مفاهيمية: التخطيط ← البرمجة ← البناء ← الاختبار ← الإصدار ← النشر ← التشغيل. كل مرحلة تُغذّي المرحلة التالية مباشرةً، والأهم من ذلك أن كل مرحلة تُنتج أيضاً إشارات تغذية راجعة تتدفق إلى المراحل السابقة — وهي الحلقات التي تجعل التحسين المستمر ممكناً.

المراحل السبع لدورة حياة التسليم من التخطيط إلى التشغيل. الصندوق الأرجواني المتقطع هو التكامل المستمر (CI)، والصندوق الأخضر المتقطع هو التسليم/النشر المستمر (CD). تُظهر الأقواس الحمراء كيف تُرسل المراحل المتأخرة إشارات فشل ومعلومات عودةً للمراحل الأولى.

التعمق في كل مرحلة

1. التخطيط (Plan)

يُقسَّم العمل إلى قصص ومهام في أدوات مثل Jira أو Linear أو GitHub Issues. في الشركات ذات الأداء العالي، تشمل هذه المرحلة تعريف الإنجاز (DoD) — قائمة تحقق صريحة يجب أن تجتازها كل قصة قبل اعتبارها مكتملة. هنا تُسجَّل ليس فقط المتطلبات الوظيفية بل متطلبات التشغيل أيضاً: أهداف مستوى الخدمة (SLOs)، وإجراءات التراجع، واحتياجات الرصد. القصص التي تتجاهل متطلبات التشغيل تُولّد عمل إطفاء حرائق لاحقاً.

2. البرمجة (Code)

يكتب المطوّرون الكود في فروع ميزات قصيرة العمر مشتقة من main. مراجعة طلب السحب (PR) هي بوابة الجودة الأولى: إنسان يتحقق من الصحة والأسلوب والأمان وتغطية الاختبارات. تعمل خطّافات ما قبل الإيداع (pre-commit hooks) محلياً لتشغيل أدوات تدقيق الكود وماسحات الأسرار، حتى لا تصل المشكلات التافهة إلى CI.

خطّاف ما قبل الإيداع (عبر إطار pre-commit، ملف .pre-commit-config.yaml)
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.5.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: detect-private-key
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.1
    hooks:
      - id: gitleaks        # يمنع الإيداعات التي تحتوي على أسرار

3. البناء (Build)

عند كل دفعة، يُترجم نظام CI الكودَ، ويحلّ التبعيات، ويُجري التحليل الساكن، وينتج أداة إنجاز حتمية وثابتة — صورة Docker أو JAR أو ثنائي مُصرَّف. تُوسَم الأداة بـ Git SHA وتُدفع إلى السجل. إنتاج الأداة مرة واحدة فقط (لا مرة لكل بيئة) هو قاعدة صارمة: نفس البايتات التي اجتازت الاختبارات هي البايتات التي تذهب إلى الإنتاج. إعادة البناء لكل بيئة تُدخل انجرافاً في التكوين.

Dockerfile — بناء متعدد المراحل (مثال Node.js)
# ---- مرحلة البناء ----
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
RUN npm run build

# ---- مرحلة التشغيل ----
FROM node:20-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER node
EXPOSE 3000
CMD ["node", "dist/main.js"]

ممارسة احترافية: أوسم صورتك بـ Git SHA الكامل: docker build -t myapp:$(git rev-parse --short HEAD) . — لا تستخدم :latest أبداً في خطوط CI. الوسم الثابت يعني أنك تستطيع تحديد ما يعمل في أي مكان بدقة تامة.

4. الاختبار (Test)

تُرتَّب الاختبارات على شكل هرم: اختبارات الوحدة السريعة الكثيرة في القاعدة، وعدد أقل من اختبارات التكامل في الوسط، وطبقة رفيعة من اختبارات النهاية إلى النهاية (E2E) في القمة. تُطبّق خطوط الشركات الكبرى حدوداً للتغطية (عادةً 80 %+ على المسارات الحرجة) وتعامل الاختبارات الفاشلة باعتبارها عائقاً للخط — لا تحذيراً اختيارياً.

تعمل فحوصات آلية إضافية هنا: SAST (اختبار أمان التطبيقات الساكت)، وفحص ثغرات التبعيات (trivy، snyk)، واختبارات العقود لمستهلكي API. أي فشل في هذه المرحلة يُرسل إشعاراً فورياً عبر Slack أو PagerDuty إلى الفريق المسؤول — كلما كانت التغذية الراجعة أسرع، كان تكلفة الإصلاح أرخص.

5. الإصدار (Release)

ترفع مرحلة الإصدار الأداة المُتحقَّق منها إلى سجل الأدوات (مثل ECR أو GCR أو Artifactory) وتنشئ وسماً في Git يربط هذا الإصدار بالكود إلى الأبد. في التطوير القائم على الجذع الرئيسي (trunk-based)، كل بناء ناجح على main هو مرشح إصدار محتمل. تحصل الأداة المُصدَرة أيضاً على قائمة مواد البرمجيات (SBOM) — جرد لكل مكتبة داخل الصورة، وهو مطلوب من كثير من العملاء المؤسسيين والحكوميين.

6. النشر (Deploy)

تضع مرحلة النشر الأداة المُصدَرة في بيئة تشغيل. استراتيجية النشر هي التي تحدد مستوى المخاطرة:

التحديث المتدرّج (Rolling) — تحلّ حاويات جديدة محلّ القديمة تدريجياً؛ مخاطر منخفضة وتكلفة بنية تحتية منعدمة.
الأزرق/الأخضر (Blue/Green) — بيئتان متطابقتان؛ يتحوّل الحركة المرورية ذرياً؛ التراجع فوري بإعادة توجيه موزّع الحمل.
الكناري (Canary) — توجيه نسبة صغيرة (1–5 %) من الحركة الحية إلى الإصدار الجديد أولاً؛ ترقية أو تراجع بناءً على معدلات الأخطاء الفعلية.

على نطاق Google، تعمل الاختبارات الكنارية لساعات أو أيام قبل الطرح الكامل. تفصل أعلام الميزات (Feature Flags) بين النشر (الكود حي) والإصدار (الميزة مرئية للمستخدمين)، مما يمنح المشغّلين مفتاح إيقاف وقت التشغيل مستقلاً عن خط النشر.

7. التشغيل (Operate)

يُراقَب النظام الجاري من خلال المقاييس والسجلات والتتبع — الركائز الثلاث لقابلية المراقبة. تُطلق التنبيهات عند استنزاف ميزانيات أخطاء SLO. يُغذّي تحليل ما بعد الحوادث مرحلةَ التخطيط، مغلقاً الحلقة. هذا ليس نشاطاً اختيارياً بعد الإطلاق: في الشركات المتميزة، تضمّ دوريات الاستعداد المهندسين أنفسهم الذين كتبوا الكود، مما يخلق حافزاً قوياً لجعل البرمجيات قابلة للرصد منذ اليوم الأول.

رؤية جوهرية: دورة حياة تسليم البرمجيات ليست شلالاً. كل مرحلة تُصدر إشارات تغذية راجعة تتدفق للخلف. الاختبار الفاشل هو تغذية راجعة لمرحلة البرمجة؛ التنبيه الإنتاجي هو تغذية راجعة لمرحلة التخطيط. ثقافة DevOps تعني أن هذه الإشارات تُعالَج خلال ساعات لا سبرينتات.

حلقة التغذية الراجعة هي المنتج الحقيقي

خط الإنتاج المادي (خادم CI، سجل الأدوات، أداة النشر) هو بنية تحتية. المنتج الحقيقي هو سرعة حلقة التغذية الراجعة. يُظهر بحث DORA (الذي سيُغطَّى في الدرس الخامس) أن الفرق المتميزة تنشر بحسب الطلب وتستعيد الخدمة في أقل من ساعة. هذه السرعة لا يمكن تحقيقها إلا عندما تفشل كل مرحلة بسرعة، وتفشل بوضوح، وتُعيد معلومات الفشل فوراً إلى الفريق المسؤول.

فخ إنتاجي شائع: تبني فرق كثيرة خطاً صحيحاً تقنياً لكنها تسمح للاختبارات بالعمل بالتوازي مع بوابات موافقة يدوية تستغرق أياماً. الخط يبدو مؤتمتاً على المخطط لكنه يتصرف كشلال في الواقع. قِس وقت القيادة من الإيداع إلى الإنتاج — إذا تجاوز 24 ساعة، فالبوابات ونقاط التسليم اليدوية هي الاختناق لا الاختبارات.

الخط كـكود

تُخزَّن تهيئة الخط نفسها في مستودع الكود جنباً إلى جنب مع كود التطبيق — عادةً كـ .github/workflows/ (GitHub Actions) أو .gitlab-ci.yml أو Jenkinsfile. هذا يعني أن الخط يحظى بمراجعة الكود، والتاريخ، والتراجع، ونفس معايير الجودة التي يحظى بها التطبيق. الخطوط المُدارة عبر واجهة مستخدم فقط هي خطر إنتاجي: حين يتعطل خادم CI، لا يتذكر أحد كيفية إعادة إنشاء الوظائف.

خط GitHub Actions CI مُختصر (.github/workflows/ci.yml)
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Unit tests
        run: npm test -- --coverage

      - name: Build Docker image
        run: |
          IMAGE_TAG=$(git rev-parse --short HEAD)
          docker build -t myapp:$IMAGE_TAG .

      - name: Scan image for vulnerabilities
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: myapp:${{ github.sha }}
          exit-code: 1
          severity: CRITICAL

ملخص

تُحرّك دورة حياة تسليم البرمجيات التغييرَ عبر سبع مراحل — التخطيط والبرمجة والبناء والاختبار والإصدار والنشر والتشغيل — مع حلقات تغذية راجعة تربط كل مرحلة بالمراحل السابقة. يغطي CI مراحل البرمجة حتى الاختبار ويضمن التحقق من كل إيداع في دقائق. يغطي CD مراحل الإصدار حتى النشر ويضمن وصول الأدوات المُتحقَّق منها إلى الإنتاج بأمان. تُغلق مرحلة التشغيل الحلقة بإعادة إشارات العالم الحقيقي إلى دورة التخطيط التالية. بوصفك مهندس DevOps، أنت تمتلك الأتمتة وبوابات الجودة وقابلية المراقبة التي تجعل هذه الحلقات سريعة بما يكفي لتُحدث فرقاً.