أتمتة توليد Changelog و GitHub Releases بـ release-please — وداعًا للتحرير اليدوي

نقطة مهمة: الـ Release PR دايمًا موجود. طول ما في commits مفيهاش release، هو مفتوح. ده الـ trade-off الرئيسي: في كل مشروع هتلاقي PR اسمه "chore: release 1.x.x" دايمًا في القائمة. ناس بتحبه، ناس بتكرهه.

الإعداد الكامل — ملف واحد workflow + ملفّين config

افتح repo فيه package.json وحط الملفات دي.

1) .github/workflows/release-please.yml

2) release-please-config.json — بيحدد نوع الـ release وإعدادات الـ changelog:

3) .release-please-manifest.json — الـ source of truth للـ version الحالي:

ادفع الثلاثة على main. بعد أول push، استنى 30 ثانية. هتلاقي PR جديد اسمه "chore(main): release 0.2.0" فيه الـ CHANGELOG. افتحه واعمله merge. خلاص — أول Release رسمي اتعمل.

مثال Commits حقيقية وناتجها

لو عملت الـ commits دي على main خلال أسبوع:

release-please هيفتحلك PR ناتجه:

• version: من 0.1.0 لـ 0.2.0 (لأن فيه feat → minor bump)
• CHANGELOG.md: قسم "المزايا الجديدة" فيه بندين، قسم "تصليحات" فيه بندين. الـ docs و chore مش هيظهروا.
• GitHub Release v0.2.0: بنفس المحتوى، بيتعمل أوتوماتيكيًا لما تـ merge.

Monorepo — لو عندك أكتر من package

release-please v13 بيدعم monorepos بشكل first-class. لو عندك packages/api و packages/web و packages/shared، الـ config بيبقى:

الـ plugin node-workspace بيحدّث الـ internal dependencies بين الـ packages تلقائيًا. لو api بتستخدم shared ونزل Release جديد لـ shared، الـ api/package.json هيتحدّث أوتوماتيك.

الأرقام اللي تهمّك

• الوقت اليدوي قبل: ~20 دقيقة/release × 4 releases شهريًا = 80 دقيقة شهريًا.
• الوقت مع release-please: ~2 دقيقة review لكل PR × 4 = 8 دقائق.
• التوفير الشهري: 72 دقيقة (90%).
• أخطاء version mismatch: من ~2 شهريًا لـ 0 (بحكم إن الـ bump deterministic).
• تكلفة GitHub Actions: صفر للمشاريع العامة؛ للخاصة ~3 دقائق/شهر × $0.008 = أقل من 3 سنت/شهر.

Trade-offs حقيقية لازم تعرفها

هتكسب: CHANGELOG دقيق، version صحيح دايمًا، GitHub Release تلقائي، source of truth واحد هو الـ commits، دعم monorepos قوي.

هتخسر:

• انضباط في صياغة الـ commits. لو فريقك بيكتب "update stuff" في كل commit، release-please مش هيفيدك.
• الـ Release PR هيقعد مفتوح دايمًا، ناس بتشوفه ضوضاء.
• الـ CHANGELOG بالإنجليزي افتراضيًا. تعريبه محتاج changelog-sections كـ ما فوق، مش اللغة كلها.
• مش بيشوف الـ commits اللي قبل ما تفعّله. أول run بيبدأ من نقطة الصفر.

متى لا تستخدم release-please

تجنّبه لو: (1) المشروع شخصي ومش بتعمل releases أصلاً، (2) فريقك مش ملتزم بـ Conventional Commits ومش هتقدر تفرضها (استخدم commitlint مع pre-commit hook لو عاوز تفرضها)، (3) الـ release لديك محتاج خطوات يدوية حرجة زي migrations أو approvals من Compliance — release-please ممكن يقفّزك عليها. في الحالة دي استخدم publish_now: false أو semantic-release اللي بيدي تحكّم أكتر في مراحل النشر.

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

اختار أصغر repo عندك دلوقتي، وحط الـ 3 ملفات اللي فوق عليه. ادفعهم على branch منفصل، افتح PR، و شوف release-please بيتصرّف إزاي. لو في commits موجودة مش بصيغة Conventional Commits، حوّل الفريق للصيغة دي في الـ commits الجديدة فقط — مش لازم تعدّل التاريخ. بعد أول release ناجح، طبّقه على بقية المشاريع.

المصادر

• googleapis/release-please — المستودع الرسمي
• release-please-action على GitHub Marketplace
• توثيق manifest releaser ودعم monorepos
• مواصفة Conventional Commits الرسمية
• Semantic Versioning Specification