Git للبيانات الميدانية

مشكلة التزامن

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

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

كيف تتعامل معظم برامج الميدان مع هذا الأمر

هناك ثلاث طرق شائعة، ولكل منها تكلفتها.

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

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

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

نموذج التحكم في الإصدارات

يستمد نهجنا بشكل مباشر من طريقة عمل فرق تطوير البرمجيات. فالمفاهيم تتطابق تمامًا.

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

الإرسال هو التثبيت. عندما يكون العامل جاهزًا، ينقر على زر «إرسال». يتم إرسال جميع التغييرات المعلقة إلى الخادم كإصدار واحد — مجموعة مترابطة من التغييرات مزودة بطابع زمني وهوية المرسل. هذا هو التثبيت. وهو عملية متكاملة: إما أن يتم تنفيذ جميع التغييرات أو لا يتم تنفيذ أي منها.

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

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

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

كيف يبدو ذلك في الواقع

هناك فريقان يعملان على نفس شبكة الألياف الضوئية. الفريق «أ» يعمل في الميدان على تعديل مسارات الكابلات في الجزء الشمالي. أما الفريق «ب» فيعمل تحت الأرض على تعديل نقاط الربط في الجزء المركزي. وكلا الفريقين غير متصلين بالشبكة.

ينتهي فريق «أ» من العمل ويعود إلى العمل عبر الإنترنت. ويقوم الفريق بإرسال نسخته. ويقبل الخادم النسخة — دون أي تعارضات، لأن أحداً لم يقم بتعديل تلك الميزات منذ آخر مزامنة قام بها فريق «أ». ويقوم المسؤول بمراجعة الاختلافات، ويتأكد من أن تغييرات مسار الكابلات منطقية، ثم يوافق عليها. وتدخل التغييرات حيز التنفيذ.

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

إجمالي البيانات المفقودة: صفر. إجمالي الوقت المستغرق في المطابقة اليدوية: دقائق. إجمالي الميزات التي تم استبدالها دون إشعار: صفر.

قارن ذلك بالبدائل الأخرى. في حالة تطبيق مبدأ «آخر كتابة هي الفائزة»، كان تقديم الفريق ب سيحلّ محل تغييرات مسار الكابلات التي أجراها الفريق أ دون أن يلاحظ أحد. أما في حالة قفل السجلات، لما استطاع أحد الفريقين إجراء تعديلات بينما كان الآخر يعمل تحت الأرض. أما في حالة «تجنب التداخل على أساس المنطقة»، لكان الجزء المتداخل يمثل كابوسًا تنسيقيًا يتعين التعامل معه عبر المكالمات الهاتفية وجداول البيانات.

«العمل دون اتصال بالإنترنت أولاً»، وليس «التسامح مع العمل دون اتصال بالإنترنت»

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

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

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

ملخص

• تعاني إدارة البيانات الميدانية من نفس مشكلة التزامن التي حلتها عمليات تطوير البرمجيات منذ عقود: قيام عدة أشخاص بتحرير نفس المحتوى، غالبًا دون اتصال بالإنترنت، مع مخاطر حدوث عمليات استبدال صامتة.
• مبدأ «آخر تعديل هو الفائز» يؤدي إلى فقدان البيانات دون علم. ويمنع قفل السجلات العمل دون اتصال بالإنترنت. كما تفشل آلية «تجنب التداخل» القائمة على المناطق عند كل حدود وتداخل.
• نموذج التحكم في الإصدارات — المسودات المحلية، عمليات التسليم الفورية، مراجعة المسؤول، اكتشاف التعارضات، السجل الدائم — ينطبق مباشرة من تطوير البرمجيات إلى العمليات الميدانية.
• يتم تخزين التعديلات الميدانية محليًا حتى يقوم العامل بإرسالها. تمر عمليات الإرسال غير الإدارية عبر قائمة انتظار للمراجعة. يتم اكتشاف التعارضات على الخادم وعرضها لحلها بشكل صريح — لا توجد عمليات استبدال صامتة، ولا فقدان للبيانات.
• يتم الاحتفاظ بكل إصدار تم الالتزام به مع اسم المرسل والطابع الزمني والموافق. يتم ضغط سجل الإصدارات ولكن لا يتم حذفه أبدًا. يمكن إعادة بناء حالة أي ميزة في أي وقت.
• وضع عدم الاتصال بالإنترنت هو وضع العمل الافتراضي، وليس استثناءً يجب التعامل معه. يفترض النظام أن المستخدمين عادةً ما يكونون غير متصلين ويقومون بالمزامنة من حين لآخر — وهو ما يتطابق مع كيفية عمل الميدان فعليًا.