Get best of the week

أدوات DevOps ليست فقط لـ DevOps. عملية بناء بنية تحتية لأتمتة الاختبار من الصفر

الجزء الأول: الويب / Android


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



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

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


المصدر: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

هنا ، من المحتمل أن ننتهي من الجزء التمهيدي ونركز على الغرض من هذه المقالة. 

عن ماذا تتحدث هذه المقالة


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

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

ما ليس في هذه المقالة


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

هذا بسبب الحقيقة بأن: 

  • من السهل جدًا العثور على هذه المواد في مصادر مختلفة (التوثيق والكتب ودورات الفيديو) ؛
  • إذا بدأنا في الخوض بشكل أعمق ، فسيتعين علينا كتابة 10 و 20 و 30 جزءًا من هذه المقالة (في حين أن الخطط 2-3) ؛
  • لا أريد أن أضيع وقتك ، لأنك ربما تريد استخدام أدوات أخرى لتحقيق نفس الأهداف.

ممارسة


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

خطة


خطوةتقنيةأدوات
1تشغيل محلي (إعداد اختبارات تجريبية على الويب / android وتشغيلها محليًا) Node.js ، السيلينيوم ، Appium
2أنظمة التحكم في الإصدار شخص سخيف
3حاوياتDocker ، شبكة Selenium ، Selenoid (الويب ، Android)
4CI / CDGitlab ci
5المنصات السحابيةمنصة Google السحابية
6تزامنKubernetes
7البنية التحتية كرمز (IaC)Terraform غير مرئي

هيكل كل قسم


للحفاظ على السرد في شكل مرئي ، يتم وصف كل قسم على النحو التالي:

  • ,
  • ,
  • ,
  • ,
  • .

1.



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

ومع ذلك ، كأداة أتمتة ، أوصي باستخدام Selenium WebDriver لمنصات الويب و Appium لمنصة Android ، على التوالي ، حيث سنستخدم في الخطوات التالية صور Docker المصممة خصيصًا للعمل بشكل خاص مع هذه الأدوات. علاوة على ذلك ، وبالإشارة إلى المتطلبات في الوظائف الشاغرة ، فإن هذه الأدوات هي الأكثر طلبًا في السوق.

كما لاحظت ، فإننا نأخذ بعين الاعتبار اختبارات الويب و Android فقط. لسوء الحظ ، فإن iOS قصة مختلفة تمامًا (بفضل Apple). أخطط لعرض الحلول والممارسات المتعلقة بنظام iOS في الأجزاء التالية.

قيمة البنية التحتية للأتمتة


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

توضيح الوضع الحالي للبنية التحتية




روابط التعلم



أدوات مماثلة


  • أي لغة برمجة تحبها بالاشتراك مع Selenium / Appium - الاختبارات ؛
  • أي اختبارات ؛
  • أي عداء اختبار.

2. أنظمة التحكم في الإصدار (Git)


موجز التكنولوجيا


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

قيمة البنية التحتية للأتمتة


وهنا يمكنك طرح سؤال معقول: "لماذا يخبرنا عن Git؟ الجميع يعرف ويستخدم هذا لكل من كود التطوير وكود الاختبار التلقائي ". ستكون على حق تمامًا ، ولكن في هذه المقالة نتحدث عن البنية التحتية ويلعب هذا القسم دور معاينة القسم 7: "البنية التحتية كرمز (IaC)". بالنسبة لنا ، هذا يعني أن البنية التحتية بأكملها ، بما في ذلك الاختبار ، موصوفة في شكل رمز ، لذلك يمكننا أيضًا تطبيق أنظمة الإصدار عليها والحصول على مزايا مماثلة لكل من كود التطوير والتشغيل الآلي.

سنلقي نظرة على IaC بمزيد من التفصيل في الخطوة 7 ، ولكن حتى الآن يمكنك البدء في استخدام Git محليًا عن طريق إنشاء مستودع محلي. سيتم توسيع الصورة الكبيرة عندما نضيف مستودعًا بعيدًا إلى البنية التحتية.

توضيح الوضع الحالي للبنية التحتية




روابط التعلم



أدوات مماثلة



3. الحاويات (دوكر)


موجز التكنولوجيا


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

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

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

