چگونه زمانهای استقرار برنامههای JS را به کسری تقسیم کردم

تصور کنید زمان خط لوله CI/CD خود را از 26 دقیقه به 1 دقیقه کاهش دهید.
مثل یک رویا به نظر می رسد، درست است؟
خوب، من آنجا بوده ام و این کار را در Notionlytics انجام داده ام. تنها چیزی که لازم بود یک سری بهینه سازی عملکرد و کمی تفکر خلاقانه بود.
بنابراین، بیایید به بررسی تکنیکهایی بپردازیم که برای دستیابی به این پیشرفت چشمگیر استفاده کردم.
تعویض دنده
Pnpm
اول از همه، من دو تغییر اساسی در زیرساخت ایجاد کردم. من با Yarn خداحافظی کردم و pnpm را در آغوش گرفتم، مدیر بسته که به سرعت و کارایی اش معروف است. pnpm با فرآیند نصب سه مرحلهای خود، به سرعت تفکیک وابستگی، محاسبه ساختار دایرکتوری و وابستگیهای پیوند را مدیریت میکند.
نتیجه؟
بهبود قابل توجه در زمان نصب.
توربورپو
در ادامه، NX را با Turborepo برای مدیریت monorepo عوض کردم. وظایف ذخیره سازی Turborepo برای ذخیره نتایج و گزارش های اسکریپت های مختلف مانند build، test و linت بسیار ارزشمند بود. علاوه بر این، اجرای موازی وظایف آن به طور قابل توجهی زمان ساخت را کاهش داد.
NX بدون شک تأثیرگذار است و حقیقت را بگویم – من کاملاً به آن عادت کردم. با این وجود، زمان پیشرفت فرا رسیده است: Turborepo رویکرد سادهتری را ارائه میکند و احساس بسیار سریعتری دارد.
اگر می توانید مرا کش کنید
Pnpm
برای به حداکثر رساندن عملکرد، من ذخیره کش را در گردش کار CI خود گنجانده ام.
با استفاده از اکشن actions/cache action، ما یک استراتژی برای ذخیره و بازیابی وابستگی ها اجرا کردیم و از نصب های اضافی جلوگیری کردیم.
در اینجا نحوه انجام آن آمده است:
- name: Configure pnpm cache
id: pnpm-cache
run: echo "STORE_PATH=$(pnpm store path)" >> $GITHUB_OUTPUT
- uses: actions/cache@v3
with:
path: ${{ steps.pnpm-cache.outputs.STORE_PATH }}
key: ${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}
restore-keys: |
${{ runner.os }}-pnpm-store-
توربورپو
حالا برای بخش هیجان انگیز: ذخیره سازی Turborepo. اولاً، مزیت آن در توانایی Turborepo برای به خاطر سپردن خروجی پس از ساخت اولیه نهفته است. بیلدهای بعدی فقط آنچه را که تغییر کرده است بازسازی می کنند.
اما صبر کنید، چیزهای بیشتری وجود دارد!
Turborepo همچنین ارائه می دهد ذخیره از راه دور Turborepo ویژگی، به ما امکان می دهد خروجی های ساخت را بین ساخت های CI حفظ کنیم.
در حالی که Vercel به عنوان مقصد پیشفرض ذخیرهسازی از راه دور Turbo عمل میکند، من به طور تصادفی به یک یافته قابل توجه برخوردم: setup-github-actions-caching-for-turbo – یک اکشن GitHub که ذخیره سازی مصنوعات ساخت را در خود GitHub Actions بدون هیچ هزینه اضافی امکانپذیر میکند!
در اینجا نحوه تنظیم آن آمده است:
- name: Configure Turbo cache
uses: dtinth/setup-github-actions-caching-for-turbo@v1
به همین سادگی. راه اندازی بدون دردسر است و به طور یکپارچه کار می کند.
استقرارها
صفحات Cloudflare
استقرار لحظات حیاتی در خط لوله CI/CD هستند، بنابراین من این مرحله را با انتقال از میزبانی Vercel به صفحات Cloudflare بهینه کردم.
صفحات Cloudflare به دلیل استقرار موازی آن با استفاده از wrangler CLI، ارائه میزبانی رایگان برای همیشه دارایی ثابت و هش کردن سریع فایل ها، به عنوان برنده آشکار ظاهر شد.
یک مزیت قابل توجه این است که CLI مورد استفاده برای استقرار در Cloudflare به طور خودکار دارایی ها را هش بررسی می کند. این بدان معنی است که اگر از تقسیم کد استفاده کنید، فقط تکه های تغییر یافته آپلود می شوند و در نتیجه استقرار سریعتر انجام می شود.
انتشار معنایی
برای سادهتر کردن استقرار، انتشار معنایی را معرفی کردم. این ابزار commit tagging را خودکار می کند و تغییرات را نسبت به نسخه قبلی ردیابی می کند. در نتیجه، استقرارها در حال حاضر تنها زمانی اتفاق میافتند که برچسبهای جدید وجود داشته باشند و در دقایق ارزشمند ما صرفهجویی کنند.
معیار
بنابراین، بیایید با اعداد صحبت کنیم.
در ابتدا، monorepo شامل سایتهای استاتیک Next.js، یک برنامه React CRA و یک Node.js API طولمدت خط لوله CI/CD خیرهکنندهای داشت. 26 دقیقه و 49 ثانیه، صرف نظر از تغییر کد. با رشد پروژه، این زمان فقط افزایش یافت.
با این حال، پس از اجرای تمام بهینهسازیهای عملکرد، در اینجا نتایجی به دست آوردهایم:
- بدون کش: 12 دقیقه و 6 ثانیه (کاهش قابل توجه 50٪!)
- با کش:
- Node.js: 7 دقیقه و 1 ثانیه (به دلیل ساختن و فشار دادن تصویر داکر هنوز نسبتاً کند است)
- برنامه React CRA: 3 دقیقه و 22 ثانیه
- برنامه Next.js: 1 دقیقه و 19 ثانیه
- زیرساخت / اسناد / تغییرات کار: فقط 1 دقیقه و 2 ثانیه
من میتوانم بگویم که اینها پیشرفتهای بسیار خوبی هستند: نه تنها مدت زمان خط لوله CI/CD خود را بیش از نصف کاهش دادیم، بلکه اکنون زمان پاسخگویی بسیار سریعتری برای تغییرات در هر بخشی از monorepo داریم. اکنون میتوانیم ویژگیها و رفع اشکالها را بسیار سریعتر و با استرس کمتر به تولید ارائه کنیم.
با تشکر برای خواندن!
نظر شما در مورد این نتایج چیست؟ هر نکته ای که می خواهید به اشتراک بگذارید؟ بیایید گفتگو را در نظرات زیر ادامه دهیم.
PS: اگر این را دوست داشتید – ممکن است کارهای دیگری را که اخیرا انجام داده ام دوست داشته باشید:
بهروزرسانیهای تغییرات لاگ مبتنی بر هوش مصنوعی در Slack، هر دوشنبه، با GitHub Actions
شما هرگز مجبور نخواهید بود دوباره با نظرات قدیمی TODO سر و کار داشته باشید
من را در توییتر دنبال کنید: @MaxPrilutsky