إدارة الإجراءات ومهام سير العمل

مكتمل

هنا، ستستكشف الأدوات والاستراتيجيات المختلفة المتاحة لك في GitHub Enterprise Cloud وGitHub Enterprise Server من أجل مشاركة إجراءات GitHub ومهام سير العمل وإدارة استخدامها داخل مؤسستك.

يتم تنظيم المحتوى حول المستوى الذي تتوفر فيه الأدوات المعروضة: مستوى المؤسسة أو المستوى التنظيمي.

على مستوى المؤسسة

تكوين نهج استخدام GitHub Actions

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

لديك العديد من الخيارات في Enterprise Cloud لتكوين نهج، وكذلك في Enterprise Server إذا تم تمكين GitHub Connect في إعدادات المؤسسة.

لتكوين نهج استخدام GitHub Actions لمؤسستك، انتقل إلى حساب المؤسسة ثم إلى Policies > Actions في الشريط الجانبي. يجب أن تظهر الخيارات التالية.

تتيح لك القائمة المنسدلة في الأعلى المسماة تمكين لجميع المؤسسات إمكانية تحديد أي مؤسسات يمكنها استخدام GitHub Actions (جميعها أم بعضها أم ولا واحدة منها)، بينما تمكنك الخيارات الثلاثة الموجودة أسفلها من تحديد مستوى تقييد GitHub Actions داخل هذه المؤسسات.

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

مزامنة الإجراءات العامة يدوياً لـ Enterprise Server

تأتي معظم الإجراءات الرسمية التي تم تأليفها بواسطة GitHub مجمعة تلقائيا مع Enterprise Server، ويتم التقاطها في نقطة زمنية من GitHub Marketplace. وهي تشمل actions/checkout، actions/upload-artifactو actions/download-artifact، actions/labelerو، و، وإجراءات مختلفة actions/setup- ، من بين إجراءات أخرى. للحصول على جميع الإجراءات الرسمية المضمنة في مثيل المؤسسة، استعرض للوصول إلى مؤسسة الإجراءات على المثيل الخاص بك: https://HOSTNAME/actions.

كما هو مذكور في قسم تكوين نهج استخدام إجراءات GitHub، من الممكن تكوين Enterprise Server للوصول تلقائيا إلى الإجراءات العامة المتوفرة في GitHub Marketplace وتكوين نهج استخدام لهم. ومع ذلك، إذا كنت تريد تحكما أكثر صرامة في الإجراءات العامة التي يجب توفيرها في مؤسستك، يمكنك تنزيل الإجراءات ومزامنتها يدويا في مثيل المؤسسة باستخدام actions-sync الأداة.

على المستوى التنظيمي

توثيق معايير الشركة

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

كأفضل ممارسة، من المستحسن توثيق ما يلي في GitHub wiki أو كملف markdown في مستودع يمكن للجميع الوصول إليه داخل المؤسسة:

• مستودعات للتخزين
• اصطلاحات تسمية الملفات/المجلدات
• موقع المكونات المشتركة
• خطط الصيانة المستمرة
• إرشادات المساهمة

إنشاء قوالب مهام سير العمل

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

يتم إنشاء قالب سير عمل على خطوتين:

1. إنشاء ملف سير عمل yml.

2. إنشاء ملف بيانات تعريف json يصف كيفية تقديم القالب للمستخدمين عند إنشاء سير عمل.

   إشعار

   يجب أن يكون ملف بيانات التعريف له نفس اسم ملف سير العمل. بدلا من ملحق .yml، يجب إلحاقه .properties.json. على سبيل المثال، يحتوي ملف يسمى octo-organization-ci.properties.json على بيانات التعريف لملف سير العمل المسمى octo-organization-ci.yml.

يجب وضع كلا الملفين في مستودع .github عام وفي دليل يسمى قوالب سير العمل. قد تضطر إلى إنشاء كل منهما إذا لم يكونا موجودين بالفعل في مؤسستك.

فيما يلي مثال على ملف سير عمل أساسي:

name: Octo Organization CI

on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Run a one-line script
        run: echo Hello from Octo Organization

لاحظ أن الملف السابق يستخدم عنصر نائب $default فرع. عند إنشاء سير العمل باستخدام القالب، يتم استبدال هذا العنصر النائب تلقائياً باسم الإصدار الفرعي الافتراضي للمستودع.

فيما يلي ملف بيانات التعريف الذي ستقوم بإنشائه لملف سير العمل:

{
    "name": "Octo Organization Workflow",
    "description": "Octo Organization CI workflow template.",
    "iconName": "example-icon",
    "categories": [
        "Go"
    ],
    "filePatterns": [
        "package.json$",
        "^Dockerfile",
        ".*\\.md$"
    ]
}

تستخدم ملفات بيانات التعريف المعلمات التالية:

