قسمت 1: وب/اندروید

یادداشت: این مقاله ترجمه مقاله اصلی به زبان روسی است ابزارهای DevOps فقط برای DevOps نیستند. "ساختن زیرساخت اتوماسیون تست از ابتدا." با این حال، تمام تصاویر، پیوندها، نقل قول ها و اصطلاحات به زبان اصلی حفظ می شوند تا از تحریف معنی هنگام ترجمه به روسی جلوگیری شود. برای شما آرزوی موفقیت در تحصیل دارم

در حال حاضر، تخصص DevOps یکی از پر تقاضاترین ها در صنعت IT است. اگر سایت های محبوب جستجوی کار را باز کنید و بر اساس حقوق فیلتر کنید، خواهید دید که مشاغل مرتبط با DevOps در بالای لیست قرار دارند. با این حال، درک این نکته مهم است که این به طور عمده به یک موقعیت "عالی" اشاره دارد که به این معنی است که داوطلب دارای سطح بالایی از مهارت ها، دانش فناوری و ابزار است. این همچنین با درجه بالایی از مسئولیت مرتبط با عملیات بی وقفه تولید همراه است. با این حال، ما شروع به فراموش کردن کردیم که DevOps چیست. در ابتدا، شخص یا بخش خاصی نبود. اگر به دنبال تعاریفی از این اصطلاح بگردیم، اسامی زیبا و صحیح بسیاری از جمله روش شناسی، عمل، فلسفه فرهنگی، گروه مفاهیم و غیره را خواهیم یافت.

تخصص من یک مهندس اتوماسیون تست (مهندس اتوماسیون QA) است، اما معتقدم که نباید فقط با نوشتن تست های خودکار یا توسعه معماری چارچوب تست مرتبط باشد. در سال 2020، دانش زیرساخت های اتوماسیون نیز ضروری است. این به شما امکان می‌دهد فرآیند اتوماسیون را خودتان سازماندهی کنید، از اجرای آزمایش‌ها گرفته تا ارائه نتایج به همه ذینفعان مطابق با اهدافتان. در نتیجه، مهارت های DevOps برای انجام کار ضروری است. و همه اینها خوب است، اما، متأسفانه، یک مشکل وجود دارد (spoiler: این مقاله سعی دارد این مشکل را ساده کند). نکته این است که DevOps سخت است. و این بدیهی است، زیرا شرکت‌ها برای کاری که انجام آن آسان است، هزینه زیادی نمی‌پردازند... در دنیای DevOps، تعداد زیادی ابزار، اصطلاحات و روش‌ها وجود دارد که نیاز به تسلط دارند. این امر به ویژه در ابتدای کار دشوار است و به تجربه فنی انباشته شده بستگی دارد.

منبع: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

در اینجا احتمالاً با قسمت مقدماتی پایان می دهیم و به هدف این مقاله می پردازیم. 

این مقاله درباره چیست؟

در این مقاله قصد دارم تجربه خود را از ساخت زیرساخت اتوماسیون آزمایشی به اشتراک بگذارم. منابع اطلاعاتی زیادی در اینترنت در مورد ابزارهای مختلف و نحوه استفاده از آنها وجود دارد، اما من دوست دارم آنها را صرفاً در چارچوب اتوماسیون بررسی کنم. من معتقدم که بسیاری از مهندسان اتوماسیون با شرایطی آشنا هستند که هیچ کس به جز شما تست های توسعه یافته را اجرا نمی کند یا به حفظ آنها اهمیت می دهد. در نتیجه تست ها قدیمی می شوند و باید برای به روز رسانی آن ها وقت بگذارید. باز هم، در آغاز یک حرفه، این می تواند یک کار بسیار دشوار باشد: تصمیم گیری عاقلانه که کدام ابزارها باید به حذف یک مشکل معین، نحوه انتخاب، پیکربندی و نگهداری آنها کمک کنند. برخی از آزمایش‌کنندگان برای کمک به DevOps (انسان‌ها) مراجعه می‌کنند و، صادقانه بگوییم، این رویکرد کار می‌کند. در بسیاری از موارد این ممکن است تنها گزینه باشد زیرا ما به همه وابستگی‌ها دسترسی نداریم. اما همانطور که می دانیم، DevOps افراد بسیار شلوغی هستند، زیرا آنها باید به کل زیرساخت های شرکت، استقرار، نظارت، میکروسرویس ها و سایر وظایف مشابه بسته به سازمان/تیم فکر کنند. همانطور که معمولاً اتفاق می افتد، اتوماسیون در اولویت نیست. در چنین شرایطی باید سعی کنیم از ابتدا تا انتها هر کاری که ممکن است از جانب خود انجام دهیم. این امر وابستگی ها را کاهش می دهد، گردش کار را سرعت می بخشد، مهارت های ما را بهبود می بخشد و به ما امکان می دهد تصویر بزرگتری از آنچه اتفاق می افتد ببینیم.

این مقاله محبوب ترین و محبوب ترین ابزارها را ارائه می دهد و نحوه استفاده از آنها را برای ساخت زیرساخت اتوماسیون گام به گام نشان می دهد. هر گروه با ابزارهایی نشان داده می شود که از طریق تجربه شخصی آزمایش شده اند. اما این بدان معنا نیست که شما باید از همان چیزی استفاده کنید. خود ابزارها مهم نیستند، ظاهر می شوند و منسوخ می شوند. وظیفه مهندسی ما درک اصول اولیه است: چرا به این گروه از ابزارها نیاز داریم و چه مشکلات کاری را می توانیم با کمک آنها حل کنیم. به همین دلیل است که در پایان هر بخش پیوندهایی را به ابزارهای مشابهی که ممکن است در سازمان شما استفاده شود، می گذارم.

آنچه در این مقاله نیست

یک بار دیگر تکرار می کنم که مقاله در مورد ابزار خاصی نیست، بنابراین هیچ کدی از اسناد و توضیحات دستورات خاص درج نخواهد شد. اما در پایان هر بخش پیوندهایی برای مطالعه دقیق می گذارم.

این کار به این دلیل انجام می شود که: 

• یافتن این مطالب در منابع مختلف (اسناد، کتاب، دوره های ویدیویی) بسیار آسان است.
• اگر شروع به عمیق تر شدن کنیم، باید 10، 20، 30 قسمت از این مقاله را بنویسیم (در حالی که برنامه ها 2-3 هستند).
• من فقط نمی خواهم وقت شما را تلف کنم زیرا ممکن است بخواهید از ابزارهای دیگری برای رسیدن به اهداف مشابه استفاده کنید.

عمل

من واقعاً دوست دارم این مطالب برای هر خواننده ای مفید باشد، نه اینکه فقط خوانده شود و فراموش شود. در هر مطالعه، تمرین جزء بسیار مهمی است. برای این آماده کرده ام مخزن GitHub با دستورالعمل های گام به گام در مورد نحوه انجام همه چیز از ابتدا. همچنین تکالیفی در انتظار شماست تا مطمئن شوید که خطوط دستوراتی را که اجرا می کنید بی خیال کپی نکنید.

برنامه ریزی کنید

گام
پیشرفته
ابزار

1
اجرای محلی (آزمایش های آزمایشی وب / اندروید را آماده کنید و آن را به صورت محلی اجرا کنید) 
Node.js، Selenium، Appium

2
سیستم های کنترل نسخه 
رفتن

3
کانتینری سازی
داکر، شبکه سلنیوم، سلنوئید (وب، اندروید)

4
CI/CD
Gitlab CI

5
سیستم عامل های ابر
Google Cloud Platform

6
تنظیم و ارکستراسیون
کوبرنیتس

7
زیرساخت به عنوان یک کد (IaC)
Terraform، Ansible

ساختار هر بخش

برای روشن نگه داشتن روایت، هر بخش بر اساس طرح کلی زیر شرح داده شده است:

• شرح مختصری از فناوری،
• ارزش برای زیرساخت اتوماسیون،
• تصویری از وضعیت فعلی زیرساخت،
• لینک های مطالعه،
• ابزارهای مشابه

1. تست ها را به صورت محلی اجرا کنید

شرح مختصری از تکنولوژی

