أطلقت Cloudflare خدمة Worker Previews لتوفير بيئة تشغيل مستقلة لكل فرع Git، بحيث يمكن اختبار التغييرات البرمجية في ظروف أقرب إلى الإنتاج من دون التأثير في حركة المرور أو الإعدادات أو الحالة الخاصة بالنسخة العاملة. وتتوفر الخدمة الآن لمستخدمي Workers.
تمنح كل معاينة عنوان URL ثابتاً للفرع، يتحدث مع كل عملية دفع جديدة، إضافة إلى إعدادات ومتغيرات وأسرار وارتباطات منفصلة. ويمكن للمطورين إرسال الطلبات إلى المعاينة من الطرفية أو أنظمة التكامل المستمر أو المتصفح، ثم فحص السجلات والأخطاء والمقاييس وآثار التنفيذ عبر أدوات Workers Observability.
بيئة مستقلة تتجاوز مجرد رابط للنسخة
توضح Cloudflare أن Worker Previews تختلف عن Version URLs السابقة. فالأخيرة تشير إلى نسخة مرفوعة محددة ويمكن أن تستخدم موارد الإنتاج، بينما تنشئ Worker Previews بيئة معزولة لكل فرع، مع إمكانية تشغيل مئات المعاينات بالتوازي ضمن لوحة تحكم واحدة. ويتيح ذلك اختبار نقاط API وتغييرات واجهة المستخدم وتدفقات تسجيل الدخول في سياق تشغيل فعلي بدلاً من الاكتفاء بفحص الكود أو الاعتماد على بيئة staging مشتركة.
وعند تشغيل الأمر npx wrangler preview، تنشئ Cloudflare نسخة المعاينة اعتماداً على إعداد أساسي يحدده المطور في ملف Wrangler. ويمكن تعديل إعدادات معاينة بعينها، مثل توجيهها إلى قاعدة بيانات أو مفتاح API للاختبار، من دون تغيير إعدادات الإنتاج أو المعاينات الأخرى. كما يمكن تقديم عناوين المعاينات عبر نطاق مخصص، مع استخدام Cloudflare Access لحمايتها وتقييد الوصول إليها.
عزل الحالة والموارد الحساسة
يمتد العزل إلى الموارد ذات الحالة. فلكل معاينة مساحة Durable Objects وتطبيق Containers مستقلان، ما يمنع تغييرات الحالة والجلسات وعمليات الترحيل أو تغييرات المخطط الفاشلة من الوصول إلى الإنتاج أو إلى فروع أخرى. وتربط Cloudflare هذا السلوك بالسياق البرمجي للفرع، إذ يحل ctx.exports إلى مساحة الإنتاج عند التشغيل في الإنتاج، وإلى مساحة المعاينة المناسبة عند التشغيل داخل فرع تجريبي.
عملياً، يسمح ذلك بمقارنة إعدادات مختلفة للتطبيق نفسه، مثل اختبار أداء التشغيل البارد والدافئ، مع بقاء نتائج كل تجربة محصورة في بيئتها. ويمكن أيضاً استخدام Browser Run لفتح رابط المعاينة في متصفح دون واجهة، وتنفيذ تدفقات تسجيل الدخول والتقاط لقطات أو جلسات قابلة لإعادة التشغيل، ثم ربط ما ظهر للمستخدم بآثار التنفيذ والأخطاء المسجلة.
ما الذي يتغير عملياً؟
تقدم Worker Previews حلقة تغذية راجعة قبل الإنتاج لكل فرع: نشر التغيير، تشغيله، مراقبته، إصلاح الخلل، ثم إعادة الاختبار قبل الدمج. وترى Cloudflare أن هذا يدعم ما تسميه دورة حياة تطوير الوكلاء، حيث يستطيع الوكيل البرمجي تنفيذ التغيير وفحصه ومراجعة نتائجه ضمن نطاق الفرع نفسه، مع إمكانية تدخل المراجع البشري عند الحاجة.
استخدمت Cloudflare الخدمة داخلياً لاختبار CloudflareOS وGatekeepers، خصوصاً التدفقات التي تجمع بين OAuth والصلاحيات والموافقات وحالة التطبيق. كما أوردت الشركة تجارب من Supermemory وRamp بشأن اختبار تغييرات Workers ومراجعة طلبات الدمج من أجهزة محمولة.
القيود المعلنة والخطوات التالية
لا تعزل المعاينات حالياً سلسلة الطلب كاملة في التطبيقات متعددة Workers؛ إذ قد يستدعي ارتباط خدمة من معاينة نسخة الإنتاج من Worker المرتبط. كذلك تستطيع المعاينات إرسال رسائل إلى Queues لكنها لا تستهلكها بعد، ويتطلب عزل تنفيذ Workflows إعداداً منفصلاً. وتعمل Cloudflare على دعم هذه المسارات، إلى جانب توفير معاينات طويلة الأمد لبيئات staging وQA وبيئات المطورين المستمرة.
قراءة certi.news: القيمة الأساسية في الإعلان ليست إنشاء رابط اختبار جديد، بل نقل العزل إلى مستوى الإعدادات والحالة والمراقبة. وهذا يقلل مخاطر اختبار تغييرات تمس الموارد ذات الحالة، لكنه لا يلغي الحاجة إلى تصميم بيئة الاختبار بعناية، خصوصاً عندما تعتمد الخدمة على Workers متعددة أو طوابير ورسائل وتدفقات طويلة الأمد. لذلك تبدو Worker Previews أكثر اكتمالاً من معاينة نسخة منفردة، مع بقاء بعض أجزاء التطبيق خارج نموذج العزل الكامل في الإصدار الحالي.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.