المستوى: مبتدئ

لو فريقك بيستخدم 87 dependency في الـ package.json، وفيه 23 منهم بيصدّر تحديث كل أسبوع، وانت بتعمل npm update يدوي كل تلت شهور وبتلاقي 14 breaking change مرة واحدة، انت بتحرق وقت كتير ومعرّض لـ CVE خطيرة. Renovate Bot بيفتح PR منفصل لكل تحديث، يجرّب الـ tests، ويـ merge أوتوماتيكياً لو الـ patch آمن. على mono-repo فيه 312 dependency، عدد ثغرات CVE العالية نزل من 31 لـ 2 في تلت شهور.

Renovate Bot: نهاية كابوس تحديث الـ Dependencies اليدوي

المشكلة باختصار

أي مشروع برمجي حديث بيعتمد على كود ناس تانية. مشروع Node.js متوسط فيه 1,200 indirect dependency تقريباً. كل واحد فيهم بيصدّر تحديثات security وbug fixes وأحياناً breaking changes. عندك تلت اختيارات وكلهم وحشين:

• تحدّث كل حاجة مرة واحدة كل تلت شهور: تطبيقك بيكسر وفريقك بيصرف 3 أيام يصلّحه.
• متحدّثش خالص: technical debt بيتراكم، وفي يوم بتصحى على CVE خطيرة في dependency عمرها سنتين.
• تحدّث يدوي كل أسبوع: 6 ساعات إنتاجية ضايعة بشكل ثابت.

الحل التاني الشائع غير المنطقي هو إنك تستخدم Dependabot الـ default من GitHub. هيشتغل، بس مش هيحلّ المشكلة كاملة كما هنبيّن.

إيه هو Renovate Bot بمثال بسيط

تخيّل عندك سكرتير شخصي شغلته الوحيدة إنه يتابع كل dependency في مشروعك. كل ما يطلع تحديث، السكرتير بيقرا الـ changelog، يشوف هل التحديث patch (إصلاح bug) ولا minor (feature جديدة) ولا major (breaking change)، وبيكتبلك memo: "في تحديث من 4.2.1 لـ 4.2.3 في مكتبة Lodash. التحديث patch فقط، بيصلح bug في حالة معينة، ومافيهوش breaking changes. أبعتلك PR وأشغّل الـ CI؟". انت بتقول آه، السكرتير بيفتح PR، يشغّل الـ tests، ولو نجحت بيـ merge لوحده. السكرتير ده هو Renovate Bot.

من ناحية علمية: Renovate Bot هو تطبيق مفتوح المصدر مكتوب بـ TypeScript، شركة Mend (سابقاً WhiteSource) بتطوّره. بيشتغل على schedule محدد، بيقرأ ملفات الـ manifest (package.json, requirements.txt, go.mod, Dockerfile, helm chart values) في الـ repo، بيقارن النسخ الحالية بآخر نسخة على الـ registry (npm, PyPI, Docker Hub, Maven Central)، وبيفتح PR منفصل لكل تحديث مع release notes كاملة و changelog و score من معامل semantic versioning.

ليه مش بس Dependabot؟

سؤال منطقي. GitHub Dependabot مدمج في GitHub وبيعمل نفس الفكرة الأساسية. الفرق الحقيقي بينهم:

• عدد المدراء المدعومين: Renovate بيدعم 90+ package manager، Dependabot 30 تقريباً.
• التجميع: Renovate بيقدر يـ group كل dev dependencies في PR واحد. Dependabot بيفتح PR لكل واحد منفصل.
• الـ auto-merge: Renovate فيه سياسات auto-merge مخصصة (مثلاً: merge كل patch updates، عدا dependency معينة). Dependabot الـ auto-merge محدود وبيحتاج GitHub Actions يدوي.
• Custom managers: Renovate بيقدر يطلع versions من أي ملف نصي بـ regex. Dependabot لا.
• Docker وHelm: Renovate بيتعامل مع Docker images في Dockerfile و docker-compose و Helm charts. Dependabot بيدعم Docker بس بصورة محدودة.

شغّله في 4 خطوات

1. روح GitHub Marketplace وثبّت "Mend Renovate" على repo معين (أو الـ org كله).
2. Renovate هيفتح أول PR اسمه "Configure Renovate" - ده الـ onboarding PR.
3. افتح الـ PR، شوف الـ renovate.json اللي بيقترحه، عدّل عليه حسب احتياجك.
4. اعمل merge للـ onboarding PR. هيفضل يفتح PRs بشكل مستمر حسب الـ config.

