توی این پست یه مقدار در مورد تست نوشتن و اهمیت اون توضیح میدم و بعدش انواع تست رو بهتون معرفی میکنم و برای آغاز مطلب CI/CD در ادامه‌ی مسیر دواپس‌مون، میریم سراغ معرفی اولیه مفاهیم CI/CD و نهایتا دو تا از ابزارهای مهم‌ش رو با هم مقایسه میکنم.
خب یه مروری کنیم پست‌های قبلی رو:
توصیه میکنم که حتما این پست‌ها رو هم مطالعه کنید. بریم که ادامه بدیم.
تست نرم‌افزار و ضرورت اون:
تست مهمه چون احتمالش هست که باگ یا ارور توی کد باشه که با تست بتونیم اونو متوجه بشیم قبل از اینکه مشتری مون توی پروداکشن متوجه اش بشه و بهمون بگه. معمولا نرم افزار هایی که تست شدن بیشتر قابل اتکا هستن، امن تر هستن، کارایی بیشتری دارن و رضایت مشتری بالاتری رو دارن.
تست ها رو به دو نوع Functional که توی اونها معمولا صحت کارکرد یک یا چند سرویس رو به لحاظ لاجیکی بررسی میکنیم و Non-Functional که توی اونها سرویس‌ها رو به لحاظ عملکردی در شرایط مختلف تست میکنیم، تقسیم میشن.
چرا تست اتومیشن داشته باشیم؟
چون میتونیم تست اتومیت رو توی CI/CD به راحتی انجام بدیم که بهمون توی ذخیره زمان و هزینه کمک میکنه و دیباگ‌مون رو سریعتر میکنه. بهمون امکان استفاده مجدد از تست رو میده و دقتمون رو بالاتر میبره و سریعتر بازخورد نسبت به کدمون رو میتونیم از چرخه CI/CD بگیریم.
انواع تست:
تو یونیت تست یک ماژول از اپلیکیشن یا یک میکروسرویس رو به تنهایی تست میکنیم تا مطمئن بشیم به شکلی که انتظار داریم کار میکنه.
بعد اینکه توی یونیت تست فهمیدیم هر سرویس به تنهایی داره درست کار میکنه حالا توی اینتگریشن تست، سعی میکنیم بررسی کنیم که آیا سرویس‌ها در ارتباط با همدیگه هم به درستی کار میکنند.
توی این تست فانکشنالیتی یه تابع رو به همراه دیپندنسی‌های مورد نیازش که باهاشون ارتباط داره، توی سیستم آزمایش میکنیم. مثلا اینکه آیا فرآیند درگاه پرداخت بدرستی کار میکنه توی یک سایت فروشگاه اینترنتی، میشه تست فانکشنال.
این نوع تست برای این هست که ببینیم آیا سیستم نرم‌افزاری ما نیازمندی و انتظارات کاربران یا سهامداران را برآورده میکند یا نه. معمولا این تست توسط کاربران نهایی یا گروهی تعیین شده انجام می‌شود. دقت کنید که این کاربر نهایی یه گروه مشخص قبل تعیین شده هست معمولا که صرفا شبیه سازی میکنه رفتار کاربر در محیط واقعی رو.
فرض کنید داریم دودکش یه خونه ای رو درست میکنیم برای اینکه ببینیم درست کار میکنه یه سیگار زیرش می‌کشیم ببینیم دود میره بالا یا نه 🙂 البته شما مراقب سلامتیتون باشید و سیگار نکشید.
یا مثلا قبل وصل کردن لوله بخاری یه کاغذ آتیش میزنیم می‌گیریم جلو دودکش ببینیم خاموش میشه یا شعله رو میکشه بالا.
حالا از فلسفه اسمش که بگذریم 🙂 اسموک تست، نوعی تست پایه ای هست که به ما کمک میکنه عملکردهای حیاتی سیستم رو سریع ارزیابی کنیم و مشکلات اصلی و بزرگ رو در زمان توسعه و تست متوجه شون بشیم.
( اصلاحیه ۲ مرداد ۱۴۰۳ : یکی از دوستان که پست رو خونده بود لطف کرد بهمون بازخورد داد که : فلسفه Smoke Test از تست سخت‌افزارهای الکترونیکی میاد که یک بورد الکترویکی رو متصل میکنند و اگه با جریان نیروی الکتریکی ازش دود خارج شد یعنی مشکل داره و دیگه سراغ چیزهای اضافه نمیرن. دمش گرم مرسی که با دقت مطالب رو دنبال می‌کنید.)
تو پرفورمنس تست ارزیابی میکنیم که سیستم نرم‌افزاری ما توی شرایط مختلف به لحاظ کارایی چطور عمل میکند. فاکتور هایی مثل منابع مصرفی، ثبات، قابلیت اسکیل کردن و پاسخگویی رو ارزیابی میکنیم تا مطمئن بشیم سیستم ما میتونه لود مورد انتظارمون رو هندل کنه.
اگه از شما بخوان که یه سیستم رو تیون کنید، چطوری متوجه میشید که این اپلیکیشن نیازمندی اصلیش RAM هست یا CPU یا IOPS؟ توی لود تست ما اپلیکیشن‌مون رو میبریم زیر لود تا متوجه بشیم کجاش درد میکنه 🙂 که بعدش بتونیم به درمانش کمک کنیم.
توی این تست بررسی میکنیم که اپلیکیشن مون به خوبی میتونه توی شرایطی که نیاز بود خودش رو بزرگتر کنه و اگه درخواست ها زیاد شد میتونه هندل کنه با اسکیل کردن خودش؟ مثلا یه جشنواره گذاشتیم یا توی عید مثلا قراره یکدفعه حجم درخواست‌هایی که سمتمون میاد زیاد بشه.
توی والیوم تستینگ هم لود می‌ندازیم روی سیستم، کلا والیوم تست و لود تست و اسکیلیبیلیتی تست شبیه هم هستن توی همه شون لود میریزیم روی سیستم، تفاوت توی مقدار لودی هست که میریزیم. تا جایی که هندل میکنه لود بریزیم؟ یا تا جایی که میمیره؟
حالا توی والیوم تست هم دنبال ارزیابی عملکرد سیستم زیر لود یا یک والیوم از دیتا هستیم. هدف اینه که مطمئن شیم سیستم میتونه اون والیوم دیتا یا اون حجم از تراکنش یا اون حجم از فعالیت کاربر رو بدون افت کیفیت یا خطا هندل کنه.
توی سکیوریتی به بررسی معیارهای امنیتی و آسیب پذیری‌های سیستم می‌پردازیم. هدف‌مون توی این تست این هست که ریسک‌های امنیتی رو مشخص کنیم مثلا مطمئن شیم که جایی بدون اینکه آتورایز کنیم دسترسی نداده باشیم یا مثلا دیتامون لیک نشده باشه یا آسیب پذیری‌های شناخته شده دیگه.
استرس تست هم مثل تست هایی که لود می‌ریختیم هست و هدف ما توی این تست اینه که محدودیت ها و لیمیت‌های سیستم مون رو شناسایی کنیم و ببینیم چقدر لود میتونه تحمل کنه یا ریسورس‌هامون چقدر کشش دارند. پس یه جورایی توی استرس تست انقدر لود میریزیم تا بمیره 🙂
توی اندتواند تست دنبال این هستیم که کارکرد سیستم‌مون رو از صفر تا صد به شکل کامل بررسی کنیم. مثلا از اول که کاربر میاد و ثبت نام میکنه تا لاگین کردنش و انتخاب کردنش و پرداخت کردنش و … توی یه فروشگاه اینترنتی. یه جورایی یه نمونه از سناریوی دنیای واقعی رو انجام میدیم ببینیم همه چی خوبه یا نه.
معرفی ابزارهای معروف تست:
یه لیست از اسم یه سری ابزار معروف تست رو اینجا براتون میذارم که اگه خواستید در موردشون بیشتر بخونید.
خلاصش که تست بنویسید! اگه تست ننویسید، چیزایی که قرار بوده توی تست متوجه بشید رو مشتری هاتون زنگ میزنن بهتون میگن و این اصلا خوب نیست 🙂
بررسی CI و مزایای اون:
شرایطی رو در نظر بگیرید که ما کد اپلیکیشن مون رو گذاشتیم توی یک گیت ریپازیتوری مثلا توی گیت‌لب و توسعه دهنده‌هامون هم تغییراتی رو که میدن هر روز دارن پوش میکنن توی گیت که در شرایط معمولی هم اغلب همینه و چندین و چند بار در روز پوش انجام میشه. حالا ما میتونیم با هر پوشی که انجام میشه یه سری اسکریپت رو فعال کنیم که کد جدید رو بیلد کنه و اپلیکیشن‌مون رو حالا با کد جدیدی که داره، به شکل خودکار تست کنه. به این روش اصطلاحا میگن Continuous Integration یا CI. هر تغییری که سابمیت میشه توی اپلیکیشن‌مون حتی توی برنچ های توسعه و … به شکل اتومیت بیلد و تست میشه هربار.
استفاده از این روش ریسک مون رو کاهش میده ، ارتباط و تعامل افراد پروژه رو بهتر میکنه و کیفیت محصول ما رو بالاتر میبره و به جلوگیری از هدر رفت زمان مون هم کمک میکنه.
بررسی CD و مزایای اون:
حالا یه قدم جلوتر میریم، یعنی با هر پوش به گیت نه تنها کد رو به شکل خودکار بیلد و تست میکنیم بلکه کد جدید رو میبریم و توی محیط های مختلفی که می‌خوایم دیپلوی هم میکنیم. اگه دیپلوی نهایی رو هم سیستم به شکل خودکار انجام بده بهش میگیم Continuous Deployment که زیاد مرسوم نیست ولی اگه برای انجام دیپلوی نهایی نیاز باشه که یه تریگر دستی نهایی انجام بدیم، مثلا یه کلیک کنیم توی گیتمون تا انجام بشه، بهش میگیم Continuous Delivery.
استفاده ازین روش ریسک ریلیزهامون رو میاره پایین، زمان تحویل محصولمون به مارکت رو کمتر میکنه، به کیفیت محصولمون کمک میکنه و هزینه هامون رو کمتر میکنه.
معرفی و مقایسه ابزارهای CI/CD:
کلی ابزار هستن که برای قسمت های مختلف CI/CD بهمون کمک میکنن. ابزارهایی مثل:
که معروف ترین هاش گیت‌لب و جنکینز هستن که معمولا ازشون استفاده میشه.
مقایسه‌‌ی کامل گیت‌لب با جنکینز:
از نظر طراحی و ساختار: CI/CD گیت‌لب به شکل کامل با پلتفرمش اینتگریت شده و به عنوان یه فیچر داخلی گیت‌لب محسوب میشه و نیاز به نصب کردن چیزی نداره برای اینکه توی گیت‌لب باهاش کار کنیم، اما جنکینز سرور جداگانه خودش رو داره و میتونه به صورت on-premises یا روی سرور ابری بالا بیاد.
از نظر سازگاری با ورژن کنترل سیستم‌ها: CI/CD گیت‌لب به صورت دیفالت سازگاری داره با ریپازیتوری‌های گیت‌لب و فیچرهای کنترلی اونها مثل برنچ و مرج و ریکوئست و پایپ‌لاین‌ها. جنکینز اما به صورت مستقیم با هیچ ورژن کنترل سیستمی بدون نیاز به کانفیگ‌های جداگانه اینتگریت نمیشه و برای استفاده از جنکینز توی ورژن کنترل سیستم‌ها باید از پلاگین‌ها استفاده کنیم. جنکینز از پلاگین‌های زیاد و متنوعی برای وصل شدن به ورژن کنترل سیستم های مختلف پشتیبانی میکنه.
از نظر کانفیگ کردن پایپ لاین: گیت لب از یک فایل به فرمت yaml با نام gitlab-ci.yml. برای تعریف کردن استیج‌های پایپ‌لاین، جاب‌ها و دیپندنسی اونها استفاده میکنه و این فایل کانفیگ رو توی خود ریپازیتوری ذخیره میکنیم. اما جنکینز از یک فایل اسکریپت به نام Jenkinsfile استفاده میکنه که میتونیم اونو به زبان Groovy بنویسیم یا از یک DSL (domain-specific language) به نام Scripted Pipeline استفاده کنیم یا اینکه با سینتکس جدید تری به نام Declarative Pipeline اسکریپت جنکینز رو بنویسیم.
از نظر راحتی نصب و ستاپ: CI/CD گیت‌لب که به صورت built-in به عنوان فیچر توی خود گیت‌لب هست و همراه اون آپدیت میشه و … . جنکینز اما نیاز به نصب و کانفیگ داره و باید سرور زیرساختش رو منیج و کانفیگ کنیم. همچنین برای آپدیت و آپگرید هم باید یوزر یا ادمین این کار رو انجام بده.
از نظر کامیونیتی: گیت‌لب جامعه در حال رشدی رو داره و اکوسیستمی که تقریبا تمام فیچرها و مرحله‌های CI/CD رو پوشش میده بدون نیاز به پلاگین خاصی، از طرفی جنکینز توی اکوسیستمی که داره یک حجم بالایی از پلاگین هارو توسعه میده و امکان کاستوم کردن جزئیات با دیتیل بالا رو میده و با طیف متنوعی از ابزارها و تکنولوژی‌ها میتونه سازگار بشه.
از نظر اسکیل پذیری و توزیع شدن: گیت لب از بیلدهای دیستریبیوتد و انجام جاب‌ها به صورت موازی از طریق چندین رانر پشتیبانی میکنه و رانرها میتونن روی ماشین‌های جداگانه نصب بشن که به اسکیل کردن گیت‌لب کمک میکنه. جنکینز اما برای اسکیل شدن از روش افزایش تعداد ایجنت های بیلد یا نود ها استفاده میکنه درحالیکه مدیریت زیرساخت و لود بالانس در جنکینز نیاز به نصب و کانفیگ‌های جداگانه داره.
توی قسمت‌های بعدی مسیر دواپس‌مون رو ادامه میدیم و بیشتر گیت‌لب رو با هم بررسی میکنیم.
مراقب خودتون باشید. 🌹🐳🌹
خوبه که داکرمی رو تو جاهای مختلف فالو کنید. پذیرای نظرات شما هستیم.
🫀 Follow DockerMe 🫀
🔔 Follow YouTube 🔔
📣 Follow Instagram 📣
🖇 Follow LinkedIn DockerMe🖇
🔎 Follow Linkedin Ahmad Rafiee 🔎
🕊 Follow Twitter 🕊
