بناء مسار CI/CD جيد باستخدام GitHub Actions لم يعد الأمر مجرد خيار إضافي "لوقت فراغ": ففي فرق العمل الحديثة، يُعدّ شرطًا أساسيًا للتنفيذ السريع والموثوق. ومع ذلك، فإن إيجاد مثال كامل وعام ومدروس جيدًا يمكنك تكييفه مع شركتك غالبًا ما يكون أكثر تعقيدًا مما يبدو.
سنمزج في السطور التالية النظرية الكلاسيكية لـ CI/CD مع أمثلة تطبيقية واقعية باستخدام GitHub Actions، وخطوط الأنابيب القابلة لإعادة الاستخدام، والمهام، وبرامج باش النصية، وحدات PowerShell PnPعمليات النشر على منصات Kubernetes وGoogle Cloud وKinsta، بالإضافة إلى أفضل الممارسات للأمان والمراقبة وقابلية التوسع. الفكرة هي أنه يمكنك أخذ هذه العناصر وتطبيقها في سياقك الخاص، وتجنب العديد من المشاكل الشائعة.
لماذا تحتاج إلى خط أنابيب CI/CD مصمم بشكل جيد
في مجال التطوير المهني الحالي، يُعدّ التكامل المستمر/التسليم المستمر بمثابة النظام الدوري للبرمجة.يُدمج هذا النظام التغييرات، ويُجري الاختبارات، ويُنشئ الملفات، وينشر الإصدارات الجديدة بأقل قدر من التدخل. وبدون هذه الآلية، يصبح كل نشر عملية بطيئة، وعرضة للأخطاء، وتتطلب جهدًا يدويًا كبيرًا.
يركز التكامل المستمر (CI) على التحقق من صحة التغييرات بمجرد تحميلها إلى المستودع، تُجرى اختبارات الوحدة، وأدوات فحص الأخطاء، والتحليلات الثابتة لاكتشاف الأخطاء بأسرع وقت ممكن. كلما أسرعت في تلقي الملاحظات، كلما تمكنت من إصلاحها بشكل أسرع، وقلّت آثار أي تراجع في الأداء.
النشر المستمر (CD بمعنى النشر المستمر) أو التسليم المستمر (اعتمادًا على مستوى الأتمتة) يضيف أتمتة جزء الإصدار: بناء الصور، ونشر الحزم، والنشر إلى بيئات الاختبار أو التجريب أو الإنتاج، وحتى تغيير حركة المرور باستخدام استراتيجيات الأزرق والأخضر أو الكناري.
في الشركات التي لديها الكثير من التعليمات البرمجية القديمةتعتبر البنية التحتية الجيدة واحدة من أفضل الأدوات لتحديث النظام البيئي: فهي تسمح لك بإدخال الاختبارات في الخدمات القديمة، وأتمتة المهام التي كانت تتم يدويًا في السابق، وتقليل تكلفة صيانة البنى التحتية مثل Jenkins أو Nexus التي أصبحت قديمة.
ما هي GitHub Actions ولماذا تتناسب بشكل جيد مع CI/CD؟
GitHub Actions هي منصة الأتمتة المدمجة في GitHub. يُمكّنك هذا من تحديد مسارات العمل في ملفات YAML داخل المستودع نفسه. وباستخدامه، يمكنك تجميع برنامجك واختباره وتحليله ونشره دون الحاجة إلى إعداد خوادم تكامل مستمر خارجية.
سير العمل هو مجموعة من المهام والخطوات والذي يتم تحفيزه بواسطة أحداث مثل push, pull_request, schedule (كرون) workflow_dispatch (يدويًا) أو حتى إجراءات بشأن المشكلات. يتم تشغيل كل مهمة في برنامج تشغيل (على سبيل المثال، ubuntu-latestويتألف من خطوات تستخدم إجراءات أو أوامر قابلة لإعادة الاستخدام run.
يوفر GitHub سوقًا ضخمًا للأسهم حيث تتوفر لديك عمليات تكامل جاهزة لكل شيء تقريبًا: Docker، Kubernetes، AWS، Azure، Google Cloud، SonarCloud، Slack، Jira، تحليل الأمان، أدوات فحص الأخطاء لآلاف اللغات، إلخ. وهذا يقلل بشكل كبير من الوقت اللازم لإعداد خطوط الأنابيب المتقدمة.
بالمقارنة مع حلول مثل Jenkins أو Concourseتتمتع خدمة GitHub Actions بعدة مزايا واضحة: فهي خدمة مُدارة (لا تحتاج لإدارة الخوادم)، وترتبط ارتباطًا وثيقًا بالبرمجيات، وتعتمد نموذج الدفع حسب الاستخدام، وتحظى بدعم مجتمع ضخم. علاوة على ذلك، فإن العديد من المطورين على دراية بها من خلال مشاريعهم الشخصية، مما يُسهّل عملية تعلمها بشكل كبير.
المكونات الأساسية لسير عمل GitHub Actions
يبدأ كل شيء بملف YAML في .github/workflows/على سبيل المثال ci.yml o build-test-deploy.ymlعلى الرغم من أن التركيب النحوي يمكن أن ينمو بشكل كبير، إلا أن البنية الأساسية بسيطة نسبياً.
الأقسام الرئيسية في YAML هي: name (اسم سير العمل)، on (الأحداث التي تؤدي إلى حدوث ذلك)، jobs (مجموعة من المهام المنطقية)، وضمن كل مهمة، runs-on (عداء)، steps (خطوات)، env (المتغيرات العالمية) و if (شروط تنفيذ الخطوات أو المهام).
تمثل الوظائف مجموعات من العمل يمكن تشغيلها بالتوازي أو بالتسلسل باستخدام needsفي كل وظيفة، تستخدم الخطوات الإجراءات (uses:) أو الأوامر (run:يتضمن مثال نموذجي ما يلي: استخراج الكود، وتثبيت التبعيات، وتنفيذ أداة التحقق من الأخطاء، والاختبارات، والبناء.
الأسرار والمتغيرات البيئية تتم إدارتها على مستوى المستودع أو المؤسسة أو البيئة. وفي سير العمل، تتم الإشارة إليها باستخدام ${{ secrets.MI_SECRET }} ويتيح العمل مع مفاتيح واجهة برمجة التطبيقات أو رموز النشر أو بيانات اعتماد السحابة دون الكشف عنها في المستودع.
يسمح YAML أيضًا بإنشاء مصفوفات التنفيذ مع strategy.matrix، مفيد جدًا لاختبار التعليمات البرمجية الخاصة بك على إصدارات مختلفة من Node أو Python أو Java، أو حتى على أنظمة تشغيل مختلفة دون كتابة نفس الكتلة عدة مرات.
صمم مسار CI/CD حديث باستخدام أفضل الممارسات
عادةً ما يتم تقسيم خط الأنابيب السليم إلى مراحل واضحة: عمليات فحص سريعة (التحقق من الأخطاء، اختبارات الوحدة)، بناء المنتج، الإصدار (الإصدار، التسمية، سجل التغييرات، النشر في مستودع المنتج) والنشر في بيئة واحدة أو أكثر.
ينبغي أن تكون مرحلة التكامل المستمر بأسرع ما يمكن. يضمن هذا أن يتلقى أي طلب دفع أو سحب ردود فعل فورية تقريبًا. ومن الممارسات الشائعة تشغيل عمليات التحقق المختلفة بالتوازي باستخدام مصفوفات أو مهام منفصلة، مع افتراض تكلفة أعلى قليلاً مقابل تقليل وقت الانتظار الإجمالي.
لفصل خط الأنابيب عن اللغة الملموسةيمكنك استخدام أداة لإدارة المهام مثل Task (مشابهة لـ Make ولكن بصيغة أكثر سهولة في الاستخدام). بهذه الطريقة، لا يستدعي سير عمل GitHub Actions سوى المهام العامة (task test, task lintإلخ.) ويحدد كل مستودع كيفية تنفيذها داخليًا اعتمادًا على ما إذا كان Node أو Java أو Python، إلخ.
تُصبح إدارة الإصدارات والملفات ذات أهمية خلال مرحلة الإصدار.هنا يمكنك إنشاء صورة Docker، أو ملف jar/war، أو حزمة npm، أو أي عنصر آخر، ثم تحميله إلى السجل المناسب (سجل Docker، أو Maven، أو npm في سجل العناصر، إلخ)، ووضع علامات على عمليات الالتزام، وإنشاء إصدارات GitHub أو سجلات التغييرات باستخدام أدوات مثل git-cliff أو إجراءات الإفراج.
وأخيراً، مرحلة النشر انقل هذا العنصر إلى بيئة التشغيل: Kubernetes (GKE)، Google App Engine، Cloud Functions، الخدمات على Kinsta، خوادمك الخاصة عبر SSH، إلخ. هنا يمكنك ربط الخطوات اللاحقة، مثل الاختبارات الوظيفية بعد النشر أو إشعارات Slack بتفاصيل الإصدار.
مثال: مسار عمل كامل مع ESLint والاختبارات والنشر على Kinsta
ومن الأمثلة التوضيحية جداً استخدام GitHub Actions للتحقق من صحة تطبيق React باستخدام ESLint واختبارات الوحدة، ثم نشره على Kinsta باستخدام واجهة برمجة التطبيقات الخاصة بها. يتم تنسيق كل شيء في سير عمل CI/CD واحد.
يُحدد الجزء الأول من ملف YAML المُشغِّل واسم خط الأنابيب. على سبيل المثال، أنه يعمل على كل push y pull_request إلى الفرع mainوحتى جدولة المهام باستخدام وظائف CRON (على سبيل المثال، كل يوم في منتصف الليل أو كل يوم اثنين في الساعة 8:00 بالتوقيت العالمي المنسق) باستخدام الحدث schedule.
يمكن تسمية أول وظيفة في سلسلة التوريد eslint وهو مسؤول عن التحقق من بنية الكود. ويتم تشغيله في ubuntu-latest ويستخدم مجموعة من إصدارات Node (مثل 18.x و20.x)، مع خطوات لاستخراج وتكوين Node باستخدام actions/setup-nodeقم بتخزين تبعيات npm مؤقتًا، ثم قم بالتثبيت باستخدام npm ci ورمي npm run lint.
الوظيفة الثانية، testsالأمر يعتمد على eslint من خلال needs: eslintلذا، لا يتم تشغيله إلا إذا نجح فحص بناء الجملة. في الداخل، يتكرر النمط: استخراج الملفات، وتثبيت التبعيات، وتنفيذ... npm run test على إصدار محدد من Node.
الوظيفة الثالثة، deployيتم ربطها بعد كلتا الوظيفتين باستخدام needs: ويستخدم خطوة مع curl لاستدعاء واجهة برمجة تطبيقات Kinsta. وللقيام بذلك، يتم تكوين مفتاح واجهة برمجة التطبيقات ومعرّف التطبيق كأسرار في GitHub (KINSTA_API_KEY y APP_ID) ويتم عرضها في الوظيفة عبر env لإنشاء طلب POST الذي يؤدي إلى عملية النشر.
من المهم أن نفهم أن مهمة النشر هذه تعتبر Kinsta مجرد قبول واجهة برمجة التطبيقات (API) نجاحًا؛ ومع ذلك، إذا فشل النشر لاحقًا داخليًا في Kinsta، فقد يظل سير عمل GitHub يُظهر حالة جيدة. يجب مراعاة ذلك لتجنب التهاون واستكمال العملية بمراقبة ما بعد النشر.
إدارة متقدمة لجدولة المهام وسير العمل
صيغة CRON في GitHub Actions يعتمد هذا النظام على تنسيق يونكس ذي الحقول الخمسة: الدقيقة، الساعة، يوم الشهر، الشهر، ويوم الأسبوع. يمكن استخدام كل حقل من هذه الحقول. النجوم، والنطاقات، والقوائم، والخطوات (*, 1-5, 1,15,30, */5)، مما يسمح بجدولة مهام الصيانة، والنسخ الاحتياطية، والتنظيف، أو الفحوصات الدورية.
على سبيل المثال 0 0 * * * نفّذ سير العمل كل منتصف الليل (UTC)، بينما 0 8 * * 1 يحدث هذا كل يوم اثنين في تمام الساعة الثامنة. ويتكامل هذا بسلاسة مع المحفزات المعتادة لـ push y pull_requestبحيث يمكن لملف YAML نفسه أن يتفاعل مع كل من تغييرات التعليمات البرمجية وعمليات التنفيذ المجدولة.
تُعد هذه الإمكانية مثالية للمهام التي لا يُجدي إصدارها في كل عملية دمج.: عمليات فحص أمنية مكثفة (على سبيل المثال، باستخدام OWASP Dependency Check في Java)، وعمليات تدقيق التبعية، وفحوصات تغطية الاختبار، أو تنظيف العناصر القديمة في السجل.
إعادة استخدام سير العمل: توسيع نطاق التكامل المستمر/التسليم المستمر ليشمل مئات المستودعات
عندما يكون لدى مؤسستك عشرات أو مئات من المستودعاتنسخ ولصق نفس ملف YAML في كل مكان وصفة للفوضى. أي تغيير يتطلب تعديل نصف نظام GitHub Enterprise، مما يجعل الحفاظ على الاتساق وأفضل الممارسات شبه مستحيل.
يكمن الحل في تصميم سير عمل قابل لإعادة الاستخدام يتم مركزة في مستودع "قوالب" CI/CD. تعرض هذه العمليات المدخلات والمخرجات، ولا تحدد كل خدمة سوى ملف YAML صغير يستدعيها، مع تمرير معلمات مثل نوع العنصر (Docker، مكتبة Java، حزمة npm)، ووقت تشغيل النشر (GKE، GAE، وظيفة السحابة، إلخ) أو عناصر المهمة التي يجب تنفيذها.
يتمثل النمط الشائع في فصل ثلاث عمليات سير عمل كبيرة قابلة لإعادة الاستخدام: واحد من build-check-task (التكامل المستمر)، وهو أحد build-release-dockerfile أو غيرها من القطع الأثرية ونشر ثالث (deploy-gke, deploy-gaeإلخ)، بحيث يقوم كل مستودع ببناء خط أنابيبه من خلال الجمع بينها.
ولتغليف المنطق المشترك، يمكن أيضاً تعريف إجراءات مخصصة. en .github/actionsعلى سبيل المثال، لتكوين Gradle أو Java أو Node أو Task، وللحصول على بيانات تعريف البناء، ولنشر صور Docker، ولتحديد إصدارات Git باستخدام سكربت Bash، أو لإرسال إشعارات إلى Slack. القاعدة الأساسية هي أن تستخدم مستودعات الخدمات فقط سير العمل القابل لإعادة الاستخدام، وليس هذه الإجراءات مباشرةً، لضمان سهولة إدارة التوافق مع الإصدارات السابقة.
التكامل السريع والمستمر مع المهام والمصفوفات والتحليل الثابت
أثناء مرحلة البناء أو التحقق، يُنصح بتشغيل العديد من الأشياء بالتوازي.اختبارات الوحدة، والتحليل الثابت (PMD، وCheckstyle، وSpotBugs في Java؛ وESLint في JS/TS)، والمسح الضوئي باستخدام SonarCloud، وما إلى ذلك. هذا يحافظ على إجمالي وقت خط الأنابيب معقولًا حتى في قواعد البيانات الكبيرة.
تعمل المهمة (ملف المهمة.yml) كطبقة تجريدية بناءً على أوامر محددة، مما يسمح لسير عمل التكامل المستمر باستدعاء task check, task test o task lintبالنسبة لمشروع جافا، يمكن تفويض هذه المهام إلى Gradle باستخدام JUnit وPMD وCheckstyle وSpotBugs؛ أما بالنسبة لمشروع Node، فيمكن تفويضها إلى Jest وESLint وأدوات الأمان مثل npm audit أو مشابه.
تضيف GitHub Actions جزء المصفوفة لتشغيل نفس المهام على إصدارات مختلفة من وقت التشغيل: على سبيل المثال، اختبار مكتبة Node على الإصدارات 16 و18 و20، أو مشروع Python على الإصدارين 3.10 و3.12. الأمر بسيط للغاية، يكفي تعريف مصفوفة من الإصدارات واستخدامها في إعدادات المهمة.
يُعد هذا النهج مفيدًا بشكل خاص في المؤسسات التي ترغب في دعم مجموعات متعددة من البرامج. (Java، Node، TypeScript، Python، إلخ) دون الحاجة إلى إعادة كتابة منطق خط الأنابيب لكل مستودع: تتكيف المهمة مع كل لغة وتبقى سير العمل القابلة لإعادة الاستخدام كما هي تقريبًا.
مرحلة الإصدار: تحديد الإصدارات، ووضع العلامات، ونشر العناصر
بمجرد اجتياز الفحوصات، يحين وقت بناء العنصر الذي سيتم نشره فعليًا.صورة Docker، ملف JAR، حزمة npm، أيًا كان المناسب. يشمل ذلك أدوات اللغة وسجلات المؤسسة وسياسة التحكم في الإصدارات.
تستخدم بعض مشاريع جافا إضافات مثل Gradle Axion. لإدارة الإصدارات بناءً على علامات Git. في السياقات المختلطة (Java، Node، إلخ)، قد يكون من الأسهل استخدام سكربت Bash مخصص يقوم بحساب الإصدار التالي (باستخدام SemVer على سبيل المثال)، وإنشاء العلامة، ودفعها إلى المستودع البعيد، وإنشاء الإصدار المقابل.
أدوات مثل git-cliff فهي تساعد في إنشاء سجلات التغييرات استنادًا إلى رسائل الالتزام، تُصنّف التغييرات حسب نوعها (ميزة، إصلاح، تغيير جذري، إلخ). ويضمن دمجها في مسار العمل أن يأتي كل إصدار بسجل تغييرات واضح دون الحاجة إلى كتابته يدويًا.
لنشر القطع الأثرية، يتم الجمع بين الإجراءات المناسبة وبيانات الاعتماد.سجلات Docker (Docker Hub، وGitHub Container Registry، وArtifact Registry)، ومستودعات Maven، وسجلات npm، وما إلى ذلك. مرة أخرى، يتم تخزين بيانات الاعتماد كأسرار ويتم إدخالها في المهام فقط عند الحاجة.
النشر المستمر على Kubernetes وGCP وKinsta وبيئات أخرى
النشر هو المرحلة التي يتفاعل فيها نظام التكامل المستمر/التسليم المستمر مع البنية التحتيةهنا، تتكامل GitHub Actions بسلاسة مع أي منصة تقريبًا: Kubernetes، وApp Engine، وCloud Functions، والخوادم التقليدية، ومنصات مثل Kinsta، وما إلى ذلك.
بالنسبة لـ Kubernetes (على سبيل المثال في GKE) النمط المعتاد وهي: المصادقة مع Google Cloud (باستخدام الإجراءات الرسمية)، والتكوين kubectl في سياق المجموعة، قم بتطبيق بيانات Helm أو مخططاتها، وإذا لزم الأمر، قم بتنفيذ نشر مُتحكم به (على سبيل المثال، باستخدام Canary أو Blue-Green) وتحقق من الحالة باستخدام الأوامر من kubectl rollout status.
في حالة App Engine أو Cloud Functionsتقوم هذه العملية ببناء الصورة أو العنصر، ونشره في سجل العناصر، ثم تستدعي أوامر النشر. gcloud مناسب، باستخدام بيانات اعتماد مُدارة مثل الأسرار والمشغلين المؤقتين.
عند تنفيذ عملية النشر باستخدام واجهات برمجة تطبيقات خارجية مثل Kinstaعادة ما تكون خطوة من curl أو إجراء متخصص يرسل الطلب مع رمز المصادقة والمعلمات اللازمة (معرّف التطبيق، الفرع، إلخ). تُعتبر المهمة ناجحة إذا استجابت واجهة برمجة التطبيقات بشكل صحيح لطلب الإصدار الجديد.
عادةً ما يصاحب عملية النشر إشعار. إلى Slack أو Teams أو أدوات التواصل الأخرى، مع توضيح الخدمة التي تم نشرها، والبيئة المستخدمة، والإصدار المستخدم، والجهة التي قامت بتشغيلها، وروابط سجلات سير العمل. في بيئة الإنتاج، يُستخدم هذا أيضًا لأغراض التدقيق والتتبع.
مراقبة الجودة: الأمن والمراقبة والسجلات
أتمتة عمليات البناء والنشر أمر رائع، ولكن بدون رؤية واضحة. فيما يتعلق بما يحدث، قد يصبح مسار العمل غامضًا. يوفر GitHub Actions سجلات مفصلة حسب التنفيذ، وحسب المهمة، وحسب الخطوة، مما يسمح لك بتشخيص حالات فشل التجميع أو الاختبار أو النشر.
ولتلبية الاحتياجات الأكثر تقدماً، يتم دمج خدمات المراقبة الخارجية. مثل Datadog أو New Relic أو Splunk، التي تجمع مقاييس حول سير العمل وأوقات التنفيذ ومعدلات الفشل وما إلى ذلك، مما يساعد على اكتشاف الاختناقات وتحديد أولويات تحسينات خط الأنابيب.
وفي الوقت نفسه، يلعب الأمن دورًا رئيسيًا: إدارة الأسرار المشفرة، وسياسات الوصول الضرورية الدنيا، ومراجعة أذونات الإجراءات، ودمج ماسحات ثغرات التعليمات البرمجية والتبعيات (مسح التعليمات البرمجية، ومسح الأسرار، وOWASP، وما إلى ذلك) ضمن سير العمل نفسه.
كما تضيف العديد من الفرق اختبارات ما بعد النشر في البيئة المحدثة حديثًا: اختبارات وظيفية شاملة، وفحوصات الأداء، واختبارات التحقق الأساسية، وإذا حدث خطأ ما، آليات التراجع التلقائي التي تستعيد الإصدار المستقر السابق.
إدارة سير العمل: الفروع المحمية وطلبات السحب
يجب أن تتوافق طريقة العمل مع الفروع وطلبات السحب مع التكامل المستمر/التسليم المستمر (CI/CD). حتى يكون كل شيء منطقيًا. وأكثر الأمور شيوعًا هو حماية الفرع الرئيسي (main o master) ويشترط أن يمر أي تغيير عبر طلب السحب وأن يجتاز فحوصات خط الأنابيب.
يتيح لك GitHub تحديد قواعد حماية الفروع تُلزم هذه السياسات باستخدام طلبات السحب، وتمنع عمليات الإيداع المباشر، وتشترط أن تكون بعض فحوصات الحالة (سير عمل إجراءات محددة) ناجحة قبل السماح بالدمج. وقد تتطلب أيضًا حدًا أدنى من المراجعات، وقواعد موافقة، وما إلى ذلك.
يضمن هذا النموذج أن الكود الذي يصل إلى مرحلة الإنتاج لقد اجتازت المراجعة البشرية وجميع عمليات فحص خط الأنابيب الآلية، مما يقلل بشكل كبير من خطر التسلل عبر الأخطاء أو الثغرات الأمنية الخطيرة.
في الشركات ذات البيئات المتعددة (التطوير، والتجريب، والإنتاج) عادةً ما يتم تخصيص النشر إلى بيئة الإنتاج لعمليات الدمج في الفرع الرئيسي، في حين أن الفروع الأخرى قد تؤدي إلى عمليات نشر إلى بيئات سابقة للاختبار الداخلي أو العروض التوضيحية.
بالنظر إلى الصورة الكبيرة، فإن خط أنابيب التكامل المستمر/التسليم المستمر المصمم جيدًا مع GitHub Actions يُصبح هذا النظام بمثابة العمود الفقري لعملية التطوير: دمج التغييرات، وإجراء اختبارات شاملة، وبناء ونشر المُخرجات البرمجية، والنشر على منصات سحابية متعددة، والمراقبة باستخدام أدوات المراقبة، والحوكمة من خلال قواعد واضحة للتفرع وطلبات السحب. بفضل سير العمل القابل لإعادة الاستخدام، والإجراءات المُخصصة، والأدوات المساعدة مثل Task وRease Action وGit Cliff، وإدارة الصلاحيات والأسرار القوية، يُمكن دعم كل شيء بدءًا من تطبيقات بايثون البسيطة وصولًا إلى بنى Kubernetes المعقدة، مع الحفاظ على سرعة التسليم وجودة الكود والأمان دون إرهاق الفريق بمهام يدوية.