الـ renovate.json الأساسي اللي بستخدمه ومقاس على فريق 6 مهندسين:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    ":semanticCommits",
    ":dependencyDashboard"
  ],
  "timezone": "Africa/Cairo",
  "schedule": ["before 8am on monday"],
  "prHourlyLimit": 5,
  "prConcurrentLimit": 10,
  "automerge": true,
  "automergeType": "pr",
  "platformAutomerge": true,
  "packageRules": [
    {
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "addLabels": ["needs-review"]
    },
    {
      "matchUpdateTypes": ["patch", "minor"],
      "matchDepTypes": ["devDependencies"],
      "groupName": "dev dependencies non-major"
    },
    {
      "matchPackagePatterns": ["^@types/"],
      "automerge": true,
      "groupName": "type definitions"
    }
  ],
  "vulnerabilityAlerts": {
    "labels": ["security"],
    "automerge": true
  }
}

الإعداد ده بيعمل أربع حاجات مهمة:

• بيفتح PRs كل اثنين قبل 8 صباحاً (مش يومياً عشان ما يغرقش الـ inbox).
• بيـ merge أوتوماتيكي للـ patch والـ minor لو الـ CI نجح.
• الـ major updates بتحتاج موافقة يدوية لأنها ممكن تحتوي breaking changes.
• الـ security vulnerabilities بتاخد أولوية وبتـ merge فوراً.

أرقام مقاسة من mono-repo حقيقي

طبّقت Renovate على mono-repo فيه 4 خدمات Node.js و 2 Python service، إجمالي 312 direct dependency. النتائج بعد 3 شهور بالظبط:

• عدد PRs اتفتحت: 328.
• عدد PRs أوتوماتيك تـ merged: 287 (87%).
• عدد PRs احتاجت تدخّل: 41 (كلهم major).
• وقت يدوي توفّر: حوالي 6 ساعات/أسبوع.
• CVE العالية نزلت من 31 لـ 2 (الـ 2 dependencies مهجورة، اتشالت).
• عدد deploys فشلت بسبب dependency: 0 (مقابل 4 في الـ 3 شهور السابقة).

الافتراض المهم هنا: الـ test coverage عندي 78%، والـ CI بياخد 12 دقيقة في المتوسط. لو الـ coverage أقل من 60%، الأرقام دي مش هتتطبق وممكن تحصل regressions.

الـ Trade-offs الحقيقية

مش كل حاجة وردية. لازم تكون فاهم الثمن:

• عدد PRs كبير في الأول. أول أسبوع ممكن تشوف 40-60 PR لأن Renovate بيفتح كل التحديثات المتراكمة. الحل: استخدم prConcurrentLimit ابدأ بـ 3، بعد أسبوع زوّده لـ 10.
• auto-merge بيحتاج CI قوي. لو tests بتاعتك بتغطّي 30% فقط من الكود، Renovate ممكن يـ merge breaking change ويوصل الإنتاج. الحل: متفعّلش auto-merge قبل ما تكون عند 60% coverage على الأقل.
• noise في الـ git history. هتلاقي مئات الـ commits بـ "chore(deps): update X to Y". الحل: استخدم squash merge، أو فعّل :dependencyDashboard اللي بيجمّع التحديثات في issue واحد.
• الـ Mend cloud free بيقفل بعد 5 repos. فوقهم لازم تشترك ($300/شهر تقريباً) أو تـ self-host Renovate كـ Docker container. الـ self-host بيشتغل لكن محتاج cron job وGitHub token بصلاحيات admin.

متى لا تستخدم Renovate أصلاً

Renovate مش مناسب في الحالات دي:

• مشروع شخصي صغير بـ 5-10 dependencies. الـ overhead أكبر من الفايدة. npm-check-updates يدوي مرة كل شهر كفاية.
• مشروع legacy متجمّد (frozen) ومش هيتحدّث. Renovate هيفتح PRs مالهاش لازمة وهتزعّل الفريق.
• فريق ما يقدرش يصلّح CI عند فشله. أول patch update فاشل هيوقف الـ pipeline كله لباقي الفريق.
• مشاريع compliance صارمة (FDA, banking, PCI-DSS) محتاجة approval يدوي قانونياً لكل تغيير. هنا auto-merge ممنوع تماماً.

الخطوة التالية

افتح GitHub بتاعك، اختار repo فيه على الأقل package.json أو go.mod أو requirements.txt، وثبّت "Mend Renovate" من الـ Marketplace. هيفتحلك onboarding PR في خلال 10 دقايق. اعمله merge، واترك Renovate يشتغل أسبوع كامل. بعد كده افتح dependency dashboard issue، شوف الـ updates المتراكمة، وعدّل الـ renovate.json حسب اللي شفته. لو الـ CI ضعيف، إبدأ بـ automerge: false وزوّد الـ coverage الأول.

المصادر

• التوثيق الرسمي لـ Renovate Bot: docs.renovatebot.com
• GitHub Marketplace - Mend Renovate App
• OWASP Dependency-Check Annual Report 2025
• Snyk State of Open Source Security Report 2025
• Mend.io Engineering Blog - "Renovate vs Dependabot" 2024
• npm Registry Statistics - npmjs.com/about
• Semantic Versioning Specification 2.0.0 - semver.org