این فقط یک مرحله مقدماتی برای اجرای آزمایش‌های آزمایشی به صورت محلی و تأیید موفقیت آنها است. در قسمت عملی از Node.js استفاده می شود اما زبان برنامه نویسی و پلتفرم آن نیز مهم نیست و می توانید از مواردی که در شرکت شما استفاده می شود استفاده کنید. 

با این حال، به عنوان ابزار اتوماسیون، توصیه می‌کنم به ترتیب از Selenium WebDriver برای پلتفرم‌های وب و Appium برای پلتفرم اندروید استفاده کنید، زیرا در مراحل بعدی از تصاویر Docker استفاده خواهیم کرد که برای کار با این ابزارها طراحی شده‌اند. همچنین با توجه به شرایط شغلی، این ابزار بیشترین تقاضا را در بازار دارد.

همانطور که ممکن است متوجه شده باشید، ما فقط تست های وب و اندروید را در نظر می گیریم. متأسفانه، iOS داستان کاملاً متفاوتی است (با تشکر از اپل). من قصد دارم راه‌حل‌ها و روش‌های مرتبط با IOS را در بخش‌های آینده به نمایش بگذارم.

ارزش برای زیرساخت اتوماسیون

از منظر زیرساخت، اجرای محلی هیچ ارزشی ارائه نمی دهد. شما فقط بررسی می کنید که تست ها بر روی ماشین محلی در مرورگرها و شبیه سازهای محلی اجرا شوند. اما در هر صورت، این یک نقطه شروع ضروری است.

تصویری از وضعیت فعلی زیرساخت ها

پیوندهایی برای کاوش

• سلنیوم
• اپیم
• شبیه ساز آندروید
• نمونه های Selenium JS GitHub
• نمونه های Appium JS GitHub

ابزارهای مشابه

• هر زبان برنامه نویسی که دوست دارید در رابطه با تست های سلنیوم/آپیوم.
• هر آزمایش؛
• هر دونده آزمایشی

2. سیستم های کنترل نسخه (Git)

شرح مختصری از تکنولوژی

اگر بگویم که کنترل نسخه بخش بسیار مهمی از توسعه است، چه در تیم و چه به صورت انفرادی، برای هیچ کس فاش بزرگی نخواهد بود. بر اساس منابع مختلف، به جرات می توان گفت که Git محبوب ترین نماینده است. سیستم کنترل نسخه مزایای زیادی مانند اشتراک گذاری کد، ذخیره نسخه ها، بازگردانی به شاخه های قبلی، نظارت بر تاریخچه پروژه و پشتیبان گیری را ارائه می دهد. ما در مورد هر نکته به تفصیل صحبت نمی کنیم، زیرا مطمئن هستم که شما با آن آشنایی کامل دارید و در کارهای روزمره خود از آن استفاده می کنید. اما اگر به طور ناگهانی نه، پس توصیه می کنم خواندن این مقاله را مکث کنید و این شکاف را در اسرع وقت پر کنید.

ارزش برای زیرساخت اتوماسیون

و در اینجا می توانید یک سوال معقول بپرسید: "چرا او درباره Git به ما می گوید؟ همه این را می دانند و هم برای کد توسعه و هم برای کد تست خودکار از آن استفاده می کنند. کاملاً حق با شماست، اما در این مقاله ما در مورد زیرساخت صحبت می کنیم و این بخش به عنوان پیش نمایش بخش 7 عمل می کند: "زیرساخت به عنوان کد (IaC)". برای ما، این بدان معناست که کل زیرساخت، از جمله آزمایش، به صورت کد توضیح داده شده است، بنابراین می‌توانیم سیستم‌های نسخه‌سازی را نیز برای آن اعمال کنیم و از مزایای مشابهی مانند کد توسعه و اتوماسیون برخوردار شویم.

ما در مرحله 7 به IaC با جزئیات بیشتری نگاه خواهیم کرد، اما حتی اکنون می توانید با ایجاد یک مخزن محلی شروع به استفاده از Git به صورت محلی کنید. وقتی یک مخزن راه دور به زیرساخت اضافه کنیم، تصویر بزرگ گسترش می یابد.

تصویری از وضعیت فعلی زیرساخت ها

پیوندهایی برای کاوش

• کنترل نسخه چیست؟
• رفتن
• شروع به کار - درباره کنترل نسخه

ابزارهای مشابه

• SVN
• تند 
• Microsoft TFS (اکنون بخشی از خدمات Azure DevOps است)

3. کانتینرسازی (Docker)

شرح مختصری از تکنولوژی

برای نشان دادن اینکه چگونه کانتینرسازی قواعد بازی را تغییر داده است، اجازه دهید به چند دهه قبل برگردیم. در آن زمان، مردم ماشین های سرور را برای اجرای برنامه ها خریداری می کردند و از آنها استفاده می کردند. اما در بیشتر موارد منابع استارتاپ مورد نیاز از قبل مشخص نبود. در نتیجه، شرکت ها برای خرید سرورهای گران قیمت و قدرتمند هزینه کردند، اما بخشی از این ظرفیت به طور کامل استفاده نشد.

مرحله بعدی تکامل ماشین های مجازی (VM) بود که مشکل هدر دادن پول برای منابع بلااستفاده را حل کرد. این فناوری امکان اجرای برنامه های کاربردی را به طور مستقل از یکدیگر در یک سرور فراهم می کند و فضای کاملاً ایزوله را اختصاص می دهد. اما متاسفانه هر تکنولوژی معایبی دارد. اجرای یک VM به یک سیستم عامل کامل نیاز دارد که CPU، RAM، فضای ذخیره سازی را مصرف می کند و بسته به سیستم عامل، هزینه های مجوز باید در نظر گرفته شود. این عوامل بر سرعت بارگذاری تاثیر می گذارد و قابلیت حمل را دشوار می کند.

و اکنون به کانتینرسازی می رسیم. بار دیگر، این فناوری مشکل قبلی را حل می کند، زیرا کانتینرها از سیستم عامل کامل استفاده نمی کنند، که مقدار زیادی از منابع را آزاد می کند و راه حلی سریع و انعطاف پذیر برای حمل و نقل ارائه می دهد.

البته فناوری کانتینرسازی چیز جدیدی نیست و اولین بار در اواخر دهه 70 معرفی شد. در آن روزها تحقیقات و توسعه ها و تلاش های زیادی صورت گرفت. اما این داکر بود که این فناوری را تطبیق داد و آن را به راحتی در دسترس توده ها قرار داد. امروزه وقتی در مورد کانتینر صحبت می کنیم، در بیشتر موارد منظور Docker است. وقتی از کانتینرهای داکر صحبت می کنیم، منظور کانتینرهای لینوکس است. ما می‌توانیم از سیستم‌های Windows و macOS برای اجرای کانتینرها استفاده کنیم، اما درک این نکته مهم است که در این مورد یک لایه اضافی ظاهر می‌شود. به عنوان مثال، Docker در مک به صورت بی صدا کانتینرها را در داخل یک لینوکس VM سبک وزن اجرا می کند. هنگامی که در مورد اجرای شبیه سازهای اندروید در داخل کانتینرها صحبت می کنیم، به این موضوع باز خواهیم گشت، بنابراین در اینجا نکته بسیار مهمی وجود دارد که باید با جزئیات بیشتر مورد بحث قرار گیرد.

ارزش برای زیرساخت اتوماسیون

متوجه شدیم که کانتینرسازی و داکر عالی هستند. بیایید به این موضوع در زمینه اتوماسیون نگاه کنیم، زیرا هر ابزار یا فناوری نیاز به حل یک مشکل دارد. اجازه دهید مشکلات آشکار اتوماسیون تست را در زمینه تست های UI بیان کنیم:

• تعداد زیادی وابستگی هنگام نصب سلنیوم و به خصوص Appium.
• مشکلات سازگاری بین نسخه های مرورگرها، شبیه سازها و درایورها؛
• عدم وجود فضای ایزوله برای مرورگرها/شبیه سازها، که به ویژه برای اجرای موازی بسیار مهم است.
• مدیریت و نگهداری در صورت نیاز به اجرای همزمان 10، 50، 100 یا حتی 1000 مرورگر دشوار است.

