لماذا تكون عمليات نشر قواعد البيانات أصعب من نشر التطبيقات

لقد كنت تنشر كود التطبيق طوال الأسبوع. ميزة جديدة تُضاف، العملية القديمة تتوقف، وأخرى جديدة تبدأ. إذا حدث خطأ، تعود إلى الإصدار السابق. الدورة بأكملها تستغرق دقائق. تشعر بالأمان لأن الكود قابل للاستبدال.

ثم يأتي دور ترحيل قاعدة البيانات. يجب إضافة عمود جديد. يجب إعادة تسمية جدول. تقوم بتشغيل سكريبت الترحيل، وفجأة أصبح لقاعدة بيانات الإنتاج هيكل مختلف. يعمل التطبيق بشكل جيد في البداية، لكن بعد ساعة يبلغ أحدهم عن فقدان بيانات في تقرير. تحاول التراجع عن الترحيل، لكن البيانات التي تم تحويلها أثناء الترحيل لم تعد إلى حالتها الأصلية بشكل نظيف. لا تزال بعض الصفوف تحتوي على الهيكل الجديد. بعض القيم القديمة اختفت.

هذه هي اللحظة التي يدرك فيها العديد من الفرق أن نشر قاعدة البيانات ليس مجرد "نشر لنوع مختلف من الأشياء". إنها مشكلة مختلفة جوهريًا.

الكود قابل للاستبدال، البيانات ليست كذلك

عندما تعلمت بناء التطبيقات لأول مرة، ربما فكرت في التطبيق كمجموعة من الأكواد. تكتب كودًا، تشغله، ترى النتيجة، وتغير الكود مرة أخرى إذا كان هناك خطأ. إذا كان الإصدار الجديد لا يعمل، تعود إلى الإصدار السابق. هذه العملية تبدو خفيفة لأنه لا توجد عواقب طويلة المدى. يمكن التخلص من الكود الخاطئ أو استبداله أو إعادة كتابته من الصفر.

لكن عندما يبدأ الآخرون في استخدام التطبيق، ينمو شيء بجانبه: البيانات. بيانات المستخدم، بيانات المعاملات، بيانات الطلبات، سجلات التاريخ. هذه البيانات ليست مجرد محتويات قاعدة بيانات. البيانات هي سجل لما حدث بالفعل في العمل. كل صف في جدول يخزن شيئًا ذا قيمة. إذا فقدت البيانات، فإن إعادة كتابة الكود لن تعيدها. البيانات المفقودة لا يمكن إعادة توليدها.

هذا هو الفرق الأساسي بين كود التطبيق وقاعدة البيانات. يمكن التعامل مع كود التطبيق كقطعة أثرية قابلة للاستبدال. يمكنك حذف مجلد المشروع، واستنساخه مرة أخرى من المستودع، وسيعمل التطبيق تمامًا كما كان من قبل. لكن قاعدة البيانات ليست كذلك. قاعدة البيانات تخزن الحالة، وهي الحالة الحالية لبيانات العمل. هذه الحالة تتكون من تراكم العمليات التي حدثت بالفعل. إذا تم حذف قاعدة البيانات، تختفي الحالة. لا يوجد استنساخ Git يمكنه استعادة بيانات العملاء التي تم جمعها على مدار عام.

تأثير النشر

يتجلى تأثير هذا الاختلاف فورًا أثناء النشر. عندما تنشر إصدارًا جديدًا من تطبيق، ترسل أحدث كود إلى الخادم، وتوقف العملية القديمة، وتبدأ العملية الجديدة. إذا كان للإصدار الجديد مشاكل، يمكنك التراجع بالعودة إلى الإصدار السابق. سيعمل التطبيق كما كان قبل التحديث.

لكن عندما يغير نشر قاعدة البيانات هيكل الجدول، تتأثر البيانات الموجودة. قد يتم ملء عمود جديد بقيم افتراضية. قد تتغير أنواع البيانات. قد تحتاج البيانات القديمة إلى التحويل. إذا تسببت هذه التغييرات في مشاكل، فإن التراجع ليس بسيطًا مثل تبديل إصدارات الكود. البيانات التي تم تغييرها بالفعل لا تعود تلقائيًا إلى شكلها الأصلي.

خذ مثالاً على ترحيل بسيط يضيف عمودًا ويملؤه بالبيانات:

-- الترحيل الأمامي
ALTER TABLE users ADD COLUMN age INT;
UPDATE users SET age = 25 WHERE age IS NULL;

-- سكريبت التراجع
ALTER TABLE users DROP COLUMN age;

إذا تم تشغيل الترحيل الأمامي وبدأ التطبيق في كتابة أعمار جديدة، فإن التراجع يحذف العمود وتفقد تلك القيم الجديدة. على عكس كود التطبيق، لا يمكنك ببساطة إعادة نشر الإصدار القديم لاستعادة البيانات المفقودة.

لهذا السبب يصبح العديد من الفرق حذرين مع نشر قواعد البيانات. يمكنهم تبديل إصدارات التطبيق بسرعة عدة مرات في اليوم، لكنهم يترددون في تشغيل ترحيل قاعدة البيانات مع كل نشر. ليس لأن الترحيلات صعبة تقنيًا، ولكن لأن العواقب مختلفة. يمكن إصلاح الكود الخاطئ بإعادة كتابته. قد يستغرق إصلاح البيانات الخاطئة أيامًا، وأحيانًا لا يمكن استعادتها تمامًا كما كانت من قبل.

