السجل الورقي الذي ينقذك أثناء تصحيح الإنتاج

يظهر خطأ في الإنتاج. البيانات خاطئة. المستخدمون يشتكون. يفتح المطور المناوب سجل الالتزامات (commit log) ويرى رسالة تلو الأخرى تقول "إصلاح خطأ"، "تحديث"، أو "قيد التطوير". الآن عليه فتح كل ملف تم تغييره، وتخمين ما كان يفترض أن يفعله كل تغيير، على أمل أن يعثر على التغيير الصحيح. هذه هي اللحظة التي تحول فيها سوء ممارسات الالتزام (commit hygiene) تحقيقًا يستغرق خمس دقائق إلى معاناة تستغرق ساعتين.

في كل مرة يحفظ فيها المطور تغييراته في نظام التحكم بالمصادر (source control)، يقوم بإنشاء التزام (commit). الالتزام هو سجل. يخزن الكود الذي تغير، ومن غيّره، ومتى تغير، والرسالة التي كتبها المطور. غالبًا ما تُعتبر هذه الرسالة أمرًا ثانويًا، لكنها تصبح واحدة من أكثر المعلومات قيمة عندما يحدث خطأ ما.

ما الذي يجعل رسالة الالتزام مفيدة

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

قارن بين هاتين الرسالتين:

• "تحديث تنسيق التاريخ"
• "تغيير تنسيق التاريخ من DD/MM/YYYY إلى YYYY-MM-DD لأن المكتبة الجديدة لا تدعم التنسيق السابق"

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

تتبع رسائل الالتزام الجيدة نمطًا بسيطًا: تصف ما تغير ولماذا تغير. يمكن أن يكون "ماذا" موجزًا. أما "لماذا" فهو الجزء الذي يوفر الوقت أثناء التصحيح، ومراجعة الكود (code review)، ودمج أعضاء الفريق الجدد.

الوسم (Tagging) كأداة تنقل

الالتزامات وحدها لا تكفي لتتبع الإصدارات (releases). قد يحتوي سجل الالتزامات على مئات أو آلاف الإدخالات. العثور على النقطة المحددة التي تم فيها إصدار النسخة 2.3.0 يعني التمرير عبر قائمة طويلة ما لم يكن لديك علامات.

تحل الوسوم (tags) هذه المشكلة. الوسم هو تسمية تُلحق بالتزام معين لتمييز لحظة مهمة. الاستخدام الأكثر شيوعًا هو تمييز إصدار. وسم مثل v1.2.3 أو v2024.05.15 يخبرك بالضبط أي نسخة من الكود كانت قيد التشغيل في وقت معين.

تتبع معظم الفرق التنظيم الدلالي للنسخ (semantic versioning) لوسومها. يستخدم النمط ثلاثة أرقام: رئيسي (major)، وثانوي (minor)، وتصحيحي (patch). يتغير الرقم الرئيسي عند وجود تغييرات جذرية غير متوافقة مع الإصدارات السابقة. يتغير الرقم الثانوي عند إضافة ميزات جديدة ولكن كل شيء لا يزال يعمل مع الإصدار القديم. يتغير الرقم التصحيحي عند تضمين إصلاحات أخطاء فقط. بمجرد النظر إلى رقم الإصدار، تعرف مدى خطورة الترقية.

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

ربط الالتزامات والوسوم بملاحظات الإصدار (Release Notes)

الوسوم تميز الإصدار. ملاحظات الإصدار تخبرك بما هو موجود داخل هذا الإصدار. لا تحتاج ملاحظة الإصدار إلى أن تكون طويلة. كل ما تحتاجه هو سرد التغييرات التي تهم الفريق والمستخدمين: ما هي الميزات الجديدة التي تمت إضافتها، وما هي الأخطاء التي تم إصلاحها، وما إذا كانت هناك أي إجراءات خاصة مطلوبة مثل تغييرات التكوين (configuration changes) أو ترحيل قاعدة البيانات (database migrations).

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

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

قائمة ممارسات عملية لفريقك

إذا لم يكن لدى فريقك هذه العادات بعد، إليك قائمة قصيرة من الأشياء التي يمكنك البدء في فعلها اليوم:

• اكتب رسائل التزام تشرح لماذا تم إجراء التغيير، وليس فقط ما تغير
• ضع وسمًا على كل إصدار برقم إصدار يتبع التنظيم الدلالي للنسخ (semantic versioning)
• احتفظ بملف ملاحظات الإصدار (release notes) الذي يسرد التغييرات لكل إصدار
• تأكد من أن ملاحظة الإصدار تذكر أي تغييرات جذرية (breaking changes) أو خطوات الترحيل (migration steps)
• استخدم نفس تنسيق الوسم عبر جميع المستودعات (repositories) حتى يعرف الجميع ما يتوقعونه

الخلاصة العملية

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