اما از آنجایی که سلنیوم محبوب‌ترین ابزار اتوماسیون و داکر محبوب‌ترین ابزار کانتینری‌سازی است، جای تعجب نیست که کسی سعی کرده است آنها را ترکیب کند تا ابزاری قدرتمند برای حل مشکلات ذکر شده در بالا ایجاد کند. بیایید چنین راه حل هایی را با جزئیات بیشتری در نظر بگیریم. 

شبکه سلنیوم در داکر

این ابزار در دنیای سلنیوم برای اجرای چندین مرورگر بر روی چندین ماشین و مدیریت آنها از یک هاب مرکزی محبوب ترین است. برای شروع، باید حداقل 2 قسمت را ثبت کنید: Hub و Node(های). هاب یک گره مرکزی است که تمام درخواست های آزمایش ها را دریافت کرده و آنها را در گره های مناسب توزیع می کند. برای هر Node می‌توانیم پیکربندی خاصی را پیکربندی کنیم، مثلاً با تعیین مرورگر مورد نظر و نسخه آن. با این حال، ما هنوز باید خودمان از درایورهای مرورگر سازگار مراقبت کنیم و آنها را روی Node های مورد نظر نصب کنیم. به همین دلیل، شبکه سلنیوم به شکل خالص خود استفاده نمی شود، مگر زمانی که نیاز به کار با مرورگرهایی داشته باشیم که روی سیستم عامل لینوکس نصب نمی شوند. برای همه موارد دیگر، یک راه حل قابل توجه انعطاف پذیر و صحیح استفاده از تصاویر Docker برای اجرای Selenium grid Hub و Nodes است. این رویکرد مدیریت گره را تا حد زیادی ساده می کند، زیرا می توانیم تصویر مورد نیاز خود را با نسخه های سازگار مرورگرها و درایورهای نصب شده از قبل انتخاب کنیم.

علیرغم بررسی‌های منفی در مورد پایداری، به‌ویژه هنگام اجرای تعداد زیادی Node به صورت موازی، شبکه سلنیوم همچنان محبوب‌ترین ابزار برای اجرای آزمایش‌های سلنیوم به صورت موازی است. توجه به این نکته حائز اهمیت است که بهبودها و اصلاحات مختلف این ابزار به طور مداوم در متن باز ظاهر می شود که با تنگناهای مختلف مبارزه می کند.

سلنوئید برای وب

این ابزار پیشرفتی در دنیای سلنیوم محسوب می شود، زیرا بدون نیاز به جعبه کار می کند و زندگی بسیاری از مهندسان اتوماسیون را بسیار آسان کرده است. اول از همه، این اصلاح دیگری از شبکه سلنیوم نیست. در عوض، توسعه دهندگان نسخه کاملاً جدیدی از Selenium Hub را در Golang ایجاد کردند که همراه با تصاویر سبک وزن Docker برای مرورگرهای مختلف، انگیزه ای برای توسعه اتوماسیون آزمایشی ایجاد کرد. ضمناً در مورد سلنیوم گرید باید تمام مرورگرهای مورد نیاز و نسخه های آنها را از قبل تعیین کنیم که در کار با یک مرورگر مشکلی ایجاد نمی شود. اما وقتی صحبت از چندین مرورگر پشتیبانی می شود، Selenoid به لطف ویژگی «مرورگر برحسب تقاضا» راه حل شماره یک است. تنها چیزی که از ما نیاز است این است که از قبل تصاویر لازم را با مرورگرها بارگیری کنیم و فایل پیکربندی را که سلنوئید با آن تعامل دارد به روز کنیم. پس از دریافت درخواست سلنوئید از تست ها، به طور خودکار ظرف مورد نظر را با مرورگر مورد نظر راه اندازی می کند. هنگامی که آزمایش کامل شد، سلنوئید ظرف را بازنشسته می‌کند و در نتیجه منابع را برای درخواست‌های آینده آزاد می‌کند. این رویکرد به طور کامل مشکل شناخته شده "تخریب گره" را که اغلب در شبکه سلنیوم با آن مواجه می شویم، حذف می کند.

اما، افسوس، سلنوئید هنوز یک گلوله نقره ای نیست. ما ویژگی «مرورگر درخواستی» را دریافت کردیم، اما ویژگی «منابع بر اساس تقاضا» هنوز در دسترس نیست. برای استفاده از سلنوئید، باید آن را روی سخت افزار فیزیکی یا روی ماشین مجازی مستقر کنیم، به این معنی که باید از قبل بدانیم چه تعداد منابع باید تخصیص داده شود. من حدس می‌زنم این مشکل برای پروژه‌های کوچکی که 10، 20 یا حتی 30 مرورگر را به صورت موازی اجرا می‌کنند، نیست. اما اگر به 100، 500، 1000 و بیشتر نیاز داشته باشیم، چه؟ نگهداری و پرداخت هزینه برای این همه منابع همیشه معنی ندارد. در بخش‌های 5 و 6 این مقاله، راه‌حل‌هایی را مورد بحث قرار می‌دهیم که به شما امکان مقیاس‌سازی را می‌دهد و در نتیجه هزینه‌های شرکت را به میزان قابل توجهی کاهش می‌دهد.

سلنوئید برای اندروید

پس از موفقیت Selenoid به عنوان یک ابزار اتوماسیون وب، مردم چیزی مشابه را برای اندروید می خواستند. و این اتفاق افتاد - Selenoid با پشتیبانی اندروید منتشر شد. از نقطه نظر کاربر سطح بالا، اصل عملکرد مشابه اتوماسیون وب است. تنها تفاوت این است که به جای کانتینرهای مرورگر، سلنوئید کانتینرهای شبیه ساز اندروید را اجرا می کند. به نظر من در حال حاضر این قدرتمندترین ابزار رایگان برای اجرای موازی تست های اندروید است.

من واقعاً دوست ندارم در مورد جنبه های منفی این ابزار صحبت کنم، زیرا واقعاً آن را دوست دارم. اما هنوز هم همان معایبی وجود دارد که برای اتوماسیون وب اعمال می شود و با مقیاس بندی همراه است. علاوه بر این، ما باید در مورد یک محدودیت دیگر صحبت کنیم که اگر برای اولین بار ابزار را راه اندازی کنیم، ممکن است تعجب آور باشد. برای اجرای تصاویر اندروید، به یک ماشین فیزیکی یا ماشین مجازی با پشتیبانی از مجازی سازی تودرتو نیاز داریم. در راهنمای چگونگی، من نشان می‌دهم که چگونه می‌توان این را در VM لینوکس فعال کرد. با این حال، اگر کاربر macOS هستید و می‌خواهید Selenoid را به صورت محلی اجرا کنید، این امکان برای اجرای تست‌های اندروید وجود نخواهد داشت. اما همیشه می‌توانید یک VM لینوکس را با پیکربندی «مجازی سازی تودرتو» به صورت محلی اجرا کنید و Selenoid را در داخل آن مستقر کنید.

تصویری از وضعیت فعلی زیرساخت ها

در زمینه این مقاله، 2 ابزار برای نشان دادن زیرساخت اضافه خواهیم کرد. اینها شبکه Selenium برای تست های وب و Selenoid برای تست های اندروید هستند. در آموزش GitHub، نحوه استفاده از Selenoid برای اجرای تست های وب را نیز به شما نشان خواهم داد. 

پیوندهایی برای کاوش

• داکر: ظرف چیست
• داکر: شروع کنید
• 5 جایگزین کانتینر برای Docker
• شبکه سلنیوم
• داکر سلنیوم
• سلنوئید
• سلنوئید Github
• راه اندازی KVM برای شبیه سازهای اندروید
• کتاب Docker Deep Dive

ابزارهای مشابه

• ابزارهای کانتینری‌سازی دیگری نیز وجود دارد، اما Docker محبوب‌ترین آنهاست. اگر می‌خواهید چیز دیگری را امتحان کنید، به خاطر داشته باشید که ابزارهایی که برای اجرای آزمایش‌های سلنیوم به صورت موازی پوشش داده‌ایم، به درستی کار نمی‌کنند.  
• همانطور که قبلاً گفته شد، اصلاحات زیادی در شبکه سلنیوم وجود دارد، به عنوان مثال، زالنیوم.

