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

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

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

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

الـ 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