ما المقصود بإدارة التعليمات البرمجية المصدرية؟

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

تتضمن إدارة التعليمات البرمجية المصدرية الميزات الأساسية التالية:

• المستودع

• التحكم في الإصدار

• التفرع

• تسجيل التغييرات

• الدمج

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

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

يمكن لفرق تطوير البرمجيات الاختيار بين بنيتين رئيسيتين للمستودعات:

• Monorepo: يضم عدة مشاريع داخل مستودع واحد. يُستخدم هذا النهج عادةً مع العناصر شديدة الترابط.

• Polyrepo: تُحفظ المشاريع في مستودعات منفصلة، بحيث يكون لكل مشروع مستودعه الخاص. تُستخدم هذه البنية عادةً مع العناصر ضعيفة الترابط، مثل الخدمات المُصغَّرة.

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

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

يعمل الفرع الرئيسي بمثابة “الجذع” الذي تنشأ منه جميع الفروع وتعود لتندمج فيه. ويحتوي على أحدث إصدار مستقر أو إصدار من التعليمات البرمجية جاهز للإنتاج.

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

تسجّل كل عملية مجموعة من التغييرات التي تطرأ على التعليمات البرمجية المصدرية في سجل المستودع. ومن أفضل الممارسات أن تقتصر كل عملية تسجيل للتغييرات على تغيير منطقي واحد يعالج مهمة محددة واحدة فقط، وأن تجتاز جميع الاختبارات المطلوبة، وأن تُجمَّع التعليمات البرمجية أو تُبنى بنجاح، بما يضمن بقاء قاعدة التعليمات البرمجية في حالة صالحة. يجب أن تكون كل عملية تسجيل للتغييرات مصحوبة برسالة واضحة وذات معنى توضّح ما تغيّر وسبب تغييره.

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

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

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

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

تُعد إدارة التعليمات البرمجية المصدرية عنصرًا أساسيًا في معظم مراحل دورة حياة تطوير البرمجيات. تساعد SCM على التعامل السليم مع التعليمات البرمجية طوال مراحل SDLC.

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

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

تعمل SCM جنبًا إلى جنب مع التكامل المستمر (CI)، وهو الجزء الأول من مسار CI/CD وإحدى السمات المميزة لمنهجية DevOps. عند رفع التعليمات البرمجية المصدرية إلى المستودع، تُطلق خوادم CI مثل CircleCI وGitHub Actions وGitLab CI/CD وJenkins عملية البناء، فتؤتمت تجميع التعليمات البرمجية وحزمها. تُجري أدوات CI اختبارات مؤتمتة للتأكد من أن التغييرات لا تتسبب في تعطيل قاعدة التعليمات البرمجية، ولتحديد أي مشكلات قبل وصولها إلى بيئة الإنتاج.

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

من خلال النشر المستمر، تُنشر التغييرات التي تم التحقق من صحتها بنجاح تلقائيًا في بيئة الإنتاج. إذا فشلت عملية نشر، تعمل هذه الأنظمة جميعًا (SCM وCI/CD والنشر المستمر) معًا للرجوع بسلاسة إلى إصدار مستقر سابق.

تسهم SCM في تعزيز سلاسة دورات الإصدارات المستقبلية. وتُعد عنصرًا أساسيًا في إدارة قواعد التعليمات البرمجية مع تطورها من خلال إصلاح الأخطاء البرمجية والتحسينات والميزات الجديدة والتصحيحات وتحسينات الأداء وإعادة هيكلة التعليمات البرمجية وغيرها من التحديثات.

يمكن لفرق هندسة البرمجيات الاستفادة من المزايا التالية التي توفرها أنظمة SCM:

• التحكم في الوصول والتدقيق

• النسخ الاحتياطي لقاعدة التعليمات البرمجية

• تحسين جودة التعليمات البرمجية

• التعاون الفعّال

• سرعة إصدار البرمجيات

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

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

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

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

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

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

من خلال SCM، يمكن لكل عضو في الفريق العمل بصورة مستقلة ومتزامنة مع الآخرين. وبما أن إدارة التعليمات البرمجية المصدرية تتكامل بسلاسة مع مسارات CI/CD، تصبح دورات التسليم أسرع. يمكن لفرق التطوير الاستجابة سريعًا لمشكلات بيئة الإنتاج وإصدار التصحيحات في وقت أقرب.

كانت أداة Source Code Control System (SCCS) من أوائل أدوات SCM، وقد طوّرها مبرمج الكمبيوتر Marc Rochkind في Bell Labs خلال سبعينيات القرن العشرين. فرض SCCS آلية قفل صارمة لا تسمح إلا لشخص واحد في كل مرة بتعديل ملف، وكانت المراجعات تُخزَّن في صورة نسخ كاملة. ثم جاء Revision Control System (RCS) ليُدخل تحسينات على SCCS؛ إذ كان يحتفظ بأحدث إصدار من الملف ولا يخزن سوى الفروق بين الإصدارات الأقدم.

في ثمانينيات القرن العشرين، ظهر Concurrent Versions System (CVS). استند إلى RCS واتبع نموذج مستودع قائمًا على بنية العميل والخادم، مما أتاح التزامن والدمج.

ظهر Subversion (SVN) في أوائل العقد الأول من القرن الحادي والعشرين بهدف تقديم "CVS أفضل". احتفظ بالكثير من وظائف CVS، وأضاف ميزات مثل تسجيل التغييرات في وحدات مستقلة وإخضاع الأدلة للتحكم في الإصدارات. ويُعرف رسميًا باسم Apache Subversion، وتتولى Apache Software Foundation حاليًا صيانته كمشروع مفتوح المصدر، ولا يزال مستخدمًا على نطاق واسع.

شهد منتصف العقد الأول من القرن الحادي والعشرين ظهور أنظمة لامركزية للتحكم في الإصدارات. قاد Linus Torvalds، مبتكر Linux، تطوير Git، وهو نظام موزع ومفتوح المصدر للتحكم في الإصدارات صُمم في الأصل لنواة Linux. بدلًا من تخزين الملفات وتعديلاتها، يحفظ Git لقطات لحالة المشروع بمرور الوقت. يمكن استخدامه بمفرده من خلال تشغيل أوامر Git في سطر الأوامر، كما يضم منظومة غنية من الأدوات، تشمل واجهات المستخدم الرسومية (GUIs) وعمليات التكامل مع بيئات التطوير المتكاملة (IDE).

يشكّل Git الأساس لبعض أشهر أدوات إدارة التعليمات البرمجية المصدرية اليوم، ومنها Bitbucket وGitHub وGitLab. لكن مع قيام وكلاء ذكاء اصطناعي الآن بتوليد كميات هائلة من التعليمات البرمجية، تعيد بعض الشركات النظر في SCM. على سبيل المثال، يصف Cursor’s Origin نفسه بأنه "منصة Git لعصر قائم على الوكلاء"، بينما يربط Zed’s DeltaDB تغييرات التعليمات البرمجية بالمحادثة مع الوكيل التي نتجت عنها تلك التغييرات. وبالمثل، تعمل GitLab على ما تسميه "إدارة التعليمات البرمجية المصدرية من الجيل التالي" لمجموعات كبيرة من وكلاء البرمجة.