4.CI/CD

شرح مختصری از تکنولوژی

تمرین یکپارچه سازی مداوم در توسعه بسیار محبوب است و با سیستم های کنترل نسخه همتراز است. با وجود این، من احساس می کنم که در اصطلاح سردرگمی وجود دارد. در این پاراگراف من می خواهم 3 تغییر این فناوری را از دیدگاه خودم شرح دهم. در اینترنت مقالات زیادی با تفاسیر مختلف پیدا خواهید کرد و اگر نظر شما متفاوت باشد کاملا طبیعی است. مهم ترین چیز این است که شما با همکاران خود همسو هستید.

بنابراین، 3 عبارت وجود دارد: CI - Continuous Integration، CD - Continuous Delivery و دوباره CD - Continuous Deployment. (در زیر از این اصطلاحات در انگلیسی استفاده خواهم کرد). هر اصلاح چندین مرحله اضافی را به خط لوله توسعه شما اضافه می کند. اما کلمه مداوم (مستمر) مهمترین چیز است. در این زمینه، منظور ما چیزی است که از ابتدا تا انتها، بدون وقفه یا مداخله دستی اتفاق می افتد. بیایید به CI & CD و CD در این زمینه نگاه کنیم.

• یکپارچه سازی مداوم این مرحله اولیه تکامل است. پس از ارسال کد جدید به سرور، انتظار داریم بازخورد سریعی دریافت کنیم که تغییرات ما خوب است. به طور معمول، CI شامل اجرای ابزارهای تجزیه و تحلیل کد استاتیک و تست‌های API واحد/داخلی است. این به ما امکان می‌دهد در عرض چند ثانیه/دقیقه اطلاعاتی درباره کد خود به دست آوریم.
• تحویل مداوم مرحله پیشرفته‌تری است که در آن تست‌های یکپارچه‌سازی/UI را اجرا می‌کنیم. با این حال، در این مرحله به سرعت CI به نتیجه نمی رسیم. اولاً، این نوع آزمایشات تکمیل شدن زمان بیشتری می برد. ثانیاً، قبل از راه‌اندازی، باید تغییرات خود را در محیط تست/مرحله‌بندی مستقر کنیم. علاوه بر این، اگر ما در مورد توسعه تلفن همراه صحبت می کنیم، یک مرحله اضافی برای ایجاد یک بیلد از برنامه ما ظاهر می شود.
• استقرار مداوم فرض بر این است که اگر تمام تست های پذیرش در مراحل قبلی گذرانده شده باشد، به طور خودکار تغییرات خود را در تولید آزاد می کنیم. علاوه بر این، پس از مرحله انتشار، می توانید مراحل مختلفی مانند اجرای تست دود در تولید و جمع آوری معیارهای مورد علاقه را پیکربندی کنید. استقرار پیوسته تنها با پوشش خوب توسط تست های خودکار امکان پذیر است. اگر به مداخلات دستی از جمله آزمایش نیاز باشد، دیگر این کار وجود ندارد مداوم (مداوم). سپس می توانیم بگوییم که خط لوله ما فقط با روش تحویل مداوم مطابقت دارد.

ارزش برای زیرساخت اتوماسیون

در این بخش، باید توضیح دهم که وقتی در مورد تست‌های UI end-to-end صحبت می‌کنیم، به این معنی است که باید تغییرات و خدمات مرتبط خود را در محیط‌های آزمایشی مستقر کنیم. یکپارچه سازی مداوم - فرآیند برای این کار قابل اجرا نیست و ما باید مراقب اجرای حداقل شیوه های تحویل مداوم باشیم. اگر بخواهیم آنها را در مرحله تولید اجرا کنیم، Continuous Deployment در زمینه تست های UI نیز منطقی است.

و قبل از اینکه به تصویر تغییر معماری نگاه کنیم، می خواهم چند کلمه در مورد 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 نیاز دارید.

تصویری از وضعیت فعلی زیرساخت ها

پیوندهایی برای کاوش

• مارتین فاولر: ادغام مداوم
• GitLab CI/CD
• کتاب ادغام پیوسته
• کتاب تحویل مستمر

ابزارهای مشابه

• جنکینز
• TeamCity
• تراویس 
• و خیلی های دیگر

5. پلتفرم های ابری

شرح مختصری از تکنولوژی

در این بخش ما در مورد یک روند محبوب به نام "ابرهای عمومی" صحبت خواهیم کرد. علیرغم مزایای عظیمی که فناوری‌های مجازی‌سازی و کانتینری‌سازی شرح داده شده در بالا ارائه می‌کنند، ما همچنان به منابع محاسباتی نیاز داریم. شرکت‌ها سرورهای گران قیمت خریداری می‌کنند یا مراکز داده را اجاره می‌کنند، اما در این مورد باید محاسباتی انجام شود (گاهی غیرواقعی) که به چه تعداد منابع نیاز داریم، آیا از آنها 24/7 و برای چه اهدافی استفاده خواهیم کرد یا خیر. به عنوان مثال، تولید نیاز به سروری دارد که XNUMX/XNUMX کار می کند، اما آیا برای آزمایش خارج از ساعات کاری به منابع مشابهی نیاز داریم؟ همچنین به نوع آزمایشی که انجام می شود نیز بستگی دارد. به عنوان مثال، تست های بار/استرس است که قصد داریم در ساعات غیر کاری اجرا کنیم تا روز بعد به نتیجه برسیم. اما قطعاً در دسترس بودن سرور XNUMX/XNUMX برای تست‌های خودکار سرتاسر و به‌ویژه برای محیط‌های آزمایش دستی لازم نیست. برای چنین شرایطی، خوب است که منابع مورد نیاز را در صورت تقاضا به دست آورید، از آنها استفاده کنید و زمانی که دیگر نیازی به آنها ندارید، پرداخت را متوقف کنید. علاوه بر این، دریافت فوری آنها با چند کلیک ماوس یا اجرای چند اسکریپت عالی خواهد بود. این همان چیزی است که از ابرهای عمومی استفاده می شود. بیایید به تعریف نگاه کنیم:

«کلاد عمومی به عنوان خدمات محاسباتی ارائه شده توسط ارائه دهندگان شخص ثالث از طریق اینترنت عمومی تعریف می شود و آنها را برای هر کسی که می خواهد از آنها استفاده یا خریداری کند در دسترس قرار می دهد. آنها ممکن است رایگان باشند یا بر حسب تقاضا فروخته شوند و به مشتریان این امکان را می دهند که فقط به ازای استفاده از چرخه های CPU، فضای ذخیره سازی یا پهنای باندی که مصرف می کنند، پرداخت کنند."

عقیده ای وجود دارد که ابرهای عمومی گران هستند. اما ایده اصلی آنها کاهش هزینه های شرکت است. همانطور که قبلا ذکر شد، ابرهای عمومی به شما این امکان را می دهند که منابع را بر حسب تقاضا دریافت کنید و فقط برای زمانی که از آنها استفاده می کنید پرداخت کنید. همچنین، گاهی اوقات فراموش می کنیم که کارمندان حقوق دریافت می کنند و متخصصان نیز منبع گران قیمتی هستند. باید در نظر گرفت که ابرهای عمومی پشتیبانی از زیرساخت را بسیار آسان‌تر می‌کنند، که به مهندسان اجازه می‌دهد روی کارهای مهم‌تر تمرکز کنند. 

ارزش برای زیرساخت اتوماسیون

چه منابع خاصی برای تست های UI سرتاسر نیاز داریم؟ اساساً اینها ماشین‌های مجازی یا خوشه‌ها هستند (در بخش بعدی در مورد Kubernetes صحبت خواهیم کرد) برای اجرای مرورگرها و شبیه‌سازها. هر چه بخواهیم مرورگرها و شبیه سازهای بیشتری را به طور همزمان اجرا کنیم، CPU و حافظه بیشتری مورد نیاز است و پول بیشتری باید برای آن بپردازیم. بنابراین، ابرهای عمومی در زمینه اتوماسیون تست به ما این امکان را می‌دهند که تعداد زیادی (100، 200، 1000...) مرورگر/مشابه‌دهنده را بر حسب تقاضا اجرا کنیم، نتایج آزمایش را در سریع‌ترین زمان ممکن دریافت کنیم و از پرداخت هزینه برای چنین منابع غیرمجاز خودداری کنیم. قدرت. 

