كيف يقوم GitHub Actions بأتمتة مهام التطوير؟

مكتمل

نقدم هنا إجراءات GitHub ومهام سير العمل. يمكنك معرفة أنواع الإجراءات التي يمكنك استخدامها ومكان العثور عليها. يمكنك أيضا إلقاء نظرة على أمثلة على هذه الأنواع من الإجراءات وكيفية احتواؤها في سير العمل.

يقلل GitHub الوقت من مرحلة الفكرة إلى مرحلة النشر

تم تصميم GitHub لمساعدة فرق المطورين ومهندسي DevOps على إعداد التطبيقات ونشرها بسرعة. هناك العديد من الميزات في GitHub التي تمكن هذه الكفاءات، ولكنها تندرج عموما في إحدى فئتين:

• الاتصال: ضع في اعتبارك جميع الطرق التي تجعل GitHub من السهل على فريق من المطورين التواصل حول مشروع تطوير البرامج: استعراض التعليمة البرمجية في طلبات السحب، ومشكلات GitHub، ولوحات المشروع، ومواقع wikis، والإشعارات، وما إلى ذلك.
• التلقائية: تتيح GitHub Actions لفريقك تلقائية مهام سير العمل في كل خطوة في عملية معالجة البرامج، من التكامل إلى التسليم إلى التوزيع. حتى أنه يتيح لك أتمتة إضافة الملصقات لطلبات السحب وفحص المشكلات وطلبات السحب القديمة.

عند الجمع بين هذه الميزات، سمحت للآلاف من فرق التطوير بإنقاص مقدار الوقت المستغرق من الفكرة الأولية إلى التوزيع بشكل فعال.

استخدم أتمتة سير العمل لتقليل وقت التطوير

في هذه الوحدة النمطية، نركز على الأتمتة. لنأخذ لحظة لفهم كيف يمكن للفرق استخدام الأتمتة لتقليل مقدار الوقت الذي يستغرقه إكمال سير عمل التطوير والتوزيع النموذجي.

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

• تأكد من أن التعليمات البرمجية تجتاز جميع اختبارات الوحدة.
• قم بإجراء فحوصات جودة التعليمات البرمجية والامتثال للتأكد من أن التعليمات البرمجية المصدر تفي بمعايير المؤسسة.
• تحقق من التعليمات البرمجية وتبعياتها بحثا عن مشكلات الأمان المعروفة.
• إنشاء التعليمات البرمجية عن طريق دمج التعليمات البرمجية المصدر الجديدة من (يحتمل) مساهمين متعددين.
• تأكد من اجتياز البرنامج لاختبارات التكامل.
• حدد إصدار الإصدار الجديد.
• تسليم الثنائيات الجديدة إلى موقع نظام الملفات المناسب.
• نشر الثنائيات الجديدة إلى خادم واحد أو أكثر.
• حدد ما إذا كانت أي من هذه المهام لا تمر، وقم بالإبلاغ عن المشكلة إلى الشخص المناسب أو الفريق المناسب لحلها.

التحدي هو القيام بهذه المهام بشكل موثوق ومتسق ومستدام. هذه العملية هي وظيفة مثالية لأتمتة سير العمل. إذا كنت تعتمد بالفعل على GitHub، فقد ترغب في إعداد أتمتة سير العمل باستخدام إجراءات GitHub.

ما هو GitHub Actions؟

GitHub Actions هي برامج نصية مجمعة لأتمتة المهام في سير عمل تطوير البرامج في GitHub. يمكنك تكوين إجراءات GitHub لتشغيل مهام سير العمل المعقدة التي تلبي احتياجات مؤسستك. يمكن أن يحدث المشغل في كل مرة يتحقق فيها المطورون من التعليمات البرمجية المصدر الجديدة في فرع معين، أو على فترات زمنية محددة، أو يدويا. والنتيجة هي سير عمل مؤتمت موثوق ومستدام يؤدي إلى انخفاض كبير في وقت التطوير.

أين يمكنك العثور على GitHub Actions؟

GitHub Actions هو برامج نصية تلتزم بتنسيق بيانات yml. يحتوي كل مستودع على علامة التبويب "Actions" التي توفر طريقة سريعة وسهلة للبدء في إعداد برنامجك النصي الأول. إذا رأيت سير عمل تعتقد أنه قد يكون نقطة بداية رائعة، فما عليك سوى تحديد الزر Configure لإضافة البرنامج النصي والبدء في تحرير ملف المصدر yml.

ومع ذلك، بخلاف GitHub Actions المميزة في علامة تبويب Actions، يمكنك:

