AR
RU
EN
ES
ZH
FR
DE
PT
HI
خط أنابيب CI/CD لـ TypeScript: الإعداد من الصفر — دليل خطوة بخطوة
\n\nلقد كتبت مشروعًا رائعًا باستخدام TypeScript. الكود جميل، والأنواع صارمة، والمنطق دقيق. ولكن في كل مرة تحتاج فيها إلى تحميل تحديث على الخادم، تقوم يدويًا بتشغيل البناء، وتتحقق مما إذا كان هناك شيء قد تعطل، وتدعو ألا يسقط الإنتاج. هل هذا مألوف؟
\n\nحان الوقت لتغيير ذلك. خط أنابيب CI/CD ليس سحرًا لكبار المطورين ذوي الخبرة لعشرين عامًا. إنها أداة تؤتمت المهام الروتينية: التدقيق (linting)، والاختبارات، والبناء، والنشر. commit واحد في الفرع — وكل شيء يذهب إلى الإنتاج تلقائيًا، دون توتر.
\n\nفي هذه المقالة، سنقوم بإعداد خط أنابيب CI/CD كامل لمشروع TypeScript من الصفر. باستخدام GitHub Actions — أداة مجانية وقوية. ستتعلم:
\n- \n
- إضافة التدقيق والتنسيق التلقائي \n
- تشغيل اختبارات الوحدة والتحقق من الأنواع \n
- بناء التطبيق ونشره على خادم بعيد \n
- تجنب الأخطاء الشائعة عند إعداد CI/CD \n
هل أنت مستعد؟ هيا بنا!
\n\nلماذا يعتبر CI/CD بالغ الأهمية لمشروع TypeScript
\n\nTypeScript هي لغة مكتوبة بشدة (strongly typed) يتم تجميعها إلى JavaScript. للوهلة الأولى، يعطي هذا وهمًا بالأمان: إذا تم تجميع الكود، فهذا يعني أنه يعمل. ولكن في الممارسة العملية، لا يكتشف التجميع الأخطاء المنطقية، أو مشاكل API، أو التبعيات المعطلة.
\n\nCI/CD (التكامل المستمر / النشر المستمر) يحل هذه المشكلة:
\n- \n
- التحقق التلقائي: يمر كل commit عبر خط أنابيب — التدقيق، الاختبارات، التجميع. إذا تعطل شيء ما، ستعرف خلال دقيقة، وليس بعد أسبوع. \n
- معيار موحد: يعمل الفريق بأكمله وفقًا لنفس القواعد. لن ينسى أحد تشغيل الاختبارات قبل الدفع (push). \n
- نشر سريع: لا مزيد من الأوامر اليدوية على الخادم. merge واحد في main — والتحديث موجود بالفعل على الموقع المباشر. \n
بالنسبة لـ TypeScript، يعتبر CI/CD مهمًا بشكل خاص لأن أخطاء الأنواع قد تظهر فقط في وقت التشغيل (runtime) إذا لم يتم إعداد التجميع بشكل صحيح. يمنع خط الأنابيب ذلك.
\n\nالخطوة 1: تحضير مشروع TypeScript
\n\nقبل إعداد CI/CD، تأكد من أن المشروع جاهز للأتمتة. إليك الحد الأدنى من المتطلبات:
\n- \n
package.jsonمع نصوص (scripts) محددة \n tsconfig.json— إعدادات TypeScript \n - ESLint و Prettier — لتوحيد الكود \n
- اختبارات (Jest, Vitest أو Mocha) \n
لنفترض أن لديك مشروعًا بسيطًا. قد يبدو الهيكل كالتالي:
\n\nmy-ts-project/\n├── src/\n│ ├── index.ts\n│ └── utils.ts\n├── tests/\n│ └── utils.test.ts\n├── .eslintrc.json\n├── .prettierrc\n├── tsconfig.json\n├── package.json\n└── README.md\nتأكد من أن النصوص (scripts) محددة في package.json:
{\n "scripts": {\n "lint": "eslint src/ tests/ --ext .ts",\n "format": "prettier --check src/ tests/",\n "type-check": "tsc --noEmit",\n "test": "jest",\n "build": "tsc",\n "start": "node dist/index.js"\n }\n}\nالآن المشروع جاهز لـ CI/CD. إذا كان هناك شيء ناقص، قم بإضافته. سيقوم خط الأنابيب باستدعاء هذه الأوامر تحديدًا.
\n\nالخطوة 2: اختيار منصة CI/CD
\n\nهناك العديد من الخيارات: Jenkins, GitLab CI, CircleCI, Travis CI. ولكن للمبتدئين والمشاريع الصغيرة، GitHub Actions هو الخيار الأفضل:
\n- \n
- مدمج في GitHub — لا حاجة لإعداد أي شيء بشكل منفصل \n
- حد مجاني: 2000 دقيقة شهريًا (للمستودعات الخاصة) \n
- نظام بيئي ضخم من الإجراءات (actions) الجاهزة \n
- صيغة YAML واضحة \n
إذا كان كودك موجودًا على GitLab — استخدم GitLab CI (الوصف مشابه تقريبًا). لكن في هذه المقالة نعمل مع GitHub.
\n\nالخطوة 3: إنشاء خط أنابيب CI/CD — الملف الأول
\n\nفي جذر المشروع، أنشئ مجلد .github/workflows/، وداخله ملف ci.y