محبوب ترین ارائه دهندگان ابر عبارتند از خدمات وب آمازون (AWS)، مایکروسافت آژور، پلتفرم ابری گوگل (GCP). راهنمای چگونه نمونه هایی از نحوه استفاده از GCP را ارائه می دهد، اما به طور کلی مهم نیست که از چه چیزی برای کارهای اتوماسیون استفاده می کنید. همه آنها تقریباً عملکرد یکسانی را ارائه می دهند. به طور معمول، برای انتخاب یک ارائه‌دهنده، مدیریت بر زیرساخت‌های کلی شرکت و الزامات تجاری تمرکز می‌کند که خارج از محدوده این مقاله است. برای مهندسان اتوماسیون، مقایسه استفاده از ارائه دهندگان ابری با استفاده از پلتفرم های ابری به طور خاص برای اهداف آزمایشی، مانند Sauce Labs، BrowserStack، BitBar و غیره جالب تر خواهد بود. پس بیایید آن را هم انجام دهیم! به نظر من، Sauce Labs معروف ترین مزرعه تست ابری است، به همین دلیل از آن برای مقایسه استفاده کردم. 

GCP vs Sauce Labs برای اهداف اتوماسیون:

بیایید تصور کنیم که باید 8 تست وب و 8 تست اندروید را به طور همزمان اجرا کنیم. برای این کار از GCP استفاده می کنیم و 2 ماشین مجازی را با Selenoid اجرا می کنیم. در مورد اول ما 8 کانتینر را با مرورگرها افزایش می دهیم. در دوم 8 کانتینر با شبیه ساز وجود دارد. بیایید نگاهی به قیمت ها بیندازیم:  

برای اجرای یک کانتینر با کروم، نیاز داریم n1-استاندارد-1 ماشین. در مورد اندروید اینطور خواهد بود n1-استاندارد-4 برای یک شبیه ساز در واقع، یک راه انعطاف‌پذیرتر و ارزان‌تر، تنظیم مقادیر خاص کاربر برای CPU/Memory است، اما در حال حاضر این برای مقایسه با Sauce Labs مهم نیست.

و در اینجا تعرفه های استفاده از Sauce Labs آمده است:

من معتقدم که شما قبلاً متوجه تفاوت شده اید، اما من همچنان یک جدول با محاسبات برای وظیفه ما ارائه خواهم کرد:

منابع مورد نیاز
ماهانه
ساعات کاری(8 صبح تا 8 شب)
ساعات کاری+ پیشگیرانه

GCP برای وب
n1-استاندارد-1 x 8 = n1-استاندارد-8
$194.18
23 روز * 12 ساعت * 0.38 = 104.88 دلار 
23 روز * 12 ساعت * 0.08 = 22.08 دلار

Sauce Labs for Web
تست های موازی Cloud8 مجازی
$1.559
-
-

GCP برای اندروید
n1-standard-4 x 8: n1-standard-16
$776.72
23 روز * 12 ساعت * 1.52 = 419.52 دلار 
23 روز * 12 ساعت * 0.32 = 88.32 دلار

Sauce Labs برای اندروید
تست های موازی Real Device Cloud 8
$1.999
-
-

همانطور که می بینید، تفاوت در هزینه بسیار زیاد است، به خصوص اگر آزمایشات را فقط در یک دوره کاری دوازده ساعته انجام دهید. اما در صورت استفاده از ماشین‌های پیش‌گیرانه، می‌توانید هزینه‌ها را حتی بیشتر کاهش دهید. چیست؟

یک VM preemptible نمونه‌ای است که می‌توانید آن را با قیمتی بسیار کمتر از نمونه‌های معمولی ایجاد و اجرا کنید. با این حال، Compute Engine ممکن است این نمونه‌ها را خاتمه دهد (پیش‌گیری) اگر برای کارهای دیگر نیاز به دسترسی به آن منابع داشته باشد. نمونه‌های قابل پیش‌گیری ظرفیت مازاد Compute Engine هستند، بنابراین در دسترس بودن آنها با استفاده متفاوت است.

اگر برنامه‌های شما در برابر خطا مقاوم هستند و می‌توانند پیش‌پرداخت‌های احتمالی را تحمل کنند، نمونه‌های قابل پیش‌گیری می‌توانند هزینه‌های Compute Engine شما را به میزان قابل توجهی کاهش دهند. به عنوان مثال، کارهای پردازش دسته‌ای می‌توانند در نمونه‌های پیش‌گیرانه اجرا شوند. اگر برخی از این موارد در طول پردازش خاتمه یابد، کار کند می شود اما به طور کامل متوقف نمی شود. نمونه‌های پیش‌گیرانه، وظایف پردازش دسته‌ای شما را بدون اعمال بار کاری اضافی بر روی نمونه‌های موجود و بدون نیاز به پرداخت هزینه کامل برای نمونه‌های عادی تکمیل می‌کنند.

و هنوز تمام نشده است! در واقعیت، من مطمئن هستم که هیچ کس تست ها را به مدت 12 ساعت بدون استراحت انجام نمی دهد. و اگر چنین است، می‌توانید به‌طور خودکار ماشین‌های مجازی را در مواقعی که به آن‌ها نیاز ندارید، راه‌اندازی و متوقف کنید. زمان استفاده واقعی ممکن است به 6 ساعت در روز کاهش یابد. سپس پرداخت در چارچوب وظیفه ما به 11 دلار در ماه برای 8 مرورگر کاهش می یابد. آیا این فوق العاده نیست؟ اما با ماشین‌های پیش‌گیرانه باید مراقب وقفه‌ها و بی‌ثباتی باشیم، هرچند که این موقعیت‌ها را می‌توان در نرم‌افزار فراهم کرد و مدیریت کرد. ارزشش را دارد!

اما به هیچ وجه نمی گویم "هرگز از مزارع آزمایش ابری استفاده نکنید". آنها یک سری مزایای دارند. اول از همه، این فقط یک ماشین مجازی نیست، بلکه یک راه حل اتوماسیون آزمایشی تمام عیار با مجموعه ای از عملکردهای خارج از جعبه است: دسترسی از راه دور، گزارش ها، تصاویر صفحه، ضبط ویدئو، مرورگرهای مختلف و دستگاه های فیزیکی تلفن همراه. در بسیاری از موقعیت ها، این می تواند یک جایگزین شیک ضروری باشد. پلتفرم‌های تست مخصوصاً برای اتوماسیون IOS مفید هستند، زمانی که ابرهای عمومی فقط می‌توانند سیستم‌های لینوکس/ویندوز را ارائه دهند. اما در مقالات بعدی در مورد iOS صحبت خواهیم کرد. توصیه می‌کنم همیشه به وضعیت نگاه کنید و از وظایف شروع کنید: در برخی موارد استفاده از ابرهای عمومی ارزان‌تر و کارآمدتر است و در برخی دیگر قطعاً پلتفرم‌های تست ارزش هزینه‌ای را دارند.

تصویری از وضعیت فعلی زیرساخت ها

پیوندهایی برای کاوش

• GCP
• GCP: Preemptable
• GCP: قیمت گذاری VM
• SauceLabs
• مقایسه ارائه دهندگان ابر

ابزارهای مشابه:

• AWS 
• لاجوردی

6. ارکستراسیون

شرح مختصری از تکنولوژی

من یک خبر خوب دارم - ما تقریباً در پایان مقاله هستیم! در حال حاضر، زیرساخت اتوماسیون ما شامل تست‌های وب و اندروید است که از طریق GitLab CI به صورت موازی و با استفاده از ابزارهای فعال Docker: Selenium grid و Selenoid اجرا می‌کنیم. علاوه بر این، ما از ماشین های مجازی ایجاد شده از طریق GCP برای میزبانی کانتینرهایی با مرورگرها و شبیه سازها استفاده می کنیم. برای کاهش هزینه‌ها، ما این ماشین‌های مجازی را فقط در صورت تقاضا راه‌اندازی می‌کنیم و زمانی که آزمایش انجام نمی‌شود آن‌ها را متوقف می‌کنیم. آیا چیز دیگری وجود دارد که بتواند زیرساخت های ما را بهبود بخشد؟ پاسخ بله است! با Kubernetes (K8s) آشنا شوید!

