تحتاج أي شركة تطوير برامج إلى بيئات اختبار قريبة من بيئة الإنتاج. هذا ينطبق بشكل خاص على البرامج المعبأة ، والتي لها دورة إصدار طويلة.
يتم حل العديد من مشاكل بيئات اختبار البناء من خلال وضعها في السحابة. سنتحدث عن خيارات الاختبار على
منصة Mail.Ru Cloud Solutions (MCS) القائمة على
السحابة . لكن جزء مما نقول صحيح لأي سحابة.
صعوبات في تهيئة بيئة اختبار
قبل أن نتحدث عن إمكانيات بيئات الاختبار في السحابة ، سنتحدث عن الصعوبات التي تواجهها الشركات في برامج الاختبار.
فروع Git المختلفة - بيئات مختلفة
تستخدم معظم الشركات المشاركة في تطوير البرامج أنظمة التحكم في الإصدارات. الأكثر شيوعًا هو
Git ، والذي يستخدمه 87٪ من المطورين (استطلاع RhodeCode
على Twitter ).
أفضل الممارسات في Git هي ما يسمى بفروع الميزات ، عندما يتم تخصيص فرع منفصل لكل وظيفة جديدة في المستودع. يسمح هذا النهج للمطورين بعدم "دفع مرفقيهم" ويجعل التغييرات أكثر استقلالية ، ولكنه يتطلب نشر العديد من البيئات المخصصة لاختبار الميزات الفردية.
نقص في استخدام الموارد الحاسوبية
25٪ من الخوادم الفعلية عبارة عن زومبي يستهلك الكهرباء ولكن لا يفعل أي شيء مفيد. ولا
يستطيع العديد من متخصصي تكنولوجيا المعلومات
قول ما تقوم به 15-30٪ من الخوادم المثبتة في شركاتهم.
حتى هنا. لا تختلف الأجهزة الموجودة داخل المؤسسة لبيئات الاختبار هنا عن أي أجهزة أخرى ، وكقاعدة عامة ، يتم التخلص منها بشكل سيئ. ولا يمكن أن يكون الأمر خلاف ذلك. عند شراء أسطول معدات الخادم ، يتم إعادة تعيينك حسب الموارد في حالة زيادة الاستهلاك وعدد بيئات الاختبار. ونتيجة لذلك ، تكون بيئات الاختبار خاملة في الليل وفي عطلات نهاية الأسبوع "فقط في حالة" ، وأنت تدفع فقط مقابل استهلاك الكهرباء والتبريد.
إن التطبيق البسيط للمحاكاة الافتراضية في السحابة الخاصة بك لا يحل مشكلة قابلية التوسع غير المرنة ونقص استخدام المعدات.
تحديد الصعوبة
بيئات الاختبار والتطوير ليست مجرد عدد قليل من الأجهزة الافتراضية. عادة ، يتضمن خادم تطبيق ، خادم قاعدة بيانات ، بالإضافة إلى خوادم قائمة انتظار الرسائل وخوادم ذاكرة التخزين المؤقت.
من الصعب على المطورين رفع وتكوين مثل هذه البنية التحتية بأنفسهم ، إذا لم يكن لديهم الخبرة المناسبة ، فقد يستغرق ذلك عدة أيام. بالنسبة للمسؤولين ذوي الخبرة ، يعد هذا أمرًا سهلاً ، ولكنه ليس شيقًا بشكل عام. بالإضافة إلى ذلك ، يتم فرض البيروقراطية ، ويمكن أن تستغرق عملية تخصيص الموارد لإنشاء بيئة اختبار وقتًا طويلاً.
مشكلة أخرى هي أن مسؤول النظام بدوام كامل غالبًا ما لا يمتلك الخبرة في نشر بيئات اختبار محددة ، وتضطر الشركة إلى جذب مستشارين باهظين التكلفة من الخارج. ومن الأمثلة على ذلك وضع الحماية للبيانات الضخمة استنادًا إلى Hadoop أو Spark أو HDFS أو Airflow. يستغرق نشر مثل هذه البيئة أسبوعًا على الأقل من أخصائي مؤهل في منطقة BigData وعلى الأقل شهرًا من مسؤول نظام عادي. قصة مماثلة مع مجموعات Kubernetes: يستغرق بناء مجموعة اختبار قريبة من تكوين الإنتاج عدة أيام على الأقل.
ونتيجة لذلك ، تضطر الشركة إلى اللجوء إلى طرف ثالث - لجذب الاستشاريين. ومع ذلك ، فإن
العثور على خبراء في البيانات الضخمة أمر صعب للغاية ، ويمكن عد مسؤولي هذه الأنظمة تقريبًا على الأصابع. نعم ، يمكن لمهندس DevOps التعامل مع جميع مهام نشر بيئات الاختبار ، ولكن ليس لدى كل شركة ذلك ، وإيجاد خبير جيد في هذا المجال ليس أسهل من أخصائي BigData. في الواقع ، في عام 2016 ، أشار موقع البحث عن الوظائف ، بالفعل ،
إلى أن الشركات كانت تبحث عن مهندس DevOps لفترة أطول من أي متخصصين آخرين.
كيف تحل السحابة هذه المشاكل
الفوترة الثانية فقط للموارد المستهلكة والتحجيم الفوري
تتمثل الميزة الأكثر وضوحًا للخدمات السحابية في القدرة على استئجار بنية أساسية سحابية لأي تكوين (خادم واحد أو مجموعة كاملة) لأي فترة. في نظامنا
Mail.Ru Cloud Solutions (MCS) ، يتم إعداد الفواتير في الثانية - ما عليك سوى الدفع مقابل موارد الحوسبة التي تم استخدامها بالفعل.
على عكس المعدن العاري والسحابة الخاصة ومعظم مزودي السحابة الروس ، لا تفرض MCS موارد على الأجهزة الافتراضية المتوقفة (ذاكرة الوصول العشوائي ووحدة المعالجة المركزية): ما عليك سوى الدفع مقابل مساحة القرص المستخدمة. على سبيل المثال ، يكلف تكوين اختبار لـ 20 وحدة معالجة مركزية و 40 غيغابايت من ذاكرة الوصول العشوائي و 1 تيرابايت للقرص الصلب 24،800 ₽ / شهر ومساحة القرص 7،000 ₽ / شهر. على سبيل المثال ، إذا كنت تستخدم أدوات الأتمتة لإيقاف مثل هذه البيئة في الساعة 21:00 ونشرها في الساعة 9:00 ، فستدفع 15900 ₽ - أقل مرة ونصف من استئجار على مدار الساعة.
في تجربتنا ، يمكن أن يصل إجمالي المدخرات من الاختبار في السحابة إلى 60-70٪ ، مقارنة بالاختبار في البنية التحتية الداخلية.
تتيح لك القدرة على توسيع الموارد في السحابة لأعلى ولأسفل على الفور نشر البيئات بسرعة فقط في الوقت المناسب والاستفادة من القدرات المؤجرة بنسبة 100٪ تقريبًا. يتم تقليل وقت نشر بيئة الاختبار بعدة أيام ، أو حتى شهور ، مقارنة بالافتراضات داخل المؤسسة.
الموارد المخصصة من قبل المطورين أنفسهم
باستخدام بوابات الخدمة الذاتية ، يمكن للمطورين تكوين بيئات الاختبار في السحابة وتخصيص الموارد لهم دون الاتصال بالمسؤولين. حتى هذا الإجراء البسيط يمكن أن يقصر وقت وصول المنتج إلى السوق بعدة أسابيع.
واجهة برمجة التطبيقات لإنشاء بيئات الاختبار وتدميرها تلقائيًا
تتيح لك السحابة إنشاء بيئات قصيرة العمر على نموذج
في الوقت المناسب .
باستخدام REST API و CLI ، يمكنك نشر بيئات الاختبار بشكل مجمّع وإيقافها وتحديثها وحذفها. بهذه الطريقة ، يمكنك تكوين دورة الحياة الكاملة لبيئات الاختبار والحفاظ على صحة مئات البيئات. بفضل التحجيم الفوري للسحابة والفوترة في كل ثانية ، يتم تحقيق المرونة وتقليل تكاليف التشغيل.
هنا مثال من تجربتنا.تطور الشركة برمجيات لـ 150 بنك. لكل بنك فرع خاص به في Git مع وظائف إضافية مدمجة في الحل المعبأ. تضطر الشركة إلى رفع بيئتين أو ثلاث اختبارات عمل متوازية لكل عميل: الاختبار مع الإصدار الحالي ، الاختبار مع الإصدار الجديد ، التحقق من التحديثات من التيار إلى الجديد. إجمالاً ، بالنسبة لـ 150 عميلًا ، من الضروري نشر وصيانة ما يصل إلى 450 بيئة اختبار في نفس الوقت فقط - وهذا لا يأخذ في الاعتبار بيئات التطوير.
في وضع السحابة الخاصة (يستخدمون المحاكاة الافتراضية في مركز البيانات الخاص بهم) ، يكاد يكون من المستحيل العمل مع هذا الحمل ، نظرًا لأن الأجهزة المتاحة غالبًا ما تكون غير كافية للتشغيل المتوازي لجميع البيئات. ونتيجة لذلك ، ينتظر المطورون دورهم للاختبار ولا يمكنهم التحقق بسرعة من تشغيل الإصدار الجديد من التطبيق.
يزيل النشر والإدارة التلقائيان لبيئات الاختبار في السحابة العامة القيود المفروضة على سرعة الاختبار ويقلل في النهاية من وقت السوق. بالإضافة إلى ذلك ، فإن إدارة التكلفة عند استئجار الموارد السحابية تكون أكثر قابلية للتنبؤ بها ، والتكاليف نفسها أقل مما كانت عليه عند استخدام معداتك المتخصصة في منصات الاختبار.
ميزة أخرى لبيئات الاختبار السحابية هي التكامل مع أدوات CI / CD. تحتوي هذه الحلول (على سبيل المثال ، Jenkins) على مكونات إضافية تتيح لك إنشاء بيئات اختبار بشكل ديناميكي في سحابة MCS أثناء الإنشاء. يمكنك تنشيط بيئة اختبار مباشرة قبل تشغيل الاختبارات الوظيفية أو اختبارات الانحدار. إذا نجحت الاختبارات ، فسوف تنهار البيئة تلقائيًا ، إذا كان هناك خطأ - سيتم حفظ البيئة حتى يتمكن المطورون من إعادة الاتصال وفهم سبب الانحدار.
كتل البناء الجاهزة لبيئات الاختبار
نشر بيئة الاختبار بسرعة إلى منصة Mail.Ru Cloud Solutions
تساعد
PaaS ، على سبيل المثال ،
حاويات Kubernetes وقواعد البيانات في السحابة. تعمل Kubernetes على تطوير كتالوج خدمات يحتوي على مئات التطبيقات.
من الكتالوج ، يمكنك نشر ActiveMQ و RabbitMQ ومجموعات كافكا وأنظمة مراقبة وتحليل السجلات والعديد من أنظمة إدارة قواعد البيانات وقواعد البيانات في بضع دقائق. على عكس
Docker Hub الشهير ، الذي يحتوي فقط على قوالب تطبيق مخصصة ، فإن
كتالوج خدمة Kubernetes يحتوي على قوالب عالية المستوى تبسط التكامل. من القوالب ، يمكنك نشر مكونات التطبيق التي تم تكوينها مسبقًا (قائمة انتظار الرسائل ، واكتشاف الخدمة ، وقواعد البيانات ، وخوادم التطبيقات ، وأدوات CI / CD ، وخوادم التخزين المؤقت ، وأدوات blockchain ، وأكثر من ذلك بكثير) ، دون الحاجة إلى تكوين الأجهزة الافتراضية التي يتم نشرها عليها.
التطبيقات المتاحة في سوق Kubeapps.صناديق رمل للبيانات الضخمة
في MCS ، يمكنك نشر بيئات اختبار لتطبيقات البيانات الضخمة. باستخدام
البيانات الكبيرة لخدمة PaaS
، يمكنك إنشاء مجموعات من Hadoop و Spark و HBase و Airflow. عملية النشر مؤتمتة بالكامل ، وهذا يوفر أسابيع من الوقت مقارنة بالتكوين الذاتي.
ميزة إضافية هنا هي الفوترة من الثانية إلى الثانية والتحجيم الفوري. تقلل القدرة على إنشاء بيئات اختبار قابلة للتوسيع لفترات قصيرة من تكاليف الشركة للحفاظ على البنية التحتية التحليلية لتكنولوجيا المعلومات. يمكن أن تصل المدخرات إلى 80٪ مقارنة بالمقر الداخلي.
التكامل مع البنية التحتية ككود
على عكس الحلول الخاصة القائمة على برنامج VMWare ، تم بناء منصة MCS السحابية على أساس برنامج OpenStack المفتوح ، والذي يحتوي على تكامل كامل مع أدوات متنوعة: Terraform ، Ansible ، Puppet ، Chef.
بنيت Terraform بروح البنية التحتية ككود (IaC) ، عندما يتم ترتيب عملية إنشاء البنية التحتية كترميز وأكثر دراية للمطورين. من الصعب استخدام Terraform في سحابة خاصة لأنها تفتقر إلى التكامل التام مع VMware. في سحابة MCS ، يمكن للشركات استخدام أمثلة جاهزة للعمل مع Terraform (وهي موجودة في
مستودع GitHub ).
إنشاء بيئة اختبار باستخدام Terraform.تذكرني
- أصبح الاختبار في السحابة ممارسة طبيعية في صناعة تكنولوجيا المعلومات ويتم تطبيقه بالفعل من قبل مجموعة متنوعة من المنظمات: من جامعات الدولة إلى شركات تكنولوجيا المعلومات الكبيرة .
- يساعد بناء بيئات الاختبار في السحابة على توفير المال بسبب إمكانية التوسع الفوري والأتمتة عبر واجهات برمجة التطبيقات ، والتي توفر استخدامًا بنسبة 100٪ تقريبًا للبنية التحتية المستأجرة.
- الخدمات الإضافية على النظام الأساسي للسحابة والقوالب على حاويات Kuberntetes هي كتل بناء جاهزة ولا تحتاج إلى تكوين.
- من السهل تأجير الخدمات التي يصعب تكوينها ، مثل أدوات معالجة البيانات الضخمة ، في السحابة كقوالب مسبقة التكوين. ستوفر أسابيع من خلال عدم الغوص في الإعدادات.
- تم بناء MCS على OpenStack ومتكامل تمامًا مع Terraform وأدوات DevOps الأخرى.
يمكن تجربة كل هذه الأدوات مجانًا في منصة Mail.Ru Cloud Solutions. حتى نهاية شهر نوفمبر ،
باستخدام هذا الرابط مع الرمز الترويجي ILOVEHABR ، يمكنك إضافة 1000 روبل إلى حسابك واختبار اختبار.