الجزء 1: الويب/أندرويد
لاحظ: هذه المقالة هي ترجمة إلى اللغة الروسية للمقال الأصلي ومع ذلك، يتم الاحتفاظ بجميع الرسوم التوضيحية والروابط والاقتباسات والمصطلحات باللغة الأصلية لتجنب تشويه المعنى عند ترجمتها إلى اللغة الروسية. أتمنى لك دراسة سعيدة!
يعد تخصص DevOps حاليًا أحد أكثر التخصصات طلبًا في صناعة تكنولوجيا المعلومات. إذا قمت بفتح مواقع البحث عن الوظائف الشائعة وقمت بالتصفية حسب الراتب، فسترى أن الوظائف المتعلقة بـ DevOps موجودة في أعلى القائمة. ومع ذلك، من المهم أن نفهم أن هذا يشير بشكل أساسي إلى منصب "كبير"، مما يعني أن المرشح يتمتع بمستوى عالٍ من المهارات والمعرفة بالتكنولوجيا والأدوات. ويأتي هذا أيضًا مع درجة عالية من المسؤولية المرتبطة بتشغيل الإنتاج دون انقطاع. ومع ذلك، بدأنا ننسى ما هو DevOps. في البداية، لم يكن الأمر يتعلق بشخص أو قسم محدد. وإذا بحثنا عن تعريفات لهذا المصطلح سنجد العديد من الأسماء الجميلة والصحيحة، مثل المنهجية والممارسات والفلسفة الثقافية ومجموعة المفاهيم وما إلى ذلك.
تخصصي هو مهندس أتمتة الاختبار (مهندس أتمتة ضمان الجودة)، لكنني أعتقد أنه لا ينبغي أن يرتبط فقط بكتابة الاختبارات التلقائية أو تطوير بنية إطار الاختبار. وفي عام 2020، تعد المعرفة بالبنية التحتية للأتمتة أمرًا ضروريًا أيضًا. يتيح لك ذلك تنظيم عملية الأتمتة بنفسك، بدءًا من إجراء الاختبارات وحتى تقديم النتائج لجميع أصحاب المصلحة وفقًا لأهدافك. ونتيجة لذلك، فإن مهارات DevOps ضرورية لإنجاز المهمة. وكل هذا جيد ولكن للأسف هناك مشكلة (المفسد: تحاول هذه المقالة تبسيط هذه المشكلة). النقطة المهمة هي أن DevOps صعب. وهذا أمر واضح، لأن الشركات لن تدفع الكثير مقابل شيء يسهل القيام به... في عالم DevOps، هناك عدد كبير من الأدوات والمصطلحات والممارسات التي تحتاج إلى إتقانها. يعد هذا أمرًا صعبًا بشكل خاص في بداية الحياة المهنية ويعتمد على الخبرة الفنية المتراكمة.
المصدر:
ربما سننتهي هنا من الجزء التمهيدي ونركز على الغرض من هذه المقالة.
عن ماذا تتحدث هذه المقالة؟
في هذه المقالة، سأشارك تجربتي في بناء البنية التحتية لأتمتة الاختبار. هناك العديد من مصادر المعلومات على الإنترنت حول الأدوات المختلفة وكيفية استخدامها، لكني أود أن أنظر إليها في سياق الأتمتة فقط. أعتقد أن العديد من مهندسي الأتمتة على دراية بالموقف عندما لا يقوم أحد غيرك بإجراء الاختبارات المطورة أو الاهتمام بصيانتها. ونتيجة لذلك، تصبح الاختبارات قديمة ويتعين عليك قضاء بعض الوقت في تحديثها. مرة أخرى، في بداية الحياة المهنية، قد تكون هذه مهمة صعبة للغاية: اتخاذ قرار حكيم بشأن الأدوات التي يجب أن تساعد في حل مشكلة معينة، وكيفية اختيارها وتكوينها وصيانتها. يلجأ بعض المختبرين إلى DevOps (البشر) للحصول على المساعدة، ولنكن صادقين، هذا النهج ناجح. في كثير من الحالات قد يكون هذا هو الخيار الوحيد لأننا لا نملك رؤية لجميع التبعيات. ولكن كما نعلم، فإن DevOps هم أشخاص مشغولون للغاية، لأنه يتعين عليهم التفكير في البنية التحتية للشركة بأكملها، والنشر، والمراقبة، والخدمات الصغيرة والمهام المماثلة الأخرى اعتمادًا على المؤسسة/الفريق. وكما هو الحال عادة، فإن الأتمتة ليست أولوية. في مثل هذه الحالة، يجب علينا أن نحاول أن نفعل كل ما هو ممكن من جانبنا من البداية إلى النهاية. سيؤدي ذلك إلى تقليل التبعيات وتسريع سير العمل وتحسين مهاراتنا والسماح لنا برؤية الصورة الأكبر لما يحدث.
تعرض المقالة الأدوات الأكثر شهرة وشعبية وتوضح كيفية استخدامها لإنشاء بنية تحتية للأتمتة خطوة بخطوة. يتم تمثيل كل مجموعة بأدوات تم اختبارها من خلال التجربة الشخصية. لكن هذا لا يعني أن عليك استخدام نفس الشيء. الأدوات في حد ذاتها ليست مهمة، فهي تظهر وتصبح قديمة. تتمثل مهمتنا الهندسية في فهم المبادئ الأساسية: لماذا نحتاج إلى هذه المجموعة من الأدوات وما هي مشاكل العمل التي يمكننا حلها بمساعدتهم. ولهذا السبب أترك في نهاية كل قسم روابط لأدوات مماثلة يمكن استخدامها في مؤسستك.
ما ليس في هذه المقالة
أكرر مرة أخرى أن المقالة لا تتعلق بأدوات محددة، لذلك لن يكون هناك أي إدخالات برمجية من الوثائق وأوصاف أوامر محددة. ولكن في نهاية كل قسم أترك روابط للدراسة التفصيلية.
يتم ذلك بسبب:
- من السهل جدًا العثور على هذه المادة في مصادر مختلفة (الوثائق والكتب ودورات الفيديو)؛
- إذا بدأنا بالتعمق أكثر، فسيتعين علينا كتابة 10، 20، 30 جزءًا من هذه المقالة (في حين أن الخطط هي 2-3)؛
- أنا فقط لا أريد أن أضيع وقتك لأنك قد ترغب في استخدام أدوات أخرى لتحقيق نفس الأهداف.
ممارسة
أود حقًا أن تكون هذه المادة مفيدة لكل قارئ، وليس مجرد قراءتها ونسيانها. في أي دراسة، تعتبر الممارسة عنصرًا مهمًا للغاية. لهذا أعددت. هناك أيضًا واجبات منزلية في انتظارك للتأكد من أنك لا تقوم بنسخ سطور الأوامر التي تقوم بتنفيذها دون قصد.
خطة
خطوة
تكنولوجيا
الأدوات
1
التشغيل المحلي (إعداد الاختبارات التجريبية للويب/Android وتشغيلها محليًا)
Node.js، السيلينيوم، Appium
2
أنظمة التحكم في الإصدار
بوابة
3
النقل بالحاويات
Docker، شبكة السيلينيوم، Selenoid (الويب، Android)
4
CI / قرص مضغوط
جيتلاب سي
5
المنصات السحابية
نظام التشغيل السحابي من غوغل
6
تزامن
Kubernetes
7
البنية التحتية كرمز (IaC)
Terraform، Ansible
هيكل كل قسم
وللإبقاء على السرد واضحًا، تم وصف كل قسم وفقًا للمخطط التالي:
- وصف موجز للتكنولوجيا،
- قيمة البنية التحتية للأتمتة،
- توضيح للحالة الراهنة للبنية التحتية،
- روابط للدراسة,
- أدوات مماثلة.
1. قم بإجراء الاختبارات محليًا
وصف موجز للتكنولوجيا
هذه مجرد خطوة تحضيرية لتشغيل الاختبارات التجريبية محليًا والتحقق من اجتيازها. في الجزء العملي، يتم استخدام Node.js، لكن لغة البرمجة والمنصة ليست مهمة أيضًا ويمكنك استخدام تلك المستخدمة في شركتك.
ومع ذلك، كأدوات أتمتة، أوصي باستخدام Selenium WebDriver لمنصات الويب وAppium لمنصة Android، على التوالي، لأننا في الخطوات التالية سنستخدم صور Docker المصممة للعمل خصيصًا مع هذه الأدوات. علاوة على ذلك، وبالإشارة إلى متطلبات الوظيفة، فإن هذه الأدوات هي الأكثر طلبًا في السوق.
كما لاحظتم، فإننا نأخذ في الاعتبار اختبارات الويب وAndroid فقط. لسوء الحظ، iOS قصة مختلفة تمامًا (شكرًا لشركة Apple). أخطط لعرض الحلول والممارسات المتعلقة بنظام IOS في الأجزاء القادمة.
قيمة البنية التحتية للأتمتة
ومن منظور البنية التحتية، فإن التشغيل محليًا لا يوفر أي قيمة. ما عليك سوى التحقق من تشغيل الاختبارات على الجهاز المحلي في المتصفحات وأجهزة المحاكاة المحلية. لكن على أية حال، فهذه نقطة انطلاق ضرورية.
رسم توضيحي للحالة الراهنة للبنية التحتية
روابط للاستكشاف
أدوات مماثلة
- أي لغة برمجة تفضلها بالإضافة إلى اختبارات السيلينيوم/الآبيوم؛
- أي اختبارات
- أي عداء الاختبار.
2. أنظمة التحكم بالإصدار (Git)
وصف موجز للتكنولوجيا
لن يكون اكتشافًا كبيرًا لأي شخص إذا قلت أن التحكم في الإصدار هو جزء مهم للغاية من التطوير، سواء على مستوى الفريق أو على المستوى الفردي. استنادًا إلى مصادر مختلفة، يمكننا أن نقول بثقة أن Git هو الممثل الأكثر شعبية. يوفر نظام التحكم في الإصدار العديد من الفوائد، مثل مشاركة التعليمات البرمجية وتخزين الإصدارات والاستعادة إلى الفروع السابقة ومراقبة تاريخ المشروع والنسخ الاحتياطية. لن نناقش كل نقطة بالتفصيل، فأنا متأكد من أنك على دراية بها جيدًا وتستخدمها في عملك اليومي. ولكن إذا لم يحدث ذلك فجأة، فإنني أوصي بالتوقف مؤقتًا عن قراءة هذه المقالة وملء هذه الفجوة في أسرع وقت ممكن.
قيمة البنية التحتية للأتمتة
وهنا يمكنك طرح سؤال معقول: "لماذا يخبرنا عن Git؟ الجميع يعرف هذا ويستخدمه لكل من كود التطوير ورمز الاختبار التلقائي. ستكون على حق تمامًا، ولكننا نتحدث في هذه المقالة عن البنية التحتية ويعمل هذا القسم بمثابة معاينة للقسم 7: "البنية التحتية كرمز (IaC)". بالنسبة لنا، هذا يعني أن البنية التحتية بأكملها، بما في ذلك الاختبار، موصوفة في شكل تعليمات برمجية، حتى نتمكن أيضًا من تطبيق أنظمة الإصدار عليها والحصول على فوائد مماثلة للتطوير والأتمتة البرمجية.
سنلقي نظرة على IaC بمزيد من التفاصيل في الخطوة 7، ولكن حتى الآن يمكنك البدء في استخدام Git محليًا عن طريق إنشاء مستودع محلي. سيتم توسيع الصورة الكبيرة عندما نضيف مستودعًا بعيدًا إلى البنية التحتية.
رسم توضيحي للحالة الراهنة للبنية التحتية
روابط للاستكشاف
أدوات مماثلة
3. الحاويات (عامل الميناء)
وصف موجز للتكنولوجيا
لتوضيح كيف غيّر النقل بالحاويات قواعد اللعبة، دعونا نعود بالزمن بضعة عقود إلى الوراء. في ذلك الوقت، كان الأشخاص يشترون ويستخدمون أجهزة الخادم لتشغيل التطبيقات. ولكن في معظم الحالات، لم تكن الموارد المطلوبة لبدء التشغيل معروفة مسبقًا. ونتيجة لذلك، أنفقت الشركات الأموال على شراء خوادم قوية ومكلفة، ولكن لم يتم استخدام بعض هذه السعة بالكامل.
كانت المرحلة التالية من التطور هي الأجهزة الافتراضية (VMs)، التي حلت مشكلة إهدار الأموال على الموارد غير المستخدمة. أتاحت هذه التقنية تشغيل التطبيقات بشكل مستقل عن بعضها البعض داخل نفس الخادم، مما أدى إلى تخصيص مساحة معزولة تمامًا. ولكن، لسوء الحظ، أي تكنولوجيا لها عيوبها. يتطلب تشغيل جهاز افتراضي نظام تشغيل كاملاً، يستهلك وحدة المعالجة المركزية (CPU) وذاكرة الوصول العشوائي (RAM) والتخزين، واعتمادًا على نظام التشغيل، يجب أخذ تكاليف الترخيص في الاعتبار. تؤثر هذه العوامل على سرعة التحميل وتجعل إمكانية النقل صعبة.
والآن نأتي إلى الحاويات. مرة أخرى، تحل هذه التقنية المشكلة السابقة، حيث لا تستخدم الحاويات نظام تشغيل كامل، مما يحرر كمية كبيرة من الموارد ويوفر حلاً سريعًا ومرنًا لقابلية النقل.
وبطبيعة الحال، فإن تكنولوجيا النقل بالحاويات ليست جديدة، وقد تم تقديمها لأول مرة في أواخر السبعينيات. في تلك الأيام، تم إجراء الكثير من الأبحاث والتطورات والمحاولات. لكن شركة Docker هي التي قامت بتكييف هذه التكنولوجيا وجعلها في متناول الجماهير بسهولة. في الوقت الحاضر، عندما نتحدث عن الحاويات، فإننا نعني في معظم الحالات Docker. عندما نتحدث عن حاويات Docker، فإننا نعني حاويات Linux. يمكننا استخدام أنظمة Windows وmacOS لتشغيل الحاويات، ولكن من المهم أن نفهم أنه في هذه الحالة تظهر طبقة إضافية. على سبيل المثال، يقوم Docker على Mac بتشغيل الحاويات بصمت داخل جهاز Linux VM خفيف الوزن. سنعود إلى هذا الموضوع عندما نناقش تشغيل محاكيات Android داخل الحاويات، لذلك يوجد هنا فارق بسيط جدًا يجب مناقشته بمزيد من التفصيل.
قيمة البنية التحتية للأتمتة
اكتشفنا أن النقل بالحاويات وDocker رائعان. دعونا ننظر إلى هذا في سياق الأتمتة، لأن كل أداة أو تقنية تحتاج إلى حل مشكلة ما. دعونا نحدد المشاكل الواضحة لأتمتة الاختبار في سياق اختبارات واجهة المستخدم:
- عدد كبير من التبعيات عند تثبيت السيلينيوم وخاصة Appium؛
- مشاكل التوافق بين إصدارات المتصفحات وأجهزة المحاكاة وبرامج التشغيل؛
- عدم وجود مساحة معزولة للمتصفحات/أجهزة المحاكاة، وهو أمر بالغ الأهمية بشكل خاص للتشغيل المتوازي؛
- من الصعب إدارتها وصيانتها إذا كنت بحاجة إلى تشغيل 10 أو 50 أو 100 أو حتى 1000 متصفح في نفس الوقت.
ولكن نظرًا لأن السيلينيوم هي أداة الأتمتة الأكثر شيوعًا وDocker هي أداة النقل بالحاويات الأكثر شيوعًا، فلا ينبغي أن يكون مفاجئًا أن يحاول شخص ما الجمع بينهما لإنشاء أداة قوية لحل المشكلات المذكورة أعلاه. دعونا نفكر في مثل هذه الحلول بمزيد من التفصيل.
شبكة السيلينيوم في عامل الإرساء
هذه الأداة هي الأكثر شيوعًا في عالم السيلينيوم لتشغيل متصفحات متعددة على أجهزة متعددة وإدارتها من مركز مركزي. للبدء، تحتاج إلى تسجيل جزأين على الأقل: المحور والعقدة (العقد). Hub عبارة عن عقدة مركزية تتلقى جميع الطلبات من الاختبارات وتوزعها على العقد المناسبة. يمكننا تكوين تكوين معين لكل عقدة، على سبيل المثال، عن طريق تحديد المتصفح المطلوب وإصداره. ومع ذلك، ما زلنا بحاجة إلى الاهتمام ببرامج تشغيل المتصفح المتوافقة بأنفسنا وتثبيتها على العقد المطلوبة. لهذا السبب، لا يتم استخدام شبكة السيلينيوم في شكلها النقي، إلا عندما نحتاج إلى العمل مع المتصفحات التي لا يمكن تثبيتها على نظام التشغيل Linux. بالنسبة لجميع الحالات الأخرى، سيكون الحل المرن والصحيح إلى حد كبير هو استخدام صور Docker لتشغيل شبكة السيلينيوم المحورية والعقد. يعمل هذا الأسلوب على تبسيط إدارة العقد إلى حد كبير، حيث يمكننا تحديد الصورة التي نحتاجها باستخدام الإصدارات المتوافقة من المتصفحات وبرامج التشغيل المثبتة بالفعل.
على الرغم من المراجعات السلبية حول الاستقرار، خاصة عند تشغيل عدد كبير من العقد بالتوازي، لا تزال شبكة السيلينيوم هي الأداة الأكثر شيوعًا لتشغيل اختبارات السيلينيوم بالتوازي. من المهم أن نلاحظ أن التحسينات والتعديلات المختلفة لهذه الأداة تظهر باستمرار في المصادر المفتوحة، والتي تتغلب على الاختناقات المختلفة.
سيلينويد للويب
تعتبر هذه الأداة طفرة في عالم السيلينيوم لأنها تعمل بشكل مباشر وقد جعلت حياة العديد من مهندسي الأتمتة أسهل بكثير. بادئ ذي بدء، هذا ليس تعديلا آخر لشبكة السيلينيوم. بدلاً من ذلك، أنشأ المطورون إصدارًا جديدًا تمامًا من Selenium Hub في Golang، والذي أعطى، جنبًا إلى جنب مع صور Docker خفيفة الوزن لمتصفحات مختلفة، زخمًا لتطوير أتمتة الاختبار. علاوة على ذلك، في حالة Selenium Grid، يجب علينا تحديد جميع المتصفحات المطلوبة وإصداراتها مسبقًا، وهذا لا يمثل مشكلة عند العمل بمتصفح واحد فقط. ولكن عندما يتعلق الأمر بالعديد من المتصفحات المدعومة، فإن Selenoid هو الحل الأول بفضل ميزة "المتصفح حسب الطلب". كل ما هو مطلوب منا هو تنزيل الصور الضرورية بالمتصفحات مسبقًا وتحديث ملف التكوين الذي يتفاعل معه Selenoid. بعد أن يتلقى Selenoid طلبًا من الاختبارات، سيقوم تلقائيًا بتشغيل الحاوية المطلوبة باستخدام المتصفح المطلوب. عند اكتمال الاختبار، سيتقاعد Selenoid من الحاوية، وبالتالي تحرير الموارد للطلبات المستقبلية. يزيل هذا النهج تمامًا المشكلة المعروفة المتمثلة في "تدهور العقدة" والتي نواجهها غالبًا في شبكة السيلينيوم.
ولكن، للأسف، سيلينويد لا يزال ليس رصاصة فضية. لقد حصلنا على ميزة "المتصفح حسب الطلب"، لكن ميزة "الموارد حسب الطلب" لا تزال غير متاحة. لاستخدام Selenoid، يجب علينا نشره على أجهزة مادية أو على جهاز افتراضي، مما يعني أننا يجب أن نعرف مسبقًا عدد الموارد التي يجب تخصيصها. أعتقد أن هذه ليست مشكلة بالنسبة للمشاريع الصغيرة التي تعمل على 10 أو 20 أو حتى 30 متصفحًا بالتوازي. ولكن ماذا لو كنا بحاجة إلى 100، 500، 1000 وأكثر؟ ليس من المنطقي الحفاظ على الكثير من الموارد ودفع ثمنها طوال الوقت. في القسمين 5 و6 من هذه المقالة، سنناقش الحلول التي تسمح لك بالتوسع، وبالتالي تقليل تكاليف الشركة بشكل كبير.
سيلينويد لالروبوت
بعد نجاح Selenoid كأداة لأتمتة الويب، أراد الناس شيئًا مشابهًا لنظام Android. وقد حدث ما حدث - تم إصدار Selenoid بدعم Android. من وجهة نظر المستخدم رفيع المستوى، يشبه مبدأ التشغيل أتمتة الويب. والفرق الوحيد هو أنه بدلاً من حاويات المتصفح، يقوم Selenoid بتشغيل حاويات محاكي Android. في رأيي، تعد هذه حاليًا أقوى أداة مجانية لإجراء اختبارات Android بالتوازي.
لا أرغب حقًا في التحدث عن الجوانب السلبية لهذه الأداة، لأنني أحبها حقًا. ولكن لا تزال هناك نفس العيوب التي تنطبق على أتمتة الويب وترتبط بالتوسع. بالإضافة إلى ذلك، نحتاج إلى التحدث عن قيد آخر قد يكون مفاجئًا إذا كنا نقوم بإعداد الأداة لأول مرة. لتشغيل صور Android، نحتاج إلى جهاز فعلي أو جهاز افتراضي يدعم المحاكاة الافتراضية المتداخلة. في الدليل الإرشادي، أوضح كيفية تمكين هذا على جهاز Linux VM. ومع ذلك، إذا كنت من مستخدمي macOS وترغب في نشر Selenoid محليًا، فلن يكون من الممكن إجراء اختبارات Android. ولكن يمكنك دائمًا تشغيل Linux VM محليًا مع تكوين "المحاكاة الافتراضية المتداخلة" ونشر Selenoid بالداخل.
رسم توضيحي للحالة الراهنة للبنية التحتية
وفي سياق هذه المقالة، سنضيف أداتين لتوضيح البنية التحتية. هذه هي شبكة السيلينيوم لاختبارات الويب وSelenoid لاختبارات Android. في البرنامج التعليمي لـ GitHub، سأوضح لك أيضًا كيفية استخدام Selenoid لإجراء اختبارات الويب.
روابط للاستكشاف
أدوات مماثلة
- هناك أدوات أخرى للحاويات، لكن Docker هي الأكثر شيوعًا. إذا كنت تريد تجربة شيء آخر، فضع في اعتبارك أن الأدوات التي قمنا بتغطيتها لإجراء اختبارات السيلينيوم بالتوازي لن تعمل خارج الصندوق.
- كما سبق أن قلنا، هناك العديد من التعديلات على شبكة السيلينيوم، على سبيل المثال،.
4. سي آي/سي دي
وصف موجز للتكنولوجيا
تحظى ممارسة التكامل المستمر بشعبية كبيرة في التطوير وهي على قدم المساواة مع أنظمة التحكم في الإصدار. ورغم ذلك أشعر أن هناك ارتباكا في المصطلحات. في هذه الفقرة أود أن أصف 3 تعديلات على هذه التقنية من وجهة نظري. ستجد على الإنترنت العديد من المقالات ذات التفسيرات المختلفة، ومن الطبيعي تمامًا أن يختلف رأيك. الشيء الأكثر أهمية هو أنك على نفس الصفحة مع زملائك.
لذلك، هناك 3 مصطلحات: CI - التكامل المستمر، CD - التسليم المستمر ومرة أخرى CD - النشر المستمر. (أدناه سأستخدم هذه المصطلحات باللغة الإنجليزية). يضيف كل تعديل عدة خطوات إضافية إلى مسار التطوير الخاص بك. لكن الكلمة متواصل (المستمر) هو الأهم. ونعني في هذا السياق شيئًا يحدث من البداية إلى النهاية، دون انقطاع أو تدخل يدوي. دعونا نلقي نظرة على CI & CD و CD في هذا السياق.
- التكامل المستمر هذه هي الخطوة الأولى للتطور. بعد إرسال التعليمات البرمجية الجديدة إلى الخادم، نتوقع تلقي تعليقات سريعة تفيد بأن التغييرات التي أجريناها على ما يرام. عادةً، يتضمن CI تشغيل أدوات تحليل التعليمات البرمجية الثابتة واختبارات واجهة برمجة التطبيقات للوحدة/الداخلية، مما يتيح لنا الحصول على معلومات حول التعليمات البرمجية الخاصة بنا في غضون ثوانٍ/دقائق قليلة.
- التسليم المستمر هي خطوة أكثر تقدمًا حيث نقوم بإجراء اختبارات التكامل/واجهة المستخدم. ومع ذلك، في هذه المرحلة لا نحصل على نتائج بالسرعة التي نحصل عليها مع CI. أولاً، تستغرق هذه الأنواع من الاختبارات وقتًا أطول حتى تكتمل. ثانيًا، قبل الإطلاق، يجب علينا نشر تغييراتنا في بيئة الاختبار/التدريج. علاوة على ذلك، إذا كنا نتحدث عن تطوير الأجهزة المحمولة، فستظهر خطوة إضافية لإنشاء نسخة من تطبيقنا.
- الانتشار المستمر يفترض أننا نقوم تلقائيًا بإصدار تغييراتنا على الإنتاج إذا تم اجتياز جميع اختبارات القبول في المراحل السابقة. بالإضافة إلى ذلك، بعد مرحلة الإصدار، يمكنك تكوين مراحل مختلفة، مثل إجراء اختبارات الدخان على الإنتاج وجمع المقاييس ذات الأهمية. لا يمكن النشر المستمر إلا من خلال التغطية الجيدة من خلال الاختبارات الآلية. إذا كانت هناك حاجة إلى أي تدخلات يدوية، بما في ذلك الاختبار، فهذا لم يعد كذلك مستمر (مستمر). ثم يمكننا القول أن خط الأنابيب الخاص بنا يتوافق فقط مع ممارسة التسليم المستمر.
قيمة البنية التحتية للأتمتة
في هذا القسم، يجب أن أوضح أنه عندما نتحدث عن اختبارات واجهة المستخدم الشاملة، فهذا يعني أنه يجب علينا نشر تغييراتنا والخدمات المرتبطة بها في بيئات الاختبار. التكامل المستمر - العملية غير قابلة للتطبيق على هذه المهمة ويجب أن نهتم بتنفيذ ممارسات التسليم المستمر على الأقل. يعد النشر المستمر منطقيًا أيضًا في سياق اختبارات واجهة المستخدم إذا أردنا تشغيلها في الإنتاج.
وقبل أن ننظر إلى الرسم التوضيحي لتغيير البنية، أريد أن أقول بضع كلمات عن GitLab CI. على عكس أدوات CI/CD الأخرى، يوفر GitLab مستودعًا بعيدًا والعديد من الميزات الإضافية الأخرى. وبالتالي، فإن GitLab أكثر من CI. يتضمن إدارة التعليمات البرمجية المصدر، وإدارة Agile، وخطوط أنابيب CI/CD، وأدوات التسجيل، وجمع المقاييس خارج الصندوق. تتكون بنية GitLab من Gitlab CI/CD وGitLab Runner. وفيما يلي وصف موجز من الموقع الرسمي:
Gitlab CI/CD هو تطبيق ويب مزود بواجهة برمجة التطبيقات (API) التي تخزن حالته في قاعدة بيانات، وتدير المشاريع/الإنشاءات وتوفر واجهة مستخدم. GitLab Runner هو تطبيق يقوم بمعالجة الإنشاءات. يمكن نشره بشكل منفصل ويعمل مع GitLab CI/CD من خلال واجهة برمجة التطبيقات. لإجراء الاختبارات، تحتاج إلى كل من مثيل Gitlab وRunner.
رسم توضيحي للحالة الراهنة للبنية التحتية
روابط للاستكشاف
أدوات مماثلة
- واشياء أخرى عديدة
5. المنصات السحابية
وصف موجز للتكنولوجيا
سنتحدث في هذا القسم عن اتجاه شائع يسمى "السحب العامة". على الرغم من الفوائد الهائلة التي توفرها تقنيات المحاكاة الافتراضية والحاويات الموضحة أعلاه، إلا أننا لا نزال بحاجة إلى موارد حاسوبية. تقوم الشركات بشراء خوادم باهظة الثمن أو استئجار مراكز البيانات، ولكن في هذه الحالة من الضروري إجراء حسابات (غير واقعية في بعض الأحيان) لعدد الموارد التي سنحتاجها، وما إذا كنا سنستخدمها على مدار الساعة طوال أيام الأسبوع ولأي أغراض. على سبيل المثال، يتطلب الإنتاج خادمًا يعمل على مدار الساعة طوال أيام الأسبوع، ولكن هل نحتاج إلى موارد مماثلة للاختبار خارج ساعات العمل؟ ويعتمد ذلك أيضًا على نوع الاختبار الذي يتم إجراؤه. ومن الأمثلة على ذلك اختبارات الحمل/الإجهاد التي نخطط لإجرائها خارج ساعات العمل للحصول على النتائج في اليوم التالي. ولكن من المؤكد أن توفر الخادم على مدار الساعة طوال أيام الأسبوع ليس مطلوبًا للاختبارات الآلية الشاملة، وخاصةً لبيئات الاختبار اليدوية. في مثل هذه المواقف، سيكون من الجيد الحصول على أكبر عدد ممكن من الموارد عند الطلب، واستخدامها، والتوقف عن الدفع عندما لا تعود هناك حاجة إليها. علاوة على ذلك، سيكون من الرائع استلامها على الفور عن طريق إجراء بضع نقرات بالماوس أو تشغيل بعض البرامج النصية. هذا هو الغرض من استخدام السحب العامة. دعونا نلقي نظرة على التعريف:
"يتم تعريف السحابة العامة على أنها خدمات الحوسبة التي يقدمها مقدمو الطرف الثالث عبر الإنترنت العام، مما يجعلها متاحة لأي شخص يريد استخدامها أو شرائها. قد تكون مجانية أو يتم بيعها عند الطلب، مما يسمح للعملاء بالدفع فقط لكل استخدام لدورات وحدة المعالجة المركزية أو التخزين أو النطاق الترددي الذي يستهلكونه.
هناك رأي مفاده أن السحب العامة باهظة الثمن. لكن فكرتهم الرئيسية هي تقليل تكاليف الشركة. كما ذكرنا سابقًا، تتيح لك السحابة العامة الحصول على الموارد عند الطلب والدفع فقط مقابل الوقت الذي تستخدمها فيه. أيضًا، ننسى أحيانًا أن الموظفين يحصلون على رواتب، كما أن المتخصصين يعدون أيضًا موردًا باهظ الثمن. ويجب أن يؤخذ في الاعتبار أن السحابة العامة تجعل دعم البنية التحتية أسهل بكثير، مما يسمح للمهندسين بالتركيز على المهام الأكثر أهمية.
قيمة البنية التحتية للأتمتة
ما هي الموارد المحددة التي نحتاجها لإجراء اختبارات واجهة المستخدم الشاملة؟ هذه في الأساس عبارة عن أجهزة أو مجموعات افتراضية (سنتحدث عن Kubernetes في القسم التالي) لتشغيل المتصفحات والمحاكيات. كلما زاد عدد المتصفحات والمحاكيات التي نرغب في تشغيلها في وقت واحد، زادت الحاجة إلى وحدة المعالجة المركزية والذاكرة وزادت الأموال التي يتعين علينا دفعها مقابل ذلك. وبالتالي، تسمح لنا السحابة العامة في سياق أتمتة الاختبار بتشغيل عدد كبير (100، 200، 1000...) من المتصفحات/المحاكيات حسب الطلب، والحصول على نتائج الاختبار في أسرع وقت ممكن والتوقف عن الدفع مقابل مثل هذه الموارد المكثفة إلى حد الجنون. قوة.
أشهر موفري الخدمات السحابية هم Amazon Web Services (AWS)، وMicrosoft Azure، وGoogle Cloud Platform (GCP). يوفر الدليل الإرشادي أمثلة حول كيفية استخدام Google Cloud Platform، ولكن بشكل عام لا يهم ما تستخدمه في مهام التشغيل الآلي. أنها جميعا توفر نفس الوظيفة تقريبا. عادةً، لاختيار موفر خدمة، تركز الإدارة على البنية التحتية العامة للشركة ومتطلبات الأعمال، وهو ما يقع خارج نطاق هذه المقالة. بالنسبة لمهندسي الأتمتة، سيكون من المثير للاهتمام مقارنة استخدام موفري الخدمات السحابية مع استخدام الأنظمة الأساسية السحابية خصيصًا لأغراض الاختبار، مثل Sauce Labs وBrowserStack وBitBar وما إلى ذلك. لذلك دعونا نفعل ذلك أيضا! في رأيي، Sauce Labs هي أشهر مزرعة لاختبار السحابة، ولهذا استخدمتها للمقارنة.
GCP مقابل Sauce Labs لأغراض التشغيل الآلي:
لنتخيل أننا بحاجة إلى إجراء 8 اختبارات ويب و8 اختبارات Android في وقت واحد. ولهذا سوف نستخدم GCP ونقوم بتشغيل جهازين افتراضيين باستخدام Selenoid. في الأول سنقوم برفع 2 حاويات مع المتصفحات. في الثانية هناك 8 حاويات بها محاكيات. دعونا نلقي نظرة على الأسعار:
لتشغيل حاوية واحدة مع Chrome، نحتاج n1 معيار 1 سيارة. وفي حالة أندرويد سيكون كذلك n1 معيار 4 لمحاكي واحد. في الواقع، الطريقة الأكثر مرونة والأرخص هي تعيين قيم مستخدم محددة لوحدة المعالجة المركزية/الذاكرة، ولكن في الوقت الحالي هذا ليس مهمًا للمقارنة مع Sauce Labs.
وإليك تعريفات استخدام Sauce Labs:
أعتقد أنك لاحظت الفرق بالفعل، لكنني سأستمر في تقديم جدول بحسابات مهمتنا:
الموارد المطلوبة
مونلي
ساعات العمل(8 صباحًا - 8 مساءً)
ساعات العمل+ استباقي
Google Cloud Platform للويب
n1-قياسي-1 × 8 = n1-قياسي-8
$194.18
23 يومًا * 12 ساعة * 0.38 = 104.88 دولارًا
23 يومًا * 12 ساعة * 0.08 = 22.08 دولارًا
مختبرات صلصة للويب
اختبارات موازية لـ Virtual Cloud8
$1.559
-
-
Google Cloud Platform لنظام Android
n1-قياسي-4 × 8: n1-قياسي-16
$776.72
23 يومًا * 12 ساعة * 1.52 = 419.52 دولارًا
23 يومًا * 12 ساعة * 0.32 = 88.32 دولارًا
مختبرات صلصة لالروبوت
اختبارات موازية لـ Real Device Cloud 8
$1.999
-
-
كما ترون، فإن الفرق في التكلفة كبير، خاصة إذا قمت بإجراء الاختبارات فقط خلال فترة عمل مدتها اثنتي عشرة ساعة. ولكن يمكنك خفض التكاليف بشكل أكبر إذا كنت تستخدم آلات استباقية. ما هذا؟
يعد VM الوقائي مثيلًا يمكنك إنشاؤه وتشغيله بسعر أقل بكثير من المثيلات العادية. ومع ذلك، قد يقوم Compute Engine بإنهاء (استباق) هذه المثيلات إذا كان يتطلب الوصول إلى تلك الموارد لمهام أخرى. المثيلات الوقائية هي سعة Compute Engine الزائدة، لذا يختلف مدى توفرها باختلاف الاستخدام.
إذا كانت تطبيقاتك متسامحة مع الأخطاء ويمكنها تحمل الإجراءات الوقائية المحتملة للمثيلات، فيمكن للمثيلات الوقائية تقليل تكاليف Compute Engine بشكل كبير. على سبيل المثال، يمكن تشغيل مهام المعالجة المجمعة على المثيلات الوقائية. إذا انتهت بعض هذه المثيلات أثناء المعالجة، فستتباطأ المهمة ولكنها لا تتوقف تمامًا. تقوم المثيلات الوقائية بإكمال مهام المعالجة المجمعة الخاصة بك دون وضع عبء عمل إضافي على المثيلات الموجودة لديك ودون مطالبتك بدفع السعر الكامل للمثيلات العادية الإضافية.
ومازال الأمر لم ينته بعد! في الواقع، أنا متأكد من أنه لا أحد يجري اختبارات لمدة 12 ساعة دون استراحة. وإذا كان الأمر كذلك، فيمكنك تشغيل الأجهزة الافتراضية وإيقافها تلقائيًا عند عدم الحاجة إليها. قد يتم تقليل وقت الاستخدام الفعلي إلى 6 ساعات يوميًا. ثم سينخفض الدفع في سياق مهمتنا إلى 11 دولارًا شهريًا لـ 8 متصفحات. أليس هذا رائعا؟ ولكن مع الآلات الاستباقية، يجب علينا أن نكون حذرين ومستعدين للانقطاع وعدم الاستقرار، على الرغم من أنه يمكن توفير هذه المواقف والتعامل معها من خلال البرمجيات. انه يستحق ذلك!
لكنني لا أقول بأي حال من الأحوال "لا تستخدم أبدًا مزارع الاختبار السحابية". لديهم عدد من المزايا. بادئ ذي بدء، هذا ليس مجرد جهاز افتراضي، ولكنه حل أتمتة اختبار كامل مع مجموعة من الوظائف خارج الصندوق: الوصول عن بعد، والسجلات، ولقطات الشاشة، وتسجيل الفيديو، ومتصفحات مختلفة، وأجهزة محمولة فعلية. في كثير من الحالات، يمكن أن يكون هذا بديلاً أنيقًا أساسيًا. تعد منصات الاختبار مفيدة بشكل خاص لأتمتة نظام التشغيل IOS، عندما لا تستطيع السحابة العامة تقديم سوى أنظمة Linux/Windows. لكننا سنتحدث عن نظام iOS في المقالات التالية. أوصي دائمًا بالنظر إلى الموقف والبدء من المهام: في بعض الحالات يكون استخدام السحابة العامة أرخص وأكثر كفاءة، وفي حالات أخرى تستحق منصات الاختبار بالتأكيد الأموال التي يتم إنفاقها.
رسم توضيحي للحالة الراهنة للبنية التحتية
روابط للاستكشاف
أدوات مماثلة:
6. التنسيق
وصف موجز للتكنولوجيا
لدي أخبار جيدة – لقد وصلنا تقريبًا إلى نهاية المقال! في الوقت الحالي، تتكون البنية التحتية للأتمتة لدينا من اختبارات الويب وAndroid، والتي نجريها من خلال GitLab CI بالتوازي، باستخدام الأدوات التي تدعم Docker: شبكة السيلينيوم وSelenoid. علاوة على ذلك، نستخدم الأجهزة الافتراضية التي تم إنشاؤها عبر Google Cloud Platform لاستضافة الحاويات التي تحتوي على المتصفحات والمحاكيات. لتقليل التكاليف، نقوم بتشغيل هذه الأجهزة الافتراضية فقط عند الطلب ونوقفها عند عدم إجراء الاختبار. هل هناك أي شيء آخر يمكنه تحسين بنيتنا التحتية؟ الجواب نعم! تعرف على Kubernetes (K8s)!
أولاً، دعونا نلقي نظرة على كيفية ارتباط الكلمات Orchestra وCluster وKubernetes ببعضها البعض. على مستوى عالٍ، يعد التنسيق هو النظام الذي ينشر التطبيقات ويديرها. بالنسبة لأتمتة الاختبار، فإن هذه التطبيقات المعبأة في حاويات هي شبكة السيلينيوم وسيلينويد. Docker وK8s يكملان بعضهما البعض. يتم استخدام الأول لنشر التطبيق، والثاني للتزامن. في المقابل، K8s عبارة عن كتلة. تتمثل مهمة المجموعة في استخدام الأجهزة الافتراضية كعقد، مما يسمح لك بتثبيت وظائف وبرامج وخدمات متنوعة داخل خادم واحد (مجموعة). إذا فشلت أي من العقد، فسيتم استئناف العقد الأخرى، مما يضمن تشغيل تطبيقنا دون انقطاع. بالإضافة إلى ذلك، تتمتع K8s بوظائف مهمة تتعلق بالقياس، والتي بفضلها نحصل تلقائيًا على القدر الأمثل من الموارد بناءً على التحميل ووضع الحدود.
في الحقيقة، نشر Kubernetes يدويًا من الصفر ليس مهمة تافهة على الإطلاق. سأترك رابطًا للدليل الإرشادي الشهير "Kubernetes The Hard Way"، وإذا كنت مهتمًا، فيمكنك ممارسة ذلك. لكن لحسن الحظ، هناك طرق وأدوات بديلة. أسهل طريقة هي استخدام Google Kubernetes Engine (GKE) في GCP، مما سيسمح لك بالحصول على مجموعة جاهزة ببضع نقرات. أوصي باستخدام هذا الأسلوب لبدء التعلم، لأنه سيسمح لك بالتركيز على تعلم كيفية استخدام K8s لمهامك بدلاً من تعلم كيفية دمج المكونات الداخلية مع بعضها البعض.
قيمة البنية التحتية للأتمتة
دعونا نلقي نظرة على بعض الميزات المهمة التي يوفرها هاتف K8s:
- نشر التطبيق: استخدام مجموعة متعددة العقد بدلاً من الأجهزة الافتراضية؛
- القياس الديناميكي: يقلل من تكلفة الموارد التي يتم استخدامها عند الطلب فقط؛
- الشفاء الذاتي: الاسترداد التلقائي للقرون (ونتيجة لذلك تتم استعادة الحاويات أيضًا)؛
- طرح التحديثات والتراجع عن التغييرات دون توقف: تحديث الأدوات والمتصفحات والمحاكيات لا يقاطع عمل المستخدمين الحاليين
لكن K8s لا تزال ليست رصاصة فضية. لفهم جميع المزايا والقيود في سياق الأدوات التي ندرسها (شبكة السيلينيوم، السيلينويد)، سنناقش بإيجاز هيكل K8s. تحتوي المجموعة على نوعين من العقد: العقد الرئيسية والعقد العاملة. العقد الرئيسية مسؤولة عن قرارات الإدارة والنشر والجدولة. العقد العاملة هي المكان الذي يتم فيه تشغيل التطبيقات. تحتوي العقد أيضًا على بيئة تشغيل الحاوية. في حالتنا، هذا هو Docker، المسؤول عن العمليات المتعلقة بالحاويات. ولكن هناك أيضًا حلول بديلة، على سبيل المثال. من المهم أن نفهم أن التحجيم أو الشفاء الذاتي لا ينطبق مباشرة على الحاويات. يتم تنفيذ ذلك عن طريق إضافة/تقليل عدد القرون، والتي تحتوي بدورها على حاويات (عادةً حاوية واحدة لكل حجرة، ولكن اعتمادًا على المهمة، قد يكون هناك المزيد). يتكون التسلسل الهرمي عالي المستوى من العقد العاملة، والتي يوجد بداخلها حجرات، ويتم رفع الحاويات بداخلها.
تعد ميزة القياس أمرًا أساسيًا ويمكن تطبيقها على كلا العقدتين داخل مجموعة عقدة الكتلة والقرون داخل العقدة. هناك نوعان من القياس ينطبقان على كل من العقد والقرون. النوع الأول هو الأفقي - ويتم القياس عن طريق زيادة عدد العقد/القرون. وهذا النوع هو الأفضل. النوع الثاني، وفقا لذلك، عمودي. يتم إجراء القياس عن طريق زيادة حجم العقد/القرون، وليس عددها.
الآن دعونا نلقي نظرة على أدواتنا في سياق المصطلحات المذكورة أعلاه.
شبكة السيلينيوم
كما ذكرنا سابقًا، تعد شبكة السيلينيوم أداة شائعة جدًا، وليس من المستغرب أن يتم وضعها في حاويات. لذلك، ليس من المستغرب أن يتم نشر شبكة السيلينيوم في K8s. يمكن العثور على مثال لكيفية القيام بذلك في مستودع K8s الرسمي. كالعادة، أرفق الروابط في نهاية القسم. بالإضافة إلى ذلك، يوضح الدليل الإرشادي كيفية القيام بذلك في Terraform. هناك أيضًا تعليمات حول كيفية زيادة عدد القرون التي تحتوي على حاويات المتصفح. لكن وظيفة القياس التلقائي في سياق K8s لا تزال غير مهمة واضحة تمامًا. عندما بدأت الدراسة لم أجد أي توجيهات أو توصيات عملية. بعد عدة دراسات وتجارب بدعم من فريق DevOps، اخترنا أسلوب رفع الحاويات بالمتصفحات اللازمة داخل pod واحد، والذي يقع داخل عقدة عاملة واحدة. تتيح لنا هذه الطريقة تطبيق استراتيجية القياس الأفقي للعقد من خلال زيادة عددها. آمل أن يتغير هذا في المستقبل وسنرى المزيد والمزيد من الأوصاف لأساليب أفضل وحلول جاهزة، خاصة بعد إصدار شبكة السيلينيوم 4 مع بنية داخلية متغيرة.
سيلينويد:
يعد نشر السيلينويد في K8s حاليًا أكبر خيبة أمل. أنها غير متوافقة. من الناحية النظرية، يمكننا رفع حاوية Selenoid داخل الكبسولة، ولكن عندما يبدأ Selenoid في تشغيل الحاويات باستخدام المتصفحات، ستظل داخل نفس الكبسولة. وهذا يجعل القياس مستحيلًا، ونتيجة لذلك، لن يختلف عمل Selenoid داخل المجموعة عن العمل داخل الجهاز الظاهري. نهاية القصة.
قمر:
بمعرفة عنق الزجاجة هذا عند العمل مع سيلينويد، أصدر المطورون أداة أكثر قوة تسمى مون. تم تصميم هذه الأداة في الأصل للعمل مع Kubernetes، ونتيجة لذلك، يمكن ويجب استخدام ميزة القياس التلقائي. علاوة على ذلك، أود أن أقول إنه كذلك في الوقت الحالي الوحيد أداة في عالم السيلينيوم، والتي تتمتع بدعم مجموعة K8s الأصلي خارج الصندوق (لم تعد متوفرة، انظر الأداة التالية ). الميزات الرئيسية لـ Moon التي توفر هذا الدعم هي:
عديمي الجنسية تماما. يقوم Selenoid بتخزين معلومات في الذاكرة حول جلسات المتصفح الجارية حاليًا. إذا تعطلت العملية لسبب ما، فستفقد جميع الجلسات الجارية. على العكس من ذلك، ليس للقمر حالة داخلية ويمكن تكراره عبر مراكز البيانات. تظل جلسات المتصفح نشطة حتى في حالة تعطل نسخة متماثلة واحدة أو أكثر.
لذا، يعد Moon حلاً رائعًا، ولكن هناك مشكلة واحدة: فهو ليس مجانيًا. السعر يعتمد على عدد الجلسات. يمكنك تشغيل 0-4 جلسات فقط مجانًا، وهو أمر غير مفيد بشكل خاص. لكن ابتداءً من الجلسة الخامسة، سيتوجب عليك دفع 5 دولارات لكل جلسة. قد يختلف الوضع من شركة إلى أخرى، ولكن في حالتنا، فإن استخدام Moon لا معنى له. كما وصفت أعلاه، يمكننا تشغيل الأجهزة الافتراضية باستخدام شبكة السيلينيوم عند الطلب أو زيادة عدد العقد في المجموعة. بالنسبة لمسار واحد تقريبًا، نقوم بتشغيل 500 متصفح ونوقف جميع الموارد بعد اكتمال الاختبارات. إذا استخدمنا Moon، فسيتعين علينا دفع مبلغ إضافي قدره 500 × 5 = 2500 دولارًا شهريًا، بغض النظر عن عدد مرات إجراء الاختبارات. مرة أخرى، أنا لا أقول لا تستخدم القمر. بالنسبة لمهامك، يمكن أن يكون هذا حلاً لا غنى عنه، على سبيل المثال، إذا كان لديك العديد من المشاريع/الفرق في مؤسستك وتحتاج إلى مجموعة مشتركة ضخمة للجميع. كما هو الحال دائمًا، أترك رابطًا في النهاية وأوصي بإجراء جميع الحسابات اللازمة في سياق مهمتك.
كاليستو: (انتباه! هذا ليس في المقال الأصلي وهو موجود فقط في الترجمة الروسية)
كما قلت، يعد السيلينيوم أداة شائعة جدًا، كما أن مجال تكنولوجيا المعلومات يتطور بسرعة كبيرة. بينما كنت أعمل على الترجمة، ظهرت أداة واعدة جديدة تسمى Callisto على الويب (مرحبًا Cypress وغيره من أدوات قتل السيلينيوم). إنه يعمل أصلاً مع K8s ويسمح لك بتشغيل حاويات Selenoid في القرون الموزعة عبر العقد. كل شيء يعمل فور إخراجه من الصندوق، بما في ذلك القياس التلقائي. رائعة ولكن تحتاج إلى اختبار. لقد تمكنت بالفعل من نشر هذه الأداة وإجراء العديد من التجارب. لكن من السابق لأوانه استخلاص النتائج، فبعد تلقي النتائج على مسافة طويلة، ربما سأقوم بمراجعة في المقالات المستقبلية. في الوقت الحالي، أترك فقط روابط للبحث المستقل.
رسم توضيحي للحالة الراهنة للبنية التحتية
روابط للاستكشاف
أدوات مماثلة
7. البنية التحتية كرمز (IaC)
وصف موجز للتكنولوجيا
والآن نأتي إلى القسم الأخير. عادة، هذه التكنولوجيا والمهام ذات الصلة ليست من مسؤولية مهندسي الأتمتة. وهناك أسباب لذلك. أولاً، في العديد من المؤسسات، تخضع مشكلات البنية التحتية لسيطرة قسم DevOps ولا تهتم فرق التطوير حقًا بما يجعل خط الأنابيب يعمل وكيف يحتاج كل شيء مرتبط به إلى الدعم. ثانيًا، لنكن صادقين، لا تزال ممارسة البنية التحتية كرمز (IaC) غير معتمدة في العديد من الشركات. لكنه أصبح بالتأكيد اتجاهًا شائعًا ومن المهم محاولة المشاركة في العمليات والأساليب والأدوات المرتبطة به. أو على الأقل البقاء على اطلاع.
لنبدأ بالدافع لاستخدام هذا النهج. لقد ناقشنا بالفعل أنه لإجراء الاختبارات في GitlabCI، سنحتاج على الأقل إلى الموارد اللازمة لتشغيل Gitlab Runner. ولتشغيل الحاويات باستخدام المتصفحات/المحاكيات، نحتاج إلى حجز جهاز افتراضي أو مجموعة. بالإضافة إلى اختبار الموارد، نحتاج إلى قدر كبير من القدرة لدعم التطوير والتشغيل المرحلي وبيئات الإنتاج، والتي تتضمن أيضًا قواعد البيانات والجداول التلقائية وتكوينات الشبكة وموازنات التحميل وحقوق المستخدم وما إلى ذلك. والمسألة الأساسية هي الجهد المطلوب لدعم كل ذلك. هناك عدة طرق يمكننا من خلالها إجراء التغييرات ونشر التحديثات. على سبيل المثال، في سياق GCP، يمكننا استخدام وحدة تحكم واجهة المستخدم في المتصفح وتنفيذ جميع الإجراءات من خلال النقر على الأزرار. قد يكون البديل هو استخدام استدعاءات واجهة برمجة التطبيقات (API) للتفاعل مع الكيانات السحابية، أو استخدام الأداة المساعدة لسطر الأوامر gcloud لإجراء المعالجات المطلوبة. ولكن مع وجود عدد كبير جدًا من الكيانات وعناصر البنية التحتية المختلفة، يصبح من الصعب أو حتى من المستحيل تنفيذ جميع العمليات يدويًا. علاوة على ذلك، كل هذه الإجراءات اليدوية لا يمكن السيطرة عليها. لا يمكننا إرسالها للمراجعة قبل التنفيذ، واستخدام نظام التحكم في الإصدار، والتراجع بسرعة عن التغييرات التي أدت إلى الحادث. لحل مثل هذه المشكلات، قام المهندسون بإنشاء وإنشاء نصوص برمجية bash/shell تلقائية، وهي ليست أفضل بكثير من الطرق السابقة، نظرًا لأنه ليس من السهل قراءتها وفهمها وصيانتها وتعديلها بسرعة بأسلوب إجرائي.
في هذه المقالة والدليل الإرشادي، أستخدم أداتين مرتبطتين بممارسة IaC. هذه هي Terraform وAnsible. يعتقد بعض الناس أنه لا معنى لاستخدامها في نفس الوقت، لأن وظائفها متشابهة وقابلة للتبديل. لكن الحقيقة هي أنه في البداية يتم تكليفهم بمهام مختلفة تمامًا. وقد تم تأكيد حقيقة أن هذه الأدوات يجب أن تكمل بعضها البعض في عرض تقديمي مشترك للمطورين الذين يمثلون HashiCorp وRedHat. يتمثل الاختلاف المفاهيمي في أن Terraform هي أداة توفير لإدارة الخوادم نفسها. بينما Ansible هي أداة لإدارة التكوين تتمثل مهمتها في تثبيت البرامج وتكوينها وإدارتها على هذه الخوادم.
السمة المميزة الرئيسية الأخرى لهذه الأدوات هي أسلوب الترميز. على عكس bash وAnsible، يستخدم Terraform أسلوبًا تعريفيًا يعتمد على وصف الحالة النهائية المرغوبة التي سيتم تحقيقها نتيجة للتنفيذ. على سبيل المثال، إذا أردنا إنشاء 10 أجهزة افتراضية وتطبيق التغييرات من خلال Terraform، فسنحصل على 10 أجهزة افتراضية. إذا قمنا بتشغيل البرنامج النصي مرة أخرى، فلن يحدث شيء نظرًا لأن لدينا بالفعل 10 أجهزة افتراضية، وتعرف Terraform بهذا لأنها تخزن الحالة الحالية للبنية التحتية في ملف حالة. لكن Ansible يستخدم نهجًا إجرائيًا، وإذا طلبت منه إنشاء 10 أجهزة افتراضية، فعند الإطلاق الأول سنحصل على 10 أجهزة افتراضية، على غرار Terraform. ولكن بعد إعادة التشغيل سيكون لدينا بالفعل 20 جهازًا افتراضيًا. هذا هو الفرق المهم. في الأسلوب الإجرائي، لا نقوم بتخزين الحالة الحالية ونقوم ببساطة بوصف سلسلة من الخطوات التي يجب تنفيذها. بالطبع، يمكننا التعامل مع المواقف المختلفة، وإضافة عدة فحوصات لوجود الموارد والوضع الحالي، ولكن لا فائدة من إضاعة وقتنا وبذل الجهد للسيطرة على هذا المنطق. وبالإضافة إلى ذلك، فإن هذا يزيد من خطر ارتكاب الأخطاء.
بتلخيص كل ما سبق، يمكننا أن نستنتج أن Terraform والترميز التعريفي هما أداة أكثر ملاءمة لتوفير الخوادم. لكن من الأفضل تفويض عمل إدارة التكوين إلى Ansible. مع ذلك، دعونا نلقي نظرة على حالات الاستخدام في سياق الأتمتة.
قيمة البنية التحتية للأتمتة
الشيء المهم الوحيد الذي يجب فهمه هنا هو أنه يجب اعتبار البنية التحتية لأتمتة الاختبار جزءًا من البنية التحتية للشركة بأكملها. وهذا يعني أنه يجب تطبيق جميع ممارسات IaC عالميًا على موارد المؤسسة بأكملها. من المسؤول عن هذا يعتمد على عملياتك. يتمتع فريق DevOps بخبرة أكبر في هذه المشكلات، حيث يرون الصورة الكاملة لما يحدث. ومع ذلك، فإن مهندسي ضمان الجودة يشاركون بشكل أكبر في عملية أتمتة البناء وهيكل خط الأنابيب، مما يسمح لهم برؤية جميع التغييرات المطلوبة وفرص التحسين بشكل أفضل. الخيار الأفضل هو العمل معًا وتبادل المعرفة والأفكار لتحقيق النتيجة المتوقعة.
فيما يلي بعض الأمثلة على استخدام Terraform وAnsible في سياق أتمتة الاختبار والأدوات التي ناقشناها من قبل:
1. وصف الخصائص والمعلمات الضرورية للأجهزة الافتراضية والمجموعات باستخدام Terraform.
2. باستخدام Ansible، قم بتثبيت الأدوات اللازمة للاختبار: docker وSelenoid وSelenium Grid وقم بتنزيل الإصدارات المطلوبة من المتصفحات/المحاكيات.
3. باستخدام Terraform، قم بوصف خصائص الجهاز الافتراضي الذي سيتم تشغيل GitLab Runner فيه.
4. قم بتثبيت GitLab Runner والأدوات المصاحبة اللازمة باستخدام Ansible، واضبط الإعدادات والتكوينات.
رسم توضيحي للحالة الراهنة للبنية التحتية
روابط للاستكشاف:
أدوات مماثلة
دعونا نلخص ذلك!
خطوة
تكنولوجيا
الأدوات
قيمة البنية التحتية للأتمتة
1
الجري المحلي
Node.js، السيلينيوم، Appium
- الأدوات الأكثر شعبية للويب والجوال
- يدعم العديد من اللغات والأنظمة الأساسية (بما في ذلك Node.js)
2
أنظمة التحكم في الإصدار
بوابة
- فوائد مماثلة مع رمز التطوير
3
النقل بالحاويات
Docker، شبكة السيلينيوم، Selenoid (الويب، Android)
- إجراء الاختبارات بالتوازي
- بيئات معزولة
- ترقيات إصدار بسيطة ومرنة
- إيقاف الموارد غير المستخدمة ديناميكيًا
- من السهل اقامة
4
CI / قرص مضغوط
جيتلاب سي
- اختبارات جزء من خط الأنابيب
- ردود فعل سريعة
- الرؤية للشركة / الفريق بأكمله
5
المنصات السحابية
نظام التشغيل السحابي من غوغل
- الموارد عند الطلب (نحن ندفع فقط عند الحاجة)
- سهولة الإدارة والتحديث
- الرؤية والتحكم في جميع الموارد
6
تزامن
Kubernetes
في سياق الحاويات التي تحتوي على المتصفحات/المحاكيات داخل القرون:
- التحجيم / التحجيم التلقائي
- الشفاء الذاتي
- التحديثات والتراجعات دون انقطاع
7
البنية التحتية كرمز (IaC)
Terraform، Ansible
- فوائد مماثلة مع تطوير البنية التحتية
- جميع فوائد إصدار التعليمات البرمجية
- من السهل إجراء التغييرات والصيانة
- مؤتمتة بالكامل
مخططات الخريطة الذهنية: تطور البنية التحتية
الخطوة 1: المحلية
الخطوة 2: VCS
الخطوة 3: الحاويات
الخطوة 4: CI/CD
الخطوة 5: المنصات السحابية
الخطوة 6: التنسيق
الخطوة 7: IAC
ما هي الخطوة التالية؟
إذن هذه نهاية المقال. لكن في الختام أود عقد بعض الاتفاقيات معكم.
من جانبك
كما قلت في البداية، أود أن تكون المقالة ذات فائدة عملية وأن تساعدك على تطبيق المعرفة المكتسبة في العمل الحقيقي. وأضيف مرة أخرى.
ولكن حتى بعد ذلك، لا تتوقف، قم بالتدرب، وادرس الروابط والكتب ذات الصلة، واكتشف كيف تعمل في شركتك، وابحث عن الأماكن التي يمكن تحسينها والمشاركة فيها. حظ سعيد!
من جانبي
من العنوان يمكنك أن ترى أن هذا كان الجزء الأول فقط. على الرغم من أنها كانت كبيرة جدًا، إلا أن الموضوعات المهمة لم يتم تناولها هنا بعد. في الجزء الثاني، أخطط لإلقاء نظرة على البنية التحتية للأتمتة في سياق IOS. نظرًا للقيود التي تفرضها Apple على تشغيل محاكيات iOS على أنظمة macOS فقط، فقد تم تضييق نطاق الحلول لدينا. على سبيل المثال، لا يمكننا استخدام Docker لتشغيل جهاز المحاكاة أو السحابة العامة لتشغيل الأجهزة الافتراضية. لكن هذا لا يعني أنه لا توجد بدائل أخرى. سأحاول أن أبقيك على اطلاع دائم بالحلول المتقدمة والأدوات الحديثة!
كما أنني لم أذكر موضوعات كبيرة تتعلق بالمراقبة. في الجزء الثالث، سألقي نظرة على أدوات مراقبة البنية التحتية الأكثر شيوعًا وما هي البيانات والمقاييس التي يجب مراعاتها.
وأخيرا. وفي المستقبل، أخطط لإصدار دورة فيديو حول بناء البنية التحتية للاختبار والأدوات الشائعة. يوجد حاليًا عدد لا بأس به من الدورات والمحاضرات حول DevOps على الإنترنت، ولكن يتم تقديم جميع المواد في سياق التطوير، وليس في سياق أتمتة الاختبار. فيما يتعلق بهذه المسألة، أحتاج حقًا إلى تعليقات حول ما إذا كانت هذه الدورة التدريبية ستكون مثيرة للاهتمام وقيمة لمجتمع المختبرين ومهندسي الأتمتة. شكرا لكم مقدما!
المصدر: www.habr.com