دورة Chrome السريعة تضغط الاختبار: Beta يمنح المؤسسات 4–6 أسابيع
الاستعداد لدورة Chrome Stable ذات الأسبوعين يبدأ قبل وصول الإصدار المستقر: شغّل Beta بالتوازي، وحدد التطبيقات والسياسات التي قد توقف العمل، ثم مرّر التحديث عبر فريق الاختبار ومجموعة تجريبية وبقية المؤسسة. بهذه البنية تتحول فترة Beta إلى نافذة قرار، بدل ضغط اختبارات التوافق داخل الأسبوعين الفاصلين بين إصدارين مستقرين.
بالنسبة إلى متصفحات Chrome المدارة على Windows وMac، تمنح Beta معاينة تمتد من أربعة إلى ستة أسابيع. ويوضح دليل اختبار قنوات Chrome أن Stable وBeta وDev وCanary يمكن تشغيلها معًا، مع فصل مواقع التثبيت وملفات المستخدم؛ لذلك يستطيع فريق التقنية بدء الاختبار المبكر من دون استبدال متصفح العمل اليومي.
لماذا يجب أن يبدأ الاختبار في Beta؟
إذا انتظر الفريق وصول Stable، تصبح مهلة اكتشاف الخلل ومعالجته أو إبلاغ المستخدمين أقصر من دورة الاعتماد التقليدية لدى كثير من المؤسسات. أما تشغيل Beta باستمرار فيكشف التغييرات قبل وصولها إلى أسطول الإنتاج، ويتيح ربط كل نتيجة اختبار بالإصدار الذي ستظهر فيه.
بدأت دورة الأسبوعين فعليًا مع طرح Chrome 153 في 8 سبتمبر 2026 على أجهزة سطح المكتب وAndroid وiOS، وكانت Chrome 154 Beta متاحة آنذاك قبل إصدارها المستقر المقرر في 22 سبتمبر، وفق إعلان Chrome عن بدء الدورة الجديدة. هذا التسارع لا يعني اختبار كل وظيفة كل أسبوعين؛ بل يعني تقديم المسارات الأعلى خطرًا والعمل بتقويمين متداخلين لـBeta وStable.
ابدأ بسجل للتطبيقات والمسارات الحرجة
لا تضع كل المواقع التي يستخدمها الموظفون في مستوى واحد. التطبيق الحرج هو ما يؤدي تعطله إلى توقف عملية أساسية أو تعذر الوصول إليها، مثل تسجيل الدخول الموحد، أو نظام تخطيط الموارد، أو منصة التعلم، أو بوابة المدفوعات، أو تطبيق داخلي يعتمد على إضافة متصفح مُدارة.
سجّل لكل تطبيق مالكًا وظيفيًا ومالكًا تقنيًا، وأنظمة التشغيل المستخدمة، وطريقة المصادقة، والإضافات والسياسات المؤثرة، وأقصر اختبار يثبت سلامة المسار الرئيسي. حدّد أيضًا عطلًا مانعًا بعبارات قابلة للتحقق، مثل فشل تسجيل الدخول، أو فقدان البيانات، أو تعطل الطباعة ورفع الملفات، أو كسر وظيفة لا يتوفر لها بديل مقبول.
يمكن تقسيم السجل إلى ثلاث درجات: مسارات توقف العمل أو تمس الأمن والامتثال، ووظائف واسعة الاستخدام ذات بديل محدود، ثم وظائف يمكن تأجيل إصلاحها من دون تعطيل جوهري. هذا التصنيف يحدد ترتيب الاختبارات وسرعة التصعيد؛ عدد شاشات التطبيق أو شهرته داخل المؤسسة لا يكفيان لقياس خطورته.
ابنِ الطرح عبر ثلاث حلقات
الحلقة الأولى هي فريق الاختبار الدائم. تضم مسؤولي Chrome ومطوري الويب والدعم والأمن، وتستخدم Beta لفحص السياسات والمصادقة والشهادات والإضافات المُدارة وأدوات المطور. عند وصول إصدار Beta، تنفذ هذه الحلقة فورًا اختبارات القبول المختصرة للمسارات الأعلى خطورة وتوثق الإصدار ونظام التشغيل وخطوات إعادة كل عطل.
الحلقة الثانية مجموعة تجريبية ممثلة. ينبغي أن تشمل اختلافات حقيقية في الأجهزة والشبكات والبلدان والأدوار، لا موظفي التقنية وحدهم. في جهة تعليمية قد تضم إداريًا ومعلمًا ومشرف مختبر، وفي شركة قد تشمل موظفين من المبيعات والمحاسبة ومركز الاتصال، لأن كل فئة تعتمد مسارات ويب وسياسات مختلفة.
الحلقة الثالثة هي بقية المؤسسة. لا ينتقل الإصدار إليها لمجرد مرور عدد ثابت من الأيام؛ يشترط إغلاق الأعطال المانعة، وتوثيق المشكلات المقبولة وحلولها المؤقتة، وتجهيز الدعم ورسالة إعادة التشغيل عند الحاجة. إذا ظهر خلل، يتوقف التوسع عند الحلقة المتأثرة بدل الاضطرار إلى معالجة الأثر في الأسطول كله.
حجم الحلقات قرار محلي يرتبط بعدد الأجهزة وتنوع البيئة، لكن المسؤولية يجب ألا تكون موزعة بلا حسم. عيّن مالكًا لقرار التوسيع، وموعدًا نهائيًا للاعتراضات، وسجلًا يعرض الإصدار والقناة والأجهزة المشمولة والأعطال التي تمنع الانتقال.
حوّل المعاينة إلى تقويم متداخل
نافذة Beta لا تعني بدء مشروع اختبار جديد مع كل إصدار. المطلوب إيقاع متكرر يجمع مراجعة التغييرات المرتقبة، وتشغيل اختبارات الأولوية، وتوسيع Beta داخل المجموعة التجريبية، ثم إصدار قرار الجاهزية قبل وصول Stable بوقت يسمح بالإصلاح أو التواصل.
- عند وصول Beta، اختبر السياسات والمصادقة والإضافات والمسارات المصنفة في الدرجة الأولى.
- وجّه كل عطل إلى مالك التطبيق أو الإضافة، مع تسجيل إصدار Chrome ونظام التشغيل وطريقة إعادة المشكلة.
- قبل وصول Stable، صنّف العطل إلى مانع للنشر، أو مقبول مؤقتًا مع حل بديل، أو غير مرتبط بالإصدار.
- عند طرح Stable، ابدأ بالحلقة التقنية ثم التجريبية، ووسّع النشر ما دامت الأعطال المانعة مغلقة ومؤشرات الدعم ضمن الحدود المعتادة للمؤسسة.
يعمل تقويما القناتين في الوقت نفسه: يختبر الفريق Beta القادم بينما يراقب نشر Stable الحالي. ولمنع اختلاط النتائج، يجب أن يحمل كل تقرير توافق رقم الإصدار والقناة ونظام التشغيل؛ عبارة «يعمل على Chrome» وحدها لا تكفي لاتخاذ قرار نشر.
متى تختار Stable أو Extended Stable؟
اختر Stable لمعظم المستخدمين عندما تستطيع إبقاء Beta قيد الاختبار، وإنهاء فحوص المسارات الحرجة ضمن نافذة المعاينة، وتنفيذ طرح مرحلي كل أسبوعين. هذا ينسجم مع توصية Google بأن دورة Stable ذات الأسبوعين هي الخيار الأكثر أمانًا، لكنه يتطلب ملكية واضحة للاختبارات واستجابة سريعة للأعطال.
اختر Extended Stable للأجهزة المُدارة المرتبطة بدورات اعتماد طويلة أو نوافذ تغيير ضيقة. يبين شرح Google للقناة الممتدة أنها متاحة على Windows وMac، وتطرح مرحلة رئيسية كل ثمانية أسابيع، مع تحديثات أمنية أسبوعية بين المراحل حيثما كان نقل الإصلاح ممكنًا تقنيًا؛ وقد تبقى بعض التغييرات المعقدة أو مزايا الأمان الكبيرة حصرية لـStable.
- ابقَ على Stable إذا كانت سرعة الحصول على أحدث الإصلاحات الأمنية تتقدم على كلفة الاختبار المتكرر.
- استخدم Extended Stable إذا كانت المؤسسة لا تستطيع اعتماد تغييرات المراحل كل أسبوعين، مع إبقائها قيد الاختبار على مجموعة صغيرة قبل التعميم.
- لا تعتبر Extended Stable بديلًا عن Beta؛ بطء تغييرات المراحل لا يثبت توافق تطبيقات المؤسسة تلقائيًا.
- يمكن توزيع القنوات بحسب المخاطر بدل فرض قرار واحد: مستخدمون عامون على Stable وبيئات محددة ذات اعتماد أطول على Extended Stable.
المعيار الحاسم ليس الرغبة في تقليل عدد التحديثات، بل قدرة الفريق على اكتشاف التعارض قبل الإنتاج واحتواء أثره. إذا كانت هذه القدرة قائمة، تدعم Beta طرح Stable السريع؛ وإذا كانت نافذة الاعتماد أطول بنيويًا، تمنح Extended Stable وقتًا إضافيًا من دون إلغاء الحاجة إلى الاختبار المرحلي.
اقرأ أيضًا:
اشترك في نشرتنا الإخبارية
احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.