ابتدا، بیایید ببینیم که چگونه کلمات ارکستراسیون، خوشه، و Kubernetes با یکدیگر مرتبط هستند. در سطح بالا، ارکستراسیون سیستمی است که برنامه ها را مستقر و مدیریت می کند. برای اتوماسیون آزمایشی، چنین کاربردهای کانتینری مانند شبکه سلنیوم و سلنوئید هستند. داکر و K8 مکمل یکدیگر هستند. اولی برای استقرار برنامه و دومی برای ارکستراسیون استفاده می شود. به نوبه خود، K8s یک خوشه است. وظیفه کلاستر استفاده از VMها به عنوان Nodes است که به شما امکان می دهد عملکردها، برنامه ها و خدمات مختلفی را در یک سرور (خوشه) نصب کنید. اگر هر یک از گره ها از کار بیفتند، گره های دیگر را انتخاب می کنند، که عملکرد بدون وقفه برنامه ما را تضمین می کند. علاوه بر این، K8s دارای عملکردهای مهم مربوط به مقیاس بندی است، که به لطف آن، ما به طور خودکار مقدار بهینه منابع را بر اساس بار و تعیین محدودیت ها به دست می آوریم.

در حقیقت، استقرار دستی Kubernetes از ابتدا یک کار بی اهمیت نیست. من یک لینک به راهنمای معروف "Kubernetes The Hard Way" می گذارم و اگر علاقه مند هستید، می توانید آن را تمرین کنید. اما خوشبختانه روش ها و ابزارهای جایگزینی وجود دارد. ساده ترین راه استفاده از Google Kubernetes Engine (GKE) در GCP است که به شما امکان می دهد با چند کلیک یک خوشه آماده دریافت کنید. من توصیه می کنم از این رویکرد برای شروع یادگیری استفاده کنید، زیرا به شما این امکان را می دهد که به جای یادگیری نحوه ادغام اجزای داخلی با یکدیگر، روی یادگیری نحوه استفاده از K8s برای وظایف خود تمرکز کنید. 

ارزش برای زیرساخت اتوماسیون

بیایید به چند ویژگی مهم که K8s ارائه می دهد نگاهی بیندازیم:

• استقرار برنامه: استفاده از یک خوشه چند گره به جای VMs.
• مقیاس بندی پویا: هزینه منابعی که فقط در صورت تقاضا استفاده می شوند را کاهش می دهد.
• خود درمانی: بازیابی خودکار غلاف ها (در نتیجه ظروف نیز بازسازی می شوند).
• عرضه به‌روزرسانی‌ها و بازگرداندن تغییرات بدون توقف: به‌روزرسانی ابزارها، مرورگرها و شبیه‌سازها کار کاربران فعلی را قطع نمی‌کند.

اما K8s هنوز یک گلوله نقره ای نیست. برای درک تمام مزایا و محدودیت ها در زمینه ابزارهایی که در نظر گرفته ایم (شبکه سلنیوم، سلنوئید)، به طور خلاصه به ساختار K8 ها می پردازیم. Cluster شامل دو نوع Node است: Master Nodes و Workers Node. گره های اصلی مسئول تصمیم گیری های مدیریت، استقرار و زمان بندی هستند. گره های کارگر جایی هستند که برنامه ها راه اندازی می شوند. گره ها همچنین حاوی یک محیط زمان اجرا کانتینر هستند. در مورد ما، این Docker است که مسئول عملیات مربوط به کانتینر است. اما برای مثال راه حل های جایگزینی نیز وجود دارد ظرف. درک این نکته مهم است که جرم گیری یا خود ترمیمی مستقیماً روی ظروف اعمال نمی شود. این کار با افزودن/کاهش تعداد غلاف ها اجرا می شود که به نوبه خود حاوی ظروف هستند (معمولاً یک ظرف در هر غلاف، اما بسته به وظیفه ممکن است تعداد بیشتری وجود داشته باشد). سلسله مراتب سطح بالا از گره های کارگری تشکیل شده است که در داخل آنها غلاف هایی وجود دارد که در داخل آنها کانتینرها بلند شده اند.

ویژگی مقیاس‌بندی کلیدی است و می‌تواند برای هر دو گره در یک مجموعه گره و غلاف درون یک گره اعمال شود. 2 نوع پوسته پوسته شدن وجود دارد که برای هر دو گره و غلاف اعمال می شود. نوع اول افقی است - پوسته پوسته شدن با افزایش تعداد گره ها/غلاف ها اتفاق می افتد. این نوع ارجح تر است. نوع دوم، بر این اساس، عمودی است. مقیاس بندی با افزایش اندازه گره ها/غلاف ها و نه تعداد آنها انجام می شود.

حالا بیایید ابزارهای خود را در چارچوب اصطلاحات بالا بررسی کنیم.

شبکه سلنیوم

همانطور که قبلا ذکر شد، شبکه سلنیوم یک ابزار بسیار محبوب است، و جای تعجب نیست که آن را در کانتینر قرار دهید. بنابراین، تعجبی ندارد که شبکه سلنیوم می تواند در K8 ها مستقر شود. نمونه ای از نحوه انجام این کار را می توان در مخزن رسمی K8s یافت. طبق معمول، لینک‌هایی را در انتهای بخش پیوست می‌کنم. علاوه بر این، راهنمای نحوه انجام این کار در Terraform را نشان می دهد. همچنین دستورالعمل هایی در مورد نحوه مقیاس بندی تعداد پادهایی که حاوی ظروف مرورگر هستند وجود دارد. اما عملکرد مقیاس خودکار در زمینه K8s هنوز یک کار کاملاً واضح نیست. وقتی شروع به مطالعه کردم، هیچ راهنمایی و توصیه عملی پیدا نکردم. پس از چندین مطالعه و آزمایش با پشتیبانی تیم DevOps، رویکرد بالا بردن کانتینرها با مرورگرهای لازم در داخل یک پاد را انتخاب کردیم که در داخل یک گره کارگر قرار دارد. این روش به ما اجازه می دهد تا با افزایش تعداد گره ها، استراتژی مقیاس افقی گره ها را اعمال کنیم. امیدوارم در آینده این موضوع تغییر کند و به خصوص پس از عرضه سلنیوم گرید 4 با معماری داخلی تغییر یافته، شاهد توضیحات بیشتر و بیشتری از رویکردهای بهتر و راه حل های آماده باشیم.

سلنوئید:

استقرار سلنوئید در K8s در حال حاضر بزرگترین ناامیدی است. با هم سازگار نیستند. در تئوری، می‌توانیم یک ظرف سلنوئید را در داخل یک پاد بالا بیاوریم، اما وقتی سلنوئید شروع به راه‌اندازی کانتینرها با مرورگرها می‌کند، آنها همچنان در همان پاد خواهند بود. این امر مقیاس‌گذاری را غیرممکن می‌کند و در نتیجه، کار سلنوئید در داخل یک خوشه با کار در یک ماشین مجازی تفاوتی نخواهد داشت. پایان داستان.

ماه:

با دانستن این تنگنا هنگام کار با Selenoid، توسعه دهندگان ابزار قدرتمندتری به نام Moon را منتشر کردند. این ابزار در ابتدا برای کار با Kubernetes طراحی شده بود و در نتیجه می توان و باید از ویژگی autoscaling استفاده کرد. علاوه بر این، من می گویم که در حال حاضر است تک تک ابزاری در دنیای سلنیوم که دارای پشتیبانی خوشه‌ای بومی K8 است (دیگر در دسترس نیست، ابزار بعدی را ببینید ). ویژگی های کلیدی Moon که این پشتیبانی را ارائه می دهد عبارتند از: 

