التحكم في الإصدار الموزع

في تطوير البرمجيات ، يعد التحكم في الإصدارات الموزعة (المعروف أيضًا باسم التحكم الموزع في المراجعة ) شكلاً من أشكال التحكم في الإصدارات حيث يتم عكس قاعدة التعليمات البرمجية الكاملة ، بما في ذلك تاريخها الكامل، على جهاز كمبيوتر كل مطور. ^[1] بالمقارنة مع التحكم المركزي في الإصدارات (راجع monorepo )، فإن هذا يتيح التفرع والدمج الإداري التلقائي ، ويسرع معظم العمليات (باستثناء الدفع والجلب)، ويحسن القدرة على العمل دون اتصال بالإنترنت، ولا يعتمد على موقع واحد للنسخ الاحتياطية. ^{[1] [2] [3]} Git ، نظام التحكم في الإصدارات الأكثر شهرة في العالم، ^[4] هو نظام تحكم في الإصدارات الموزع.

في عام 2010، وصف مؤلف تطوير البرمجيات جويل سبولسكي أنظمة التحكم في الإصدارات الموزعة بأنها "ربما تكون أكبر تقدم في تكنولوجيا تطوير البرمجيات في السنوات العشر الماضية". ^[2]

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

تتضمن مزايا نظام DVCS (مقارنة بالأنظمة المركزية) ما يلي:

• يسمح للمستخدمين بالعمل بشكل منتج عندما لا يكونون متصلين بشبكة.
• العمليات الشائعة (مثل عمليات الالتزام وعرض السجل وعكس التغييرات) أسرع في نظام DVCS، لأنه لا توجد حاجة للتواصل مع خادم مركزي. ^[5] مع نظام DVCS، يكون التواصل ضروريًا فقط عند مشاركة التغييرات بين نظراء آخرين.
• يسمح بالعمل الخاص، بحيث يمكن للمستخدمين استخدام تغييراتهم حتى في المسودات المبكرة التي لا يرغبون في نشرها. ^{[ بحاجة لمصدر ]}
• تعمل النسخ العاملة بشكل فعال كنسخ احتياطية عن بعد، مما يتجنب الاعتماد على جهاز مادي واحد كنقطة فشل واحدة. ^[5]
• يسمح باستخدام نماذج تطوير مختلفة، مثل استخدام فروع التطوير أو نموذج القائد/الملازم. ^[6]
• يسمح بالتحكم المركزي في "إصدار الإصدار" للمشروع ^{[ بحاجة لمصدر ]}
• في مشاريع برمجيات FOSS ، من الأسهل بكثير إنشاء فرع مشروع من مشروع متوقف بسبب صراعات القيادة أو الخلافات في التصميم.

تشمل عيوب نظام DVCS (مقارنة بالأنظمة المركزية) ما يلي:

• إن عملية الخروج الأولية من المستودع تكون أبطأ مقارنة بالخروج في نظام التحكم في الإصدار المركزي، وذلك لأن جميع الفروع وسجل المراجعة يتم نسخها إلى الجهاز المحلي بشكل افتراضي.
• الافتقار إلى آليات القفل التي تعد جزءًا من معظم أنظمة التحكم في الإصدارات المركزية ولا تزال تلعب دورًا مهمًا عندما يتعلق الأمر بالملفات الثنائية غير القابلة للدمج مثل الأصول الرسومية أو الحزم الثنائية المعقدة للغاية المكونة من ملف واحد أو حزم XML (على سبيل المثال مستندات Office وملفات PowerBI وحزم BI الخاصة بـ SQL Server Data Tools وما إلى ذلك). ^{[ بحاجة لمصدر ]}
• مطلوب مساحة تخزين إضافية لكل مستخدم حتى يكون لديه نسخة كاملة من سجل قاعدة التعليمات البرمجية الكاملة. ^[7]
• زيادة التعرض لقاعدة التعليمات البرمجية نظرًا لأن كل مشارك لديه نسخة معرضة للخطر محليًا. ^{[ بحاجة لمصدر ]}

تقدم بعض الأنظمة المركزية في الأصل الآن بعض الميزات الموزعة. يستضيف Team Foundation Server وVisual Studio Team Services الآن مستودعات التحكم في الإصدارات المركزية والموزعة عبر استضافة Git.

