اگه با جوئل تست آشنایی ندارید باید بگم یکی از معروف ترین روش های تفکیک و درجه بندی شرکت های نرم افزاری بر اساس کیفیت نرم افزارشون هست که Stack Overflow هم برای نشون دادن کیفیت شرکت ها ازش استفاده میکنه. این تست، شامل دوازده سوال بله / خیر هست و در نهایت امتیازی از یک تا دوازده به شرکت میده که نشون میده چقدر از اصول نرم‌افزاری تو اون شرکت رعایت میشن. پیشنهاد میکنم لیست دوازده تا سوالش رو حتما بخونین.
بند سوم این تست میپرسه: آیا شرکت شما هر روز از کد ها بیلد میگیره؟
اهمیت بیلد گرفتن روزانه شاید در نگاه اول مخصوصا برای یه شرکت کوچیک اونقد مهم نباشه. چون نهایتا یک یا دو نفر هستن که روی اون ریپوزیتوری کار میکنن و (احتمالا) در جریان کدهای اون ریپو هستن. اما وقتی اعضای درگیر روی یه پروژه بیشتر و بیشتر میشن، اتفاقات پیش‌بینی نشده میتونن به سرعت نمایی رشد کنن و کل فرآیند توسعه و ریلیز رو مختل کنند. برای همینه که این تست شرکت ها رو تشویق میکنه که هر روز وضعیت بیلد ریپو هاشون رو مشخص کنند که تازه شب ریلیز متوجه مشکل جدید روی پروژه نشن!
پس مهمه که بیلد پروژه همیشه سبز باشه!
اما گرفتن این بیلد ها باید به نحوی کاملا مکانیزه بشن و فرآیند دستی توش دخیل نباشه. اینجاست که ابزار های ci/cd به کار میان. و تو این مقاله، میخوام ابزاری که گیتهاب به همین منظور ساخته رو با یه مثال عملی بهتون معرفی کنم. :)
ابزار های ci/cd روی ماشین هایی اجرا میشند و با استفاده از یک سری کامند با سینتکس خاص خودشون فرآیند بیلد و دیپلوی (و احیانا تست و لینت و …) رو روی اون ماشین اجرا میکنند.
مثالی که میخوام بزنم، فرض میکنه که شما یه پروژه فرانت اندی ساده با vite دارید و میخواید فرآیند بیلد و دیپلوی اش رو با استفاده از Github Actions و ghcr و docker-compose مکانیزه کنید. اینطوری فرآیند بیلد و نگه داری ایمیج ها، هیچ هزینه ای برامون نخواهدداشت و فقط ماشین پروداکشن هست که باید بابتش هزینه کنید و سرور بخرید.
فرص کنید یه پروژه فرانت اندی داریم که میخوایم فایل های استتیک پروژه مون توسط یک ماشین داکری پشت یه nginx سرو بشن. در نتیجه یه داکرفایل شبیه این خواهیم داشت:
این فایل اول با استفاده از یه داکر ایمیج node-16 (که اسمشو گذاشتیم build) فایل های پروژه رو روی داکر میبره و سپس کامند های مربوط به نصب پکیج ها و نهایتا تولید فایل های استتیک رو اجرا میکنه. فایل های استتیک، در مسیر /app/dist تولید میشن که تو سه خط آخر روی ایمیج nginx کپی میشن و کانتینر ما رو با یه nginx baseimage میسازن که وقتی بالا بیاد و اجرا بشه، اون فایل های استتیک رو سرو میکنه.
اگه روی ماشین شخصیتون، داکر رو نصب داشته باشید، با این کامند میتونید بیلد رو بگیرید:
docker build -t my-front .
و برای اجراش میتونید این کامند رو استفاده کنید:
docker run -t my-front
پروژه بالا میاد و فایل هاتون داخل nginx سرو میشن (در ادامه کانفیگی با docker-compose تعریف خواهیم کرد که بتونیم پورت درستی رو از کانتینر expose کنیم و بتونیم از بیرون داکر بهش ریکوئست بزنیم. اما اگه الی الحساب حتما میخواید از بیرون کانتینر به این nginx ریکوئست بزنید، یادتون نره که پورت expose کنید)
حالا اگه بخوایم این داکر رو، جایی بجز روی ماشین شخصی بیلد بگیریم، باید محیطی وجود داشته باشه که بتونه کامند های docker ما رو اجرا کنه. اینطوری میتونیم تعریف کنیم هر کسی که روی پروژه کامیت جدیدی پوش کرد یا هر باری که برنچ مستر آپدیت شد بیلد خودبخود انجام بشه. به این منظور، کف ریپویی که روی گیتهاب پوش میکنیم، فایل تو مسیر .github/workflows/build.yml میسازیم:
هر کدوم از step هایی که روی این فایل تعریف شدند، یه کار کوچیک انجام میدن:
قبل این که این فایل رو بفرستید روی برنچ مستر گیتهاب، سایت ghcr.io رو باز کنید و اکانتتون رو اونجا فعال کنید. بعدش که پوش کنید، کد ها شروع به اجرا میشن و حتی نیاز به کانفیگ خاصی روی خود گیتهاب یا جای دیگه نیست.
در مورد سرور پروداکشن:
مثالی که این بالا آوردم، یه پروژه شخصی هست که فعلا روی یه vps سرو میشه. روی ماشین docker-compose نصب هست و یه docker-compose.yml شبیه این روی پروژه وجود داره:
این فایل کمکم میکنه که با یه دستور بتونم بیلد جدید رو از Github Container Registry پول کنم و بالا بیارمش.
خوشحال میشم از کانفیگ شما مخاطب عزیز برای بیلد و دیپلوی تون بدونم. :)
