ابدأ في CI/CD Pipeline: خطوتك الأولى الملموسة اليوم
CI CD Pipeline : الأساسيات في مقال واحد — كود حقيقي، مخططات وخطوات ملموسة، مقتطفات من دورة مكونة من 20 درسًا.
أفضل طريقة لتعلم CI CD Pipeline هي بالممارسة. يساعدك هذا المقال على البدء مع مقتطفات عملية مستمدة من دورة تتكون من 20 درسًا — ما يكفي للحصول على نتيجة أولى اليوم.
- مقدمة في CICD
- التكامل المستمر
- جودة الكود
- تحسين خط الأنابيب
- النشر المستمر
تغطية الكود وعتبات الجودة
الفصل 02 • الدرس 03 • المدة: 45 دقيقة
- فهم ما هي تغطية الكود وحدودها
- قياس التغطية باستخدام الأدوات القياسية (pytest-cov, jest, JaCoCo)
- تحديد عتبات ذكية (line, branch, mutation)
- حظر طلب سحب إذا انخفضت التغطية
- عرض التقارير في Codecov أو SonarQube
1. ما هي تغطية الكود؟
تقيس تغطية الكود النسبة المئوية للأسطر (أو الفروع، الشروط، الدوال) المنفذة بواسطة الاختبارات الآلية.
| النوع | القياس | مثال |
|---|---|---|
| Line Coverage | نسبة الأسطر المنفذة | 80 % = 80 سطرًا من أصل 100 تم لمسها |
| Branch Coverage | نسبة الفروع الشرطية المختبرة | if/else, switch — يجب أن يمر المساران |
| Function Coverage | نسبة الدوال المستدعاة | هل تم اختبار جميع الدوال المصدرة؟ |
| Statement Coverage | نسبة التعليمات المنفذة | قريب من line coverage |
| Mutation Coverage | نسبة الطفرات المكتشفة بالاختبارات | أكثر موثوقية لكنه مكلف (mutation testing) |
100 % تغطية لا تعني 100 % جودة. يمكن الحصول على 100 % أسطر منفذة دون التحقق من النتائج. assert مهم بقدر تنفيذ الكود.
2. التغطية في بايثون باستخدام pytest-cov
pip install pytest pytest-cov # تشغيل الاختبارات مع التغطية pytest --cov=mon_module --cov-report=term --cov-report=html # مخرجات الطرفية: # Name Stmts Miss Cover # ------------------------------------- # mon_module.py 50 5 90% # ------------------------------------- # TOTAL 50 5 90% # تقرير HTML تفاعلي في htmlcov/index.html
التهيئة عبر pyproject.toml
[tool.pytest.ini_options]
addopts = "--cov=src --cov-report=term-missing --cov-report=xml --cov-fail-under=80"
[tool.coverage.run]
source = ["src"]
omit = [
"*/tests/*",
"*/migrations/*",
"*/__init__.py"
]
[tool.coverage.report]
exclude_lines = [
"pragma: no cover",
"raise NotImplementedError",
"if __name__ == .__main__.:",
]
fail_under = 80
show_missing = true3. التغطية في جافا سكريبت باستخدام Jest
npm install --save-dev jest
# package.json
{
"scripts": {
"test": "jest",
"test:coverage": "jest --coverage"
},
"jest": {
"collectCoverageFrom": [
"src/**/*.{js,ts}",
"!src/**/*.d.ts",
"!src/index.ts"
],
"coverageThreshold": {
"global": {
"branches": 75,
"functions": 80,
"lines": 80,
"statements": 80
}
},
"coverageReporters": ["text", "lcov", "html", "cobertura"]
}
}
# تشغيل
npm run test:coverage
# إذا لم يتم الوصول إلى العتبة:
# Jest: "global" coverage threshold for lines (80%) not met: 73.5%
# → فشل البناء4. التغطية في جافا باستخدام JaCoCo
<!-- pom.xml -->
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.11</version>
<executions>
<execution>
<goals><goal>prepare-agent</goal></goals>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals><goal>report</goal></goals>
</execution>
<execution>
<id>jacoco-check</id>
<goals><goal>check</goal></goals>
<configuration>
<rules>
<rule>
<element>BUNDLE</element>
<limits>
<limit>
<counter>LINE</counter>
<value>COVEREDRATIO</value>
<minimum>0.80</minimum>
</limit>
</limits>
</rule>
</rules>
</configuration>
</execution>
</executions>
</plugin>
mvn clean test
# التقرير في target/site/jacoco/index.html5. تحديد عتبات ذكية
| نوع المشروع | العتبة الموصى بها |
|---|---|
| Critical (banking, healthcare, aerospace) | 90-95 % |
| SaaS / Web app production | 80-85 % |
| Backend API | 75-85 % |
| Frontend (UI logic) | 60-70 % |
| Prototype / MVP | 40-60 % |
| Script utilitaire | 0-30 % (غالبًا غير ضروري) |
بدلًا من عتبة مطلقة، اطلب ألا تنخفض التغطية مقارنة بالفرع main. يقوم Codecov و SonarQube بذلك بشكل أصلي.
6. دمج GitHub Actions
name: CI with Coverage
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v5
with:
python-version: '3.12'
- name: Install
run: pip install -e ".[dev]"
- name: Tests + coverage
run: pytest --cov --cov-report=xml --cov-report=term --cov-fail-under=80
- name: Upload coverage to Codecov
uses: codecov/codecov-action@v4
with:
file: ./coverage.xml
token: ${{ secrets.CODECOV_TOKEN }}
fail_ci_if_error: true7. Codecov: العرض والمقارنة
codecov.yml للتخصيص
coverage:
status:
project:
default:
target: 80%
threshold: 1%
patch:
default:
target: 90%
threshold: 5%
comment:
layout: "header, diff, flags, files"
behavior: default
require_changes: false
ignore:
- "tests/**"
- "**/__init__.py"
- "migrations/**"إدارة الـ artifacts والـ registries
الفصل 03 • الدرس 03 • المدة: 45 دقيقة
- فهم ما هو الـ artifact والـ registry
- تخزين ومشاركة الـ artifacts (zip, jar, wheel) في GitHub Actions
- رفع صور Docker إلى Docker Hub, GHCR, AWS ECR
- إدارة الإصدارات الدلالية للـ artifacts
- وضع قواعد الاحتفاظ لتجنب انفجار التكاليف
1. ما هو الـ artifact؟
الـ artifact هو أي ملف ينتجه البناء ويُقصد استخدامه لاحقًا:
| نوع الـ artifact | مثال | الـ Registry النموذجي |
|---|---|---|
| Image container | devforge-api:1.2.3 (Docker) | Docker Hub, GHCR, ECR, Quay |
| Package Python | my-lib-1.0.0.whl | PyPI, AWS CodeArtifact, GitHub Packages |
| Package npm | my-lib-1.0.0.tgz | npm registry, GitHub Packages |
| JAR Java | my-app-1.0.jar | Maven Central, Nexus, JFrog Artifactory |
| Binaire compilé | my-cli-linux-amd64 | GitHub Releases, S3 |
| Helm chart | my-chart-1.0.0.tgz | ChartMuseum, OCI registries |
| Fichier ZIP générique | build-output.zip | GitHub Actions Artifacts, S3 |
2. Artifacts GitHub Actions (داخل سير العمل)
رفع artifact
- name: Build wheel
run: python -m build
- name: Upload wheel as artifact
uses: actions/upload-artifact@v4
with:
name: python-wheel
path: dist/*.whl
retention-days: 30التنزيل في مهمة لاحقة
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- name: Download wheel
uses: actions/download-artifact@v4
with:
name: python-wheel
path: ./dist
- name: Install
run: pip install dist/*.whlartifacts GitHub مجانية حتى 500 ميجابايت لكل مستودع عام، وتنتهي صلاحيتها افتراضيًا بعد 90 يومًا.
3. مقارنة Container registries
| Registry | التكلفة | المزايا | العيوب |
|---|---|---|---|
| Docker Hub | مجاني (عام) / 5 $/user (خاص) | الأكثر شعبية، نظام بيئي واسع | حدود معدل على السحب |
| GHCR (GitHub) | مجاني (عام) / مشمول مع GitHub | تكامل أصلي مع GitHub | أقل شهرة |
| AWS ECR | 0.10 $/Go/شهر | أمان IAM، فحص تلقائي، متكامل مع ECS/EKS | خاص بالمنطقة |
| GCR / Artifact Registry | 0.10 $/Go/شهر | متكامل مع GCP، متعدد الصيغ | التقيد بـ GCP |
| Azure ACR | Basic 5 $/شهر | متكامل مع Azure | التقيد بـ Azure |
| Quay.io | مجاني (عام) / مدفوع (خاص) | كاشف ثغرات قوي | دعم أقل |
| Harbor (self-hosted) | مجاني (لكن عمليات) | بدون اعتماد خارجي، تحكم كامل | يحتاج صيانة ذاتية |
4. الرفع إلى Docker Hub من GitHub Actions
- name: Login Docker Hub
uses: docker/login-action@v3
with:
username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }}
- name: Build and push
uses: docker/build-push-action@v5
with:
context: .
push: true
tags: |
myuser/myapp:latest
myuser/myapp:${{ github.sha }}
myuser/myapp:${{ github.ref_name }}
platforms: linux/amd64,linux/arm64
cache-from: type=gha
cache-to: type=gha,mode=max5. الرفع إلى GHCR (GitHub Container Registry)
- name: Login to GHCR
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Build and push
uses: docker/build-push-action@v5
with:
push: true
tags: |
ghcr.io/${{ github.repository }}:latest
ghcr.io/${{ github.repository }}:${{ github.sha }}لا يحتاج GHCR أي سر إضافي: يكفي GITHUB_TOKEN المولد تلقائيًا.
6. الرفع إلى AWS ECR
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/github-actions-ecr
aws-region: eu-west-3
- name: Login to ECR
id: ecr
uses: aws-actions/amazon-ecr-login@v2
- name: Build and push
uses: docker/build-push-action@v5
with:
push: true
tags: |
${{ steps.ecr.outputs.registry }}/myapp:latest
${{ steps.ecr.outputs.registry }}/myapp:${{ github.sha }}7. الإصدار الدلالي للصور
اتفاقية SemVer: MAJOR.MINOR.PATCH
| الوسم | متى يُستخدم |
|---|---|
1.2.3 | الإصدار الدقيق غير القابل للتغيير (إنتاج صارم) |
1.2 | آخر تصحيح للإصدار الثانوي 1.2 |
1 | آخر إصدار ثانوي للإصدار الرئيسي 1 |
latest | الأحدث (تجنبه في الإنتاج!) |
sha-abc1234 | وسم مبني على commit Git |
main / develop | الأحدث في الفرع |
pr-42 | خاص بطلب سحب |
v1.2.3-rc.1 | مرشح إصدار |
باستخدام docker/metadata-action
- name: Generate tags
id: meta
uses: docker/metadata-action@v5
with:
images: myuser/myapp
tags: |
type=ref,event=branch
type=ref,event=pr
type=semver,pattern={{version}}
type=semver,pattern={{major}}.{{minor}}
type=semver,pattern={{major}}
type=sha,prefix=sha-,format=short
type=raw,value=latest,enable={{is_default_branch}}
# مخرجات تلقائية حسب السياق:
# - على main: latest, sha-abc1234, main
# - على الوسم v1.2.3: 1.2.3, 1.2, 1, sha-abc1234
# - على PR #42: pr-42, sha-abc1234الفصل 00.1 — فلسفة CI/CD: لماذا الأتمتة؟
1. العالم قبل CI/CD — «Integration Hell»
قبل تبني ممارسات CI/CD، كانت فرق التطوير تعمل في صوامع لأسابيع أو أشهر على فروع منفصلة. وعند محاولة دمج الكود، كانت النتيجة غالبًا كارثية. كان يُطلق على هذه الظاهرة اسم Integration Hell (جحيم التكامل).
🔴 قبل CI/CD
🟢 مع CI/CD
2. تكلفة الخطأ — قاعدة «Shift Left»
مبدأ «Shift Left» (الانتقال يسارًا) يعني اكتشاف وإصلاح المشكلات في أقرب وقت ممكن في دورة التطوير. كلما تأخر اكتشاف الخطأ، زادت تكلفة إصلاحه.
يسمح CI/CD برفع المشكلات منذ الـ commit، مما يقلل بشكل كبير من تكلفة التصحيح. تعمل الاختبارات الآلية وتحليل الكود الثابت وفحوصات الأمان عند كل push، قبل وصول الكود إلى الإنتاج بوقت طويل.
3. الأعمدة الثلاثة: CI، CD (التسليم) وCD (النشر)
🔵 CI — التكامل المستمر
يدمج المطورون كودهم في فرع مشترك عدة مرات يوميًا. عند كل دمج، ينطلق خط أنابيب آلي: التجميع، الاختبارات الوحدية، تحليل الكود.
الهدف: اكتشاف التعارضات والأخطاء بسرعة.
🟡 CD — التسليم المستمر
يكون الكود دائمًا في حالة قابلة للنشر. بعد CI، يُعد خط الأنابيب تلقائيًا إصدارًا (حزمة، صورة Docker) جاهزًا للنشر على أي بيئة.
الهدف: القدرة على النشر في أي وقت، مع إمكانية موافقة بشرية.
🟢 CD — النشر المستمر
كل commit يجتاز الاختبارات يُنشر تلقائيًا في الإنتاج، بدون تدخل بشري. هذا هو المستوى الأقصى من الأتمتة، المستخدم من Netflix وAmazon وGoogle.
الهدف: إزالة أي تأخير بين الكود والقيمة للمستخدم.
| الممارسة | تكرار النشر | الموافقة البشرية | مستوى الثقة المطلوب |
|---|---|---|---|
| يدوي | ربع سنوي / سنوي | دائمًا | منخفض (العملية) |
| CI فقط | أسبوعي / شهري | دائمًا | متوسط (اختبارات أساسية) |
| CI + CD تسليم | يومي / أسبوعي | اختيارية | مرتفع (اختبارات كاملة) |
| CI + CD نشر | عدة مرات/يوم | أبدًا | مرتفع جدًا (اختبارات + مراقبة) |
4. خط أنابيب CI/CD — نظرة عامة
خط أنابيب CI/CD هو سلسلة خطوات آلية تحول commit كود إلى تطبيق منشور في الإنتاج.
| الخطوة | الوصف | الأدوات الشائعة | المدة النموذجية |
|---|---|---|---|
| الكود | يدفع المطور الكود إلى Git | Git, GitHub, GitLab | — |
| البناء | التجميع، حل التبعيات | Maven, npm, Gradle, Docker | 1–5 دقائق |
| اختبار وحدي | اختبارات سريعة على مستوى الدوال | JUnit, Jest, pytest | 1–3 دقائق |
| تحليل الجودة | تغطية الكود، linting، الأمان | SonarQube, ESLint, Snyk | 2–5 دقائق |
| الحزمة | إنشاء artifact قابل للنشر | Docker, JAR, ZIP, Helm | 2–10 دقائق |
| اختبار التكامل | اختبارات على بيئة كاملة | Postman, Cypress, k6 | 5–15 دقيقة |
| نشر Staging | النشر على بيئة اختبار | Kubernetes, ECS, Heroku | 2–5 دقائق |
| نشر Prod | النشر في الإنتاج | Rolling, Blue/Green, Canary | 2–10 دقائق |
| المراقبة | المراقبة والتنبيهات بعد النشر | Prometheus, Grafana, Datadog | مستمر |
5. مقاييس DORA — قياس أداء DevOps
حدد مشروع DORA (DevOps Research and Assessment) أربعة مقاييس رئيسية تقيس فعالية مؤسسة DevOps. تتيح هذه المقاييس تحديد موقع فريقك وتحديد أهداف التحسين.
📈 Deployment Frequency
يغطي هذا المقال المقتطفات الأكثر فائدة — الدورة الكاملة CI CD Pipeline (7 فصول، 20 درسًا، تمارين مصححة ومشروع نهائي) تأخذك إلى النهاية.
./acceder-au-cours-complet دورة مجانية: إتقان Claude Codeالأسئلة الشائعة
كم من الوقت لتعلم CI CD Pipeline؟
هل هناك متطلبات مسبقة؟
من أين نبدأ عمليًا؟
📬 هل تريد تلقي هذا النوع من الأدلة كل أسبوع؟ اشترك مجانًا — كود حقيقي، بدون ثرثرة.