Cloudflare Artifacts: لماذا يحتاج كل وكيل برمجي مستودع Git خاصاً به؟
فتحت كلاودفلير Artifacts في بيتا عامة: تخزين متوافق مع Git يُنشأ منه مستودع لكل وكيل أو مهمة. نشرح الفكرة وحدودها ومتى تفيدك فعلاً.
في الأول من أكتوبر 2026 فتحت Cloudflare خدمة Artifacts للتجربة العامة، بعد أن أعلنتها في أبريل ضمن بيتا خاصة. العنوان المختصر للخدمة: نظام ملفات مُؤرشَف الإصدارات يتحدث بروتوكول Git، ويمكن إنشاء مستودع منه لكل مشروع أو مستخدم أو جلسة أو مهمة. الفكرة تبدو بسيطة، لكنها تعكس تحوّلاً في طريقة التفكير: حين يصبح الوكيل البرمجي هو من يكتب الكود، قد لا تكون منصات Git المصمَّمة للبشر هي الشكل الأنسب للتخزين.
في هذا المقال نشرح ما تقدّمه الخدمة فعلاً، ولماذا يرى بعض المطورين أنها مناسبة لعصر الوكلاء، وما الذي ينبغي الانتباه إليه قبل الاعتماد عليها.
ما هي Artifacts؟
Artifacts مساحة تخزين مُؤرشَفة الإصدارات تتيح لك العمل معها بثلاث طرق:
- ارتباطات Workers: لإنشاء المستودعات وإدارتها من داخل الكود.
- واجهة REST: للمنصات الأخرى التي لا تعمل على Workers.
- بروتوكول Git: أي عميل Git يدعم smart HTTP يستطيع الاستنساخ والدفع باستخدام رمز وصول قصير العمر.
أي أن الوكيل أو الأداة التي تعرف Git تعمل معها كما تعمل مع أي مستودع بعيد، دون تعلّم واجهة جديدة.
لماذا مستودع لكل وكيل؟
توصي كلاودفلير بمبدأ واضح: مستودع واحد لكل وحدة عمل مستقلة. عشرة آلاف وكيل تعني عشرة آلاف مستودع. وذكر أحد موظفيها أن الخدمة تقترب من خمسين ألف مستودع جديد يومياً.
حين يعمل الوكيل في مستودع خاص به، يصبح التراجع عن خطئه حذف فرع بدل ترميم مشروع مشترك.
المنطق وراء ذلك عملي:
- العزل: وكيل يخطئ لا يلوّث عمل وكيل آخر.
- التتبع: كل خطوة تُسجَّل كإيداع (commit) يمكن مراجعته.
- التفرّع السريع: يمكن نسخ حالة جاهزة لتجربة اتجاه مختلف دون كلفة تذكر.
- الصلاحيات الضيقة: يمكن إصدار رمز محدود بمستودع واحد، فلا يملك الوكيل مفتاحاً لكل شيء.
ما الذي أُضيف في البيتا العامة؟
بحسب ما نُشر، تشمل النسخة العامة:
| الميزة | فائدتها |
|---|---|
| ارتباطات Workers | إنشاء مستودع أو نسخه برمجياً |
| ضوابط الاختصاص القضائي للبيانات | تحديد مكان تخزين البيانات |
| اشتراكات الأحداث | تشغيل اختبار أو مراجعة عند كل دفع |
| import | إنشاء مستودع من مصدر موجود |
| fork | نسخة معزولة، ويمكن جعلها للقراءة فقط |
الخدمة متاحة لعملاء خطة Workers Paid، ويمكن ضبط المساحات والمستودعات والرموز من لوحة التحكم.
سيناريوهات تستحق التجربة
منصة تولّد تطبيقات للمستخدمين
لكل مستخدم مستودع، وكل طلب تعديل إيداع. إن أراد المستخدم التراجع فهو يعود إلى إيداع سابق دون منطق تخزين مخصص.
تجارب متوازية
تنسخ حالة مشروع إلى عدة نسخ، ويجرّب كل وكيل حلاً مختلفاً، ثم تقارن النتائج وتدمج الأفضل.
مراجعة تلقائية
عبر اشتراكات الأحداث يشغّل كل دفع اختباراً أو وكيل مراجعة، فتصبح سلسلة العمل أقرب إلى خط إنتاج صغير.
ما الذي ينبغي الانتباه إليه؟
- ما زالت بيتا: الواجهات والأسعار قد تتغير، فلا تبنِ عليها مسار إنتاج حرجاً قبل قراءة الوثائق الرسمية.
- التسعير: الأرقام المتداولة (0.15 دولار لكل ألف عملية و0.50 دولار لكل جيجابايت شهرياً) مصدرها ملخص طرف ثالث لمرحلة البيتا الخاصة، فتحقق منها في وثائق كلاودفلير.
- الارتباط بالمنصة: استخدام ارتباطات Workers يربط جزءاً من بنيتك بكلاودفلير، فاعتمد على بروتوكول Git القياسي حيث أمكن كي تسهل الهجرة لاحقاً.
- حجم المستودعات: عدد ضخم من المستودعات الصغيرة يحتاج سياسة تنظيف واضحة، وإلا تراكمت التكاليف.
كيف تبدأ بخطوات صغيرة؟
- أنشئ مستودعاً تجريبياً واحداً واستنسخه بعميل Git المعتاد.
- أصدر رمزاً محدود الصلاحية ودعه يستخدمه وكيلك في مهمة بسيطة.
- جرّب fork لتجربة اتجاهين مختلفين لنفس المهمة.
- اربط حدثاً بسيطاً مثل تشغيل اختبار بعد كل دفع.
- قيّم الكلفة بعد أسبوع من الاستخدام الفعلي، ثم قرّر التوسع.
كيف يغيّر هذا طريقة تصميم أنظمة الوكلاء؟
حتى الآن كان أغلب الفرق يخزّن عمل الوكيل في مجلد مؤقت على خادم، فإذا انتهت الجلسة ضاع كل شيء أو بقيت ملفات يصعب تتبعها. اعتماد مستودع لكل مهمة يغيّر ثلاثة أمور في التصميم.
الحالة تصبح قابلة للتدقيق
كل تعديل يقوم به الوكيل يظهر في سجل الإيداعات. وإذا أنتج الوكيل نتيجة غريبة، تستطيع الرجوع خطوة بخطوة لمعرفة أين انحرف، وهذا أسهل بكثير من قراءة سجلات نصية طويلة.
الاستئناف يصبح طبيعياً
وكيل توقف في منتصف المهمة بسبب انقطاع أو حد استخدام يمكنه أن يستأنف من آخر إيداع. الحالة محفوظة في مكان معياري لا في ذاكرة عملية انتهت.
التسليم بين الوكلاء يصبح أبسط
بدل تمرير ملفات عبر قنوات مخصصة، يمرّر وكيل لآخر عنوان المستودع ورمزاً محدود الصلاحية. الوكيل الثاني يستنسخ ويكمل، ويمكنك مراجعة ما حدث لاحقاً بأدوات تعرفها أصلاً.
ملاحظات أمنية عملية
وجود عدد كبير من المستودعات والرموز يفتح باب أخطاء إن لم تُدَر جيداً:
- اجعل الرموز قصيرة العمر ومحصورة بمستودع واحد، ولا تعيد استخدام رمز واسع الصلاحية.
- استعمل النسخ للقراءة فقط عند إعطاء وكيل مراجعة صلاحية الاطلاع دون التعديل.
- لا تضع أسراراً في المستودع، فسجل الإيداعات يحتفظ بكل ما كُتب حتى لو حُذف لاحقاً.
- حدّد مكان تخزين البيانات عبر ضوابط الاختصاص القضائي إن كانت لديك متطلبات امتثال.
- ضع سياسة لحذف المستودعات المنتهية حتى لا تتراكم بلا فائدة.
متى لا تحتاج إليها؟
ليس كل مشروع بحاجة إلى مستودع لكل وكيل. إذا كان فريقك صغيراً ويعمل وكيل واحد أو اثنان على مستودع واحد مع مراجعة بشرية، فإن GitHub أو GitLab المعتادين يكفيان ويوفران لك الأدوات التي تعرفها من مراجعات الدمج والتكاملات. القيمة الحقيقية لـ Artifacts تظهر حين يكبر العدد: مئات أو آلاف المهام المتزامنة، أو منتج يولّد مشاريع لمستخدميه تلقائياً. قبل أن تنتقل، اسأل نفسك سؤالين بسيطين: كم مستودعاً سأنشئ يومياً؟ ومن سيقرأ هذه المستودعات، إنسان أم برنامج؟ إن كانت الإجابة قليلة وإنساناً، فابقَ على ما لديك. أما إن كنت تبني منصة وكلاء من الصفر، فجرّب Artifacts في مسار واحد معزول أولاً، وقِس كلفتها وسهولة الاستعادة، ثم وسّع الاستخدام تدريجياً.
أسئلة شائعة
هل Artifacts بديل عن GitHub؟
ليس بالضرورة. هي موجّهة لحالات تُنشأ فيها مستودعات بأعداد كبيرة ومن قبل برامج لا بشر، وكلاودفلير نفسها دعت المطورين لبناء منصات Git جديدة فوقها.
هل أحتاج لتعلّم واجهة جديدة؟
لا للاستخدام الأساسي، فأي عميل Git يدعم smart HTTP يعمل مع المستودع. الواجهات الإضافية مفيدة فقط عند الإنشاء البرمجي.
هل هي مجانية؟
هي متاحة لعملاء خطة Workers Paid، وهناك تسعير على العمليات والتخزين. راجع الوثائق الرسمية للأرقام الحالية.
الخلاصة
Artifacts تلتقط حاجة حقيقية: وكلاء يكتبون الكود بكثافة يحتاجون مستودعات رخيصة ومعزولة وقابلة للتفرّع. هي ما تزال في البيتا، فجرّبها في مهام محدودة، وابقَ على بروتوكول Git القياسي قدر الإمكان، وراجع التسعير الرسمي قبل التوسع.
المصادر: مدونة Cloudflare، Cloudflare: Next Git platform، سجل تغييرات Artifacts، DEV Community
