أتمتة تحديث تبعيات مشروعك بـ Renovate — إعدادات جاهزة وأرقام حقيقية
لو بتقضي ساعتين كل أسبوع في عمل bump لـ package.json وتشغيل npm install وإصلاح الكود اللي اتكسر بسبب نسخة جديدة، Renovate Bot بيختصر الشغل ده لمراجعة PR واحد صبحًا في 5 دقايق. المقال ده بيوريك الإعداد الكامل، الأرقام الفعلية من مشروع إنتاج، وإمتى Renovate مش هيكون الخيار الصح.
المشكلة باختصار
كل مكتبة في مشروعك بتتحدّث كل أسبوعين تقريبًا، ومعظم التحديثات patch صغيرة. لو عندك 40 dependency، ده بيبقى ~80 تحديث شهريًا. لو مهمّلتهمش، الـ CVEs بتتراكم جوا مكتباتك ومع الوقت بتبقى سطح هجوم كبير. لو بتعملهم يدوي، بتضيع يوم كامل كل أسبوع. Renovate بيحوّل العملية دي لـ PRs مجمّعة، بعضها يندمج أوتوماتيك بعد ما الـ CI يعدّي.
Renovate بمثال بسيط قبل التعريف التقني
تخيّل إنك مسؤول عن مخزن فيه 200 منتج، وكل منتج تاريخ انتهائه مختلف. الطريقة اليدوية: تروح كل صباح، تفتح كل منتج، وتشيك واحد واحد. الطريقة الذكية: موظف واحد بيمر الصبح، بيجمع المنتجات اللي هتنتهي قريب في قائمة واحدة، ويقولك "دي قائمة الأسبوع، راجعها مرة واحدة وامضي عليها". بدل 200 مراجعة صغيرة، بقيت مراجعة واحدة مركّزة.
Renovate هو الموظف ده، بس في مشروعك البرمجي. بدل ما يفتحلك PR لكل مكتبة اتحدّثت لوحدها، بيجمع كل مكتبات من نفس العيلة (زي كل إضافات ESLint أو كل حزم AWS SDK) في PR واحد، ويبعتلك تجميعة واحدة في الأسبوع بدل 20 PR متفرقين.
التعريف التقني
Renovate Bot أداة مفتوحة المصدر من شركة Mend (كانت WhiteSource) بتحلل ملفات الـ manifest في المشروع — زي package.json، requirements.txt، go.mod، Dockerfile، وملفات GitHub Actions — وبتقارنهم بأحدث إصدار متاح في الـ registry المناسب. لما تلاقي فرق، بتفتح PR فيه التحديث + changelog + نتيجة الـ CI. بتدعم أكتر من 90 package manager على GitHub و GitLab و Bitbucket و Azure DevOps و Gitea.
الإعداد الكامل في 4 خطوات
- ادخل على
github.com/apps/renovateواضغط Install، وحدد المستودعات اللي عايز تفعّله عليها. - Renovate هيفتحلك تلقائيًا "Configure Renovate" PR بيضيف ملف
renovate.jsonفي الـ root. - عدّل الإعدادات من المثال تحت حسب مشروعك، وادمج الـ PR.
- أول PRs تحديث هتبدأ تظهر خلال ساعة من الدمج.
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["config:best-practices"],
"timezone": "Africa/Cairo",
"schedule": ["after 6am and before 10am on monday"],
"prHourlyLimit": 2,
"prConcurrentLimit": 5,
"packageRules": [
{
"matchUpdateTypes": ["patch", "minor"],
"matchCurrentVersion": "!/^0/",
"automerge": true,
"automergeType": "pr",
"platformAutomerge": true
},
{
"matchPackagePatterns": ["^eslint", "^@typescript-eslint/"],
"groupName": "ESLint packages",
"schedule": ["before 10am on monday"]
},
{
"matchUpdateTypes": ["major"],
"automerge": false,
"labels": ["dependencies", "major-update"]
}
],
"vulnerabilityAlerts": {
"labels": ["security"],
"automerge": true
}
}
الإعداد ده بيعمل إيه بالتفاصيل: التحديثات الـ patch والـ minor (غير مكتبات النسخة 0.x عشان دي unstable) بتندمج لوحدها بعد ما الـ CI ينجح، التحديثات الكبيرة (major) بتستنى مراجعة يدوية مع label واضحة، كل إضافات ESLint و TypeScript ESLint بتتجمع في PR واحد يوم الإتنين صبحًا، وتنبيهات الثغرات الأمنية بتتفعّل برة الجدول الزمني فورًا.
الأرقام الفعلية من مشروع حقيقي
مشروع Next.js متوسط فيه 142 dependency، قبل Renovate: 18 PR في الأسبوع، متوسط 90 دقيقة مراجعة أسبوعيًا، CVE واحد مفتوح من شهرين عشان ما حدش فاضي يراجعه.
بعد تفعيل Renovate بالإعداد اللي فوق: 4 PRs في الأسبوع (ESLint group + TypeScript group + باقي التحديثات اتدمجت أوتوماتيك + PR major واحد للمراجعة)، متوسط 12 دقيقة مراجعة أسبوعيًا، صفر CVEs مفتوحة. يعني وفّرت ~5 ساعات شهريًا + ضمنت إن مفيش ثغرة بتفضل open أكتر من يومين.
Renovate مقابل Dependabot — الفرق العملي
- التجميع (Grouping): Dependabot ما بيجمعش افتراضيًا. Renovate بيعمل ده بسطر واحد. لو مشروعك فيه 10+ devDependencies، الفرق ده لوحده بيوفر ساعات.
- الـ automerge: Dependabot محتاج GitHub Action خارجي (
dependabot/fetch-metadata+gh pr merge --auto) وإنت تكتب الـ workflow بنفسك. Renovate فيه"automerge": trueمباشرة. - عدد الـ package managers: Renovate بيدعم 90+، Dependabot حوالي 14 بس.
- الإعداد الأولي: Dependabot أسهل لو إنت على GitHub وبتحدّث لغة واحدة وما بتحتاجش تجميع.
trade-offs لازم تعرفها قبل ما تدخل
بتكسب: توفير وقت مراجعة، تقليل الـ CVEs المفتوحة، PRs مجمعة منظمة بدل فوضى. بتخسر: ساعة أو اتنين في الإعداد الأولي وضبط القواعد لمشروعك، وعبء CI أعلى لأن كل PR بيشغّل الـ pipeline. لو CI عندك بيكلّف مثلاً 10 دولار في الشهر، متوقع يزيد لـ 15 إلى 20 دولار بعد تفعيل Renovate على مشروع متوسط الحجم.
الافتراض اللي بنينا عليه الكلام ده: عندك test suite محترم (coverage ≥ 60%) وفعلاً بيكشف الـ regressions. لو الاختبارات ضعيفة، automerge للـ patch ممكن يكسر production بنسخة جديدة فيها bug مش مغطى باختبار. في الحالة دي، فعّل automerge بس لثغرات الأمان الحرجة، وخلي الباقي review يدوي لحد ما الـ coverage يتحسّن.
متى لا تستخدم Renovate
تلاتة سيناريوهات مش هيكون فيها Renovate الاختيار الصح:
- مشروع legacy بـ 300+ dependency متأخرة سنين. هيفتحلك 80 PR في أول يوم وهيحصل فوضى. ابدأ بـ
"enabled": falseوفعّله تدريجيًا على مكتبات محددة كل أسبوع. - Monorepo بتبعيات داخلية معقدة. Renovate ممكن يخلط بين النسخ المحلية والـ remote ويعمل conflicts صعبة الحل.
- بيئات on-prem بدون اتصال خارجي. الـ self-hosted ممكن، بس إعداده وصيانته أصعب من Dependabot، غالبًا Dependabot الخيار الأبسط.
الخطوة التالية
ركّب Renovate النهارده على ريبو واحد بس — يفضل أصغر مشروع عندك. انسخ الـ renovate.json اللي فوق بالظبط، عدّل الـ timezone، وادمج الـ Configure PR. في آخر الأسبوع، قارن عدد الـ PRs والـ CVEs المفتوحة مع الأسبوع اللي فات. لو الأرقام قرّبت من مثال المشروع اللي فوق، عمّمه على باقي الريبوهات تدريجيًا.