بطبيعة الحال ، تقنية الحاويات ليست جديدة وقد تم تقديمها لأول مرة في أواخر السبعينيات. في تلك الأيام ، كان هناك الكثير من البحث والأساس والمحاولات. لكن دوكر هو من قام بتكييف هذه التكنولوجيا وجعلها في متناول الجماهير بسهولة. في الوقت الحاضر ، عندما نتحدث عن الحاويات ، نعني في معظم الحالات Docker. عندما نتحدث عن حاويات Docker ، فإننا نعني حاويات Linux. يمكننا استخدام أنظمة Windows و macOS لتشغيل الحاويات ، ولكن من المهم أن نفهم أنه في هذه الحالة تظهر طبقة إضافية. على سبيل المثال ، يُطلق Docker على جهاز Mac بصمت حاويات داخل Linux VM خفيف الوزن. سنعود إلى هذا الموضوع عندما نناقش إطلاق محاكيات Android داخل الحاويات ، وهنا يظهر فارق بسيط مهم للغاية ، والذي يحتاج إلى تحليل بمزيد من التفاصيل.

قيمة البنية التحتية للأتمتة


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

  • عدد كبير من التبعيات عند تثبيت السيلينيوم وخاصة Appium ؛
  • مشكلات التوافق بين إصدارات المتصفحات والمحاكاة وبرامج التشغيل ؛
  • نقص المساحة المعزولة للمتصفحات / المحاكيات ، وهو أمر بالغ الأهمية بشكل خاص للإطلاق المتوازي ؛
  • من الصعب إدارته وصيانته إذا كنت بحاجة إلى تشغيل 10 أو 50 أو 100 أو حتى 1000 متصفح في نفس الوقت.

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

شبكة السيلينيوم في عامل الميناء

هذه الأداة هي الأكثر شعبية في عالم السيلينيوم لإطلاق وإدارة متصفحات متعددة على أجهزة متعددة من موقع مركزي. للبدء ، يجب عليك تسجيل جزأين على الأقل: Hub و Node (s). المحور هو موقع مركزي يتلقى جميع الطلبات من الاختبارات ويوزعها على العقد المناسبة. لكل عقدة ، يمكننا تكوين تكوين معين ، على سبيل المثال ، تحديد المتصفح المطلوب وإصداره. ومع ذلك ، ما زلنا بحاجة إلى رعاية برامج تشغيل المتصفح المتوافقة بأنفسنا وتثبيتها على العقد الضرورية. لهذا السبب ، لا يتم استخدام شبكة Selenium في شكلها النقي ، إلا عندما نحتاج إلى العمل مع المتصفحات التي لا يمكن تثبيتها على نظام التشغيل Linux.بالنسبة لجميع الحالات الأخرى ، يعد استخدام صورة Docker لتشغيل شبكة Selenium Hub and Nodes حلًا مرنًا وصحيحًا. يبسط هذا النهج بشكل كبير إدارة العقد ، حيث يمكننا اختيار الصورة التي نحتاجها مع الإصدارات المتوافقة المثبتة بالفعل من المتصفحات وبرامج التشغيل.

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

الملف اللولبي للويب

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

ولكن للأسف ، لا يزال الملف اللولبي ليس رصاصة فضية. لدينا ميزة المتصفح عند الطلب ، ولكن ميزة الموارد عند الطلب لا تزال غير متوفرة. لاستخدام ملف Selenoid ، نحتاج إلى نشره على جهاز مادي أو VM ، مما يعني أننا بحاجة إلى أن نعرف مسبقًا مقدار الموارد التي يجب تخصيصها. أعتقد أن هذه ليست مشكلة للمشاريع الصغيرة التي تعمل بـ 10 أو 20 أو حتى 30 متصفحًا بالتوازي. ولكن ماذا لو احتجنا إلى 100 ، 500 ، 1000 وأكثر؟ ليس من المنطقي الحفاظ على العديد من الموارد ودفعها طوال الوقت. في القسمين 5 و 6 من هذه المقالة ، سنناقش الحلول التي تسمح لك بالتوسع ، وبالتالي تقليل تكاليف الشركة بشكل كبير.

الملف اللولبي للروبوت

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

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

توضيح الوضع الحالي للبنية التحتية


في سياق هذه المقالة ، سنضيف أداتين لتوضيح البنية التحتية. هذه هي شبكة Selenium لاختبارات الويب و Selenoid لاختبارات Android. في دليل GitHub ، سأوضح أيضًا كيفية استخدام ملف Selenoid لتشغيل اختبارات الويب. 



روابط التعلم



أدوات مماثلة


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