كيف يغير هذا عملية النشر الخاصة بك

يؤثر الفرق بين الكود والبيانات على كيفية تصميم عملية النشر الخاصة بك. بالنسبة للتطبيقات، تحتاج بشكل أساسي إلى ضمان أن الكود الجديد يمكن تشغيله. بالنسبة لقواعد البيانات، يجب عليك ضمان أن التغييرات الهيكلية لا تضر بالبيانات الموجودة، ولا تعطل التطبيق قيد التشغيل، ويمكن التراجع عنها إذا حدث خطأ ما.

إليك الآثار العملية:

نشر التطبيقات هو عملية إضافية. تضيف كودًا جديدًا، وتزيل الكود القديم، ويستمر النظام. لا يزال الإصدار القديم متاحًا في المستودع أو تخزين القطع الأثرية.

نشر قواعد البيانات هو عملية تحويلية. تغير هيكل البيانات الموجودة. يختفي الهيكل القديم بمجرد تشغيل الترحيل. حتى إذا كان لديك نسخة احتياطية، فإن استعادتها تعني فقدان أي بيانات تم إنشاؤها بعد أخذ النسخة الاحتياطية.

التراجع في نشر التطبيقات رخيص. توجه موازن التحميل إلى الإصدار القديم، أو تعيد تشغيل العملية القديمة. يتم تحديد حالة التطبيق بواسطة الكود قيد التشغيل.

التراجع في نشر قواعد البيانات مكلف. تحتاج إلى كتابة ترحيل عكسي يحول البيانات إلى هيكلها السابق. يجب اختبار هذا الترحيل العكسي. قد يفشل إذا تمت إضافة بيانات جديدة لا تتوافق مع الهيكل القديم. وإذا قام الترحيل الأمامي بتحويل البيانات بشكل لا رجعة فيه (على سبيل المثال، دمج الأسماء الأولى والأخيرة في عمود واحد)، فقد يفقد الترحيل العكسي المعلومات.

الخطر الحقيقي ليس تقنيًا

يعامل العديد من الفرق ترحيلات قواعد البيانات كمشكلة تقنية بحتة. يكتبون سكريبتات الترحيل، ويختبرونها في بيئة الاختبار، ويشغلونها في الإنتاج. عندما يحدث خطأ، يلومون سكريبت الترحيل أو أداة قاعدة البيانات.

لكن الخطر الحقيقي غالبًا ما يكون تنظيميًا. ترحيل قاعدة البيانات يمس بيانات تنتمي إلى مستخدمين حقيقيين. يمكن أن يؤدي الخطأ إلى إتلاف سجلات العملاء أو البيانات المالية أو سجلات الامتثال. قد لا يفهم الفريق الذي يدير الترحيل تمامًا كيفية استخدام البيانات من قبل الأنظمة الأخرى. قد تؤدي إعادة تسمية عمود إلى كسر استعلام تقارير يعمل مرة واحدة في الشهر. قد يتسبب تغيير نوع البيانات في فشل خدمة قديمة بصمت.

لهذا السبب تتطلب عمليات نشر قواعد البيانات مستوى مختلفًا من العناية. التعقيد التقني يمكن إدارته. التعقيد التنظيمي هو ما يجعل الفرق تبطئ.

قائمة تحقق عملية لنشر قواعد البيانات

قبل تشغيل ترحيل قاعدة البيانات في الإنتاج، ضع في اعتبارك هذه الفحوصات:

• هل يمكن عكس الترحيل؟ اكتب واختبر سكريبت التراجع قبل تشغيل الترحيل الأمامي.
• هل سيكسر الترحيل التطبيق الحالي؟ إذا كان التطبيق يقرأ من عمود تقوم بإعادة تسميته، فسيفشل التطبيق حتى يتم تحديثه أيضًا.
• هل يمكن تشغيل الترحيل أثناء تشغيل التطبيق؟ بعض الترحيلات تقفل الجداول، مما قد يتسبب في توقف الخدمة.
• هل هناك نسخة احتياطية؟ خذ نسخة احتياطية قبل تشغيل أي ترحيل يحول البيانات.
• من يحتاج إلى المعرفة؟ أبلغ الفرق التي تستهلك هذه البيانات، بما في ذلك التقارير والتحليلات وعلوم البيانات.

الخلاصة

كود التطبيق قابل للاستبدال. يمكنك التخلص منه، وإعادة كتابته، ونشر إصدار جديد دون فقدان أي شيء مهم. بيانات قاعدة البيانات ليست قابلة للاستبدال. كل ترحيل يغير شيئًا لا يمكن إعادة إنشائه بسهولة.

تعامل مع عمليات نشر قواعد البيانات بنفس الدقة التي تتعامل بها مع حوادث الإنتاج. اكتب سكريبتات التراجع. اختبر الترحيلات ضد بيانات واقعية. تواصل مع الفرق التي تعتمد على البيانات. ولا تفترض أبدًا أن الترحيل آمن فقط لأنه نجح في بيئة الاختبار.

الفرق بين الكود والبيانات ليس تفصيلاً تقنيًا. إنه السبب في أن عمليات نشر قواعد البيانات تستحق عمليتها الخاصة، واستراتيجية الاختبار الخاصة بها، وتقييم المخاطر الخاص بها.