--- title: "علينا أن ننشر التحديث عند منتصف ليل السبت..." description: "نسمع هذا الطلب كثيرًا من عملائنا، وغالبًا من الشركات التي تخدم أعدادًا كبيرة من المستهلكين ولا تحتمل أي توقف للخدمة مهما قصرت مدته." canonical: https://oozou.com/ar/blog/we-need-to-deploy-at-midnight-on-saturday-5 locale: ar date: 2020-07-15 author: "OOZOU Team" --- # علينا أن ننشر التحديث عند منتصف ليل السبت... > نسمع هذا الطلب كثيرًا من عملائنا، وغالبًا من الشركات التي تخدم أعدادًا كبيرة من المستهلكين ولا تحتمل أي توقف للخدمة مهما قصرت مدته. Published: 2020-07-15 · Author: OOZOU Team (Engineering) · 6 min read بعد سنوات من بناء التطبيقات ونشرها على نطاق واسع، نفهم تمامًا لماذا يسود الاعتقاد بأن النشر يجب أن يتم بهذه الطريقة. فالرهانات عالية، وخطر تعطيل شيء ما خلال ساعات العمل حقيقي جدًا. لكننا نعرف أيضًا لماذا ليست هذه هي الطريقة الصحيحة. سأشرح ما يحدث عادةً قبل عمليات النشر "الضخمة" هذه وأثناءها، تلك التي تجري في ساعات الليل المتأخرة أو في عطلة نهاية الأسبوع: **الاختبار: بيئة UAT مطابقة لبيئة الإنتاج، أليس كذلك؟ على الأرجح لا.** يخضع التطبيق لاختبارات صارمة طوال فترة UAT التي تسبق موعد الإصدار، ويبذل الجميع أقصى جهدهم للتأكد من أن التطبيق اختُبر جيدًا وأن كل الوظائف المتوقعة تعمل كما ينبغي. ويشارك في ذلك عادةً عدة فرق من جميع وحدات الأعمال المعنية، من الاختبار والتطوير إلى مالكي المنتج وغيرهم. وكثيرًا ما يصبح الاختبار معقدًا للغاية عندما يتضمن تكاملًا مع مكوّنات أو خدمات من أطراف خارجية، إذ قد تظهر مشكلات كثيرة في توافق الإصدارات بين الجزء الذي يجري نشره والأجزاء الموجودة أصلًا، مثلًا: - هل توفرت نسخة UAT من جميع التبعيات الخارجية أثناء الاختبار؟ - هل كانت البيانات في تلك الأنظمة تمثّل بيانات الإنتاج؟ - هل تغيّرت البيانات في تلك الأنظمة بمرور الوقت كما سيحدث في الإنتاج؟ - هل جرت محاكاة الحِمل بشكل صحيح؟ وهكذا... ويتضاعف هذا التعقيد مع كل مكوّن إضافي. **النشر: الليلة الكبرى / عطلة نهاية الأسبوع الكبرى** وها قد حانت لحظة الحقيقة. كل المعنيين إما في المكتب أو على أهبة الاستعداد، ومعظمهم متعبون. بعضهم فاته مشاهدة فيلم مع عائلته، وبعضهم اضطر إلى اختلاق الأعذار للتغيّب عن عشاء مع الأصدقاء. لا أحد سعيد بالعمل في هذا الوقت بالتأكيد، مهما أوحت ملامح وجهه بغير ذلك. تُشغَّل السكربتات اللازمة ويتم النشر. رائع، يتنفس الجميع الصعداء. لكن مهلًا... مالك المنتج أخبرنا للتو أنه لا يستطيع إضافة منتجات إلى سلة التسوق لسبب ما. تنقبض قلوب الجميع ويبدأ تحليل السبب الجذري. هل المشكلة في الكود؟ في الـ API الخاص بخدمة السلة؟ في البنية التحتية؟ تمر الساعات… تبدأ الأعصاب بالتوتر، ويقف المديرون ومالكو المنتج خلف المختبرين والمطورين، الذين يكتبون بسرعة محمومة في محاولة لمعرفة ما الذي حدث. ولن تفيد كل البيتزا التي تقدّمها الإدارة في منتصف الليل. ويجري التخلي عن قواعد البرمجة وسير العمل يمينًا ويسارًا بهدف "إصلاح المشكلة فقط" بأسرع ما يمكن. وبعد عدة ساعات يتضح أن السبب قطعة بيانات تبدو بريئة في نظام الإنتاج، تسببت في مسار تنفيذ غير متوقع مقارنةً بنظام UAT المقابل. وفي النهاية يغادر الناس المكاتب بخطوات متثاقلة مع شروق الشمس. يحاول مالكو المنتج والمديرون (الذين يشعرون بالشيء نفسه!) رفع معنويات الجميع وإخبارهم بأنهم أدّوا عملًا رائعًا. أما الفريق فلا يفكر إلا في سرير دافئ وفي كل الأشياء الجميلة التي فاتته الليلة الماضية مع الأصدقاء والعائلة. إن بدت لكم هذه القصة مألوفة، فتابعوا القراءة وسأخبركم لماذا لا داعي لأن تتكرر أبدًا. **انشروا مبكرًا، مبكرًا جدًا** إن كنتم ستطلقون ميزة جديدة لعملائكم في نهاية الشهر، فلماذا لا تضعون ذلك الكود في التطبيق في _بداية_ الشهر وتخفونه ببساطة؟ والأفضل من ذلك، لماذا لا تطلقون الميزة في بداية الشهر، لكن تعرضونها فقط لمجموعة اختبار صغيرة تستطيع أن تقدّم لكم ملاحظات قيّمة عليها باستخدام بيانات حقيقية؟ يُعرف هذا الإطلاق التدريجي والمنضبط للميزات عادةً باسم _Feature Flipping_ (تبديل الميزات). فأنتم "تبدّلون" حالة الميزة (عادةً من خلال شاشة إدارية) لتفعيلها أو تعطيلها للجميع، أو ربما لتفعيلها لعدد قليل من الأشخاص في كل مرة. وهكذا تُستخدم ميزتكم الجديدة استخدامًا فعليًا في تطبيق الإنتاج الحقيقي مع بيانات حقيقية، دون أن يعلم عملاؤكم بها حتى تفعّلوها لهم أيضًا. لكن مهلًا، ما زال عليّ أن أنشر الميزة فعلًا حتى لو كانت معطّلة… صحيح تمامًا، لكن بما أنها لا تؤثر إطلاقًا على العميل حتى تقرروا أنتم ذلك، فقد قلّلتم مخاطر النشر بشكل كبير، والأهم أنكم أصبحتم أحرارًا في اختيار موعد النشر. يمكنكم الآن النشر خلال ساعات العمل، حين يكون فريقكم كله يقظًا ومركّزًا ومتاحًا. بل يمكن تقليل هذه المخاطر أكثر عبر أساليب مثل Rolling Deployments (النشر المتدرّج)، وهذا موضوع لمقال لاحق! **انشروا كثيرًا، كثيرًا جدًا** لا تتركوا تطوير الميزات يتراكم شهرًا بعد شهر. فعندما تنشرون باستخدام feature flags، تصبحون أحرارًا في نشر أجزاء من الميزات وتفعيلها فقط لمختبري النسخة التجريبية. ومرة أخرى، أنتم تقللون المخاطر عبر عمليات نشر صغيرة يسهل التراجع عنها عند الحاجة. **الجدولة** بمجرد أن تمتلكوا آلية Feature Flipping في تطبيقكم، يمكنكم أن تصبحوا أذكى بكثير وتجدولوا التفعيل التلقائي لميزات معينة في أوقات محددة (تذكّروا أن هذا الكود منشور منذ أسابيع ويستخدمه أشخاص كثيرون). تخيّلوا ميزتكم الجديدة تصبح متاحة لعملائكم في موعدها تمامًا دون أن يحرّك أحد إصبعًا! **تحفّظات** هناك بالطبع استثناءات لكل هذه القواعد، خاصةً في عمليات النشر التي تؤثر تأثيرًا كبيرًا على الميزات الحالية. لكن تجربتنا تقول إنكم ستجدون دائمًا تقريبًا طريقة لعزل الميزات الجديدة بحيث لا تؤثر على العملاء الذين لا يرونها. **الأزمنة تتغيّر** الخبر السار أننا نتحدث مع عدد متزايد من قادة الإدارة العليا ومالكي المنتجات والفرق التقنية ذوي التفكير المتقدم، ممن يفهمون المشكلات الموصوفة هنا لأنهم عاشوها بأنفسهم في أحيان كثيرة. وهم يتحسنون في عرض هذه الحجج على فرق التسويق وأصحاب المصلحة الآخرين، وفي تغيير ثقافة النشر "الضخم" دفعة واحدة. دعوا OOZOU تساعد فريقكم على قيادة هذا التغيير أيضًا. --- Contact OOZOU: hello@oozou.com · +66 2544 0000 · https://oozou.com/ar/contact More for AI agents: https://oozou.com/llms.txt · every page has a markdown twin at its URL plus ".md"