4. CI / CD


موجز التكنولوجيا


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

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

  • التكامل المستمر هو الخطوة الأولى في التطور. بعد إرسال الرمز الجديد إلى الخادم ، نتوقع الحصول على تعليقات سريعة مفادها أن كل شيء على ما يرام مع تغييراتنا. عادةً ، يتضمن CI إطلاق أدوات تحليل الكود الثابت واختبارات الوحدة / واجهة برمجة التطبيقات الداخلية. يسمح لك هذا بالحصول على معلومات حول الكود بعد بضع ثوانٍ / دقائق.
  • Continuous Delivery , /UI-. , CI. -, . -, test/staging — . , , .
  • Continuous Deployment , (release) production, . release , smoke — production . Continuous Deployment . - , , Continuous (). , Continuous Delivery.


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

وقبل أن ننظر إلى الرسم التوضيحي لتغيير الهندسة المعمارية ، أريد أن أقول بضع كلمات حول GitLab CI. على عكس أدوات CI / CD الأخرى ، يوفر GitLab مستودعًا بعيدًا والعديد من الميزات المتقدمة الأخرى. لذا فإن GitLab أكثر من CI. ويتضمن التحكم خارج المصدر ، والإدارة الرشيقة ، وخطوط أنابيب CI / CD ، وأدوات التسجيل ، وجمع المقاييس. تتكون بنية GitLab من Gitlab CI / CD و GitLab Runner. أعطي وصفا موجزا من الموقع الرسمي:
Gitlab CI / CD هو تطبيق ويب مزود بواجهة برمجة التطبيقات (API) التي تخزن حالتها في قاعدة بيانات ، وتدير المشاريع / الإنشاءات وتوفر واجهة مستخدم. GitLab Runner هو تطبيق يقوم بمعالجة الإصدارات. يمكن نشره بشكل منفصل ويعمل مع GitLab CI / CD من خلال API. لإجراء الاختبارات ، تحتاج إلى مثيل Gitlab و Runner.








5.



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

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

قيمة البنية التحتية للأتمتة


ما الموارد المحددة التي نحتاجها لاختبارات واجهة المستخدم من طرف إلى طرف؟ هذه هي بشكل أساسي آلات أو مجموعات افتراضية (سنتحدث عن Kubernetes في القسم التالي) لإطلاق المتصفحات والمحاكاة. كلما زاد عدد المتصفحات والمحاكيات التي نريد تشغيلها في نفس الوقت ، كلما زادت الحاجة إلى وحدة المعالجة المركزية والذاكرة والمزيد من المال الذي سنضطر إلى دفعه مقابل ذلك. وبالتالي ، تتيح لنا السحابة العامة في سياق اختبار الأتمتة إطلاق عدد كبير (100 ، 200 ، 1000 ...) من المتصفحات / المحاكيات عند الطلب ، والحصول على نتائج الاختبار في أسرع وقت ممكن ، والتوقف عن الدفع مقابل مثل هذه القدرات التي تتطلب الكثير من الموارد بجنون. 

أشهر مزودي الخدمات السحابية هم Amazon Web Services (AWS) و Microsoft Azure و Google Cloud Platform (GCP). يقدم الدليل العملي أمثلة على استخدام برنامج "شركاء Google المعتمدون" ، ولكن بشكل عام لا يهم ما الذي ستستخدمه لمهام الأتمتة. جميعها توفر نفس الوظيفة تقريبًا. بشكل عام ، لتحديد مزود ، تركز الإدارة على البنية التحتية الكاملة للشركة ومتطلبات العمل ، والتي تقع خارج نطاق هذه المقالة. سيكون الأمر أكثر إثارة للاهتمام لمهندسي الأتمتة لمقارنة استخدام مزودي الخدمات السحابية باستخدام الأنظمة الأساسية السحابية خصيصًا لأغراض الاختبار مثل Sauce Labs و BrowserStack و BitBar وما إلى ذلك. لذلك دعونا نفعل نفس الشيء! في رأيي ، Sauce Labs هي أشهر مزرعة اختبار سحابية ، لذلك أخذتها للمقارنة. 

GCP مقابل Sauce Labs for Automation:

تخيل أننا بحاجة إلى تشغيل 8 اختبارات ويب و 8 اختبارات Android في نفس الوقت. للقيام بذلك ، سوف نستخدم GCP ونقوم بتشغيل جهازين افتراضيين مع الملف اللولبي. في الأول سنقوم برفع 8 حاويات مع المتصفحات. في الثانية - 8 حاويات مع المحاكيات. دعونا نلقي نظرة على الأسعار:  