• البحث عن GitHub Actions في GitHub Marketplace. يتيح لك GitHub Marketplace اكتشاف الأدوات التي تعمل على توسيع سير عملك وشراءها.
• ابحث عن مشاريع مفتوحة المصدر. مثال، تتميز مؤسسة GitHub Actions بالعديد من عمليات إعادة الشراء الشائعة مفتوحة المصدر التي تحتوي على GitHub Actions الذي يمكنك استخدامه.
• اكتب GitHub Actions الخاصة بك من البداية. يمكنك جعلها مصدر مفتوح، أو حتى نشرها إلى GitHub Marketplace.

استخدام إجراءات GitHub مفتوحة المصدر

العديد من إجراءات GitHub مفتوحة المصدر ومتاحة لأي شخص يريد استخدامها. ومع ذلك، تماما كما هو الحال مع أي برنامج مفتوح المصدر، تحتاج إلى التحقق منها بعناية قبل استخدامها في مشروعك. على غرار معايير المجتمع الموصى بها مع البرامج مفتوحة المصدر مثل تضمين README، ومدونة السلوك، والملف المساهم، وقوالب الإصدار، يمكنك اتباع هذه التوصيات عند استخدام إجراءات GitHub:

• راجع ملف action.yml الإجراء فيما يتعلق بالمدخلات والمخرجات والتأكد من أن التعليمة البرمجية تنفذ ما تقول أنها تنفذه.
• تحقق مما إذا كان الإجراء في سوق GitHub. هذا الفحص جدير بالاهتمام، حتى إذا لم يكن هناك إجراء يجب أن يكون على GitHub Marketplace ليكون صالحا.
• تحقق مما إذا تم التحقق من الإجراء في سوق GitHub. يعني التحقق أن GitHub وافق على استخدام هذا الإجراء. ومع ذلك، ما زال واجباً عليك مراجعته قبل استخدامه.
• بادر بتضمين إصدار الإجراء الذي تستخدمه بتحديد مرجع Git أو SHA أو علامة.

أنواع إجراءات GitHub

هناك ثلاثة أنواع من إجراءات GitHub: إجراءات الحاوية وإجراءات JavaScript والإجراءات المركبة.

تصبح البيئة جزءاً من التعليمة البرمجية للإجراء باستخدام إجراءات الحاوية. لا يمكن تشغيل هذه الإجراءات إلا في بيئة Linux التي يستضيفها GitHub. تدعم إجراءات الحاويات العديد من اللغات المختلفة.

لا تعمل إجراءات JavaScript على تضمين البيئة في التعليمة البرمجية. يجب عليك تحديد البيئة لتنفيذ هذه الإجراءات. يمكنك تشغيل هذه الإجراءات في جهاز ظاهري (جهاز ظاهري) في السحابة أو محليا. تدعم إجراءات JavaScript بيئات Linux وmacOS وWindows.

تسمح لك الإجراءات المركبة بدمج خطوات سير عمل متعددة ضمن إجراء واحد. على سبيل المثال، يمكنك استخدام هذه الميزة لتجميع أوامر تشغيل متعددة معا في إجراء، ثم الحصول على سير عمل ينفذ الأوامر المجمعة كخطوة واحدة باستخدام هذا الإجراء.

تحليل إجراء GitHub

فيما يلي مثال على الإجراء الذي يقوم بتنفيذ git checkout للمستودع. هذا الإجراء، actions/checkout@v1، هو جزء من خطوة في سير العمل. تنشئ هذه الخطوة أيضاً التعليمة البرمجية Node.js التي تم التحقق منها. سنتحدث عن مهام سير العمل والوظائف والخطوات في القسم التالي.

steps:
  - uses: actions/checkout@v1
  - name: npm install and build webpack
    run: |
      npm install
      npm run build

افترض أنك تريد استخدام إجراء حاوية لتشغيل التعليمة البرمجية المُعبئة في حاوية. قد يبدو عملك مثل هذا:

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
    MY_NAME:
      description: "Who to greet"
      required: true
      default: "World"

runs:
    uses: "docker"
    image: "Dockerfile"

branding:
    icon: "mic"
    color: "purple"

لاحظ قسم inputs. هنا، تحصل على قيمة متغير يسمى MY_NAME. يتم تعيين هذا المتغير في سير العمل الذي يقوم بتشغيل هذا الإجراء.

