تُفضِّلُ منهجية Agile أن يجري التسليم المستمر للبرمجيات عبر تقسيم عملية تطوير المنتج إلى مكونات أصغر، وأن يجري تسليم هذه المكونات بشكل متكرّر قدر الإمكان.
وبالتالي فإنّ استخدام نهج رشيق يقوم على بناء إصدارات مصغّرة لمنتجك، بوتيرة متكررة أكثر؛ يمكن أن يسرع من عملية تطوير المنتج بصورة عامة. وهذا هو ثالث مبدأ من مبادئ الأجايل الاثني عشر. سنستعرض شرحه وتطبيقاته في هذا المقال الجديد فأهلاً بكم..
المبدأ الثالث من مبادئ الأجايل | التسليم المستمر
ركزت منهجية أجايل على أهمية تسليم مستمر للبرمجيات على شكل أجزاء صغيرة، حيث جاء في المبدأ الثالث من إعلان الاجايل:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
تسليم برمجيات صالحة للاستعمال على فترات منتظمة، من أسبوعين إلى شهرين، مع استحسان المدة الزمنية الأقصر
إنَّ اعتماد هذا النهج المرن، مع دورات تطوير قصيرة المدى، لأجزاء صغيرة من المنتج، سيوفّر وقتاً أقل في صياغة المتطلبات.
وسيؤدي أيضاً لاختصار كميات هائلة من الوثائق المملّة فيما لو اعتمدت منهجية الشلاّل Waterfall على سبيل المثال.
والأهم من ذلك كله، أن هذه المنهجية القائمة على تكرار الإصدارات المتلاحقة، ستخلق مزيداً من الفرص لفرق العمل حتى تتحقّق من صحة الأفكار والممارسات وحتى الاستراتيجيات المطبقة خلال مراحل تطوير المنتج..
وذلك عبر استقبال تغذية راجعة مبكرة ومستمرة من أصحاب المصلحة، الذين يطّلعون على كل إصدار جديد فور صدوره.
كيف نطبّق مبدأ التسليم المستمر عملياً
يطلق مسمى: (سباقات السرعة) أو (التكرارات) على دورات التطوير الرشيقة، التي تُقسّم (المراحل الصغرى) لتطوير المنتج إلى أجزاء أصغر، وهذه الأجزاء يمكن إكمالها في إطار زمني محدد.
(سباقات السرعة sprints)(طبعاً لايتم تداول مصطلح سباقات السرعة أبداً، هو فقط الترجمة الحرفية لكلمة سبرنت)
(التكرارات iterations)
غالباً ما يتراوح هذا الإطار الزمني الواحد (السبرنت) بين أسبوع إلى 4 أسابيع، وهو حقاً سباق سريع، لاسيما إذا ما قارنته بمدة دورات التطوير الطويلة التي تتبعها فرق الشلال في كثير من الأحيان، فهي بهذا المقياس تدخل سباقات ماراثونية مرهقة!
طريقة التسليم المستمر تعمل بكفاءة في الحالات التي تتطلب جدولة وإعادة التنفيذ مراراً وتكراراً، وتوفّر اختصاراً للوقت وللجهد البشري، وأكثر من مجرد تحديد ما يجب القيام به، ثم القيام به آلياً.
يتم تحقيق هذا المبدأ على أرض الواقع من خلال توثيق المتطلبات على (شكل قصص مستخدم User Story) ذات حجم عمل صغير نسبياً، وقابل للإنجاز ثم (النشر Release) بشكل مستقل قدر الإمكان عن بعضهما.
التحقق من قابلية استعمال الأجزاء المسلّمة من المنتج
فيما تشير عبارة “صالحة للاستعمال” إلى آليات اختبار لضمان بقاء المنتج الرقمي يعمل بالشكل الأمثل، على الرغم من الإضافات التراكمية التي تتم بشكل تدريجي في أعقاب كل دورة عمل جديدة (سبرنت جديد).
ويجري التحقق من صلاحيتها للاستعمال عبر عدة اختبارات سنستعرضها في الفقرات الآتية.
اختبارات الوحدة Unit Tests
عبارة عن شيفرة برمجية خاصة، تكتب من قبل فريق التطوير، كل مبرمج عادة يكتب شيفرة الاختبار الخاصة بالشيفرة التي كتبها، الهدف الرئيسي هو اختبار وحدة الكود وسلامة الخرج المتوقع منها،
وبالتالي هو اختبار مؤتمت يخص جزء محدد جداً ذو وظيفة واحدة (method or function).
اختبارات التكامل Integration Tests
يجب أيضاً أن تجري اختبارات للتأكد من سلامة عمل هذه الأجزاء مع بعضها بعضاً، وهي آليات تسمى (اختبارات التكامل Integration Tests).
وعبر كل ما سبق سنضمن بناء منتج رقمي صالح للاستعمال بشكل تراكمي ومستقر.
ممارسة DevOps ضمن السبرنت
من أهم خصائص ممارسة DevOps أنّها تفعّل مبدأ كسر عزلة التخصصات Break Silos، ففي السابق كان يجري الفصل بين الاختصاصات بشكل فجّ، على سبيل المثال مطور التطبيقات كان يقول: وظيفتي أن أكتب الكود فحسب، وأنت يا مسؤول العمليات يتوجب عليك أن تنفذ عملية التسليم deploy..
لكن الآن لا يمكن أن يتم الأمر من دون تعاون بين [أنشطة التطوير البرمجي Dev] من جهة، و[تشغيل العمليات Ops] من جهة أخرى.
أي بين مطور البرمجيات، ومسؤول العمليات، وقد بات هذا التداخل والتعاون عميقاً وأصيلاً لدرجة استحداث منصب اسمه DevOps، يكون شاغله ملماً بكتابة الكود بدرجة كافية، وجيداً جداً في إدارة العمليات.
تسلسل أنشطة تطوير البرمجيات
في الصورة السابقة يظهر تسلسل أنشطة ممارسة DevOps ضمن قسمين رئيسين، الأول تطوير البرمجيات Dev، الذي يبدأ من:
- كتابة الكود code.
- بناء الكود build.
- اختبار الكود test.
تسلسل تشغيل العمليات
بينما يتعلّق القسم الثاني من ممارسة DevOps بالعمليات Ops ويبدأ من:
- أخذ الزيادة الجديدة increment الناتجة من مراحل التطوير، وتجهيزها للنشر = release.
- رفع الزيادة الجديدة increment على السيرفر = deploy.
- التشغيل بشكل متواصل عبر التحقق من أن السيرفر قيد العمل دون انقطاع = operate.
- المراقبة فمثلاً إذ حدث هبوط في أداء السيرفر down يتوجب: إعادة عملية الرفع – إيقاظ السيرفر – … إلى آخره من هذه الخطوات أي = monitoring.
وكما أسلفنا آنفاً، فلكي تكون ممارسة DevOps قابلة للتسليم المبكر المتواصل إلى الزبون، فينبغي أتمتة أكبر قدر ممكن من مراحلها.
ما هو السبرنت ؟ | الخلاصة
في هذه الفقرة سنلخص الحديث عن دورة العمل في مشاريع التطوير البرمجي (السبرنت) وذلك عبر الإجابة عن عدد من الأسئلة المبسطة كما سيلي:
كم المدة المثالية للسبرنت (دورة العمل الواحدة)؟
يفضل أن تكون دورة العمل بالحد الأدنى مدتها أسبوع واحد، وأقصاها شهر واحد.
ما هي مخرجات السبرنت Increments ؟
في نهاية السبرنت يفترض أن نحصل على جزء إضافي جاهز من المنتج الرقمي، وهذه الزيادة في الإنجاز نسميها increment وتمثّل المخرج النهائي على شكل برمجية (سوفت وير) قابل للتشغيل..
أو برمجية ذات قيمة فيها جزء من مميزات المنتج (Features) التي ينبغي للزبون أن يطّلع عليها، ويقدم التغذية الراجعة بشأنها.
ما صفات السبرنت الناجح؟
- مدته لا تتجاوز شهراً واحداً.
- التسليم قبله وفيه وبعده يسير برتم ثابت.
- المُخرج منه يكون زيادة increment في المنتج أو بعض خصائصه.
إدارة التطوير لدورة حياة البرمجيات
وتعرف بمصطلح SDLS
Software Development Lifecycle Management
وهي مجموعة الأدوات والإجراءات المطلوبة لتنفيذ السبرنت. ولتقريب الفكرة فقط، يمكن القول إنها تشبه خط الإنتاج.
- ففي كل سبرنت لدينا خطوات معينة SDLS يجب أن تنفّذ.
- ولا بدّ من تدعيم هذه الـ SDLS بإجراءات مؤتمتة تنفذ آلياً بشكل روتيني ضمن ممارسة DevOps.
ختاماً نلحظ مدى التداخل في مبادئ الأجايل بين المبدأ الثالث والمبدأ الأول على سبيل المثال.
وهذا يدل أهمية فكرة التسليم المستمر أو التسليم المتواصل بما يرضي العميل، ويضمن فائدة راجعة على الفريق بتسريع العمل.
وتطوير منتجات عملية تلبي احتياجات السوق واحتياجات العميل الفعلية.