في عالم تطوير البرمجيات الحديث سريع الإيقاع، أصبح التكامل المستمر (CI) و النشر المستمر (CD) العمود الفقري لسير العمل في منهجية Agile. فهذه العمليات المؤتمتة تضمن تسليم برمجيات عالية الجودة بسرعة أكبر، وتمكّن فرق التطوير من اكتشاف المشكلات مبكرًا وتبسيط الاختبارات وأتمتة النشر إلى البيئات المختلفة. ومع ذلك، حتى مع وجود خطوط CI/CD، قد تلاحظون أن بعض الخطوات تستغرق وقتًا أطول من المتوقع، خاصة عند تجهيز التبعيات (dependencies). وانتظار هذه الخطوات المتكررة، مثل تثبيت التبعيات، قد يبطئ سير عمل التطوير والنشر بشكل ملحوظ. في OOZOU، اعتمدنا استراتيجية cache باستخدام GitHub Actions لتقليص وقت تنفيذ الـ pipeline بشكل كبير، وجعل عملية CI/CD أكثر كفاءة.

المشكلة: ما الذي يبطئ خطوط CI/CD؟

حتى مع الأتمتة، ليس كل شيء سريعًا كالبرق. ومن أكثر ما يستهلك الوقت في خطوط CI/CD عملية تثبيت التبعيات. فعندما تُنفَّذ الـ pipelines مرات عديدة أو عبر استراتيجيات متعددة، يزداد وقت انتظار تثبيت التبعيات طرديًا مع عدد الاستراتيجيات التي تشغّلونها. والنتيجة أوقات build أطول، وتأخر في الاختبارات، وبطء في النشر.

تخيلوا أن لديكم استراتيجية build من نوع matrix أو عدة jobs تعمل بالتوازي. في كل job، يجب تثبيت التبعيات قبل تشغيل الاختبارات أو الخطوات الأخرى. والطبيعة المتكررة لهذه المهمة قد تتحول إلى عنق زجاجة كبير، يرفع في النهاية المدة الإجمالية لخط CI/CD.

فكيف نعالج هذه المشكلة؟

الحل: تسريع CI/CD باستخدام cache في GitHub Actions

طبّقنا في OOZOU استراتيجية cache لحل هذه المشكلة. فبالاستفادة من GitHub Actions، يمكننا تخزين التبعيات في cache وإعادة استخدامها عبر عمليات تشغيل الـ pipeline المختلفة، مما يقلل الوقت المستغرق في تثبيت التبعيات في كل job. وهذا يسرّع دورات التطوير والنشر، ويحسّن في النهاية تجربة المطوّرين.

يوفّر GitHub Actions سوقًا (marketplace) مليئًا بالـ actions التي تحسّن كفاءة سير العمل. على سبيل المثال، يجهّز الـ action المسمى actions/setup-node بيئة Node.js في الـ pipeline. وعند دمجه مع cache، يمكنه تحسين وقت تنفيذ سير العمل بشكل كبير عبر تجنّب عمليات التنزيل والتثبيت المكررة.

سير عمل CI الأولي لدينا بدون cache إليكم الشكل المعتاد لسير عمل CI بدون أي آلية cache:

name: CI without cache

on: workflow_dispatch

jobs:
  ci:
    name: Running CI
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3.0.2

      - uses: actions/setup-node@v3.1.1
        with:
          node-version: v16.14.2

      - run: yarn install

      ### Run test/lint etc.
      - run: yarn test

لنرَ النتيجة

في سير العمل الأساسي هذا، يُسحب الكود، وتُجهَّز بيئة Node.js، ثم تُثبَّت التبعيات باستخدام yarn install، وأخيرًا تُشغَّل الاختبارات. ورغم أن هذا النهج يعمل، فهو غير فعّال، خاصة لأن التبعيات نفسها تُثبَّت في كل مرة يعمل فيها الـ pipeline. وهذا يهدر وقتًا ثمينًا في عمليات تثبيت متكررة.إضافة cache لتسريع سير عمل CI لجعل العملية أكثر كفاءة، يمكننا تخزين التبعيات في cache. فبإضافة سطرين فقط، نستطيع تحسين سرعة سير عمل CI بشكل كبير.

إليكم النسخة المحدّثة مع تفعيل cache:

name: CI cache

on: workflow_dispatch

jobs:
  ci:
    name: Running CI
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3.0.2

      - uses: actions/setup-node@v3.1.1
        with:
          node-version: v16.14.2
          cache: 'yarn'
          # Useful for caching dependencies in monorepos
          cache-dependency-path: yarn.lock

      - run: yarn install
      - run: yarn test

ملاحظة: أصبح actions/setup-node يدعم cache بشكل مدمج

الإضافات الأساسية:

• cache: 'yarn': يفعّل cache لاعتماديات yarn.
• cache-dependency-path: yarn.lock: يضمن أن يعتمد الـ cache على الملف yarn.lock، فيُحدَّث الـ cache إذا تغيّرت التبعيات.

باستخدام إعداد cache هذا، يخزّن GitHub Actions التبعيات ويسترجعها تلقائيًا، مما يقلل الوقت المستغرق في تشغيل yarn install في عمليات build اللاحقة. النتيجة: CI أسرع

بهذه الإضافة البسيطة، لاحظنا تحسنًا فوريًا في الأداء في خط CI لدينا. لكن ماذا لو استطعنا الذهاب أبعد من ذلك؟

أبعد من ذلك: cache متقدم لمجلد node_modules

رغم أن آلية cache السابقة تحقق تحسينات ملحوظة، يبقى هناك مجال لمزيد من التحسين، خاصة عندما يبقى إصدار Node.js ثابتًا عبر عمليات تشغيل الـ pipeline. ففي هذه الحالة، لا نريد إعادة ترجمة التبعيات في كل مرة.

