كل مشروع تحديث لنظام قديم يبدأ بنفس الفكرة المغرية: جمّد تطوير الميزات الجديدة، أعد كتابة النظام بشكل صحيح هذه المرة، وانتقل إليه بالكامل بمجرد اكتماله. تقريبًا كل مشروع من هذا النوع إما يتجاوز الجدول الزمني بشكل كبير، أو يُلغى قبل أن يُطلق، أو يُسلّم إعادة كتابة أصبحت قديمة بالفعل بحلول موعد إطلاقها. البديل — التحديث التدريجي — أقل إثارة عند التخطيط له، لكن احتمالية وصوله فعليًا إلى الإنتاج أعلى بكثير.
لماذا تفشل إعادة الكتابة الشاملة (big-bang)
النظام القديم يُشفّر سنوات من الحالات الاستثنائية وقواعد العمل والإصلاحات الصامتة التي لم يوثقها أحد. إعادة الكتابة تضطر لاكتشاف كل ذلك من الصفر، عادةً دون السياق الأصلي، بينما يستمر العمل في التغير من تحتها. وبحلول الوقت الذي يصبح فيه النظام الجديد مكتملًا من حيث الميزات مقارنة بمتطلبات النظام القديم قبل ثمانية عشر شهرًا، يكون النظام القديم قد تطور — وكذلك العمل نفسه.
نمط "strangler fig" (شجرة الخنق)
بدلًا من استبدال النظام بأكمله دفعة واحدة، وجّه حركة المرور لقدرة واحدة في كل مرة إلى تنفيذ جديد، بينما يستمر النظام القديم في التعامل مع كل شيء آخر. مع مرور الوقت، ينمو النظام الجديد حول النظام القديم حتى لا يعتمد عليه شيء بعد الآن، فيمكن إيقافه بأمان — تمامًا كما تنمو شجرة "strangler fig" حول شجرة مضيفة. كل خطوة صغيرة بما يكفي لاختبارها ونشرها والتراجع عنها بشكل مستقل.
رتّب حسب المخاطرة والقيمة، لا حسب الأسهل
الإغراء هو تحديث أسهل وحدة أولًا لبناء زخم. لكن الأفضل غالبًا هو الترتيب حسب حيث يسبب النظام القديم أكبر قدر من الألم — الوحدة التي تتعطل أكثر من غيرها، أو تعيق أكبر عدد من عناصر خارطة الطريق — حتى لو كانت الأصعب. هناك يكسب التحديث ميزانيته فعليًا، وهناك يرى أصحاب المصلحة القيمة مبكرًا بما يكفي لمواصلة دعم المشروع.
الانتقال دون توقف للخدمة ممارسة، لا أمنية
يجب أن تُطلق كل خطوة ترحيل خلف آلية تتيح لك توجيه حركة المرور تدريجيًا والتراجع فورًا إذا حدث خطأ ما — أعلام الميزات (feature flags)، إصدارات canary، أو طبقة وسيطة (proxy) قادرة على تحويل نسبة من حركة المرور بين التنفيذ القديم والجديد. اقرن ذلك باختبار تكافؤ شامل بين القديم والجديد قبل الانتقال الكامل، ويصبح التوقف عن الخدمة شيئًا تخطط لتجنبه، لا شيئًا تأمل ألا يحدث.
العمل يستمر في التسليم بينما تُحدّث
أكبر ميزة عملية للتحديث التدريجي هي أنه لا يتطلب تجميد الميزات. لأن شريحة واحدة فقط من النظام تتغير في كل مرة، تستمر بقية الفريق في تسليم عمل المنتج بالتوازي — وهذا أيضًا ما يبقي المشروع ممولًا لفترة كافية لإنجازه.
الدين التقني لم يتراكم دفعة واحدة، ونادرًا ما يحتاج إلى سداده دفعة واحدة أيضًا. الفرق التي تنجح في إيقاف نظام قديم هي تلك التي تعاملت مع التحديث كانضباط هندسي مستمر، لا مشروعًا بطوليًا لمرة واحدة.