لتشغيل حاوية واحدة مع Chrome ، نحتاج إلى جهاز n1-standard-1 . في حالة Android ، سيكون هذا n1-standard-4 لمحاكي واحد. في الواقع ، هناك طريقة أكثر مرونة وأرخص هي تعيين قيم مستخدم محددة لوحدة المعالجة المركزية / الذاكرة ، ولكن في الوقت الحالي ليس من المهم المقارنة مع Sauce Labs.

وإليك معدلات استخدام Sauce Labs:


أفترض أنك لاحظت بالفعل الفرق ، ولكن ما زلت سأعطي جدولًا بالحسابات لمهمتنا:

الموارد المطلوبةمونتليساعات العمل (8 ص - 8 م)ساعات العمل + استباقية
Gcp للويبn1-standard-1 x 8 = n1-standard-8194.18 دولار23 يومًا * 12 ساعة * 0.38 = 104.88 دولارًا 23 يومًا * 12 ساعة * 0.08 = 22.08 دولارًا
مختبرات الصلصة للويباختبارات موازية Cloud8 الظاهري1.559 دولار--
GCP لنظام Androidn1-standard-4 x 8: n1-standard-16776.72 دولار23 يومًا * 12 ساعة * 1.52 = 419.52 دولارًا 23 يومًا * 12 ساعة * 0.32 = 88.32 دولارًا
مختبرات الصلصة للأندرويداختبارات الجهاز الحقيقي 8 سحابة متوازية1.999 دولار--

كما ترون ، فإن الفرق في التكلفة كبير ، خاصة إذا قمت بإجراء الاختبارات فقط في فترة اثنتي عشرة ساعة عمل. ولكن يمكنك تقليل التكاليف باستخدام آلات استباقية. ما هذا؟
A preemptible VM is an instance that you can create and run at a muchower price than normal instances. However, Compute Engine might terminate (preempt) these instances if it requires access to those resources for other tasks. Preemptible instances are excess Compute Engine capacity, so their availability varies with usage.

If your apps are fault-tolerant and can withstand possible instance preemptions, then preemptible instances can reduce your Compute Engine costs significantly. For example, batch processing jobs can run on preemptible instances. If some of those instances terminate during processing, the job slows but does not completely stop. Preemptible instances complete your batch processing tasks without placing additional workload on your existing instances and without requiring you to pay full price for additional normal instances.

وهذه ليست النهاية! في الواقع ، أنا متأكد من أنه لا أحد يجري الاختبارات لمدة 12 ساعة دون انقطاع. وإذا كان الأمر كذلك ، فيمكنك بدء وإيقاف الأجهزة الافتراضية تلقائيًا عندما لا تكون هناك حاجة إليها. قد ينخفض ​​وقت الاستخدام الفعلي إلى 6 ساعات في اليوم. ثم سينخفض ​​الدفع في سياق مهمتنا بقدر 11 دولارًا شهريًا لـ 8 متصفحات. أليس هذا مثاليًا؟ ولكن مع الآلات الوقائية ، يجب أن نكون حذرين ومستعدين للانقطاعات والتشغيل غير المستقر ، على الرغم من أنه يمكن توفير هذه المواقف ومعالجتها برمجيًا. انه يستحق ذلك!

لكنني لا أقول بأي حال من الأحوال "لا تستخدم أبداً مزارع الاختبار السحابي". لديهم مزايا عديدة. بادئ ذي بدء ، هذا ليس مجرد آلة افتراضية ، ولكنه حل كامل لاختبار الأتمتة مع مجموعة من الوظائف الجاهزة: الوصول عن بعد ، والسجلات ، ولقطات الشاشة ، وتسجيل الفيديو ، ومتصفحات متنوعة وأجهزة متنقلة مادية. في العديد من المواقف ، يمكن أن يكون هذا بديلاً أنيقًا لا غنى عنه. تعتبر منصات الاختبار بشكل خاص مفيدة لأتمتة IOS عندما يمكن للسحب العامة أن تقدم أنظمة Linux / Windows فقط. لكن الحديث عن iOS سيكون في المقالات المستقبلية. أوصي دائمًا بالنظر في الموقف والبدء من المهام: في بعض الحالات يكون استخدام السحاب العام أرخص وأكثر فاعلية ، وفي بعض منصات الاختبار ، من المؤكد أنه يستحق الأموال التي تنفق.