في قسم runs، لاحظ أنك تحدد docker في سمة uses. عند تعيين هذه القيمة، تحتاج إلى توفير المسار إلى ملف صورة Docker. في هذه الحالة، Dockerfile. نحن لا نتناول تفاصيل Docker هنا، ولكن إذا كنت ترغب في مزيد من المعلومات، فراجع الوحدة النمطية مقدمة إلى حاويات Docker .

يخصص القسم الأخير العلامة التجارية عملك في GitHub Marketplace إذا قررت نشره هناك.

يمكنك العثور على قائمة كاملة من بيانات تعريف الإجراءات على بنية بيانات التعريف لـ GitHub Actions.

ما سير عمل GitHub Actions؟

سير عمل GitHub Actions هو عملية تقوم بإعدادها في مستودعك تلقائياً لمهام دورة حياة تطوير البرامج، بما في ذلك GitHub Actions. باستخدام سير العمل، يمكنك إعداد أي مشروع واختباره وحزمه وإصداره وتوزيعه على GitHub.

لإنشاء سير عمل، يمكنك إضافة إجراءات إلى ملف .yml في دليل .github/workflows بمستودع GitHub الخاص بك.

في التمرين القادم، يبدو ملف سير العمل الخاص بك main.yml مثل هذا المثال:

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ./action-a
      with:
        MY_NAME: "Mona"

لاحظ السمة on: ، قيمتها هي مشغل لتحديد وقت تشغيل سير العمل هذا. هنا، يتم التشغيل عندما يكون هناك حدث منبثق في مستودعك. يمكنك تحديد أحداث فردية مثل on: push، أو صفيف من الأحداث مثل on: [push, pull_request]، أو خريطة تكوين الحدث التي تقوم بجدولة سير العمل أو تقيد تنفيذ سير العمل بملفات أو علامات أو تغييرات لإصدار فرعي معينة. قد تبدو الخريطة بهذا الشكل:

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration doesn't affect the page_build event above
      - created

يتم تشغيل الحدث على كافة أنواع الأنشطة للحدث ما لم تحدد النوع أو الأنواع. للحصول على قائمة شاملة بالأحداث وأنواع أنشطتها، راجع ما يلي: أحداث تُشغل سير العمل في وثائق GitHub.

يجب أن يحتوي سير العمل على مهمة واحدة على الأقل. الوظيفة هي قسم من سير العمل المقترن بمشغل. يمكن أن يكون المشغل مستضافاً على GitHub أو مستضافاً ذاتياً، ويمكن تشغيل الوظيفة على جهاز أو في حاوية. يمكنك تحديد المشغل مع السمة runs-on: . هنا، أنت تخبر سير العمل بتشغيل هذه المهمة على ubuntu-latest.

كل مهمة لديها خطوات لإكمالها. في مثالنا، هذه الخطوة تستخدم الإجراء actions/checkout@v1 للتحقق من المستودع. المثير للاهتمام هو القيمة uses: ./action-a وهو المسار إلى إجراء الحاوية التي تبنيها في ملف action.yml.

يعين MY_NAME الجزء الأخير من ملف سير العمل هذا قيمة المتغير لسير العمل هذا. استدعاء إجراء الحاوية اتخذ إدخالا يسمى MY_NAME.

لمزيد من المعلومات عن بناء جملة سير العمل، راجع بناء جملة سير العمل لـ GitHub Actions

الرجوع إلى الإجراءات في مهام سير العمل

عند إنشاء مهام سير العمل في GitHub Actions، يمكنك الرجوع إلى الإجراءات من مصادر مختلفة. يمكن استخدام هذه الإجراءات لأتمتة المهام في مهام سير العمل الخاصة بك. فيما يلي المصادر الأساسية حيث يمكن لمهام سير العمل الرجوع إلى الإجراءات:

1. صورة حاوية Docker منشورة على Docker Hub
   يمكن أن تشير مهام سير العمل إلى الإجراءات التي يتم نشرها كصور حاوية Docker على Docker Hub. يتم تخزين هذه الإجراءات في حاويات وتتضمن جميع التبعيات المطلوبة لتنفيذ الإجراء. لاستخدام مثل هذا الإجراء، يمكنك تحديد صورة Docker في سمة uses خطوة سير العمل. على سبيل المثال:

   steps:
     - name: Run a Docker action
       uses: docker://<docker-image-name>:<tag>
   

2. أي مستودع عام
   يمكن الرجوع إلى الإجراءات المستضافة في المستودعات العامة مباشرة في مهام سير العمل الخاصة بك. يمكن لأي شخص الوصول إلى هذه الإجراءات ويمكن استخدامها عن طريق تحديد اسم المستودع وإصداره (Git ref أو SHA أو العلامة) في السمة uses . على سبيل المثال:

   steps:
     - name: Use a public action
       uses: actions/checkout@v3
   