على نحو مماثل، تقدم بعض الأنظمة الموزعة الآن ميزات تخفف من مشكلات أوقات الخروج وتكاليف التخزين، مثل نظام الملفات الافتراضي لـ Git الذي طورته شركة Microsoft للعمل مع قواعد بيانات كبيرة جدًا، ^[8] والذي يعرض نظام ملفات افتراضي يقوم بتنزيل الملفات إلى التخزين المحلي فقط عند الحاجة إليها.

هذا القسم يحتاج إلى التوسعة . يمكنك المساعدة بإضافة المزيد إليه. ( يونيو 2008 )

النموذج الموزع مناسب بشكل عام للمشروعات الكبيرة التي تضم مطورين مستقلين جزئيًا، مثل مشروع نواة لينكس، لأن المطورين يمكنهم العمل بشكل مستقل وإرسال تغييراتهم للدمج (أو الرفض). تسمح هذه المرونة بتبني تدفقات عمل مخصصة للمساهمة في الكود المصدر، مثل تدفق عمل المُدمِج ، وهو الأكثر استخدامًا. على عكس النموذج المركزي حيث يجب على المطورين تسلسل أعمالهم لتجنب المشكلات مع الإصدارات المختلفة، في النموذج الموزع، يمكن للمطورين استنساخ تاريخ الكود بالكامل على أجهزتهم المحلية. يقومون أولاً بإرسال تغييراتهم إلى مستودعاتهم المحلية، وإنشاء "مجموعات تغييرات"، قبل دفعها إلى المستودع الرئيسي. يتيح هذا النهج للمطورين العمل محليًا ومنفصلًا، مما يجعله أكثر ملاءمة للفرق الموزعة. ^[9]

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

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

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

تُقدم المساهمات في مستودع التعليمات البرمجية المصدرية الذي يستخدم نظام التحكم في الإصدارات الموزعة عادةً عن طريق طلب سحب ، والمعروف أيضًا باسم طلب الدمج . ^[10] يطلب المساهم من المشرف على المشروع سحب تغيير التعليمات البرمجية المصدرية، ومن هنا جاء اسم "طلب السحب". يجب على المشرف دمج طلب السحب إذا أصبحت المساهمة جزءًا من قاعدة المصدر. ^[11]

يقوم المطور بإنشاء طلب سحب لإخطار المشرفين بتغيير جديد؛ ويرتبط كل طلب سحب بسلسلة تعليقات. وهذا يسمح بمناقشة مركزة لتغييرات الكود . طلبات السحب المرسلة تكون مرئية لأي شخص لديه حق الوصول إلى المستودع. يمكن للمشرفين قبول أو رفض طلب السحب. ^[12]

بمجرد مراجعة طلب السحب والموافقة عليه، يتم دمجه في المستودع. اعتمادًا على سير العمل المحدد، قد يلزم اختبار الكود قبل تضمينه في الإصدار الرسمي. لذلك، تحتوي بعض المشاريع على فرع خاص لدمج طلبات السحب غير المختبرة. ^{[11] [13]} تقوم مشاريع أخرى بتشغيل مجموعة اختبار آلية على كل طلب سحب، باستخدام أداة تكامل مستمرة ، ويتحقق المراجع من أن أي كود جديد يحتوي على تغطية اختبار مناسبة.

كانت أنظمة التحكم في الإصدارات المفتوحة المصدر الأولى تتضمن Arch و Monotone و Darcs . ومع ذلك، لم تكن أنظمة التحكم في الإصدارات المفتوحة المصدر شائعة جدًا حتى إصدار Git و Mercurial .

تم استخدام BitKeeper في تطوير نواة Linux من عام 2002 إلى عام 2005. ^[14] تم تطوير Git ، وهو الآن نظام التحكم في الإصدارات الأكثر شعبية في العالم، ^[4] بسبب قرار الشركة التي صنعت BitKeeper بإلغاء الترخيص المجاني الذي استفاد منه لينوس تورفالدس وبعض مطوري نواة Linux الآخرين سابقًا. ^[14]

• مقال عن أنظمة التحكم في المراجعة المختلفة، وخاصة القسم "الأنظمة المركزية مقابل الأنظمة اللامركزية لإدارة سلسلة التوريد"
• مقدمة لأنظمة التحكم في الإصدارات الموزعة - مقالة IBM Developer Works