توضيح الوضع الحالي للبنية التحتية




روابط التعلم



أدوات مماثلة:



6. الأوركسترا


موجز التكنولوجيا


لدي أخبار جيدة - لقد وصلنا تقريبًا إلى نهاية المقالة! في الوقت الحالي ، تتكون بنيتنا الأوتوماتيكية من اختبارات الويب و Android ، والتي نقوم بتشغيلها عبر GitLab CI بالتوازي ، باستخدام أدوات مع دعم Docker: شبكة Selenium و Selenoid. علاوة على ذلك ، نستخدم آلات افتراضية تم إنشاؤها من خلال GCP لرفع الحاويات التي تحتوي على متصفحات ومحاكيات فيها. لتقليل التكاليف ، نبدأ هذه الأجهزة الافتراضية فقط عند الطلب ونتوقف عند عدم إجراء الاختبار. هل هناك أي شيء آخر يمكن أن يحسن بنيتنا التحتية؟ الجواب نعم! تعرف على Kubernetes (K8s)!

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

في الحقيقة ، يعد نشر Kubernetes يدويًا من البداية مهمة غير تافهة تمامًا. سأترك رابطًا إلى Kubernetes The Hard Way ، وهو دليل عملي معروف ، وإذا كنت مهتمًا ، يمكنك التدرب. ولكن لحسن الحظ ، هناك طرق وأدوات بديلة. أسهلها هو استخدام Google Kubernetes Engine (GKE) في GCP ، والذي سيسمح لك بالحصول على مجموعة جاهزة بعد بضع نقرات. لبدء الدراسة ، أوصيك باستخدام هذا النهج ، لأنه سيسمح لك بالتركيز على تعلم كيفية استخدام K8s في مهامك ، بدلاً من استكشاف كيفية دمج المكونات الداخلية. 

قيمة البنية التحتية للأتمتة


خذ بعين الاعتبار بعض الميزات الهامة التي توفرها K8s:

  • : multi-nodes , VMs;
  • : , ;
  • (Self-healing): pods ( );
  • : ,

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

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

الآن فكر في أدواتنا في سياق المصطلحات أعلاه.

شبكة السيلينيوم

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

الملف اللولبي :

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

القمر :

بمعرفة هذا الاختناق أثناء العمل مع Selenoid ، أصدر المطورون أداة أكثر قوة تسمى Moon. تم تصميم هذه الأداة في الأصل للعمل مع Kubernetes ، ونتيجة لذلك ، يمكنك ويجب عليك استخدام وظيفة مقياس تلقائي. علاوة على ذلك ، أود أن أقول أنه في الوقت الحالي هو الوحيدأداة في عالم السيلينيوم ، والتي تحتوي على دعم مجموعة K8s الأصلي ( لم تعد متاحة ، راجع الأداة التالية ). الميزة الرئيسية لـ Moon التي توفر هذا الدعم هي: 
عديم الجنسية تمامًا. يقوم الملف اللولبي بتخزين معلومات الذاكرة حول جلسات المتصفح التي تعمل حاليًا. إذا تعطلت العملية لسبب ما - فستفقد جميع الجلسات الجارية. القمر ليس له حالة داخلية ، ويمكن نسخه عبر مراكز البيانات. تبقى جلسات المتصفح حية حتى في حالة تعطل نسخة متماثلة واحدة أو أكثر.
لذا ، القمر هو حل رائع ، ولكن مع مشكلة واحدة ، فهو ليس مجانيًا. السعر يعتمد على عدد الجلسات. يمكن إطلاق 0-4 جلسات فقط مجانًا ، وهو ليس مفيدًا بشكل خاص. ولكن ، بدءًا من الجلسة الخامسة ، سيتعين عليك دفع 5 دولارات لكل منها. قد يختلف الموقف من شركة لأخرى ، ولكن في حالتنا ، فإن استخدام Moon لا طائل من ورائه. كما وصفت أعلاه ، يمكننا بدء تشغيل VMs مع Selenium Grid عند الطلب أو زيادة عدد العقد في المجموعة. بالنسبة لخط أنابيب واحد تقريبًا ، نطلق 500 متصفحًا ونوقف جميع الموارد بعد اكتمال الاختبارات. إذا استخدمنا Moon ، فسيتعين علينا دفع 500 × 5 إضافية = 2500 دولارًا أمريكيًا شهريًا ولا يهم عدد مرات إجراء الاختبارات. ومرة أخرى ، لا أقول "لا تستخدم القمر". بالنسبة لمهامك ، يمكن أن يكون هذا حلاً لا غنى عنه ، على سبيل المثال ،إذا كان لديك الكثير من المشاريع / الفرق في مؤسستك وتحتاج إلى مجموعة مشتركة ضخمة للجميع. كما هو الحال دائمًا ، أترك رابطًا في النهاية وأوصي بإجراء جميع الحسابات اللازمة في سياق مهمتك.