[مهم!]

للحصول على أمان أفضل، استخدم التزام كامل SHA عند الإشارة إلى الإجراءات - وليس مجرد علامة مثل @v3.
يضمن ذلك أن سير العمل يستخدم دائما نفس التعليمات البرمجية بالضبط، حتى إذا تم تحديث الإجراء أو تغييره لاحقا.
مثال: uses: actions/checkout@c2c1744e079e0dd11c8e0af4a96064ca4f6a2e9e

3. نفس المستودع مثل ملف سير العمل الخاص بك
   يمكنك الرجوع إلى الإجراءات المخزنة في نفس المستودع مثل ملف سير العمل. هذه الميزة مفيدة للإجراءات المخصصة الخاصة بمشروعك. للإشارة إلى مثل هذه الإجراءات، استخدم مسارا نسبيا إلى دليل الإجراء. على سبيل المثال:

   steps:
     - name: Use a local action
       uses: ./path-to-action
   

لمزيد من التفاصيل، راجع إرشادات تقوية الأمان لإجراءات GitHub.

4. سوق المؤسسة
   إذا كانت مؤسستك تستخدم GitHub Enterprise، يمكنك الرجوع إلى الإجراءات من السوق الخاص لمؤسستك. يتم تنظيم هذه الإجراءات وإدارتها من قبل مؤسستك، مما يضمن الامتثال للمعايير الداخلية. على سبيل المثال:

   steps:
     - name: Use an enterprise marketplace action
       uses: enterprise-org/action-name@v1
   

Note

• يمكن أيضا الرجوع إلى الإجراءات في المستودعات الخاصة، ولكنها تتطلب مصادقة وأذونات مناسبة.
• عند الرجوع إلى الإجراءات، حدد دائما إصدارا (Git ref أو SHA أو علامة) لضمان الاتساق وتجنب التغييرات غير المتوقعة.

لمزيد من المعلومات، راجع الرجوع إلى الإجراءات في مهام سير العمل.

المشغلون الذين تستضيفهم GitHub مقابل المشغلين ذوي الاستضافة الذاتية

ذكرنا بإيجاز المشغلين على أنهم مرتبطون بوظيفة. المشغل هو مجرد خادم يحتوي على تطبيق مشغل إجراءات GitHub المثبتة. في مثال سير العمل السابق، كانت هناك سمة runs-on: ubuntu-latest داخل كتلة الوظائف، والتي أخبرت سير العمل أن المهمة ستعمل باستخدام المشغل المستضاف على GitHub الذي يعمل في ubuntu-latest البيئة.

عندما يتعلق الأمر بالعدائيين، هناك خياران للاختيار من بينهما: المشغلون المستضافون على GitHub أو المشغلون المستضافون ذاتيا. إذا كنت تستخدم مشغلا مستضافا على GitHub، يتم تشغيل كل مهمة في مثيل جديد لبيئة ظاهرية. نوع المشغل المستضاف على GitHub الذي تحدده، runs-on: {operating system-version} ثم يحدد تلك البيئة. أما بالنسبة للمشغلين ذوي الاستضافة الذاتية، ستحتاج إلى تطبيق التسمية ذات الاستضافة الذاتية ونظام التشغيل الخاص بها وبنية النظام. على سبيل المثال، سيبدو المشغل المستضاف ذاتيا مع نظام تشغيل Linux وبنية ARM32 مثل المواصفات التالية: runs-on: [self-hosted, linux, ARM32].

كل نوع من المشغلين له فوائده، ولكن المشغلين المستضافين على GitHub يقدمون طريقة أسرع وأبسط لتشغيل مهام سير العمل الخاصة بك، وإن كان ذلك مع خيارات محدودة. يمثل المشغلون ذوو الاستضافة الذاتية طريقة أعلى من حيث قابلية التكوين لتشغيل مهام سير العمل في بيئتك المحلية المخصصة. يمكنك تشغيل المشغلات المستضافة ذاتيا محليا أو في السحابة. يمكنك أيضا استخدام المشغلات المستضافة ذاتيا لإنشاء تكوين أجهزة مخصص بمزيد من طاقة المعالجة أو الذاكرة. يساعد هذا النوع من التكوين على تشغيل مهام أكبر وتثبيت البرامج المتوفرة على شبكتك المحلية واختيار نظام تشغيل لا يقدمه المشغلون المستضافون على GitHub.

يمكن أن يكون لإجراءات GitHub حدود استخدام