المعلمة	الوصف	مطلوب
الاسم	اسم قالب سير العمل المعروض في قائمة القوالب المتوفرة.	‏‏نعم‬
الوصف	وصف قالب سير العمل المعروض في قائمة القوالب المتوفرة.	‏‏نعم‬
iconName	تعريف رمز إدخال سير العمل في قائمة القوالب. يجب أن تكون أيقونة SVG بنفس الاسم، ويجب تخزينها في دليل قوالب سير العمل. على سبيل المثال، تتم الإشارة إلى ملف SVG المسمى example-icon.svg كأيقونة المثال.	لا
categories	تعريف فئة اللغة لسير العمل. عندما يعرض مستخدم ما القوالب المتوفرة، سيتم تمييز القوالب التي تطابق نفس اللغة بشكل أكثر وضوحاً.	لا
قوالب الملفات	تمكين القالب لاستخدامه إذا كان مستودع المستخدم يحتوي على ملف يطابق تعبير عادي معرف في الدليل الجذر.	لا

بمجرد إنشاء قالب سير عمل، يمكن للمستخدمين في مؤسستك العثور عليه ضمن Actions > New workflow > Workflows created by _your_organization_name.

قوالب قابلة لإعادة الاستخدام للإجراءات ومهام سير العمل

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

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

أنواع القوالب القابلة لإعادة الاستخدام

نوع القالب	الغرض	Example
مهام سير العمل القابلة لإعادة الاستخدام	توحيد البنية الأساسية لبرنامج ربط العمليات التجارية CI/CD عبر المستودعات.	ci-pipeline.yml، deploy-app.yml
الإجراءات القابلة لإعادة الاستخدام	تغليف منطق التشغيل التلقائي الشائع.	setup-env-action، security-scan-action
قوالب سير العمل	تحديد بنيات الوظائف القابلة لإعادة الاستخدام.	test-job.yml، build-job.yml

مهام سير العمل القابلة لإعادة الاستخدام

سير العمل القابل لإعادة الاستخدام هو سير عمل محدد في مستودع منفصل يمكن الرجوع إليه في مشاريع متعددة. يسمح هذا للمؤسسات بإضفاء المركزية على منطق CI/CD الخاص بها.

بنية سير عمل قابل لإعادة الاستخدام

يتم تخزين سير عمل قابل لإعادة الاستخدام في .github/workflows/ ويستخدم workflow_call المشغل.

مثال: سير عمل CI موحد (ci-pipeline.yml)

name: CI Pipeline
on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string
    secrets:
      npm-token:
        required: true
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: ${{ inputs.node-version }}
          registry-url: 'https://npm.pkg.github.com/'
      - name: Install Dependencies
        run: npm install
      - name: Run Tests
        run: npm test

استخدام سير عمل قابل لإعادة الاستخدام في مستودع آخر

بمجرد تحديده، يمكن استخدام سير العمل القابل لإعادة الاستخدام في أي مستودع عبر uses: الكلمة الأساسية .

مثل: استدعاء سير العمل القابل لإعادة الاستخدام

name: Reusable CI Pipeline
on: push
jobs:
  test:
    uses: org/reusable-workflows/.github/workflows/ci-pipeline.yml@v1
    with:
      node-version: '16'
    secrets:
      npm-token: ${{ secrets.NPM_TOKEN }}

فوائد استخدام سير عمل قابل لإعادة الاستخدام

• يضمن أن تتبع جميع المستودعات نفس بنية CI/CD.
• يقلل من التكرار ونفقات الصيانة.
• يسمح بتحديثات مركزية دون تعديل كل مستودع.

الإجراءات القابلة لإعادة الاستخدام

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

بنية إجراء قابل لإعادة الاستخدام

يتم تعريف إجراء قابل لإعادة الاستخدام في مستودع إجراء مع action.yml ملف.

مثل: إجراء بيئة الإعداد المخصص

name: "Setup Environment"
description: "Sets up Node.js and installs dependencies"
inputs:
  node-version:
    description: "Node.js version"
    required: true
  registry-url:
    description: "NPM Registry URL"
    required: false
    default: "https://registry.npmjs.org/"
runs:
  using: "node16"
  main: "index.js"

استخدام إجراء قابل لإعادة الاستخدام في سير عمل

بدلا من تكرار خطوات الإعداد في كل سير عمل، نستخدم الإجراء المخصص:

name: Build & Test
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Environment
        uses: org/actions/setup-env@v1
        with:
          node-version: '16'

الفوائد:

• يقلل من تكرار منطق الإعداد عبر المستودعات.
• يبسط ملفات سير العمل، مما يجعلها أكثر قابلية للقراءة.
• مركزية التحديثات — تعكس الإصلاحات أو التحسينات في مكان واحد عبر جميع مهام سير العمل.

قوالب سير العمل

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

في القسم السابق "إنشاء قوالب سير العمل"، حددنا كيفية إنشاء هذه القوالب من yml ملف وملف بيانات تعريف مطابق .properties.json .

لتوصيل المفهوم بشكل أكبر: قوالب سير العمل هي شكل من أشكال سير العمل القابل لإعادة الاستخدام. عند إنشائها وتخزينها في مستودع عام .github ضمن workflow-templates/ الدليل، فإنها تسمح لأعضاء المؤسسة الآخرين بإنشاء مهام سير عمل متسقة لمستودعاتهم دون الحاجة إلى تعريفها من البداية.

من خلال الاستفادة من قوالب سير العمل، يمكن للمؤسسات:

• فرض أفضل الممارسات عبر المستودعات.
• تسريع الإعداد والإعداد للمشاريع الجديدة.
• الحفاظ على التناسق في عمليات CI/CD.