كاليستو : ( إنتباه! هذا ليس في المقالة الأصلية ولا يوجد إلا في الترجمة الروسية )

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







7. (IaC)



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

لنبدأ بالدافع لاستخدام هذا النهج. لقد ناقشنا بالفعل أنه لتشغيل الاختبارات في GitlabCI نحتاج على الأقل إلى الموارد لتشغيل Gitlab Runner. ولتشغيل حاويات تحتوي على متصفحات / محاكيات ، نحتاج إلى حجز VM أو مجموعة. بالإضافة إلى اختبار الموارد ، نحتاج إلى عدد كبير من القدرات لدعم بيئات التطوير والتدريج والإنتاج ، والذي يتضمن أيضًا قواعد البيانات والجداول التلقائية وتكوينات الشبكة وموازنات التحميل وحقوق المستخدم وما إلى ذلك. القضية الرئيسية هي الجهد المطلوب لدعم هذا كله. هناك عدة طرق يمكننا من خلالها إجراء التغييرات ونشر التحديثات. على سبيل المثال ، في سياق GCP ، يمكننا استخدام وحدة تحكم واجهة المستخدم في المتصفح وتنفيذ جميع الإجراءات عن طريق النقر على الأزرار.هناك طريقة بديلة تتمثل في استخدام مكالمات API للتفاعل مع الكيانات السحابية أو استخدام أداة سطر الأوامر gcloud لإجراء المعالجات اللازمة. ولكن مع وجود عدد كبير جدًا من الكيانات وعناصر البنية التحتية المختلفة ، يصبح من الصعب أو حتى المستحيل إجراء جميع العمليات يدويًا. علاوة على ذلك ، كل هذه الإجراءات اليدوية لا يمكن السيطرة عليها. لا يمكننا إرسالها لمراجعتها قبل التنفيذ ، واستخدام نظام التحكم في الإصدار واسترجاع التعديلات التي أدت إلى الحادث بسرعة. لحل هذه المشاكل ، قام المهندسون بإنشاء وإنشاء برامج نصية bash / shell تلقائية ، وهي ليست أفضل بكثير من الطرق السابقة ، نظرًا لأنها ليست سهلة القراءة والفهم والصيانة والتعديل بأسلوب إجرائي.

في هذه المقالة وكيفية الاستخدام ، أستخدم أداتين تتعلقان بممارسة IaC. هذه هي Terraform و Ansible. يعتقد البعض أنه ليس من المنطقي استخدامها في وقت واحد ، لأن وظائفهم متشابهة وقابلة للتبادل. لكن الحقيقة هي أنهم يواجهون في البداية مهام مختلفة تمامًا. وتم تأكيد حقيقة أن هذه الأدوات يجب أن تكمل بعضها البعض في عرض مشترك من قبل المطورين الذين يمثلون HashiCorp و RedHat. الاختلاف المفاهيمي هو أن Terraform هي أداة إدارة لإدارة الخوادم نفسها. بينما Ansible هي أداة إدارة تكوين مهمتها تثبيت وتكوين وإدارة البرامج على هذه الخوادم.

