اختيار إصدارات البرمجيات للنشر

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

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

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

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

لنبدأ بالحالة الثانية إذ يسهل أكثر تقديم توجيه بشأنها.

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

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

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

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

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

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

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

إذا فكرنا في أرقام إصدارات البرامج كالأعمار، يتضح هذا. Linux 3.1 أقدم بكثير من حيث نضج البرامج من Linux 2.4. لديه عقد إضافي من التطوير.

لنستخدم مثالاً من العالم الحقيقي وثيق الصلة باليوم. أنت في متجر على وشك تثبيت خادمك (خوادمك) الأول. Windows Server 2012 R2 للتو أُصدر. هل يجب أن تثبّت Windows Server 2008 أو 2008 R2 (2010) أو Server 2012 أو Server 2012 R2 (أواخر 2013)؟

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

Windows Server 2008 كان Windows NT 6.0. Windows Server 2008 R2 كان Windows NT 6.1، وهو بوضوح مراجعة ثانوية أو حتى "تصحيح" للإصدار السابق. Windows Server 2012 كان Windows NT 6.2 وWindows Server 2012 R2 الحالي هو Windows NT 6.3. إذا استخدمنا أرقام المراجعة بدلاً من أسماء التسويق، سيبدو الأمر شبه مجنون أن نثبّت عمداً إصداراً قديماً أقل نضجاً وتحديثاً وتصحيحاً. نريد أحدث التحديثات وأحدث إصلاحات الأخطاء وأحدث المشكلات الأمنية التي تمت معالجتها.

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

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

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

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

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

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

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

لتطبيق مثال Microsoft مرة أخرى، يمكننا أخذ منظمة نشرت Windows XP اليوم. تقرر الشركة الاستثمار في دورة تحديث إلى إصدار أحدث لا مجرد الاستمرار في التصحيح. هناك عدة إصدارات من منصة Windows لسطح المكتب لا تزال تحت الدعم الفعال من Microsoft. وتشمل هذه Windows Vista وWindows 7 وWindows 8 وWindows 8.1. التحديث إلى أحد الإصدارات الأقل حداثة يؤدي إلى وقت أقصر قبل نهاية عمر ذلك الإصدار مما يزيد المخاطر التنظيمية، كما أن استخدام إصدارات أقدم يعني الاستمرار في الاستثمار في تقنيات متقادمة مما يعني زيادة الدَّين التقني وضعف الوصول إلى الميزات الجديدة التي قد تُثبت فائدتها عند توفرها. في هذا المثال بالذات، تُعتبر الإصدارات الأحدث أيضاً أكثر أماناً وتتطلب موارد أجهزة أقل.

كل شركة بحاجة إلى إيجاد التوازن الصحيح لها في دورات تحديث البرامج الحالية. كل شركة وكل حزمة برامج مختلفة. برامج المؤسسات مثل Microsoft Windows وMicrosoft Office أو قاعدة بيانات Oracle تتبع هذه النماذج جيداً. المشاريع البرمجية الصغيرة وتلك التي تقترب من النطاق المخصص قد يكون لها دورة إصدار أكثر ديناميكية وأقل قابلية للتنبؤ لكنها ستتبع عموماً معظم هذه القواعد. فكّر في تطبيق التعاطف مع عملية تطوير البرامج لفهم كيف يمكنك أنت ومورد البرامج الخاص بك أفضل شراكة لتقديم أكبر قيمة لمؤسستك وادمج ذلك مع حاجتك إلى تقليص الدَّين التقني للاستفادة من استثمارك في البرامج بأفضل طريقة ممكنة لمؤسستك.

لكن القواعد العامة بسيطة نسبياً:

عند النشر الجديد أو التحديث، استهدف أحدث إصدار معقول من البرامج. استخدم أي فرصة للنشر للتخلص من الدَّين التقني قدر الإمكان.

عندما توجد البرامج بالفعل، وازن عوامل مثل الجهد البشري وتكاليف الترخيص واتساق البيئة واختبار التوافق مقابل الفوائد في الميزات والأداء والدَّين التقني.