کاملا بی تابعیت سلنوئید اطلاعات مربوط به جلسات مرورگر در حال اجرا را در حافظه ذخیره می کند. اگر به دلایلی فرآیند آن از کار بیفتد - تمام جلسات در حال اجرا از بین می روند. ماه برعکس حالت داخلی ندارد و می تواند در مراکز داده تکثیر شود. جلسات مرورگر زنده می مانند حتی اگر یک یا چند نسخه از بین بروند.

بنابراین، ماه یک راه حل عالی است، اما یک مشکل وجود دارد: رایگان نیست. قیمت بستگی به تعداد جلسات دارد. شما فقط می توانید 0-4 جلسه را به صورت رایگان اجرا کنید، که به خصوص مفید نیست. اما، از جلسه پنجم، شما باید 5 دلار برای هر جلسه بپردازید. ممکن است شرایط از شرکتی به شرکت دیگر متفاوت باشد، اما در مورد ما استفاده از Moon بی معنی است. همانطور که در بالا توضیح دادم، می‌توانیم ماشین‌های مجازی را با سلنیوم گرید در صورت تقاضا اجرا کنیم یا تعداد گره‌ها را در خوشه افزایش دهیم. برای تقریباً یک خط لوله، ما 500 مرورگر را راه‌اندازی می‌کنیم و پس از اتمام آزمایش‌ها، همه منابع را متوقف می‌کنیم. اگر از Moon استفاده می‌کردیم، بدون توجه به اینکه چند بار آزمایش‌ها را انجام می‌دهیم، باید ماهیانه 500×5 = 2500 دلار اضافی بپردازیم. باز هم نمی گویم از Moon استفاده نکنید. برای وظایف شما، این می تواند یک راه حل ضروری باشد، به عنوان مثال، اگر پروژه ها/تیم های زیادی در سازمان خود دارید و به یک خوشه مشترک بزرگ برای همه نیاز دارید. مثل همیشه، من یک لینک در پایان می گذارم و توصیه می کنم تمام محاسبات لازم را در زمینه وظیفه خود انجام دهید.

کالیستو: (توجه! این در مقاله اصلی نیست و فقط در ترجمه روسی موجود است)

همانطور که گفتم، سلنیوم یک ابزار بسیار محبوب است و زمینه فناوری اطلاعات به سرعت در حال توسعه است. در حالی که من روی ترجمه کار می کردم، ابزار امیدوار کننده جدیدی به نام Callisto در وب ظاهر شد (سلام سرو و دیگر قاتلان سلنیوم). این به صورت بومی با K8 کار می کند و به شما امکان می دهد ظروف سلنوئید را در غلاف ها اجرا کنید که در سراسر Node ها توزیع شده اند. همه چیز درست خارج از جعبه کار می کند، از جمله مقیاس خودکار. فوق العاده است، اما نیاز به آزمایش دارد. من قبلاً موفق به استقرار این ابزار و اجرای چندین آزمایش شده ام. اما برای نتیجه‌گیری خیلی زود است، پس از دریافت نتایج در مسافت طولانی، شاید در مقالات بعدی بررسی کنم. در حال حاضر من فقط پیوندهایی را برای تحقیقات مستقل می گذارم.  

تصویری از وضعیت فعلی زیرساخت ها

پیوندهایی برای کاوش

• Kubernetes: راه اندازی
• Kubernetes: راه سخت
• Kubernetes: سلنیوم
• GCP: موتور Kubernetes
• ماه
• کتاب کوبرنتس
• اتوماسیون توزیع شده با استفاده از Kubernetes
• شبکه سلنیوم 4
• Callisto GitHub
• Wrike TechClub (کالیستو)

ابزارهای مشابه

• ازدحام داکر 
• مسابقه دو ماراتون 

7. زیرساخت به عنوان کد (IaC)

شرح مختصری از تکنولوژی

و اکنون به بخش آخر می رسیم. به طور معمول، این فناوری و وظایف مربوط به آن بر عهده مهندسان اتوماسیون نیست. و دلایلی برای این وجود دارد. اولاً، در بسیاری از سازمان‌ها، مسائل زیرساختی تحت کنترل بخش DevOps است و تیم‌های توسعه واقعاً به اینکه چه چیزی باعث می‌شود خط لوله کار کند و هر چیزی که با آن مرتبط است چگونه باید پشتیبانی شود، اهمیتی نمی‌دهند. ثانیا، بیایید صادق باشیم، عمل زیرساخت به عنوان کد (IaC) هنوز در بسیاری از شرکت ها پذیرفته نشده است. اما قطعاً به یک روند محبوب تبدیل شده است و تلاش برای مشارکت در فرآیندها، رویکردها و ابزارهای مرتبط با آن مهم است. یا حداقل به روز باشید.

بیایید با انگیزه استفاده از این رویکرد شروع کنیم. ما قبلاً بحث کرده ایم که برای اجرای تست ها در GitlabCI حداقل به منابعی برای اجرای Gitlab Runner نیاز داریم. و برای اجرای کانتینرها با مرورگرها/شبیه سازها، باید یک VM یا کلاستر رزرو کنیم. علاوه بر آزمایش منابع، ما به ظرفیت قابل توجهی برای پشتیبانی از توسعه، مرحله بندی، محیط های تولید نیاز داریم که شامل پایگاه های داده، زمان بندی خودکار، تنظیمات شبکه، متعادل کننده بار، حقوق کاربر و غیره می شود. مسئله کلیدی تلاش مورد نیاز برای حمایت از همه آن است. راه های مختلفی وجود دارد که می توانیم تغییرات ایجاد کنیم و به روز رسانی کنیم. به عنوان مثال، در زمینه GCP، می‌توانیم از کنسول UI در مرورگر استفاده کنیم و با کلیک روی دکمه‌ها، تمام اقدامات را انجام دهیم. یک جایگزین می تواند استفاده از فراخوانی های API برای تعامل با موجودیت های ابری یا استفاده از ابزار خط فرمان gcloud برای انجام دستکاری های مورد نظر باشد. اما با وجود تعداد بسیار زیاد موجودیت ها و عناصر زیرساختی مختلف، انجام تمام عملیات به صورت دستی دشوار یا حتی غیرممکن می شود. علاوه بر این، تمام این اقدامات دستی غیرقابل کنترل هستند. ما نمی‌توانیم آن‌ها را قبل از اجرا برای بررسی ارسال کنیم، از یک سیستم کنترل نسخه استفاده کنیم و به سرعت تغییراتی را که منجر به این حادثه شده است، برگردانیم. برای حل چنین مشکلاتی، مهندسان اسکریپت‌های bash/shell خودکار را ایجاد و ایجاد کردند، که خیلی بهتر از روش‌های قبلی نیستند، زیرا خواندن، درک، نگهداری و اصلاح آن‌ها در سبک رویه‌ای چندان آسان نیست.

در این مقاله و راهنما از 2 ابزار مربوط به تمرین IaC استفاده می کنم. اینها Terraform و Ansible هستند. برخی افراد معتقدند که استفاده همزمان از آنها بی معنی است، زیرا عملکرد آنها مشابه است و قابل تعویض هستند. اما واقعیت این است که در ابتدا وظایف کاملاً متفاوتی به آنها داده می شود. و این واقعیت که این ابزارها باید مکمل یکدیگر باشند در یک ارائه مشترک توسط توسعه دهندگان نماینده HashiCorp و RedHat تایید شد. تفاوت مفهومی این است که Terraform ابزاری برای مدیریت خود سرورها است. در حالی که Ansible یک ابزار مدیریت پیکربندی است که وظیفه آن نصب، پیکربندی و مدیریت نرم افزار بر روی این سرورها است.

