التقييم والتقاط الانحراف
ما في كل بيئة فعلًا، وكم تباعدت، وأي الفروق مقصود. قصير، وينتج الجرد الذي يُحاجّ به في كل قرار لاحق.
ممارسة تسليم قواعد البيانات
DevOps لقواعد البيانات في المملكة
حلّت أغلب الفرق تسليم التطبيقات وتركت قاعدة البيانات حيث كانت تمامًا: طلب تغيير، ونافذة صيانة، وشخص واحد يعرف ما في الإنتاج فعلًا. تغلق هذه الممارسة تلك الفجوة، وهي عادةً أكبر قيد منفرد على وتيرة شحن أي شيء.
باختصار
تغييرات قواعد البيانات، تُسلَّم كأي تغيير آخر
تؤدّي إنتركي إدارة قواعد البيانات ونمذجة البيانات وهندسة DevOps، وهذه الصفحة هي ما يحدث حين تكون الثلاثة ارتباطًا واحدًا: وضع المخطط والبيانات المرجعية تحت التحكم بالإصدارات، وبناء الخط الذي ينشرهما، وتصميم ما يحدث حين يجب التراجع عن نشر.
والنطاق ضيّق عمدًا. ليس هذا عن أي قاعدة بيانات ينبغي أن تكونوا عليها، فذلك تحديث منصة البيانات، ولا عن الانتقال إلى أخرى، فذلك ترحيل قواعد البيانات. بل عن التغييرات التي تشحنونها على المنصة التي عندكم أصلًا، كل أسبوع، لسنوات.
وسبب استحقاقها ممارسة خاصة حسابي. إن كانت التطبيقات تُنشر أسبوعيًا وقاعدة البيانات ربع سنويًا، فالنظام يُنشر ربع سنويًا. كل استثمار في خط التطبيق مسقوف بأبطأ شيء فيه، وفي أغلب المؤسسات أبطأ شيء تغيير مخطط ينتظر نافذة.
الأعراض
كيف يبدو هذا قبل إصلاحه
الحالات التي تصفها الفرق، وما تدل عليه كل منها عادةً. لاحظوا كم قليل منها يصفه من يعيشه مشكلةَ قاعدة بيانات.
| ما تلاحظونه | ما يدل عليه فعلًا | من أين تبدؤون |
|---|---|---|
| لا أحد متأكد مما في الإنتاج | لا مصدر حقيقة واحد لقاعدة البيانات؛ والمرجع خادم يعمل | التقاط خط أساس وفحص انحراف، قبل أي شيء آخر. لا تستطيعون أتمتة النشر إلى هدف حالته الحالية مسألة رأي. |
| تغييرات المخطط تحتاج نافذة ومدير قاعدة بيانات في منتصف الليل | لم تُصمَّم التغييرات لتُطبَّق دون توقف | أعيدوا تركيب أنماط التغيير أولًا: التوسيع ثم التقليص، والتعبئة الخلفية مفصولة عن التبديل. النافذة عرض لتصميم التغيير لا للأدوات. |
| البيئات تنحرف عن بعضها | تُجهَّز يدويًا، أو بسكربت لم يشغّله أحد من أوله إلى آخره مؤخرًا | أعيدوا بناء بيئة أدنى من المصدر وانظروا ما ينكسر. ما ينكسر هو قائمة ما يعتمد عليه الإنتاج ولم يكتبه أحد. |
| التراجع يعني الاستعادة من نسخة احتياطية | لا خطة تراجع، بل خطة تعافٍ من الكوارث فقط | الصف الأكثر إلحاحًا هنا. استعادة نسخة احتياطية تفقد كل ما أُلزم بعدها، فالفرق عمليًا لا تتراجع، بل تصلح إلى الأمام تحت الضغط، وهكذا يصير نشر سيئ انقطاعًا. |
| شخص واحد يراجع كل تغيير في قاعدة البيانات | تركّز معرفة، يُظن عادةً أنه ضبط جودة | أتمتوا ما تفحصه المراجعة فعلًا. أغلبه تسمية ووجود فهارس وكشف عمليات حاجبة وتغييرات صلاحيات، وكلها يفرضها خط أكثر اتساقًا من إنسان مرهق في الثانية فجرًا. |
| إصدارات التطبيق وقاعدة البيانات يجب أن تُنسَّق بدقة | الاثنان مقترنان بإحكام بالتصميم لا بالضرورة | فكّوا الاقتران بأنماط تغيير متوافقة مع السابق بحيث يدعم إصدار المخطط إصدار التطبيق على جانبيه. هذا التغيير هو ما يجعل كل ما فوقه ممكنًا. |
الترتيب
لماذا التسلسل غير قابل للتفاوض
كل خطوة لا تكون آمنة إلا حين تصمد التي قبلها. والفرق التي تبدأ من الأتمتة لأنها الجزء المرئي تنتهي إلى أتمتة نشر تغييرات لا يستطيع أحد وصفها.
-
أثبتوا الحقيقة
المخطط والبيانات المرجعية والصلاحيات تُلتقط في التحكم بالإصدارات، وفحص انحراف يبلّغ عن الفرق بين المستودع وكل بيئة. وإلى أن يوجد هذا، كل ما بعده تخمين.
-
أصلحوا أنماط التغيير
إضافية وقابلة للعكس افتراضيًا: أضيفوا قبل أن تحذفوا، وعبّئوا خلفيًا منفصلًا عن التبديل، ولا تغيير هدّام أبدًا في النشر نفسه مع الشيفرة التي تتوقف عن استخدام الشكل القديم. هذا ما يزيل نافذة الصيانة.
-
أتمتوا الفحوص
تحليل ساكن لكل تغيير، العمليات الحاجبة، والفهارس الغائبة، ومنح الصلاحيات، والتسمية، يعمل في الخط. متسق وسريع، ويحرّر المراجعة البشرية لأسئلة التصميم التي لا تستطيع أداة الحكم فيها.
-
انشروا عبر الخط
المخرج نفسه يُرقّى عبر البيئات، ويطبّق الخط تغيير قاعدة البيانات لا شخص أمامه وحدة تحكم مفتوحة. طُبّق، وتُحقّق منه، وسُجّل.
-
أثبتوا التراجع
كل تغيير يُشحن مع عكسه، ويُنفَّذ العكس في بيئة أدنى لا يُفترض. تراجع لم يُختبر خطةٌ لاكتشاف أثناء حادث هل كان عندكم واحد.
الجزء الصعب
التراجع هو حيث يُحسم الانضباط
الشيفرة تتراجع. البيانات لا تتراجع.
التراجع عن التطبيق مشكلة محلولة: انشروا المخرج السابق ويعود النظام كما كان. وقواعد البيانات لا تعمل هكذا، والفرق ليس فجوة في الأدوات، بل طبيعة الشيء. عمود محذوف لا يمكن استعادته بإعادة تشغيل النشر إلى الخلف، لأن البيانات التي كانت فيه ذهبت.
والنتيجة أن السلامة يجب أن تُصمَّم في التغيير لا أن تُورَّد لاحقًا بآلية تراجع. وهذا عمليًا يعني ألا يُجرى تغيير هدّام أبدًا في الإصدار نفسه مع الشيفرة التي تتوقف عن استخدام الشكل القديم: يُضاف العمود، ويُبدَّل التطبيق، ويُترك العمود القديم في مكانه مدة محدّدة، ثم يُحذف، وعندها يكون التبديل قد أثبت نفسه في الإنتاج أصلًا.
هذا التسلسل أبطأ لكل تغيير وأسرع كثيرًا لكل ربع سنة، لأنه ما يجعل النشر روتينيًا بما يكفي لتكراره. ويزيل أيضًا الجدل الذي ينتج أغلب انقطاعات قواعد البيانات: الجدل الذي يُحكم فيه بأمان تغيير هدّام لأن الإصدار الذي ينتمي إليه اختُبر.
وثمة فشل مرتبط يستحق تسمية منفصلة. ترحيل طويل يُطبَّق داخل نشر قد يحتجز أقفالًا لدقائق على جدول كبير، فيبدو النشر معلّقًا ويبدو التطبيق متوقفًا. التعبئات الخلفية مكانها خارج مسار النشر، تُشغَّل على دفعات، وتُراقَب، وهذا شاغل تشغيل اليوم الثاني بقدر ما هو شاغل تسليم.
النطاق
كيف يتشكّل العمل عادةً
أربعة أشكال. الأول كثيرًا ما يُشترى وحده، وكثيرًا ما يغيّر ما ظنّ المشتري أنه المشكلة.
بناء الخط
التحكم بالإصدارات للمخطط والبيانات المرجعية، وفحوص آلية، ونشر عبر مسار الترقية نفسه كالتطبيق، مبني في أدوات التسليم التي يستخدمها الفريق أصلًا لا بجانبها.
إعادة تركيب أنماط التغيير
تركيب أنماط التوسيع ثم التقليص والتغيير دون توقف على مخطط قائم، وهو حيث تختفي نافذة الصيانة. عادةً المرحلة الأعلى قيمة ونادرًا ما تُطلب أولًا.
التسليم والمعايير
معايير مكتوبة، ومعايير مراجعة مؤتمتة لا محفوظة، ونقل يكفي لتصمد الممارسة بعد من قدّمها. خط لا يفهمه إلا عضو واحد في الفريق نقل عنق الزجاجة ولم يزله.
الطبقة السعودية
ما الخاص بهذا السوق
أمران يغيّران شكل هذا العمل هنا.
بيانات غير الإنتاج ما زالت بيانات منظَّمة. الطريقة المعتادة للحصول على بيئة اختبار واقعية نسخ الإنتاج إليها، ولقواعد البيانات التي تحمل بيانات شخصية هذا قرار حماية بيانات لا تسهيل هندسي. وفعله كما ينبغي يعني تقنيع بيانات الاختبار أو توليدها، وهو عمل حقيقي ومكانه الخطة من البداية، لا يُكتشف حين يسأل أحد من أين حصلت البيئات الأدنى على محتوياتها.
سجل التدقيق متطلب، والخط ينتج سجلًا أفضل من الإجراء. على المؤسسات المنظَّمة أن تُظهر من غيّر ماذا، ومتى، ومن وافق. والإجراء اليدوي ينتج ذلك السجل أوراقًا تُحفظ منفصلة عن التغيير ولذلك على نحو ناقص. والخط المؤتمت ينتجه ناتجًا جانبيًا للنشر نفسه، وهو أكمل وأصعب في الجدال. وهذه من الحالات القليلة التي يشير فيها متطلب الامتثال والتفضيل الهندسي إلى الاتجاه نفسه تمامًا.
يُسلَّم العمل من الرياض عبر ممارسة الهندسة نفسها التي تبني التطبيقات المؤسسية المخصّصة، وهذا يهم هنا أكثر من المعتاد: تسليم قواعد البيانات ليس تخصصًا قابلًا للفصل، وخط صمّمه من لا يعيش مع التطبيق الذي يخدمه يميل إلى ألا يصمد أمام جدول الإصدارات.
تعريف الاكتمال
كيف يبدو المكتمل فعلًا
ممارسة تسليم قواعد البيانات سهلة الإعلان وأصعب الإثبات. هذه أشياء إما صحيحة أو غير صحيحة، وكل منها يستطيع التحقق منه من لم يشارك:
- المستودع، لا خادم يعمل، هو مرجع ما ينبغي أن يكون عليه المخطط، وفحص انحراف يبلّغ عن أي بيئة تختلف
- يمكن إعادة بناء بيئة أدنى من المصدر، على يد من لم يفعلها من قبل، دون سؤال أحد
- كل تغيير في قاعدة البيانات يصل إلى الإنتاج عبر الخط نفسه كالتطبيق، ولا يصل أي منها بطريق آخر
- كل تغيير يُشحن مع عكسه، وقد نُفّذ العكس في غير الإنتاج
- التغييرات الهدّامة لا تكون أبدًا في الإصدار نفسه مع الشيفرة التي تتوقف عن استخدام الشكل القديم
- معايير المراجعة يفرضها الخط لا يحفظها شخص، وسجل النشر نفسه هو سجل التدقيق
- بيئات غير الإنتاج تحمل بيانات مقنَّعة أو مولَّدة، وكيف حصلت عليها موثَّق
أسئلة
أسئلة يطرحها المشترون فعلًا
سؤال شائع
أي الأدوات تستخدمون لتسليم قواعد البيانات؟
ما يناسب المنصة والخط القائم أصلًا. قرار أداة الترحيل ثانوي حقًا: الأدوات في هذا المجال تتقارب على المبادئ نفسها، ولا تصلح أي منها فريقًا تتطلب أنماط تغييره انقطاعًا. وحيث لا تكون عند المنظومة أدوات، أو تكون SQL Server وتستحق مجموعة المقارنة والمراقبة مكانها، تنفّذ إنتركي أدوات Redgate؛ وتلك الصفحة تُسقط الأدوات على التسلسل أعلاه. والممارسة المبنية حول منتج بعينه تميل إلى التوصية به، وهذا سبب للشك فيها، ومنها ممارستنا إن بدأنا يومًا نفعل ذلك.
سؤال شائع
هل يمكن أن يعمل هذا دون نافذة صيانة؟
لأغلب التغييرات، نعم، وهذه إلى حد بعيد خاصية كيف كُتب التغيير لا متى طُبّق. التغييرات الإضافية، والتعبئات المفصولة، والتبديلات المرحلية تُطبَّق دون توقف. وتبقى بقية صغيرة تحتاج نافذة فعلًا، بعض إعادة هيكلة الجداول الكبيرة على بعض المحرّكات، والهدف أن تكون تلك البقية نادرة ومتوقعة لا التظاهر بأنها فارغة.
سؤال شائع
ماذا لو لم يكن عندنا تحكم بإصدارات قاعدة البيانات أصلًا؟
هذه نقطة البداية الشائعة لا الاستثنائية. الخطوة الأولى خط أساس: التقاط مخطط الإنتاج الحالي أصلًا، ومعاملة كل تغيير من تلك النقطة فصاعدًا مخرجًا مُصدَّرًا. ولا حاجة إلى إعادة بناء التاريخ الذي لم يُسجَّل قط، ومحاولة ذلك طريقة جيدة لقضاء شهر قبل تسليم أي شيء.
سؤال شائع
هل ينطبق هذا على NoSQL أيضًا؟
نعم، مع انتقال الصعوبة لا زوالها. مخزن المستندات لا يفرض مخططًا، فلا ترحيل يُشغَّل، وهذا يعني أن الأشكال القديمة تبقى في البيانات وعلى التطبيق أن يتعامل مع كل إصدار كتبه يومًا. وما زال ذلك يحتاج تصديرًا، وما زال يحتاج استراتيجية تعبئة خلفية، وما زال يحتاج من يقرّر متى يجوز أخيرًا افتراض زوال شكل قديم. وعمل إنتركي على المنصات المستندية على Couchbase.
سؤال شائع
متى يؤتي هذا ثمره؟
يؤتي التقييم ثمره فورًا، لأن معرفة ما في الإنتاج تستحق أيًا كان ما تفعلونه بعدها. والخط مسألة أسابيع. وإعادة تركيب أنماط التغيير هي الطويلة وذات العائد الحقيقي، وتُسدَّد مخططًا مخططًا لا في برنامج واحد، وهذه ميزة: تعني أن القيمة تصل تدريجيًا لا في نهاية شيء قد يُلغى.
من مركز المعرفة
القرارات المجاورة
تقنية
تنفيذ Redgate لـ DevOps قواعد البيانات
ما الذي يتغيّر حين تكون الأدوات من Redgate: أي أداة تحمل أي خطوة من التسلسل.
ممارسةترحيل قواعد البيانات
الانتقال بين المنصات: برنامج لمرة واحدة، مقابل ممارسة التسليم المتكررة في هذه الصفحة.
ممارسةتطوير البرمجيات المخصّصة
نصف التطبيق من خط التسليم نفسه، تبنيه ممارسة الهندسة نفسها في الرياض.
استكشف الحلول ذات الصلة
الخطوة التالية
ابدؤوا مما في الإنتاج فعلًا
صفوا المنصة، وكم مرة يُشحن التطبيق، وكيف تصل تغييرات قاعدة البيانات إلى الإنتاج اليوم. الفجوة بين الرقمين الأخيرين هي الحديث كله عادةً.
أو مباشرةً
+966-11-2180999 info@interkey.com.saأبراج التعاونية، البرج الشمالي، الطابق السابع، طريق الملك فهد، العليا، ص.ب. ٥٦٨٣٥، الرياض ١١٥٦٤، المملكة العربية السعودية