تناقش هذه الصفحة ماهية أنظمة الإصدار، ووظيفتها، والسبب الذي يدفعك إلى استخدام نظام إنشاء، والسبب في أن برامج التحويل البرمجي والنصوص البرمجية ليست الخيار الأفضل لأن مؤسستك تبدأ في التوسع. فهي مُخصَّصة لمطوّري البرامج الذين ليس لديهم خبرة كبيرة في استخدام نظام الإصدار.
ما المقصود بنظام الإصدار؟
بشكل أساسي، تحتوي جميع أنظمة الإصدارات على غرض مباشر: وهو تحويل رمز المصدر الذي كتبه المهندسون إلى ثنائيات قابلة للتنفيذ يمكن قراءتها بواسطة الأجهزة. لا تقتصر أنظمة البناء على الرموز التي يكتبها البشر فحسب؛ كما تسمح للآلات بإنشاء الإصدارات تلقائيًا، سواء للاختبارات أم من أجل الإنتاجات. في مؤسسة تضم آلاف المهندسين، من الشائع أن يتم تشغيل معظم الإصدارات تلقائيًا بدلاً من تشغيلها مباشرةً من قبل مهندسين.
هل يتعذّر عليّ استخدام التجميع؟
قد لا تكون الحاجة إلى نظام إصدار واضحة على الفور. لا يستخدم معظم المهندسين
نظام إصدار أثناء تعلُّم الترميز، فمعظم الاستدعاءات تبدأ باستدعاء أدوات مثل gcc أو javac مباشرةً من سطر الأوامر أو ما يعادله في
ميزة متكاملة بيئة التطوير (IDE). وطالما أنّ رمز المصدر بالكامل في الدليل نفسه، سيكون الأمر على ما يرام:
javac *.java
توجِّه هذه المجموعة البرمجي لجافا إلى التقاط كل ملف مصدر جافا في الدليل الحالي وتحويله إلى ملف فئة ثنائية. في أبسط الحالات، هذا هو كل ما تحتاج إليه.
ومع ذلك، فبعد توسيع الرمز، تبدأ المضاعفات. javac ذكي بما يكفي للبحث في الأدلة الفرعية للدليل الحالي للعثور على الرمز المراد استيراده. ولا تتوفر طريقة للعثور على الرمز المخزَّن في أجزاء أخرى من نظام الملفات (ربما مكتبة تشاركها عدّة مشاريع). كما أنه يعرف فقط كيفية إنشاء شفرة جافا. غالبًا ما تتضمّن الأنظمة الكبيرة أجزاء مختلفة مكتوبة بلغة مختلفة للبرمجة تضمّ شبكات تبعية تعتمد على هذه الأجزاء، ما يعني أنه لا يمكن لأي مجمّع لغة واحدة بناء النظام بأكمله.
بعد أن تتعامل مع الرمز من لغات متعدّدة أو وحدات تجميع متعدّدة، لن يكون رمز البناء عملية من خطوة واحدة بعد ذلك. يجب الآن تقييم ما يعتمد عليه الرمز ووضع هذه القطع بالترتيب الصحيح، ربما باستخدام مجموعة مختلفة من الأدوات لكل جزء. في حال تغيُّر أي تبعيات، عليك تكرار هذه العملية لتجنُّب ذلك حسب البرامج الثنائية القديمة. وبالنسبة إلى قاعدة الرموز ذات الحجم المعتدل، تصبح هذه العملية شاقة وعرضة للخطأ بسرعة.
لا يعرف المجمّع أيضًا أي شيء حول كيفية التعامل مع العناصر التابعة الخارجية، مثل ملفات JAR التابعة لجهات خارجية في جافا. وبدون نظام إصدار،
يمكنك إدارة هذا عن طريق تنزيل التبعية من الإنترنت، ولصقها
في مجلد lib على محرك الأقراص الثابتة، وإعداد المجمّع لقراءة المكتبات من هذا الدليل. ومع مرور الوقت، يكون من الصعب الحفاظ على التحديثات وإصدارات ومصدر هذه التبعيات الخارجية.
ماذا عن النصوص البرمجية؟
لنفترض أن مشروع هواية يبدأ ببساطة كافية بحيث يمكنك إنشاؤه من خلال تجميع البيانات فقط، ولكنك ستبدأ في مواجهة بعض المشاكل التي سبق توضيحها. ربما لا تزال تعتقد أنّك لا تحتاج إلى نظام إصدار ويمكنك برمجة تنفيذ الأجزاء المملة باستخدام بعض النصوص البرمجية البسيطة وهي تعتني ببناء الأشياء بالترتيب الصحيح. قد يساعدك هذا الأمر لفترة من الوقت، ولكن سرعان ما تواجه مشاكل أكثر:
يصبح شاقًا. مع ازدياد تعقيد النظام لديك، تبدأ في قضاء معظم الوقت تقريبًا في العمل على النصوص البرمجية للإصدار كما في الترميز الفعلي. تصحيح الأخطاء في النصوص البرمجية شاقة، مع ظهور المزيد من عمليات الاختراق فوق بعضها البعض.
إنها بطيئة. للتأكّد من أنّك لم تعتمد عن غير قصد على المكتبات القديمة، يكون لديك نص برمجي للإصدارات بناءً على كل تبعية في كل مرة تشغّلها فيها. يجب التفكير في إضافة منطق لتحديد الأجزاء التي يجب إعادة إنشائها، ولكن قد يبدو ذلك معقّدًا جدًا وعرضة للخطأ في النص البرمجي. أو يمكنك التفكير في تحديد الأجزاء التي يجب إعادة إنشائها في كل مرة، ولكن بعد ذلك، ستعود إلى البداية.
لدينا أخبار سارّة لك: فقد حان وقت إطلاق إصدار جديد. من الأفضل اكتشاف كل الوسيطات التي تحتاج إلى تمريرها إلى الأمر jar لإنشاء الإصدار النهائي. وتذكّر كيفية تحميل الفيديو وإرساله إلى المستودع المركزي. ويمكنك أيضًا إنشاء تعديلات الوثائق وإرسالها، وإرسالها إلى المستخدمين. اِمْمْمْ، رَدَّتْ نَتِيجِةْ نَصّْ تَانْيِينْ دَهْ تَانِي...
كارثة تعطُّل محرك الأقراص الثابتة وعليك إعادة إنشاء نظامك بالكامل. هل كنت ذكيًا بما فيه الكفاية للإبقاء على جميع الملفات المصدر في التحكم في الإصدار، ولكن ماذا عن تلك المكتبات التي نزّلتها؟ هل يمكنك العثور عليها جميعًا مرة أخرى والتأكد من أنها الإصدار نفسه عند تنزيلها؟ غالبًا ما كانت النصوص البرمجية تعتمد على أدوات محددة تم تثبيتها في أماكن معينة، فهل يمكنك استعادة البيئة نفسها حتى تعمل النصوص البرمجية مرة أخرى؟ ماذا عن كل هذه المتغيرات في البيئة التي ضبطتها قبل وقت طويل لكي يعمل المحوّل بشكل صحيح ثم نسيته؟
على الرغم من حدوث هذه المشاكل، فإن مشروعك ناجح بما يكفي لكي تتمكن من بدء توظيف المزيد من المهندسين. والآن بعد أن أدركت أن الأمر لا يتطلب كارثة حتى تظهر المشاكل السابقة، بل عليك إجراء نفس عملية التشغيل المؤلمة في كل مرة ينضم فيها مطوّر برامج جديد إلى فريقك. وعلى الرغم من الجهود التي تبذلها، لا تزال هناك اختلافات طفيفة في نظام كل شخص. كثيرًا ما لا يعمل ما يعمل على جهاز أحد الأشخاص على جهاز آخر، وفي كل مرة يستغرق الأمر بضع ساعات من مسارات أدوات تصحيح الأخطاء أو إصدارات المكتبة لمعرفة أين الفرق.
وتقرّر أنك تريد تشغيل نظام الإصدار تلقائيًا. من الناحية النظرية، الأمر بسيط مثل الحصول على جهاز كمبيوتر جديد وإعداده لتشغيل النص البرمجي للإصدار كل ليلة باستخدام cron. لا تزال بحاجة إلى إجراء عملية إعداد شاقة، ولكنها الآن ليست لديك ميزة في قدرة الإنسان على اكتشاف المشاكل البسيطة وحلّها. والآن، في كل يوم تدخل إليه، تلاحظ حدوث فشل في تصميم برنامج الليلة الماضية لأن مطوّر البرامج قد أجرى تغييرًا في نظامه ولكنه لم يعمل في نظام الإصدار المبرمج. في كل مرة، يكون الحل بسيطًا، ولكن كثيرًا ما يحدث ذلك لدرجة أن ينتهي الأمر بقضاء الكثير من الوقت يوميًا في اكتشاف هذه الإصلاحات البسيطة وتطبيقها.
تصبح الإصدارات أبطأ وأبطأ مع نمو المشروع. يومًا واحدًا، بينما كنت تنتظر اكتمال التشييد، نظرت بحماس إلى سطح المكتب الخامل ل زميلك في العمل، والذي هو في عطلة، وأمل أن تكون هناك طريقة للاستفادة من كل هذه العمليات الحسابية المهدورة. قُوَّة
لقد واجهت مشكلة تقليدية على نطاق واسع. بالنسبة إلى مطوّر برامج واحد يعمل على ما يصل إلى مائتَي سطر من الرموز لمدة أسبوع أو أسبوعين على الأكثر (وربما تكون هذه هي التجربة الكاملة حتى الآن لمطوّر برامج للمبتدئين تخرج للتوّ)، التجميع هو كل ما تحتاج إليه. قد تأخذك النصوص البرمجية أبعد قليلاً. وعند الحاجة إلى التنسيق بين عدّة مطوّري برامج وأجهزتهم، لا يكفي أن يكون النص البرمجي المثالي كافيًا لأنّه من الصعب جدًا مراعاة الاختلافات الطفيفة في هذه الأجهزة. في هذه المرحلة، يتوقف هذا النهج البسيط، وقد حان الوقت للاستثمار في نظام تصميم حقيقي.