ما يحدث حقًا عندما يدفع المطور الكود
يصل تقرير خطأ. لا يستطيع المستخدم إتمام عملية الدفع لأن شاشة التأكيد تتجمد. يفتح المطور الكود، ويجد المشكلة، ويكتب إصلاحًا، ويختبره محليًا. كل شيء يعمل على جهازه. يدفع التغيير إلى المستودع المشترك.
هذا الدفع هو مجرد البداية. ما يحدث بعد ذلك يحدد ما إذا كان هذا الإصلاح سيصل إلى المستخدمين في دقائق، أو ساعات، أو أيام. كما يحدد مقدار التوتر والارتباك وإعادة العمل التي سيواجهها الفريق على طول الطريق.
دعنا نستعرض الرحلة الكاملة لتغيير واحد، من كمبيوتر المطور المحمول إلى الإنتاج. سننظر في ما يفعله كل دور فعليًا، ولماذا تعتبر عمليات التسليم بينهم أكثر أهمية مما يدركه معظم الفرق.
المطور: من المحلي إلى المشترك
يبدأ المطور بإيداع الكود الخاص به في نظام التحكم بالإصدارات. الإيداع هو مجرد لقطة للتغييرات المحفوظة في مستودع مشترك مثل Git. لكن الإيداع وحده لا يعني أن التغيير جاهز. ثم يفتح المطور طلب سحب أو طلب دمج، طالبًا دمج تغييراته في الفرع الرئيسي.
عند هذه النقطة، تبدأ الفحوصات الآلية. يتم تجميع الكود أو بناؤه إلى شيء قابل للتشغيل. تُجرى اختبارات الوحدة للتحقق من الوظائف الفردية. تتحقق اختبارات التكامل مما إذا كانت الأجزاء المختلفة من التطبيق تعمل معًا. قد تُجرى أيضًا فحوصات أمنية أساسية. كل هذا يحدث دون أن يلمس أحد لوحة المفاتيح.
إذا فشل أي اختبار، يتم إخطار المطور. يصلح المشكلة، ويودع مرة أخرى، وتتكرر الدورة. إذا اجتازت جميع الاختبارات، يكون الكود جاهزًا للمرحلة التالية.
هذا هو المكان الذي تعلق فيه العديد من الفرق. خط أنابيب أخضر لا يعني أن التغيير آمن. إنه يعني فقط أن الفحوصات الآلية قد اجتازت. لا يزال هناك شخص بحاجة إلى النظر إلى التغيير من منظور بشري.
يُوضح مخطط التسلسل التالي الرحلة الكاملة لتغيير الكود من دفع المطور إلى الإنتاج، مُظهرًا التفاعلات الرئيسية بين الأدوار والأنظمة.
ضمان الجودة: الاختبار بما يتجاوز الأتمتة
لا يبدأ ضمان الجودة عندما يكون البناء جاهزًا. عادةً ما يُعد مهندسو ضمان الجودة سيناريوهات الاختبار بينما لا تزال الميزة أو الإصلاح قيد التخطيط. يفكرون في الحالات الحدودية، والمدخلات غير المعتادة، وظروف الشبكة البطيئة، والتفاعلات مع أجزاء أخرى من النظام.
عندما يجتاز البناء الفحوصات الآلية، يتولاه ضمان الجودة وينشره في بيئة اختبارية. البيئة الاختبارية هي نسخة من الإنتاج لا يصل إليها المستخدمون الحقيقيون. هذا هو المكان الذي يحدث فيه الاختبار اليدوي.
ينفذ ضمان الجودة السيناريوهات المُعدة. هل تعمل الميزة الجديدة كما هو متوقع؟ هل تكسر أي شيء آخر؟ هل يبدو تدفق المستخدم طبيعيًا؟ كما يستكشفون مسارات قد تفوتها الاختبارات الآلية. ماذا يحدث إذا أدخل شخص ما سلسلة طويلة جدًا في حقل نصي؟ ماذا لو كان اتصال قاعدة البيانات بطيئًا؟
إذا وجد ضمان الجودة مشكلة، يبلغون المطور بها. يصلح المطور المشكلة، ويودع مرة أخرى، وتتكرر الدورة حتى يوافق ضمان الجودة. هذا التبادل ذهابًا وإيابًا أمر طبيعي. إنه ليس علامة فشل. إنها الطريقة التي تكتشف بها الفرق المشكلات التي لا تستطيع الاختبارات الآلية توقعها.
النقطة الرئيسية هي أن ضمان الجودة لا يختبر فقط في النهاية. إنهم يؤثرون على ما يتم بناؤه منذ البداية. الفريق الذي يعامل ضمان الجودة كبوابة نهائية سيجد دائمًا المشكلات بعد فوات الأوان.
DevOps: إيصال التغيير إلى الإنتاج بأمان
بمجرد موافقة ضمان الجودة على البناء، ينتقل إلى النشر. هذا هو المكان الذي يتولى فيه DevOps زمام المبادرة. مهندسو DevOps مسؤولون عن إيصال البناء المعتمد إلى الإنتاج دون كسر الأشياء.
في إعداد بسيط، قد يكون النشر يدويًا. يسجل مهندس DevOps الدخول إلى الخادم، ويسحب أحدث بناء، وينفذ أوامر لتبديل الإصدار القديم بالجديد. في إعداد أكثر نضجًا، يكون النشر آليًا. ضغطة زر واحدة، أو حتى مشغل تلقائي بعد موافقة ضمان الجودة، يتولى العملية بأكملها.
لكن النشر ليس النهاية. بعد أن يصبح الإصدار الجديد مباشرًا، يراقب DevOps النظام. هل معدلات الخطأ طبيعية؟ هل وقت الاستجابة مقبول؟ هل يمكن للمستخدمين الوصول إلى الميزة الجديدة؟ إذا بدا شيء ما خاطئًا، يمكن لـ DevOps التراجع إلى الإصدار السابق بينما يحقق المطور وضمان الجودة.
غالبًا ما يتم التغاضي عن مرحلة المراقبة هذه. تحتفل الفرق بنشر ناجح وتنتقل إلى الأمام، فقط لتكتشف بعد ساعات أن خطأً خفيًا يؤثر على المستخدمين. تتضمن ممارسات DevOps الجيدة مراقبة النظام لمدة قصيرة على الأقل بعد كل نشر.
عمليات التسليم أهم من الأدوات
أحد المفاهيم الخاطئة الشائعة هو أن المطور وضمان الجودة وDevOps يعملون في خط تجميع صارم. المطور ينتهي، يسلم لضمان الجودة، ضمان الجودة ينتهي، يسلم لـ DevOps. في الواقع، يتواصلون طوال العملية.
قد يسأل المطور DevOps عن تكوين البيئة الاختبارية. قد يطلب ضمان الجودة من المطور إضافة اختبارات آلية محددة. قد يخبر DevOps المطور أن آخر نشر استغرق وقتًا أطول من المتوقع بسبب تكوين مفقود. كلما كانت هذه المحادثات أكثر سلاسة، كلما وصلت التغييرات إلى المستخدمين بشكل أسرع.
تساعد أدوات مثل خطوط أنابيب CI/CD وأطر الاختبار الآلي وأتمتة النشر. لكنها لا تحل محل التواصل. الفريق الذي يتحدث جيدًا بأدوات أساسية سيتفوق على فريق يستخدم أدوات متقدمة لكنه لا يتحدث على الإطلاق.
عندما تدخل أدوار أخرى الصورة
مع نمو الفرق وزيادة وتيرة النشر، غالبًا ما يظهر دورين إضافيين: مهندسو موثوقية الموقع (SRE) ومهندسو المنصة.
يركز SRE على الموثوقية. يضعون أهداف مستوى الخدمة، ويراقبون صحة النظام، ويبنون أتمتة للتعامل مع الحوادث. يصبحون ضروريين عادةً عندما ينشر الفريق عدة مرات في اليوم ويحتاج إلى ضمان أن كل نشر لا يضعف النظام.
يبني مهندسو المنصة أدوات داخلية وبنية تحتية تستخدمها الفرق الأخرى. ينشئون منصات الخدمة الذاتية حتى يتمكن المطورون من النشر دون انتظار DevOps. يصبحون ضروريين عندما يكون لدى المؤسسة فرق متعددة وتصبح البنية التحتية معقدة للغاية بحيث لا تستطيع كل فريق إدارتها بشكل مستقل.
هذه الأدوار لا تحل محل المطور أو ضمان الجودة أو DevOps. إنها توسع قدرة الفريق على التعامل مع سرعة وتعقيد أعلى.
قائمة مراجعة عملية لتدفق التغيير
استخدم قائمة المراجعة هذه لتقييم كيفية تعامل فريقك مع تغيير من الإيداع إلى الإنتاج:
- هل يؤدي كل إيداع إلى تشغيل عمليات بناء واختبار آلية؟
- هل يُعد ضمان الجودة سيناريوهات الاختبار قبل أن يكون البناء جاهزًا؟
- هل توجد بيئة اختبارية تعكس الإنتاج؟
- هل يمكن لـ DevOps التراجع عن النشر في غضون دقائق؟
- هل يراقب شخص ما النظام لمدة 30 دقيقة على الأقل بعد النشر؟
- هل توجد قناة اتصال واضحة بين المطور وضمان الجودة وDevOps أثناء العملية؟
إذا كان أي من هذه العناصر مفقودًا، فهذا هو المكان الذي سيظهر فيه الاحتكاك.
ما يعنيه هذا لفريقك
التغيير الذي ينتقل من الكود إلى الإنتاج ليس عملية تقنية مع انقطاعات بشرية. إنها عملية بشرية مدعومة بأدوات تقنية. تحدد جودة التواصل بين الأدوار مدى سرعة وأمان وصول التغييرات إلى المستخدمين. تساعد الأتمتة، لكنها لا تستطيع أن تحل محل عمليات التسليم الواضحة، والفهم المشترك، والاستعداد لإشراك الشخص المناسب في الوقت المناسب.
في المرة القادمة التي يدفع فيها فريقك تغييرًا، راقب عمليات التسليم. هناك يحدث العمل الحقيقي.