Renovate Bot: حدّث dependencies تلقائيًا بدون ما تكسر الإنتاج

لو فريقك بيستلم 40 Pull Request أسبوعيًا من Dependabot بس علشان version bumps، المشكلة مش في كمية التحديثات، المشكلة في شكلها. Renovate بيحول نفس الـ 40 PR إلى 5 أو 6 PRs مجمّعة، مع automerge بعد اختبارات ناجحة، ودashboard واحد يعرض كل dependency متأخر في كل repo.

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

أي مشروع production فيه 100 إلى 500 dependency مباشر، وضعفهم أو أربع أضعافهم من الـ transitive dependencies. كل أسبوع بتطلع patch updates لـ 10 أو 20 منهم. لو فريقك بيستخدم Dependabot بإعداد افتراضي، ده معناه 10 إلى 20 PR جديد كل أسبوع لكل repo. والنتيجة اللي بتحصل فعلاً: المهندسين بيعملوا approve/merge على السريع بدون ما يقرأوا الـ changelog، أو بيتجاهلوا الـ PRs لحد ما تتكدس 150 PR معلقة والـ base branch بتبقى متأخرة شهرين.

مثال بسيط قبل ما ندخل في التفاصيل

تخيل إنك طباخ في مطعم كبير. كل يوم المطعم بيستهلك 30 مكون مختلف: طحين، سكر، زيت، بهارات. كل أسبوع، المصانع بتطلع نسخة أنقى من المنتج (patch update). لو المصانع بتبعتلك رسالة SMS لكل مكون لوحده ("الطحين الجديد جاهز"، "السكر الجديد جاهز"...)، هتقضي ساعات تقرأ الرسايل وتقرر أي مكون تشتري.

Dependabot بيشتغل كده بالظبط: رسالة SMS لكل مكون. Renovate Bot بيتصرّف زي مدير مخزن ذكي: بيعمل قائمة أسبوعية واحدة فيها كل التحديثات، بيتأكد إن المكونات أقل من أسبوعين بالفعل (منعًا للشوائب)، ولو كلهم patches آمنة بيشتريهم أوتوماتيكيًا ويضيفهم للمخزن من غير ما يتعبك.

تقنيًا، Renovate بيعمل ده عن طريق 3 آليات: Grouping (تجميع PRs من نفس النوع)، Scheduling (تشغيل في أوقات محددة)، و Automerge (دمج تلقائي بعد CI ناجح + فترة انتظار).

Renovate vs Dependabot: الفرق اللي بيوفر ساعات

Dependabot هو المنتج المدمج من GitHub. بيدعم 30+ ecosystem وبيشتغل مباشرةً من ملف .github/dependabot.yml. Renovate مفتوح المصدر من Mend، بيدعم 90+ ecosystem، وبيشتغل على GitHub و GitLab و Bitbucket و Azure DevOps و Gitea. الفروق العملية:

• Grouping built-in: Renovate عنده presets جاهزة تجمع kubernetes-related أو react-related dependencies في PR واحد. Dependabot بتحتاج تكتب قاعدة يدوية لكل مجموعة.
• Automerge مدمج: بتضيف "automerge": true في package rule، Renovate بيستنى الـ CI ثم يدمج. Dependabot محتاج GitHub Action منفصل يستخدم dependabot/fetch-metadata.
• Dependency Dashboard: Issue واحد في كل repo بيعرض كل dependency متأخر مع السبب لو Renovate مش قادر يحدثه. مفيش ما يشبهه في Dependabot.
• Shared config presets: بتكتب config واحد في repo اسمه renovate-config، وكل الـ repos الباقية بترث منه بـ "extends": ["local>your-org/renovate-config"]. توحيد السياسة عبر 50 repo يبقى سطر واحد.

إعداد عملي في 10 دقايق

1. نصّب تطبيق Renovate من GitHub Marketplace على الـ organization. هو مجاني للـ open source ومجاني لأول repo خاص.
2. أعطِ صلاحية على الـ repositories اللي عايز تحدّثها. Renovate هيعمل PR أولي اسمه "Configure Renovate".
3. راجع الـ renovate.json المقترح وعدّله حسب احتياجك ثم اعمل merge.

ده الـ renovate.json اللي بنستخدمه في production:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    ":dependencyDashboard",
    ":semanticCommits"
  ],
  "timezone": "Africa/Cairo",
  "schedule": ["after 2am and before 7am every weekday"],
  "prConcurrentLimit": 5,
  "prHourlyLimit": 2,
  "minimumReleaseAge": "14 days",
  "packageRules": [
    {
      "matchUpdateTypes": ["patch", "pin", "digest"],
      "automerge": true,
      "groupName": "all patch updates",
      "schedule": ["after 3am on monday"]
    },
    {
      "matchUpdateTypes": ["minor"],
      "matchDepTypes": ["devDependencies"],
      "automerge": true,
      "groupName": "devDependencies minor"
    },
    {
      "matchPackageNames": ["node", "kubernetes"],
      "automerge": false,
      "minimumReleaseAge": "30 days"
    }
  ]
}