لدى GitHub Actions بعض حدود الاستخدام، اعتمادا على خطة GitHub وما إذا كان المشغل الخاص بك مستضافا على GitHub أو مستضافا ذاتيا. للاطلاع على المزيد من المعلومات حول حدود الاستخدام، راجع حدود الاستخدام والفوترة والإدارة في وثائق Github.

مشغلات GitHub المستضافة أكبر

يوفر GitHub مشغلات أكبر لمهام سير العمل التي تتطلب المزيد من الموارد. هذه المشغلات مستضافة على GitHub وتوفر زيادة في وحدة المعالجة المركزية والذاكرة ومساحة القرص مقارنة بمشغلات قياسية. وهي مصممة للتعامل مع مهام سير العمل كثيفة الموارد بكفاءة، ما يضمن الأداء الأمثل للمهام المطلوبة.

أحجام المشغلات وتسمياتها

تتوفر المشغلات الأكبر في تكوينات متعددة، ما يوفر وحدات vCPUs المحسنة وذاكرة الوصول العشوائي وتخزين SSD لتلبية متطلبات سير العمل المتنوعة. هذه التكوينات مثالية لسيناريوهات مثل:

• تجميع قواعد التعليمات البرمجية الكبيرة مع ملفات مصدر شاملة.
• تشغيل مجموعات اختبار شاملة، بما في ذلك التكامل والاختبارات الشاملة.
• معالجة مجموعات البيانات الكبيرة لتحليل البيانات أو مهام التعلم الآلي.
• إنشاء تطبيقات ذات تبعيات معقدة أو مخرجات ثنائية كبيرة.
• إجراء عمليات محاكاة عالية الأداء أو نمذجة حسابية.
• تنفيذ ترميز الفيديو أو العرض أو مهام سير عمل معالجة الوسائط المتعددة الأخرى.

لاستخدام مشغل أكبر، حدد تسمية المشغل المطلوبة في سمة runs-on ملف سير العمل. على سبيل المثال، لاستخدام مشغل مع 16 vCPUs و64 غيغابايت من ذاكرة الوصول العشوائي، يمكنك تعيين runs-on: ubuntu-latest-16core.

jobs:
  build:
    runs-on: ubuntu-latest-16core
    steps:
      - uses: actions/checkout@v2
      - name: Build project
        run: make build

تحافظ هذه المشغلات الأكبر حجما على التوافق مع مهام سير العمل الحالية من خلال تضمين نفس الأدوات المثبتة مسبقا مثل المشغلات القياسية ubuntu-latest .

لمزيد من المعلومات حول أحجام المشغلات للمشغلين الأكبر حجما، راجع وثائق GitHub

إدارة المشغلات الأكبر حجما

يوفر GitHub أدوات لإدارة المشغلين الأكبر حجما بفعالية، ما يضمن الاستخدام الأمثل للموارد وإدارة التكلفة. فيما يلي بعض الجوانب الرئيسية لإدارة المشغلين الأكبر حجما:

مراقبة الاستخدام

يمكنك مراقبة استخدام المشغلات الأكبر من خلال صفحة استخدام إجراءات GitHub في إعدادات المستودع أو المؤسسة. توفر هذه الصفحة رؤى حول عدد المهام التي يتم تشغيلها، وإجمالي وقت التشغيل، والتكاليف المرتبطة بها.

إدارة الوصول

للتحكم في الوصول إلى المشغلات الأكبر حجما، يمكنك تكوين نهج المستودع أو على مستوى المؤسسة. يضمن هذا التكوين أن مهام سير العمل أو الفرق المعتمدة فقط يمكنها استخدام مشغلات الموارد العالية هذه.

إدارة التكلفة

تتحمل المشغلات الأكبر تكاليف إضافية بناء على استخدامها. لإدارة التكاليف، ضع في اعتبارك الاقتراحات التالية:

• استخدم المشغلات الأكبر فقط لسير العمل الذي يتطلب موارد عالية.
• تقليل وقت التشغيل عن طريق تحسين مهام سير العمل.
• مراقبة تفاصيل الفوترة بانتظام لتتبع النفقات.

تحجيم مهام سير العمل

إذا كانت مهام سير العمل تتطلب استخداما متكررا للمشغلين الأكبر حجما، ففكر في استراتيجيات التحجيم مثل:

• استخدام المشغلات المستضافة ذاتيا لأحمال العمل التي يمكن التنبؤ بها.
• تقسيم مهام سير العمل إلى وظائف أصغر لتوزيع الحمل عبر المشغلات القياسية.