انتشار یک‌باره‌ی نسخه‌ی جدید نرم‌افزار : دیپلوی Big Bang
در روش Big Bang، نسخه‌ی جدید نرم‌افزار به‌صورت یک‌باره جایگزین نسخه‌ی قبلی میشه. این روش با وجود سادگی و سرعت اجرا، می‌تونه ریسک قطعی سرویس و بروز خطا رو افزایش بده. توی این مقاله با نحوه‌ی کار، مزایا و معایب این روش و شرایط مناسب استفاده از اون آشنا می‌شیم.
قبل از اینکه بریم سراغ استراتژی‌های مختلف Deployment، بهتره اول ببینیم اصلاً دیپلوی یا Deployment یعنی چی.
Deployment فرایند انتقال یک نسخه آماده از نرم‌افزار به محیطیه که کاربران واقعی بتونن ازش استفاده کنن. البته این کار فقط به کپی کردن فایل‌ها روی سرور محدود نمیشه. معمولاً کارهایی مثل آماده‌سازی محیط، نصب وابستگی‌ها، اجرای Migrationها، ساخت فایل‌های موردنیاز و راه‌اندازی مجدد سرویس‌ها هم بخشی از فرایند دیپلوی هستن.
توی این مجموعه قراره با چهار روش متداول برای انتشار نسخه‌های جدید نرم‌افزار آشنا بشیم. اولین روشی که می‌خوایم بررسی کنیم،Big Bang Deploymentیا انتشار یک‌باره‌ست.
Big Bang Deployment چطور کار می‌کنه؟
توی این روش، نسخه فعلی نرم‌افزار متوقف میشه، نسخه جدید جایگزینش میشه و بعد از انجام تنظیمات لازم، سرویس دوباره در دسترس کاربران قرار می‌گیره.
فرض کنید نسخهv1روی سرور در حال اجراست و حالا می‌خوایم اون رو با نسخهv2جایگزین کنیم.
توی این مدت ممکنه سرویس برای مدتی در دسترس نباشه. به همین خاطر معمولاً برای انجام دیپلوی، یک بازه زمانی مشخص به اسمMaintenance Windowدر نظر گرفته میشه تا اختلال کمتری برای کاربران ایجاد بشه.
یک مثال با Laravel
فرض کنید یک پروژه Laravel روی سرور لینوکسی اجرا میشه و برای انتشار نسخه جدید از یک اسکریپت ساده استفاده میکنیم.
نمونهای از مراحل دیپلوی می‌تونه به این شکل باشه:
Bash / Shell
cd /var/www/my-app
php artisan down
git pull origin main
composerinstall\
--no-dev \
--optimize-autoloader
php artisan migrate --force
php artisan optimize
php artisan up
توی این مثال، اول برنامه وارد حالت Maintenance میشه. بعد کدهای جدید دریافت و وابستگی‌ها نصب میشن. در ادامه Migrationها اجرا میشن و با بهینهسازی برنامه، سرویس دوباره در دسترس کاربران قرار می‌گیره.
البته این مثال فقط برای نشون دادن ترتیب مراحل نوشته شده و نباید اون رو یک اسکریپت کامل برای محیط Production در نظر بگیریم.
برای استفاده واقعی، باید موارد دیگهای مثل مدیریت خطا در صورت شکست دستورات، وضعیت فایل‌های Environment، Permissionها و Queue Workerها رو هم در نظر بگیریم.
یک مثال با Next.js
توی یک پروژه Next.js که به‌صورت Node.js Server اجرا میشه هم می‌تونیم از همین رویکرد استفاده کنیم.
در این حالت، ابتدا سرویس متوقف میشه، نسخه جدید Build میشه و بعد از آماده شدن، دوباره اجرا میشه:
Bash / Shell
cd /var/www/my-next-app
npm ci
npm run build
npm run start
البته توی یک فرایند واقعی، قبل از اجرای Build باید سرویس فعلی متوقف شده باشه یا حداقل دسترسی کاربران بهش کنترل بشه. وگرنه ممکنه با فایل‌های ناقص یا تداخل بین فرایندهای Build مواجه بشیم.
مزایای Big Bang Deployment
سادگی:پیادهسازی و مدیریت این روش نسبتاً سادهست و معمولاً به تنظیمات پیچیدهای نیاز نداره.
هزینه کمتر:لازم نیست چند نسخه از برنامه رو به‌صورت همزمان اجرا کنیم یا زیرساخت اضافهای در اختیار داشته باشیم.
مسیریابی سادهتر:معمولاً نیازی به Load Balancer برای جابهجایی ترافیک بین نسخه‌های مختلف برنامه نداریم.
معایب Big Bang Deployment
مهمترین مشکل این روش،Downtimeهست. یعنی وقتی نسخه قدیمی متوقف میشه و نسخه جدید جاش رو می‌گیره، ممکنه کاربران برای مدتی نتونن از برنامه استفاده کنن.
از طرف دیگه، اگه نسخه جدید بعد از انتشار با مشکل مواجه بشه، باید نسخه قبلی رو دوباره روی سرور مستقر کنیم. این کار ممکنه زمانبر باشه، مخصوصاً وقتی تغییراتی هم توی دیتابیس انجام شده باشن.
در واقع، هرچی فرایند جایگزینی پیچیدهتر باشه، برگشتن به نسخه قبلی هم می‌تونه دردسر بیشتری داشته باشه.
چه زمانی از این روش استفاده کنیم؟
Big Bang Deployment می‌تونه برای محیطهای Development، پروژههای داخلی با ترافیک محدود، سرویسهایی که Maintenance Window مشخص دارن یا نرمافزارهایی که زیرساخت لازم برای اجرای همزمان چند نسخه رو ندارن، انتخاب مناسبی باشه.
اما اگه با سرویس حساسی مثل یک فروشگاه اینترنتی یا سامانه مالی سروکار داریم که باید تقریباً همیشه در دسترس باشه، این روش معمولاً انتخاب مناسبی نیست. چون حتی چند دقیقه قطعی هم ممکنه روی تجربه کاربران یا فعالیت کسبوکار تأثیر بذاره.
جمع‌بندی
Big Bang Deployment یکی از سادهترین روشهای انتشار نسخه جدید نرمافزاره. توی این روش، نسخه قدیمی متوقف میشه، نسخه جدید جاش رو می‌گیره و بعد از راه‌اندازی مجدد، سرویس در دسترس کاربران قرار می‌گیره.
سادگی پیادهسازی و هزینه پایین از مزایای اصلی این روش هستن. اما در مقابل، باید Downtime و ریسک جایگزینی یک‌باره نسخه جدید رو هم در نظر بگیریم.
توی مقاله بعدی میریم سراغRolling Update؛ روشی که بهجای جایگزین کردن همه نسخهها به‌صورت همزمان، این کار رو بهتدریج انجام میده.
محمد علی
نظرات
هنوز نظری ثبت نشده است. اولین نفر باشید!