ميزة رئيسية أخرى مميزة لهذه الأدوات هي أسلوب كتابة التعليمات البرمجية. على عكس bash و Ansible ، يستخدم Terraform نمطًا إعلانيًا استنادًا إلى وصف الحالة النهائية المرغوبة ، والتي يجب تحقيقها نتيجة التنفيذ. على سبيل المثال ، إذا كنا سننشئ 10 VMs ونطبق التغييرات من خلال Terraform ، فإننا نحصل على 10 VMs. إذا قمت بتطبيق البرنامج النصي مرة أخرى ، فلن يحدث شيء ، نظرًا لأن لدينا 10 VMs بالفعل ، و Terraform تعرف عنه ، لأنها تخزن الحالة الحالية للبنية التحتية في ملف حالة. لكن Ansible يستخدم نهجًا إجرائيًا ، وإذا طلبت منه إنشاء 10 VMs ، فعند التشغيل الأول نحصل على 10 VMs ، بالمثل مع Terraform. ولكن بعد إعادة التشغيل ، سيكون لدينا بالفعل 20 جهاز VM. هذا هو الفرق المهم.في الأسلوب الإجرائي ، لا نقوم بتخزين الحالة الحالية ونصف ببساطة تسلسل الخطوات التي يجب إكمالها. بالطبع ، يمكننا التعامل مع المواقف المختلفة ، وإضافة العديد من عمليات التحقق من وجود الموارد والحالة الحالية ، ولكن لا فائدة من إضاعة وقتنا وبذل الجهود للسيطرة على هذا المنطق. بالإضافة إلى ذلك ، يزيد هذا من خطر ارتكاب الأخطاء. 

بتلخيص كل ما سبق ، يمكننا أن نستنتج أنه بالنسبة لتوفير الخوادم ، فإن Terraform والتدوين التعريفي أداة أكثر ملاءمة. ولكن تفويض عمل إدارة التكوين بشكل أفضل إلى Ansible. بعد التعامل مع هذا ، دعونا نلقي نظرة على أمثلة للاستخدام في سياق الأتمتة.

قيمة البنية التحتية للأتمتة


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

فيما يلي بعض الأمثلة على استخدام Terraform و Ansible في سياق اختبار الأتمتة والأدوات التي ناقشناها من قبل:

1. صف من خلال Terraform الخصائص والمعلمات اللازمة للأجهزة VM والمجموعات.

2. التثبيت مع Ansible الأدوات اللازمة للاختبار: docker ، Selenoid ، Selenium Grid وتنزيل الإصدارات الضرورية من المتصفحات / المحاكيات.

3. صف من خلال Terraform خصائص VM التي سيتم فيها إطلاق GitLab Runner.

4. التثبيت مع Ansible GitLab Runner والأدوات ذات الصلة اللازمة ، قم بتعيين الإعدادات والتكوينات.

توضيح الوضع الحالي للبنية التحتية



روابط الدراسة:



أدوات مماثلة




كي تختصر!


خطوةتقنيةأدواتقيمة البنية التحتية للأتمتة
1Local runningNode.js, Selenium, Appium
  • web mobile
  • ( Node.js)

2Version control systems Git

3ContainerisationDocker, Selenium grid, Selenoid (Web, Android)
  • ,

4CI / CDGitlab CI
  • /

5Cloud platformsGoogle Cloud Platform
  • ( )

6OrchestrationKubernetes/ pods:
  • /

7البنية التحتية كرمز (IaC)Terraform غير مرئي
  • فوائد مماثلة مع البنية التحتية للتنمية
  • جميع فوائد اصدار الكود
  • من السهل إجراء التغييرات والحفاظ عليها
  • مؤتمتة بالكامل



مخططات الخريطة الذهنية: تطور البنية التحتية


الخطوة 1: محلي


الخطوة 2: فكس


الخطوة 3: حاويات 


الخطوة 4: CI / CD 


الخطوة 5: المنصات السحابية


الخطوة 6: التزامن


الخطوة 7: IaC


ماذا بعد؟


إذن هذه هي نهاية المقال. ولكن في الختام ، أود أن أبرم بعض الاتفاقات معك.

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

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

من جانبي

من العنوان يتضح أن هذا كان الجزء الأول فقط. على الرغم من حقيقة أنها اتضح أنها كبيرة جدًا ، إلا أنه لم يتم الكشف عن مواضيع مهمة هنا. في الجزء الثاني ، أخطط للنظر في البنية التحتية للأتمتة في سياق IOS. نظرًا لقيود Apple فيما يتعلق بتشغيل عمليات محاكاة iOS فقط على أنظمة macOS ، تم تضييق مجموعة حلولنا. على سبيل المثال ، لا يمكننا استخدام Docker لتشغيل جهاز محاكاة أو غيوم عامة لتشغيل الأجهزة الافتراضية. لكن هذا لا يعني أنه لا توجد بدائل أخرى. سأحاول إبقائك على اطلاع بأحدث الحلول والأدوات الحديثة!

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

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

More articles:


All Articles