إليكم كيف حسّنّا الـ pipeline أكثر بإضافة cache لمجلد node_modules، مرتبط بإصدار Node.js:

name: CI cache advance

on: workflow_dispatch

jobs:
  ci:
    name: Running CI
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3.0.2

      - uses: actions/setup-node@v3.1.1
        with:
          node-version: v16.14.2

      - name: Get node version
        id: node
        run: |
          echo "::set-output name=version::$(node -v)"

      - name: Get node_modules cache
        uses: actions/cache@v3.0.2
        id: node_modules
        with:
          path: |
            **/node_modules
          # Adding node version as cache key
          key: ${{ runner.os }}-node_modules-${{ hashFiles('**/yarn.lock') }}-${{ steps.node.outputs.version }}

      - run: yarn install
      - run: yarn test

ما الذي تغيّر هنا؟

• الحصول على إصدار Node: نسترجع إصدار Node.js الحالي ونخزّنه كمُخرج (steps.node.outputs.version).
• مفتاح cache مبني على إصدار Node.js: يتضمن مفتاح الـ cache نظام التشغيل وقيمة hash للملف yarn.lock وإصدار Node.js، لضمان إعادة بناء التبعيات فقط عند الضرورة. وهذا يمنع إعادة ترجمتها ما لم يحدث اختلاف في الإصدار.الأثر: CI بأقصى سرعة

بتحسين استراتيجية cache أكثر، انخفض وقت سير العمل بشكل كبير. لنلخّص التحسينات:

• CI العادي: 1m 46s (خط الأساس)
• CI مع cache: 1m 2s (تحسن بنسبة -41.51%)
• CI مع cache (متقدم): 23s (تحسن بنسبة -79.3%)

أدت هذه التحسينات إلى خفض بنسبة 79% في الوقت المستغرق في عملية CI، مما يمنح المطوّرين وقتًا أطول لكتابة الكود ويرفع الإنتاجية.

لماذا يستغرق yarn install وقتًا رغم ذلك؟

قد تلاحظون أن خطوة yarn install ما زالت تستغرق وقتًا حتى بعد تفعيل cache. يحدث ذلك لأن التبعيات تحتاج إلى إعادة ترجمة لتعمل مع إصدار محدد من Node.js. لكن بتخزين node_modules في cache بناءً على إصدار Node.js، قلّلنا هذا العبء أكثر في عمليات build اللاحقة.

الخلاصة: سرّعوا CI/CD باستخدام cache

يُعد cache من أبسط الاستراتيجيات وأكثرها فعالية لتحسين أداء CI/CD. فبتخزين التبعيات ووحدات Node.js في cache، سرّعنا عملية CI في OOZOU بشكل كبير. ولا يقتصر أثر تقليل وقت التثبيت على تحسين تجربة المطوّرين، بل يجعل التسليم المستمر أسرع وأكثر كفاءة.

ورغم أننا عرضنا كيفية تحسين سير عمل CI باستخدام cache، يبقى الكثير لاستكشافه في تحسين CD، وسنتناوله في مقالات قادمة. ترقّبوا المزيد حول كيفية تحسين عمليات النشر لدينا.

إليكم المستودع التجريبي

الأسئلة الشائعة

**1. ما هو CI/CD؟**يشير CI/CD إلى التكامل المستمر (Continuous Integration) والنشر المستمر (Continuous Deployment). التكامل المستمر هو أتمتة دمج تغييرات الكود من عدة مساهمين في مشروع واحد، أما النشر المستمر فيؤتمت تسليم الكود المدمج إلى بيئة الإنتاج.

2. لماذا يُعد cache مهمًا في CI/CD؟ يقلل cache في CI/CD المهام المكررة مثل تثبيت التبعيات أو ترجمة الأصول، مما يسرّع سير العمل بشكل كبير. فبتخزين النتائج وإعادة استخدامها، تُنفَّذ الـ pipelines بسرعة أكبر وترتفع الكفاءة العامة.

**3. كيف يحسّن GitHub Actions سير عمل CI/CD؟**يوفّر GitHub Actions أدوات أتمتة لتجهيز المشاريع واختبارها ونشرها. ويقدم actions مثل actions/cache لتحسين الـ pipelines عبر تخزين التبعيات في cache، مما يقلل الوقت المستغرق في المهام المتكررة.

**4. هل يمكن تطبيق cache على مديري حزم آخرين غير Yarn؟**نعم، يدعم GitHub Actions الـ cache لمديري حزم متعددين مثل npm وpip وMaven وغيرها. ويمكن تكييف استراتيجية cache لتناسب متطلبات كل مدير حزم.

5. كيف يساعد cache في إدارة التبعيات ضمن CI؟ يضمن تخزين التبعيات في cache أنها بعد تثبيتها وترجمتها مرة واحدة، تُحفظ ويُعاد استخدامها في عمليات التشغيل اللاحقة، فلا حاجة إلى تنزيلها وتثبيتها من جديد، وهذا يوفّر الوقت.

6. هل تخزين node_modules في cache آمن؟ نعم، تخزين node_modules في cache آمن، بشرط أن تتأكدوا من ربط مفتاح الـ cache بالعوامل المهمة مثل إصدار Node.js أو قيمة hash للملف yarn.lock، لتجنّب أي عدم تطابق أو مشكلات محتملة.

7. كيف يؤثر cache في أداء النشر (CD)؟ رغم أن هذه المقالة تركّز على تحسين CI، يمكن تطبيق cache أيضًا في عمليات CD عبر تخزين مخرجات build أو طبقات Docker، مما يقلل أوقات النشر أكثر.