الـ config ده بيعمل 4 حاجات مهمة:

• schedule: التحديثات بتطلع بين 2 و 7 صباحًا توقيت القاهرة فقط. فريقك الصبح بيلاقي نتيجة، مش notification في نص اليوم.
• minimumReleaseAge: 14 days: Renovate ما هيعملش PR لأي نسخة أقل من أسبوعين. ده دفاع مباشر ضد supply chain attacks زي اللي حصلت في event-stream وnpm colors.js.
• prConcurrentLimit: 5: مفيش أكثر من 5 PRs مفتوحة في نفس الوقت من Renovate. بيمنع الفريق من الغرق.
• Grouping على patches: كل الـ patches الأسبوعية بتيجي في PR واحد يوم الاثنين، ويتعمل automerge بعد ما CI يعدي.

Automerge آمن: ازاي تخليه مش خطر

Automerge على dependencies مش خطر لو عندك 3 حاجات:

1. Test coverage حقيقي: الـ CI لازم يغطي الـ code paths الحرجة. لو عندك 20% coverage، automerge هيسمح للـ bugs تدخل production. لو عندك 70%+ coverage على business logic، الخطر يقل جدًا.
2. minimumReleaseAge ≥ 14 يوم: بيدي الـ registries الرسمية وقت تسحب أي package خبيث قبل ما Renovate يدمجه. ده best practice موثّق رسميًا في Renovate docs.
3. Rollback جاهز: استخدم deployment strategy (blue-green أو canary) تقدر ترجع من خلالها في دقيقتين لو حصل انحدار في production.

التدرج الموصى به:

• الأسبوع 1-2: automerge على patches + devDependencies بس. راقب الـ CI failures ولاحظ نسبة الـ false positives.
• الأسبوع 3-4: أضف minor updates على devDependencies.
• بعد شهرين: ممكن تفكر في minor updates على production libs، لكن اترك majors تنّدمج يدويًا دائمًا.

Trade-offs وما يجب الانتباه له

Renovate بيكسب 6-8 ساعات مراجعة أسبوعيًا على repo متوسط فيه 150 dependency. ثمنه:

• Learning curve أطول: config Renovate أعقد من Dependabot. توقع 4-8 ساعات أول مرة عشان تفهم الـ presets و packageRules.
• Bot token rate limits: لو عندك أكتر من 100 repo، ممكن تتحدى rate limits على GitHub API (5000 request/ساعة للـ user tokens). الحل: self-host Renovate كـ GitHub Action مع GitHub App مخصص.
• Noise على monorepos كبيرة: monorepo فيه 50 service ممكن يولّد dependency dashboard طويل جدًا. محتاج تكتب package rules مخصصة لكل طبقة (frontend, backend, infra).
• Breaking changes في minor versions: بعض الـ libraries (خاصة في Node.js ecosystem) بتكسر في minor versions رغم semver. لو بتعتمد على libraries زي دي، قلل automerge للـ patches فقط.

متى لا تستخدم Renovate

لو عندك repo واحد في GitHub فقط، و dependencies أقل من 20، و فريق من 1-2 مطور، Dependabot هيعملك المطلوب بـ zero-config. Renovate بيبرز لما يكون عندك monorepo، أو متعدد repos، أو لغات متعددة (Python + Go + Node في نفس المؤسسة).

كمان، لو بتعتمد على internal registry خاص (Artifactory أو Nexus private)، لازم Renovate يكون self-hosted، لأن السحابي ما يقدرش يوصل للحزم الخاصة.

وأخيرًا، لو فريقك ما عندوش CI pipeline موثوق، ما تشغّلش automerge أبدًا — لا في Renovate ولا في أي أداة تانية. الأمان في automerge مبني على افتراض إن اختبارات ناجحة تعني الكود شغّال.

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

افتح أي repo عندك أول الأسبوع الجاي، نصّب Renovate من Marketplace، وامرر الـ renovate.json اللي فوق. قيّم بعد أسبوعين: كم PR تم دمجه automatic، وكم CI failure كشف مشكلة فعلية. لو عدد الـ failures صفر، ده غالبًا معناه إن test coverage عندك مش كفاية — حَسّنه قبل ما تزوّد نطاق automerge.

المصادر

• Renovate Docs — Automerge configuration and troubleshooting
• Renovate Docs — Bot comparison (Renovate vs Dependabot)
• Renovate Docs — Noise Reduction (Grouping, Scheduling)
• Renovate Docs — Upgrade best practices
• Renovate Docs — Configuration Options (minimumReleaseAge, prConcurrentLimit)
• GitHub Dependabot documentation