یکی دیگر از ویژگی های متمایز کننده کلیدی این ابزارها، سبک کدنویسی است. برخلاف bash و Ansible، Terraform از یک سبک اعلامی مبتنی بر توصیف وضعیت نهایی مورد نظر استفاده می‌کند تا در نتیجه اجرا به دست آید. به عنوان مثال، اگر قرار باشد 10 VM ایجاد کنیم و تغییرات را از طریق Terraform اعمال کنیم، آنگاه 10 VM خواهیم داشت. اگر اسکریپت را دوباره اجرا کنیم، هیچ اتفاقی نمی افتد زیرا ما از قبل 10 ماشین مجازی داریم و Terraform از این موضوع مطلع است زیرا وضعیت فعلی زیرساخت را در یک فایل وضعیت ذخیره می کند. اما Ansible از یک رویکرد رویه‌ای استفاده می‌کند و اگر از آن بخواهید 10 VM بسازد، در اولین راه‌اندازی 10 VM مشابه Terraform دریافت خواهیم کرد. اما پس از راه اندازی مجدد، ما در حال حاضر 20 ماشین مجازی خواهیم داشت. این تفاوت مهم است. در سبک رویه‌ای، ما وضعیت فعلی را ذخیره نمی‌کنیم و صرفاً دنباله‌ای از مراحل را که باید انجام شوند، توصیف می‌کنیم. البته می‌توانیم موقعیت‌های مختلفی را مدیریت کنیم، چندین بررسی برای وجود منابع و وضعیت فعلی اضافه کنیم، اما اتلاف وقت و تلاش برای کنترل این منطق فایده‌ای ندارد. علاوه بر این، خطر اشتباه را افزایش می دهد. 

با جمع بندی تمام موارد فوق، می توان نتیجه گرفت که Terraform و علامت گذاری اعلامی ابزار مناسب تری برای تامین سرورها هستند. اما بهتر است کار مدیریت پیکربندی را به Ansible محول کنید. با وجود این موضوع، بیایید به موارد استفاده در زمینه اتوماسیون نگاه کنیم.

ارزش برای زیرساخت اتوماسیون

تنها چیزی که در اینجا باید فهمید این است که زیرساخت اتوماسیون تست باید به عنوان بخشی از زیرساخت کل شرکت در نظر گرفته شود. این بدان معنی است که تمام اقدامات IaC باید به صورت جهانی برای منابع کل سازمان اعمال شود. چه کسی مسئول این امر است بستگی به فرآیندهای شما دارد. تیم DevOps در این مسائل باتجربه تر است، آنها تصویر کاملی از اتفاقات را می بینند. با این حال، مهندسان QA بیشتر درگیر فرآیند اتوماسیون ساختمان و ساختار خط لوله هستند، که به آنها اجازه می دهد تا همه تغییرات مورد نیاز و فرصت های بهبود را بهتر ببینند. بهترین گزینه همکاری، تبادل دانش و ایده برای رسیدن به نتیجه مورد انتظار است. 

در اینجا چند نمونه از استفاده از Terraform و Ansible در زمینه اتوماسیون تست و ابزارهایی که قبلاً در مورد آنها صحبت کردیم آورده شده است:

1. مشخصات و پارامترهای لازم ماشین های مجازی و خوشه ها را با استفاده از Terraform شرح دهید.

2. با استفاده از Ansible، ابزارهای لازم برای آزمایش را نصب کنید: docker، Selenoid، Selenium Grid و نسخه های مورد نیاز مرورگرها/مشابه ها را دانلود کنید.

3. با استفاده از Terraform، ویژگی های VM را که GitLab Runner در آن راه اندازی می شود، توضیح دهید.

4. GitLab Runner و ابزارهای همراه لازم را با استفاده از Ansible نصب کنید، تنظیمات و تنظیمات را تنظیم کنید.

تصویری از وضعیت فعلی زیرساخت ها

پیوندهایی برای کاوش:

• Terraform
• غیر ممکن
• Ansible و Terraform با هم بهتر است
• راهنمای جامع Terraform
• چرا ما از Terraform استفاده می کنیم نه Chef، Puppet، Ansible، SaltStack یا CloudFormation
• GCP: IaC

ابزارهای مشابه

• سر اشپز
• عروسک خیمه شب بازی
• SaltStack
• آشکار

بیایید آن را خلاصه کنیم!

گام
پیشرفته
ابزار
ارزش برای زیرساخت اتوماسیون

1
دویدن محلی
Node.js، Selenium، Appium

• محبوب ترین ابزار برای وب و موبایل
• پشتیبانی از بسیاری از زبان ها و پلتفرم ها (از جمله Node.js)

2
سیستم های کنترل نسخه 
رفتن

• مزایای مشابه با کد توسعه

3
کانتینری سازی
داکر، شبکه سلنیوم، سلنوئید (وب، اندروید)

• اجرای آزمون ها به صورت موازی
• محیط های ایزوله
• به روز رسانی های ساده و انعطاف پذیر نسخه
• توقف دینامیک منابع استفاده نشده
• راه اندازی آسان

4
CI/CD
Gitlab CI

• بخشی از خط لوله را آزمایش می کند
• بازخورد سریع
• دید برای کل شرکت/تیم

5
سیستم عامل های ابر
Google Cloud Platform

• منابع درخواستی (ما فقط در صورت نیاز پرداخت می کنیم)
• آسان برای مدیریت و به روز رسانی
• دید و کنترل تمام منابع

6
تنظیم و ارکستراسیون
کوبرنیتس
در زمینه کانتینرهایی با مرورگرها/شبیه سازهای داخل پاد:

• پوسته پوسته شدن / پوسته پوسته شدن خودکار
• خود درمانی
• به روز رسانی و بازگشت بدون وقفه

7
زیرساخت به عنوان یک کد (IaC)
Terraform، Ansible

• مزایای مشابه با زیرساخت های توسعه
• تمام مزایای نسخه سازی کد
• ایجاد تغییرات و نگهداری آسان
• کاملا خودکار

نمودارهای نقشه ذهنی: تکامل زیرساخت ها

مرحله 1: محلی

مرحله 2: VCS

مرحله 3: کانتینرسازی 

مرحله 4: CI/CD 

مرحله 5: پلتفرم های ابری

مرحله 6: ارکستراسیون

مرحله 7: IaC

گام بعدی چیست؟

بنابراین، این پایان مقاله است. اما در خاتمه، من می خواهم چند توافق با شما ایجاد کنم.

از طرف تو
همانطور که در ابتدا گفته شد، مایلم این مقاله کاربردی باشد و به شما کمک کند دانش به دست آمده را در کار واقعی به کار ببرید. دوباره اضافه می کنم پیوند به راهنمای عملی.

اما حتی پس از آن، متوقف نشوید، تمرین کنید، پیوندها و کتاب‌های مرتبط را مطالعه کنید، دریابید که چگونه در شرکت شما کار می‌کند، مکان‌هایی را پیدا کنید که می‌توانند بهبود یابند و در آن شرکت کنید. موفق باشید!

از نظر من

از عنوان می بینید که این فقط قسمت اول بود. علیرغم اینکه معلوم شد بسیار بزرگ است، موضوعات مهم هنوز در اینجا پوشش داده نشده است. در بخش دوم، قصد دارم زیرساخت های اتوماسیون را در چارچوب IOS بررسی کنم. با توجه به محدودیت‌های اپل برای اجرای شبیه‌سازهای iOS فقط در سیستم‌های macOS، دامنه راه‌حل‌های ما محدود شده است. به عنوان مثال، ما نمی توانیم از Docker برای اجرای شبیه ساز یا ابرهای عمومی برای اجرای ماشین های مجازی استفاده کنیم. اما این بدان معنا نیست که هیچ جایگزین دیگری وجود ندارد. من سعی خواهم کرد با راه حل های پیشرفته و ابزارهای مدرن شما را به روز نگه دارم!

همچنین، من به موضوعات کاملاً بزرگ مرتبط با نظارت اشاره نکرده ام. در قسمت 3، من قصد دارم به محبوب ترین ابزارهای نظارت بر زیرساخت و اینکه چه داده ها و معیارهایی را باید در نظر بگیرم، بررسی کنم.

و در نهایت. در آینده، من قصد دارم یک دوره ویدیویی در مورد زیرساخت های آزمایشی ساختمان و ابزارهای محبوب منتشر کنم. در حال حاضر، تعداد زیادی دوره و سخنرانی در مورد DevOps در اینترنت وجود دارد، اما همه مطالب در زمینه توسعه ارائه شده اند، نه اتوماسیون تست. در مورد این موضوع، من واقعاً به بازخورد نیاز دارم که آیا چنین دوره ای برای جامعه آزمایش کنندگان و مهندسان اتوماسیون جالب و ارزشمند خواهد بود یا خیر. پیشاپیش از شما متشکرم!

منبع: www.habr.com