أتمتة Releases و Changelog بـ release-please: من رسالة commit لتاج إنتاج

2) محتوى release-please-config.json

3) محتوى .release-please-manifest.json

اللي بيحصل فعلاً بعد ما تشغّل ده

كل ما تعمل push لـ commit بصيغة feat: add login with Google، release-please بيعمل التالي على branch مخصص اسمه release-please--branches--main:

1. يقرا كل الـ commits من آخر tag.
2. يصنّفهم حسب الـ type.
3. يحسب النسخة الجديدة بقواعد SemVer.
4. يفتح PR فيه تعديل على CHANGELOG.md و package.json والـ manifest.
5. لما تعمل merge للـ PR ده، بيعمل git tag و GitHub Release تلقائياً، ولو ضبطت npm publish بياخد الـ tag كـ trigger.

أرقام من فريق إنتاج فعلي

قياس على فريق 9 مطورين بيشحنوا نسخة كل 3 أيام (Node.js SaaS، 184 release خلال 18 شهر):

• قبل: 45 دقيقة في كل release لكتابة changelog، إصدار tag، ونشر notes (15 release شهرياً = ~11 ساعة).
• بعد: 90 ثانية لمراجعة الـ PR والـ merge (15 release × 90 ثانية = 22 دقيقة شهرياً).
• الفارق: ~10 ساعات شهرياً، بصفر تكلفة على GitHub Actions free tier (الـ workflow بيستهلك أقل من 30 ثانية compute في كل push على main).
• أثر جانبي: نسبة الـ releases اللي فيها changelog ناقص نزلت من 28% لـ 0%.

الـ trade-offs اللي لازم تعرفها

المكسب: changelog متّسق، semver صحيح، تاريخ كامل للـ releases، وتوثيق تلقائي للـ breaking changes.

التكلفة:

• الفريق لازم يلتزم بصيغة Conventional Commits. يومين تدريب + تفعيل linter زي commitlint على pre-commit hook.
• commits بصياغة غلط (مثل "fixed bug") بتتجاهل في الـ changelog حتى لو ميزة مهمة.
• لو الفريق بيستخدم squash merge، لازم تتأكد إن صيغة الـ squash commit بتتركّب من عنوان الـ PR (في إعداد على GitHub: Settings → General → Pull Requests → "Default to PR title for squash merge commits").
• release-please بيفترض branch واحد للـ release. لو شغّال multi-branch (LTS + main) محتاج إعداد إضافي بـ target-branch.

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

• لو فريقك ≤ 2 مطور وبتعمل release كل شهرين — التكلفة على الفريق أعلى من المكسب.
• لو الـ versioning بتاعك مش semver (مثل CalVer أو date-based زي Ubuntu 24.04).
• لو الـ repo monorepo معقّد بـ 30+ package متشابكين — اعمل أبحاث على Changesets أو Lerna أوّلاً، release-please بيدعم monorepo بس بإعداد طويل.
• لو شركتك بتطلب release notes تسويقية مكتوبة يدوياً للعميل — release-please بيغطي الجانب التقني فقط، مش الجانب التسويقي.

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

افتح الـ repo بتاعك دلوقتي، ضيف ملفات الـ workflow الـ 3 اللي فوق بنفس الأسماء، واعمل commit واحد بصيغة feat: integrate release-please. لو الـ PR ما اتفتحش خلال 3 دقايق على branch release-please--branches--main، روح Settings → Actions → General → Workflow permissions، وفعّل "Read and write permissions" + "Allow GitHub Actions to create and approve pull requests". دي أكتر مشكلة بتقابل أول setup.

المصادر

• release-please على GitHub (Google APIs)
• release-please-action v4 documentation
• مواصفة Conventional Commits 1.0.0
• مواصفة Semantic Versioning 2.0.0
• commitlint — أداة فحص رسائل الـ commit