توی این پست یه مقدار در مورد تست نوشتن و اهمیت اون توضیح میدم و بعدش انواع تست رو بهتون معرفی میکنم و برای آغاز مطلب CI/CD در ادامهی مسیر دواپسمون، میریم سراغ معرفی اولیه مفاهیم CI/CD و نهایتا دو تا از ابزارهای مهمش رو با هم مقایسه میکنم.
خب یه مروری کنیم پستهای قبلی رو:
دواپس چیه و چرا لازمه؟ اینجا در مورد دواپس و ضرورت استفاده از آن صحبت کردم.
چطور اپلیکیشن مناسب کلاد آماده کنیم؟ و اینجا توضیح دادم که چطور میتونیم یه اپلیکیشن مناسب کلاد توسعه بدیم.
چه عمقی از لینوکس برای دواپس لازمه؟ و اینجا توضیح دادم که کدوم موارد لینوکس برای دواپس الزامی هست که اول سراغ اون موارد بریم.
خودکارش کن,مشکلاتت حل میشه در اینجا در مورد اتومیشن و اینکه انسیبل چیه و چه کمکی به ما میکنه صحبت کردم.
در مسیر دواپس اینبار اجزای اصلی انسیبل تو این پست اجزای انسیبل رو معرفی کردم و آنها را شرح دادم.
در مسیر دواپس به داکر رسیدیم (قسمت اول) تو این پست داکر رو شروع کردیم و اونو معرفی کردیم.
در مسیر دواپس اینبار: پشت داکر چه خبره؟ (قسمت دوم) توی این پست در مورد تکنولوژی هایی که داکر ازشون استفاده میکنه توضیح دادیم.
تست نوشتن و شروع مسیر CI/CD (قسمت اول) توی این پست انواع تست رو بررسی کردیم و با ابزارهای CI/CD آشنا شدیم و یه مقایسه بین گیتلب و جنکینز داشتیم.
در مسیر CI/CD گیت رو بررسی میکنیم (قسمت دوم) توی این پست قبل ورود به گیتلب نیاز بود که گیت و ورژن کنترل سیستم ها رو یه بررسی کنیم.
در مسیر CI/CD شناخت گیتلب (قسمت سوم) توی این پست اجزای گیتلب رو بررسی کردیم و با کامپوننتهای مختلفی که داره بیشتر آشنا شدیم.
در مسیر CI/CD پایپلاین و رانر گیتلب (قسمت چهارم) توی این پست پایپلاین و رانر گیتلب رو بررسی کردیم.
در مسیر CI/CD وریبل، گیتآپس و جمعبندی (قسمت پنجم) توی این پست وریبلهای گیتلب رو بررسی کردیم و یه معرفی کوتاه از گیتآپس و آتودواپس کردیم و در انتها یه مقدار تجربههای خودم رو در گیتلب باهاتون به اشتراک گذاشتم.
در مسیر Observability، الک (قسمت دوم) توی این پست استک قدرتمند ELK رو بررسی کردیم.
در مسیر Observability، جمع بندی استک الک (قسمت سوم) توی این پست بقیه کامپوننتهای استک الک رو بررسی کردیم و fluentd و fluentbit رو مقایسه کردیم و نهایتا یه معرفی هم روی opensearch داشتیم.
در مسیر Observability، استک پرومتئوس (قسمت چهارم) توی این پست یه معرفی اولیه داشتیم روی استک پرومتئوس.
در مسیر Observability، استک پرومتئوس (قسمت پنجم) توی این پست یه مقدار کامپوننت های استک پرومتئوس رو بیشتر بررسی کردیم.
در مسیر Observability، استک ویکتوریا (قسمت ششم) توی این پست استک ویکتوریا رو معرفی کردیم و سعی کردیم با پرومتئوس مقایسهاش کنیم.
در مسیر Observability، میمیر (قسمت هفتم) توی این پست در مورد ابزار میمیر از ابزارهای گرافانا توضیح دادیم و کاربردش رو بررسی کردیم.
در مسیر Observability، لوکی (قسمت هشتم) توی این پست در مورد ابزار گرافانا برای مدیریت لاگ یعنی لوکی توضیح دادیم و آخرشم یه معرفی کوتاه رو graylog داشتیم.
در مسیر Observability، تمپو (قسمت نهم) توی این پست در مورد تریسینگ توضیح دادیم و گرافانا تمپو رو بررسی کردیم و یه معرفی کوتاه روی Jaeger داشتیم
در مسیر Observability، گرافانا (قسمت دهم) توی این پست در مورد گرافانا و HA کردنش و همچنین یه سری از ابزارهاش مثل alloy , incident, on-call توضیح دادیم.
آغاز مسیر کوبر (قسمت اول) تو این قدم به معرفی ابزارهای ارکستریشن پرداختیم و مدارک کوبرنتیز رو بررسی کردیم.
کوبر سینگل ( قسمت دوم ) توی این قدم در مورد kubectl , kubeconfig توضیح دادیم و تعدادی ابزار رو معرفی کردیم که به کمک اونها میتونیم یک کوبرنتیز دمهدستی واسه تستهامون داشته باشیم.
کامپوننتهای کوبر ( قسمت سوم ) توی این پست کامپوننتهای مختلف کوبرنتیز رو بررسی کردیم و اجزای نودهای مستر و ورکر رو دونه دونه بررسی کردیم و توضیح دادیم.
پادها و مدیریت اونها در کوبرنتیز (قسمت چهارم) توی این پست در مورد پاد توی کوبرنتیز توضیح دادیم و موارد مربوط به اون رو بررسی کردیم.
ورکلودهای کوبر و مدیریت منابع کوبر (قسمت پنجم) توی این پست در مورد namespaceها توی کوبر توضیح دادیم و انواع ورکلود کوبر رو بررسی کردیم.
اگه لازم شد کوبر خودش گنده میشه! ( قسمت ششم ) توی این پست در مورد سه نوع ورکلود مرتبط با scaling به صورت خودکار در کوبرنتیز توضیح دادیم.
نتورک کوبر (قسمت هفتم) توی این قسمت انواع سرویس توی کوبرنتیز رو بررسی کردیم و در مورد مفاهیم اینگرس و نتورک پالیسی توضیح دادیم.
استورج کوبرنتیز (قسمت هشتم) توی این قسمت در مورد انواع استورج توی کوبرنتیز توضیح دادیم و مفاهیم PV و PVC و Storage Class رو بررسی کردیم.
پراب، ریکوئست و لیمیت (قسمت نهم) توی این قسمت موارد مربوط به محدود کردن منابع کانتینر توی کوبرنتیز رو بررسی کردیم و در مورد انواع probe ها توی کوبرنتیز توضیح دادیم.
پاد تو نود (قسمت دهم) توی این قسمت درمورد فرآیند انتقال پاد به نود مناسب مفاهیم پیشرفتهتری مثل affinity و anti-affinity و taint و toleration رو بررسی کردیم.
اولویت پاد و امنیت (قسمت یازدهم) توی این قسمت در مورد تعیین اولویت برای پادها و جنبههای مختلف امنیت در کوبرنتیز توضیح دادیم.
کنترل دسترسی به کوبر (قسمت دوازدهم) توی این قسمت در مورد مراحل دسترسی به api کوبرنتیز صحبت کردیم و بعدش مفاهیمی مثل سرویس اکانت رو توضیح دادیم.
دیزاین کلاستر (قسمت سیزدهم) توی این قسمت در مورد طراحی و دیزاین یک کلاستر و روشهای مختلفی که داره توضیح دادیم و همچنین تفاوت روشهای مختلف تقسیم منابع در کلاسترها را بررسی کردیم.
مالتی تننسی در کوبر (قسمت چهاردهم) توی این قسمت چالشهای مربوط به داشتن چند مستاجر بر روی کلاستر کوبرنتیز توضیح دادیم.
هلم (قسمت پانزدهم) توی این قسمت پکیج منیجر معروف کوبرنتیز یعنی Helm رو بررسی کردیم و در موردش ویژگیها و کاربردهاش توضیح دادیم.
سی آر دی و اُپراتور (قسمت شانزدهم) توی این قسمت در مورد اینکه چطوری یه ریسورس کاستوم شده به کلاستر اضافه کنیم توضیح دادیم و مفهوم اُپراتور رو توی کوبر بررسی کردیم.
نصب کلاستر با kubeadm (قسمت هفدهم) توی این قسمت قدم به قدم نحوه نصب یک کلاستر کوبرنتیز رو با استفاده از ابزار kubeadm توضیح دادیم.
نصب کلاستر با kubespray (قسمت هجدهم) توی این قسمت نحوه نصب کلاستر با یه پروژه خیلی خوب به نام کیوب اسپری که یه انسیبل خفن برای ستاپ کلاستر رائه میده رو توضیح دادیم.
نصب کلاستر با rancher (قسمت نوزدهم) توی این قسمت توضیح دادیم که چطور با استفاده از ابزار RKE یک کلاستر کوبرنتیز راهاندازی کنیم.
توصیه میکنم که حتما این پستها رو هم مطالعه کنید. بریم که ادامه بدیم.
تست نرمافزار و ضرورت اون:
تست مهمه چون احتمالش هست که باگ یا ارور توی کد باشه که با تست بتونیم اونو متوجه بشیم قبل از اینکه مشتری مون توی پروداکشن متوجه اش بشه و بهمون بگه. معمولا نرم افزار هایی که تست شدن بیشتر قابل اتکا هستن، امن تر هستن، کارایی بیشتری دارن و رضایت مشتری بالاتری رو دارن.
تست ها رو به دو نوع Functional که توی اونها معمولا صحت کارکرد یک یا چند سرویس رو به لحاظ لاجیکی بررسی میکنیم و Non-Functional که توی اونها سرویسها رو به لحاظ عملکردی در شرایط مختلف تست میکنیم، تقسیم میشن.
چرا تست اتومیشن داشته باشیم؟
چون میتونیم تست اتومیت رو توی CI/CD به راحتی انجام بدیم که بهمون توی ذخیره زمان و هزینه کمک میکنه و دیباگمون رو سریعتر میکنه. بهمون امکان استفاده مجدد از تست رو میده و دقتمون رو بالاتر میبره و سریعتر بازخورد نسبت به کدمون رو میتونیم از چرخه CI/CD بگیریم.
انواع تست:
Unit Testing
تو یونیت تست یک ماژول از اپلیکیشن یا یک میکروسرویس رو به تنهایی تست میکنیم تا مطمئن بشیم به شکلی که انتظار داریم کار میکنه.
Integration Testing
بعد اینکه توی یونیت تست فهمیدیم هر سرویس به تنهایی داره درست کار میکنه حالا توی اینتگریشن تست، سعی میکنیم بررسی کنیم که آیا سرویسها در ارتباط با همدیگه هم به درستی کار میکنند.
Functional Testing
توی این تست فانکشنالیتی یه تابع رو به همراه دیپندنسیهای مورد نیازش که باهاشون ارتباط داره، توی سیستم آزمایش میکنیم. مثلا اینکه آیا فرآیند درگاه پرداخت بدرستی کار میکنه توی یک سایت فروشگاه اینترنتی، میشه تست فانکشنال.
UAT (User Acceptance Testing)
این نوع تست برای این هست که ببینیم آیا سیستم نرمافزاری ما نیازمندی و انتظارات کاربران یا سهامداران را برآورده میکند یا نه. معمولا این تست توسط کاربران نهایی یا گروهی تعیین شده انجام میشود. دقت کنید که این کاربر نهایی یه گروه مشخص قبل تعیین شده هست معمولا که صرفا شبیه سازی میکنه رفتار کاربر در محیط واقعی رو.
Smoke Testing
فرض کنید داریم دودکش یه خونه ای رو درست میکنیم برای اینکه ببینیم درست کار میکنه یه سیگار زیرش میکشیم ببینیم دود میره بالا یا نه 🙂 البته شما مراقب سلامتیتون باشید و سیگار نکشید.
یا مثلا قبل وصل کردن لوله بخاری یه کاغذ آتیش میزنیم میگیریم جلو دودکش ببینیم خاموش میشه یا شعله رو میکشه بالا.
حالا از فلسفه اسمش که بگذریم 🙂 اسموک تست، نوعی تست پایه ای هست که به ما کمک میکنه عملکردهای حیاتی سیستم رو سریع ارزیابی کنیم و مشکلات اصلی و بزرگ رو در زمان توسعه و تست متوجه شون بشیم.
( اصلاحیه ۲ مرداد ۱۴۰۳ : یکی از دوستان که پست رو خونده بود لطف کرد بهمون بازخورد داد که : فلسفه Smoke Test از تست سختافزارهای الکترونیکی میاد که یک بورد الکترویکی رو متصل میکنند و اگه با جریان نیروی الکتریکی ازش دود خارج شد یعنی مشکل داره و دیگه سراغ چیزهای اضافه نمیرن. دمش گرم مرسی که با دقت مطالب رو دنبال میکنید.)
Performance
تو پرفورمنس تست ارزیابی میکنیم که سیستم نرمافزاری ما توی شرایط مختلف به لحاظ کارایی چطور عمل میکند. فاکتور هایی مثل منابع مصرفی، ثبات، قابلیت اسکیل کردن و پاسخگویی رو ارزیابی میکنیم تا مطمئن بشیم سیستم ما میتونه لود مورد انتظارمون رو هندل کنه.
Load Test
اگه از شما بخوان که یه سیستم رو تیون کنید، چطوری متوجه میشید که این اپلیکیشن نیازمندی اصلیش RAM هست یا CPU یا IOPS؟ توی لود تست ما اپلیکیشنمون رو میبریم زیر لود تا متوجه بشیم کجاش درد میکنه 🙂 که بعدش بتونیم به درمانش کمک کنیم.
Scalability
توی این تست بررسی میکنیم که اپلیکیشن مون به خوبی میتونه توی شرایطی که نیاز بود خودش رو بزرگتر کنه و اگه درخواست ها زیاد شد میتونه هندل کنه با اسکیل کردن خودش؟ مثلا یه جشنواره گذاشتیم یا توی عید مثلا قراره یکدفعه حجم درخواستهایی که سمتمون میاد زیاد بشه.
Volume
توی والیوم تستینگ هم لود میندازیم روی سیستم، کلا والیوم تست و لود تست و اسکیلیبیلیتی تست شبیه هم هستن توی همه شون لود میریزیم روی سیستم، تفاوت توی مقدار لودی هست که میریزیم. تا جایی که هندل میکنه لود بریزیم؟ یا تا جایی که میمیره؟
حالا توی والیوم تست هم دنبال ارزیابی عملکرد سیستم زیر لود یا یک والیوم از دیتا هستیم. هدف اینه که مطمئن شیم سیستم میتونه اون والیوم دیتا یا اون حجم از تراکنش یا اون حجم از فعالیت کاربر رو بدون افت کیفیت یا خطا هندل کنه.
Security
توی سکیوریتی به بررسی معیارهای امنیتی و آسیب پذیریهای سیستم میپردازیم. هدفمون توی این تست این هست که ریسکهای امنیتی رو مشخص کنیم مثلا مطمئن شیم که جایی بدون اینکه آتورایز کنیم دسترسی نداده باشیم یا مثلا دیتامون لیک نشده باشه یا آسیب پذیریهای شناخته شده دیگه.
Stress
استرس تست هم مثل تست هایی که لود میریختیم هست و هدف ما توی این تست اینه که محدودیت ها و لیمیتهای سیستم مون رو شناسایی کنیم و ببینیم چقدر لود میتونه تحمل کنه یا ریسورسهامون چقدر کشش دارند. پس یه جورایی توی استرس تست انقدر لود میریزیم تا بمیره 🙂
End to End testing
توی اندتواند تست دنبال این هستیم که کارکرد سیستممون رو از صفر تا صد به شکل کامل بررسی کنیم. مثلا از اول که کاربر میاد و ثبت نام میکنه تا لاگین کردنش و انتخاب کردنش و پرداخت کردنش و … توی یه فروشگاه اینترنتی. یه جورایی یه نمونه از سناریوی دنیای واقعی رو انجام میدیم ببینیم همه چی خوبه یا نه.
معرفی ابزارهای معروف تست:
یه لیست از اسم یه سری ابزار معروف تست رو اینجا براتون میذارم که اگه خواستید در موردشون بیشتر بخونید.
SoapUI
Katalo
Grafana K6
Postman
Assertible
Swagger
Apigee
JMeter
REST-assured
Tricentis
Karate
REST-console
APIFORTRESS
Pyresttest
Fiddler
Airborne
خلاصش که تست بنویسید! اگه تست ننویسید، چیزایی که قرار بوده توی تست متوجه بشید رو مشتری هاتون زنگ میزنن بهتون میگن و این اصلا خوب نیست 🙂
بررسی CI و مزایای اون:
شرایطی رو در نظر بگیرید که ما کد اپلیکیشن مون رو گذاشتیم توی یک گیت ریپازیتوری مثلا توی گیتلب و توسعه دهندههامون هم تغییراتی رو که میدن هر روز دارن پوش میکنن توی گیت که در شرایط معمولی هم اغلب همینه و چندین و چند بار در روز پوش انجام میشه. حالا ما میتونیم با هر پوشی که انجام میشه یه سری اسکریپت رو فعال کنیم که کد جدید رو بیلد کنه و اپلیکیشنمون رو حالا با کد جدیدی که داره، به شکل خودکار تست کنه. به این روش اصطلاحا میگن Continuous Integration یا CI. هر تغییری که سابمیت میشه توی اپلیکیشنمون حتی توی برنچ های توسعه و … به شکل اتومیت بیلد و تست میشه هربار.
استفاده از این روش ریسک مون رو کاهش میده ، ارتباط و تعامل افراد پروژه رو بهتر میکنه و کیفیت محصول ما رو بالاتر میبره و به جلوگیری از هدر رفت زمان مون هم کمک میکنه.
بررسی CD و مزایای اون:
حالا یه قدم جلوتر میریم، یعنی با هر پوش به گیت نه تنها کد رو به شکل خودکار بیلد و تست میکنیم بلکه کد جدید رو میبریم و توی محیط های مختلفی که میخوایم دیپلوی هم میکنیم. اگه دیپلوی نهایی رو هم سیستم به شکل خودکار انجام بده بهش میگیم Continuous Deployment که زیاد مرسوم نیست ولی اگه برای انجام دیپلوی نهایی نیاز باشه که یه تریگر دستی نهایی انجام بدیم، مثلا یه کلیک کنیم توی گیتمون تا انجام بشه، بهش میگیم Continuous Delivery.
استفاده ازین روش ریسک ریلیزهامون رو میاره پایین، زمان تحویل محصولمون به مارکت رو کمتر میکنه، به کیفیت محصولمون کمک میکنه و هزینه هامون رو کمتر میکنه.
معرفی و مقایسه ابزارهای CI/CD:
کلی ابزار هستن که برای قسمت های مختلف CI/CD بهمون کمک میکنن. ابزارهایی مثل:
GitLab
Jenkins
Circleci
TeamCity
Bamboo
ZUUL
Argo
GitKube
Spinnaker
که معروف ترین هاش گیتلب و جنکینز هستن که معمولا ازشون استفاده میشه.
مقایسهی کامل گیتلب با جنکینز:
از نظر طراحی و ساختار: 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 🕊
