إذا كانت شركتك تقدم للتو أدوات DevOps أو CI/CD، فقد يكون من المفيد لك التعرف على الأخطاء الأكثر شيوعًا حتى لا تكررها ولا تدوس على أشعل النار لشخص آخر.
فريق ترجمت المقال .
عدم الاستعداد لتغيير الثقافة والعمليات
إذا نظرت إلى الرسم البياني الدوري ، فمن الواضح أن الاختبار في ممارسات DevOps هو نشاط مستمر، وجزء أساسي من كل عملية نشر.
مخطط دورة DevOps اللانهائية
يعد الاختبار وضمان الجودة أثناء التطوير والتسليم جزءًا أساسيًا من كل ما يفعله المطورون. وهذا يتطلب تحولًا في العقلية لدمج الاختبار في كل مهمة.
يصبح الاختبار جزءًا من العمل اليومي لكل عضو في الفريق. الانتقال إلى الاختبار المستمر ليس بالأمر السهل، عليك أن تكون مستعدًا لذلك.
قلة التغذية الراجعة
تعتمد فعالية DevOps على ردود الفعل المستمرة. التحسين المستمر مستحيل إذا لم يكن هناك مجال للتعاون والتواصل.
تجد الشركات التي لا تنظم اجتماعات بأثر رجعي صعوبة في تطبيق ثقافة التغذية الراجعة المستمرة في CI/CD. يتم عقد اجتماعات بأثر رجعي في نهاية كل تكرار، حيث يناقش أعضاء الفريق ما سار بشكل جيد وما سار بشكل سيئ. تعد الاجتماعات بأثر رجعي أساس Scrum/Agile، ولكنها ضرورية أيضًا لـ DevOps.
وذلك لأن الاجتماعات بأثر رجعي تغرس عادة تبادل الملاحظات والآراء. من أهم النقاط في البداية هو تنظيم اجتماعات رجعية متكررة حتى تصبح مفهومة ومألوفة للفريق بأكمله.
عندما يتعلق الأمر بجودة البرمجيات، فإن جميع أعضاء الفريق مسؤولون عن الحفاظ عليها. على سبيل المثال، يمكن للمطورين كتابة اختبارات الوحدة وأيضًا كتابة التعليمات البرمجية مع وضع القابلية للاختبار في الاعتبار، مما يساعد على تقليل المخاطر من البداية.
إحدى الطرق البسيطة لتعكس التغيير في التفكير في الاختبار هي استدعاء مختبري ضمان الجودة وليس اختبار الجودة، ولكن اختبار البرمجيات أو مهندس الجودة. قد يبدو هذا التغيير بسيطًا جدًا أو حتى غبيًا. لكن وصف شخص ما بأنه "شخص يضمن جودة البرمجيات" يعطي فكرة خاطئة عن المسؤول عن جودة المنتج. في ممارسات Agile وCI/CD وDevOps، يتحمل الجميع مسؤولية جودة البرامج.
هناك نقطة أخرى مهمة وهي فهم ما تعنيه الجودة للفريق بأكمله ولكل من أعضائه والمنظمة وأصحاب المصلحة.
سوء فهم لإكمال المرحلة
إذا كانت الجودة عملية مستمرة وعامة، فإن هناك حاجة إلى فهم مشترك لاكتمال المرحلة. كيف تعرف متى انتهت المرحلة؟ ماذا يحدث عندما يتم وضع علامة على خطوة كمكتملة على لوحة Trello أو لوحة كانبان الأخرى؟
يعد تعريف Done (DoD) أداة قوية في سياق CD DevOps/CI. فهو يساعد على فهم أفضل لمعايير الجودة لما وكيف يبني الفريق.
يجب أن يقرر فريق التطوير معنى كلمة "تم". إنهم بحاجة إلى الجلوس وإعداد قائمة بالخصائص التي يجب استيفاؤها في كل مرحلة حتى تعتبر كاملة.
تجعل وزارة الدفاع العملية أكثر شفافية وتسهل تنفيذ CI/CD إذا تم فهمها من قبل جميع أعضاء الفريق وتم الاتفاق عليها بشكل متبادل.
عدم وجود أهداف واقعية ومحددة بوضوح
هذه واحدة من النصائح الأكثر اقتباسًا، ولكنها تستحق التكرار. لتحقيق النجاح في أي مسعى رئيسي، بما في ذلك CI/CD أو DevOps، تحتاج إلى تحديد أهداف واقعية وقياس الأداء مقابلها. ما الذي تحاول تحقيقه باستخدام CI/CD؟ هل يسمح هذا بإصدارات أسرع وبجودة أفضل؟
يجب ألا تكون أي أهداف محددة شفافة وواقعية فحسب، بل يجب أيضًا أن تكون متسقة مع الأنشطة الحالية للشركة. على سبيل المثال، كم مرة يحتاج عملاؤك إلى تصحيحات أو إصدارات جديدة؟ ليست هناك حاجة لزيادة تحميل العمليات وإصدارها بشكل أسرع إذا لم تكن هناك فائدة إضافية للمستخدمين.
بالإضافة إلى ذلك، لا تحتاج دائمًا إلى تنفيذ كل من CD وCI. على سبيل المثال، لا يجوز للشركات الخاضعة لرقابة صارمة مثل البنوك والعيادات الطبية أن تعمل إلا مع CI.
يُعد CI بمثابة نقطة انطلاق جيدة لأي شركة تنفذ DevOps. وعندما يتم تنفيذه، تتغير أساليب الشركات في تسليم البرامج بشكل كبير. بمجرد إتقان CI، يمكنك التفكير في تحسين العملية بأكملها، وزيادة سرعة الطرح والتغييرات الأخرى.
بالنسبة للعديد من المؤسسات، يعد CI وحده كافيًا، ويجب تنفيذ التطوير المستمر فقط إذا كان يضيف قيمة.
عدم وجود لوحات المعلومات والمقاييس المناسبة
بمجرد تحديد أهدافك، يمكن لفريق التطوير إنشاء لوحة معلومات لقياس مؤشرات الأداء الرئيسية. قبل تطويره، يجدر تقييم المعلمات التي سيتم رصدها.
التقارير والتطبيقات المختلفة مفيدة لأعضاء الفريق المختلفين. يهتم Scrum Master أكثر بالحالة والوصول. بينما قد تهتم الإدارة العليا بمعدل الإرهاق لدى المتخصصين.
تستخدم بعض الفرق أيضًا لوحات المعلومات ذات المؤشرات الحمراء والصفراء والخضراء لتقييم حالة CI/CD لفهم ما إذا كانوا يفعلون كل شيء بشكل صحيح أو ما إذا كان هناك خطأ. اللون الأحمر يعني أنك بحاجة إلى الانتباه إلى ما يحدث.
ومع ذلك، إذا لم يتم توحيد لوحات المعلومات، فقد تكون مضللة. قم بتحليل البيانات التي يحتاجها الجميع، ثم قم بإنشاء وصف موحد لما تعنيه. اكتشف ما هو أكثر منطقية بالنسبة لأصحاب المصلحة: الرسومات أو النصوص أو الأرقام.
لا توجد اختبارات يدوية
تضع أتمتة الاختبار الأساس لخط أنابيب CI/CD جيد. لكن الاختبار الآلي في جميع المراحل لا يعني أنه لا ينبغي عليك إجراء الاختبار اليدوي.
لإنشاء خط أنابيب CI/CD فعال، تحتاج أيضًا إلى اختبارات يدوية. سيكون هناك دائمًا بعض جوانب الاختبار التي تتطلب التحليل البشري.
من المفيد التفكير في دمج جهود الاختبار اليدوي في خط الأنابيب الخاص بك. بمجرد اكتمال الاختبار اليدوي لبعض حالات الاختبار، يمكنك الانتقال إلى مرحلة النشر.
لا تحاول تحسين الاختبارات
يتطلب مسار CI/CD الفعال الوصول إلى الأدوات المناسبة، سواء كانت إدارة الاختبار أو التكامل والمراقبة المستمرة.
يهدف خلق ثقافة قوية موجهة نحو الجودة إلى ومراقبة تفاعلات العملاء بعد النشر وتتبع التحسينات.
فيما يلي بعض النصائح العملية التي يمكنك تنفيذها بسهولة:
- تأكد من أن اختباراتك سهلة الكتابة ومرنة بدرجة كافية حتى لا تنكسر عند إعادة بناء الكود.
- يجب تضمين فرق التطوير في عملية الاختبار - راجع قائمة مشكلات المستخدم وطلباته التي تعتبر مهمة للاختبار أثناء مسارات CI.
- قد لا يكون لديك تغطية اختبارية كاملة، ولكن تأكد دائمًا من اختبار التدفقات المهمة لتجربة المستخدم وتجربة العملاء.
نقطة أخيرة وليس أقل أهمية
عادةً ما يتم الانتقال إلى CI/CD من الأسفل إلى الأعلى، ولكنه في النهاية تحول يتطلب موافقة القيادة والوقت والموارد من الشركة. وفي نهاية المطاف، فإن CI/CD عبارة عن مجموعة من المهارات والعمليات والأدوات وإعادة الهيكلة الثقافية؛ ولا يمكن تنفيذ مثل هذه التغييرات إلا بشكل منهجي.
ماذا تقرأ عن الموضوع:
- .
- .
- .
المصدر: www.habr.com