نحوه پیکربندی پیش‌ساخت‌های GitHub Codespaces

نصب‌های وابستگی سنگین (مثلاً npm ci ) را به onCreateCommand منتقل کنید تا در طول پیش‌ساخت اجرا شوند.

مراحل کامپایل مانند npm run build در updateContentCommand قرار دهید تا مصنوعات ساخت را از قبل آماده کنید.

postCreateCommand فقط برای تنظیمات وابسته به رمز یا تنظیمات خاص کاربر رزرو کنید .

پیش‌ساخت‌ها را از مسیر تنظیمات → فضاهای کد → پیش‌ساخت‌ها برای شاخه‌ی هدف خود فعال کنید .

تریگر را برای main روی «هر فشار» و برای شاخه‌های ویژگی روی «فقط تغییر پیکربندی» تنظیم کنید .

مناطق پیش‌ساخته را مطابق با توزیع جغرافیایی تیم خود انتخاب کنید .

یک کار اعتبارسنجی devcontainers/ci به گردش کار PR خود که در مسیرهای .devcontainer/** فیلتر شده است، اضافه کنید .

موفقیت پیش‌ساخت را در رابط کاربری گیت‌هاب تأیید کنید و تأیید کنید که فضاهای کد جدید برچسب «آماده‌ی پیش‌ساخت» را نشان می‌دهند.

یک تیم ۱۰ نفره از توسعه‌دهندگان که هر کدام تقریباً سه بار در روز فضاهای کد را راه‌اندازی می‌کنند، می‌توانند به راحتی چهار ساعت در مجموع را صرف انتظار برای قابل استفاده شدن محیط‌ها کنند. این راهنما به طور کامل مراحل راه‌اندازی را شرح می‌دهد: نحوه کار پیش‌ساخت‌ها، یک devcontainer.json آماده برای تولید، ادغام CI/CD از طریق GitHub Actions و جزئیات هزینه و صورتحساب که اسناد خود GitHub در شش صفحه پراکنده است.

فهرست مطالب

مسئله‌ی ۸ دقیقه‌ای

تصور کنید: یک مشارکت‌کننده جدید، محیط گیت‌هاب کداسپیسز را برای پروژه شما باز می‌کند و ترمینال بلافاصله شروع به اجرای npm install می‌کند. سه دقیقه می‌گذرد. ​​پنج دقیقه. هشت دقیقه. تا زمانی که اجرای پیکربندی devcontainer تمام شود، آنها زمینه را از دست داده‌اند، دو بار تلفن خود را بررسی کرده‌اند و از نظر ذهنی به چیز دیگری پرداخته‌اند. این تجربه پیش‌فرض زمانی است که محیط توسعه ابری شما فاقد پیش‌ساخت‌ها باشد.

محاسبات خیلی سریع انجام می‌شود. یک تیم ۱۰ نفره از توسعه‌دهندگان که هر کدام تقریباً سه بار در روز فضاهای کد را اجرا می‌کنند، می‌توانند به راحتی چهار ساعت در مجموع را صرف انتظار برای قابل استفاده شدن محیط‌ها کنند. و «قابل استفاده» در اینجا به معنای اتصال کامل VS Code، اتمام تمام دستورات چرخه حیات و بارگذاری افزونه‌ها است. نه فقط شروع کانتینر. لحظه‌ای که یک توسعه‌دهنده می‌تواند واقعاً کد را تایپ کند و بازخورد linting را دریافت کند.

پیش‌ساخت‌های GitHub Codespaces این مشکل را با اجرای کل فرآیند راه‌اندازی محیط از قبل و ذخیره نتیجه برطرف می‌کنند. وقتی یک توسعه‌دهنده یک فضای کد ایجاد می‌کند، به جای ساختن از ابتدا، محیط از پیش محاسبه‌شده را دریافت می‌کند. در یک مونوریپو Node.js که من با تقریباً ۱۲۰۰ وابستگی و یک مرحله کامپایل TypeScript مدیریت می‌کنم، اندازه‌گیری کردیم که زمان ایجاد از کمی بیش از ۷ دقیقه به حدود ۲۵ ثانیه پس از فعال کردن پیش‌ساخت‌ها با جداسازی مناسب دستورات چرخه عمر کاهش یافته است.

در یک مونوریپو Node.js که من با تقریباً ۱۲۰۰ وابستگی و یک مرحله کامپایل TypeScript مدیریت می‌کنم، اندازه‌گیری کردیم که زمان ایجاد از کمی بیش از ۷ دقیقه به حدود ۲۵ ثانیه پس از فعال کردن پیش‌ساخت‌ها با جداسازی مناسب دستورات چرخه عمر کاهش یافته است.

این راهنما به طور کامل مراحل راه‌اندازی را شرح می‌دهد: نحوه کار پیش‌ساخت‌ها، یک devcontainer.json آماده برای تولید، ادغام CI/CD از طریق GitHub Actions و جزئیات هزینه و صورتحساب که مستندات خود GitHub در شش صفحه پراکنده است.

نحوه عملکرد پیش‌ساخت‌های Codespaces

بدون پیش‌ساخت‌ها، ایجاد یک فضای کد از یک توالی قابل پیش‌بینی و کند پیروی می‌کند: گیت‌هاب تصویر کانتینر مشخص‌شده در پیکربندی devcontainer شما را دریافت می‌کند، مراحل ساخت Dockerfile را اجرا می‌کند، دستورات چرخه عمر مانند onCreateCommand و updateContentCommand (که معمولاً وابستگی‌ها را نصب و کد را کامپایل می‌کنند) را اجرا می‌کند، افزونه‌های VS Code را دانلود می‌کند و در نهایت یک محیط آماده را در اختیار شما قرار می‌دهد.

یک پیش‌ساخت با بارگذاری اولیه‌ی بخش‌های گران‌قیمت، این توالی را تغییر می‌دهد. وقتی یک پیش‌ساخت را برای یک شاخه‌ی خاص پیکربندی می‌کنید، گیت‌هاب تنظیمات کامل devcontainer را روی کد آن شاخه، قبل از زمان اجرا می‌کند که توسط رویدادهایی که شما تعریف می‌کنید (اعمال تغییرات، تغییرات پیکربندی یا یک برنامه) فعال می‌شود. نتیجه، یک محیط پیش‌ساخته است که ایجادهای فضای کد آینده می‌توانند از آن استفاده کنند و مراحل نصب و ساخت را به طور کامل نادیده بگیرند.

مدل ذهنی: devcontainer.json تعریف می‌کند که چه چیزی ساخته شود. پیکربندی پیش‌ساخت در تنظیمات مخزن شما مشخص می‌کند که چه زمانی آن را بسازید. اگر هیچ پیش‌ساخت معتبری برای شاخه و منطقه‌ای که توسعه‌دهنده درخواست می‌کند وجود نداشته باشد، Codespaces به ایجاد استاندارد برمی‌گردد. پیش‌ساخت‌ها یک لایه بهینه‌سازی هستند، نه یک وابستگی سخت.

چه چیزهایی در پیش‌ساخت لحاظ می‌شود؟

محیط از پیش ساخته شده شامل هر چیزی است که در طول چرخه حیات راه‌اندازی اجرا می‌شود:

بسته‌های سطح سیستم عامل که از طریق features یا یک Dockerfile سفارشی نصب می‌شوند

وابستگی‌های نصب‌شده توسط onCreateCommand و updateContentCommand

مصنوعات تولید شده در طول آن دستورات را بسازید

افزونه‌های VS Code که در customizations.vscode.extensions تعریف شده‌اند

وضعیت کامل سیستم فایل در انتهای توالی چرخه حیات

یک نکته‌ی ظریف که ارزش دانستن دارد: افزونه‌ها در پیش‌ساخت گنجانده شده‌اند، اما برخی از افزونه‌ها در اولین فعال‌سازی، مقداردهی اولیه‌ی اضافی انجام می‌دهند. افزونه‌هایی که مراحل پس از نصب سنگینی دارند (مثلاً سرورهای زبان، فایل‌های باینری را دانلود می‌کنند) ممکن است در اولین اتصال چند ثانیه‌ای به زمان اضافه کنند.

فایل devcontainer.json پایه (قبل از بهینه‌سازی)

در اینجا یک devcontainer.json معمولی و بهینه نشده برای یک پروژه Node.js/TypeScript را مشاهده می‌کنید:

 // Typical devcontainer.json — no prebuild awareness { "name": "My Project", "image": "mcr.microsoft.com/devcontainers/typescript-node:20", "postCreateCommand": "npm install && npm run build", "customizations": { "vscode": { "extensions": [ "dbaeumer.vscode-eslint", "esbenp.prettier-vscode" ] } } }

این پیکربندی تمام کارهای سنگین را به postCreateCommand محول می‌کند. هر بار که کسی یک فضای کد بدون پیش‌ساخت ایجاد می‌کند، کانتینر یک npm install (رفع درخت وابستگی از ابتدا، بررسی آسیب‌پذیری‌ها، نوشتن node_modules ) و به دنبال آن یک ساخت TypeScript را اجرا می‌کند. در یک پروژه متوسط، این زمان فقط برای نصب وابستگی ۳ تا ۵ دقیقه است، به علاوه ۱ تا ۲ دقیقه دیگر برای کامپایل.

این چیزی است که مردم از دست می‌دهند: postCreateCommand در طول فرآیند پیش‌ساخت اجرا نمی‌شود . این فرآیند فقط پس از ایجاد فضای کد توسط توسعه‌دهنده اجرا می‌شود. بنابراین قرار دادن کار نصب سنگین در اینجا به این معنی است که کار هرگز از قبل آماده نمی‌شود. این اتفاق در زمان ساخت رخ می‌دهد، صرف نظر از اینکه پیش‌ساخت‌ها فعال باشند یا خیر. دقیقاً به همین دلیل است که جداسازی دستورات چرخه حیات بسیار مهم است. و postStartCommand ، یکی دیگر از قلاب‌های چرخه حیات، پس از شروع کانتینر، از جمله در بازسازی‌ها و راه‌اندازی مجددها، اجرا می‌شود. اگر کار سنگین را در قلاب اشتباه قرار دهید، راه‌اندازی مجدد را به همان اندازه ایجاد اولیه دردناک می‌کنید.

نکته‌ای که مردم از دست می‌دهند این است: postCreateCommand در طول فرآیند پیش‌ساخت اجرا نمی‌شود . این دستور فقط پس از اینکه توسعه‌دهنده فضای کد خود را ایجاد کرد، اجرا می‌شود. بنابراین قرار دادن کار نصب سنگین در اینجا به این معنی است که کار هرگز از قبل آماده نمی‌شود.

devcontainer.json بهینه شده برای Prebuilds

نسخه بهینه‌شده، کار را در میان هوک‌های چرخه عمر صحیح تفکیک می‌کند، الزامات منابع را به صراحت اعلام می‌کند و پورت فورواردینگ را برای سناریوهای توسعه رایج پیکربندی می‌کند:

 { "name": "My Project — Prebuilt", "image": "mcr.microsoft.com/devcontainers/typescript-node:20", "features": { "ghcr.io/devcontainers/features/github-cli:1": {}, "ghcr.io/devcontainers/features/docker-in-docker:2": {} }, "onCreateCommand": "npm ci --prefer-offline --no-audit", "updateContentCommand": "npm run build", "postCreateCommand": "echo 'Environment ready.'", "postAttachCommand": "git fetch --all --prune", "customizations": { "vscode": { "extensions": [ "dbaeumer.vscode-eslint", "esbenp.prettier-vscode", "GitHub.copilot", "eamodio.gitlens" ], "settings": { "editor.formatOnSave": true, "typescript.preferences.importModuleSpecifier": "relative" } } }, "hostRequirements": { "cpus": 4, "memory": "8gb", "storage": "32gb" }, "forwardPorts": [3000, 5432], "portsAttributes": { "3000": { "label": "App", "onAutoForward": "openBrowser" } } }

بگذارید توضیح دهم چه چیزی تغییر کرده و چرا هر تصمیم مهم است.

چرا جداسازی دستورات چرخه حیات اهمیت دارد؟

مشخصات devcontainer چندین قلاب چرخه عمر را تعریف می‌کند که در نقاط متمایزی اجرا می‌شوند. انجام صحیح این جداسازی، بزرگترین عامل در اثربخشی پیش‌ساخت است:

نکته کلیدی اینجاست: onCreateCommand و updateContentCommand در طول فرآیند پیش‌ساخت اجرا می‌شوند، بنابراین نتایج آنها در محیط پیش‌ساخته ذخیره می‌شود. postCreateCommand فقط پس از اینکه توسعه‌دهنده فضای کد خود را ایجاد کرد، اجرا می‌شود و آن را به مکان مناسبی برای هر چیزی که نیاز به دسترسی به اسرار کاربر Codespaces (توکن‌های رجیستری خصوصی، کلیدهای API) دارد، تبدیل می‌کند. postAttachCommand هر بار که کسی متصل می‌شود، از جمله اتصال مجدد، اجرا می‌شود، بنابراین باید سبک بماند.

همچنین postStartCommand وجود دارد که هر بار که فضای کد شروع می‌شود (از جمله پس از یک چرخه توقف/راه‌اندازی مجدد) اجرا می‌شود. کارهای سنگین را در آنجا قرار ندهید. این کار نه تنها ایجاد اولیه، بلکه هر راه‌اندازی مجدد را کند می‌کند.

این رویکرد زمانی که نصب وابستگی شما نیاز به احراز هویت دارد (مثلاً یک رجیستری خصوصی npm) با شکست مواجه می‌شود. شما نمی‌توانید npm ci را در onCreateCommand قرار دهید زیرا محیط‌های پیش‌ساخته به اسرار Codespaces سطح کاربر دسترسی ندارند. راه حل: یک توکن رجیستری فقط خواندنی را به عنوان یک راز سطح مخزن که برای محیط‌های پیش‌ساخته در دسترس است، پیکربندی کنید (اسرار Codespaces سطح مخزن را می‌توان از طریق پیکربندی پیش‌ساخته برای پیش‌ساخته‌ها قابل دسترسی کرد)، یا بپذیرید که مرحله نصب احراز هویت شده باید در postCreateCommand قرار گیرد.

npm ci در مقابل npm نصب در Prebuilds

npm ci انتخاب مناسبی برای پیش‌ساخت‌ها است زیرا قطعی است: node_modules به طور کامل حذف می‌کند و دقیقاً آنچه را که در package-lock.json است نصب می‌کند، بدون هیچ گونه تغییر درخت یا به‌روزرسانی فایل قفل. این تضمین می‌کند که پیش‌ساخت هر بار نتیجه یکسانی را تولید می‌کند.

پرچم --prefer-offline به npm می‌گوید که از حافظه پنهان محلی خود به طور گسترده استفاده کند، که باعث کاهش تماس‌های شبکه در طول پیش‌ساخت می‌شود. --no-audit بررسی آسیب‌پذیری را در طول نصب نادیده می‌گیرد. این به معنای نادیده گرفتن امنیت نیست. این کار بررسی را به خط لوله CI شما که به آن تعلق دارد موکول می‌کند، به جای اینکه 10 تا 15 ثانیه به هر اجرای پیش‌ساخت اضافه کند.

پیکربندی محرک‌های پیش‌ساخته در تنظیمات مخزن

پیکربندی پیش‌ساخت (Prebuild) در تنظیمات مخزن شما در مسیر Settings > Codespaces > Prebuilds قرار دارد. فرآیند راه‌اندازی ساده است:

شاخه‌ای را برای پیش‌ساخت انتخاب کنید.

فایل پیکربندی devcontainer را انتخاب کنید (مربوط به مخازن چند devcontainer، که در آن هر پیکربندی می‌تواند پیش‌ساخت مخصوص به خود را داشته باشد).

شرایط فعال‌سازی را انتخاب کنید: پیش‌ساخت‌ها می‌توانند در صورت ارسال درخواست به شاخه، فقط در صورت تغییرات پیکربندی یا در صورت ترکیبی از این موارد فعال شوند.

مناطقی را انتخاب کنید که پیش‌ساخت‌ها باید در آنها در دسترس باشند. اگر تیم شما در ایالات متحده و اروپا توزیع شده است، پیش‌ساخت را در هر دو منطقه انجام دهید. یک توسعه‌دهنده در فرانکفورت که یک فضای کد را از پیش‌ساختی که فقط در شرق ایالات متحده ذخیره شده است، ایجاد می‌کند، یا به ایجاد استاندارد برمی‌گردد یا تأخیر بین منطقه‌ای را تحمل می‌کند.

تنظیم میزان نگهداری: چند نسخه از پیش ساخته شده باید نگه داشته شود.

استراتژی پیشنهادی برای فعال‌سازی

برای main : با هر بار فشار دادن، فعال می‌شود. این کار پیش‌ساخت را برای مشارکت‌کنندگان جدید، بررسی‌کنندگان روابط عمومی و هر کسی که یک محیط سریع برای آزمایش چیزی راه‌اندازی می‌کند، تازه نگه می‌دارد. پیش‌ساخت main همیشه آماده، پیکربندی با بالاترین ارزش است.

برای شاخه‌های ویژگی: فقط در صورت تغییر پیکربندی فعال می‌شود. بازسازی پیش‌ساخت در هر شاخه ویژگی، محاسبات را با حداقل سود می‌سوزاند، زیرا پیکربندی devcontainer به ندرت در اواسط ویژگی تغییر می‌کند.

شاخه‌های انتشار (release branchs) شایسته‌ی همان رفتاری هستند که با main : trigger در هر بار اجرا (push) می‌شود. گردش‌های کاری Hotfix نیازمند ایجاد سریع محیط هستند و شاخه‌های انتشار (release branchs) به ندرت تغییر می‌کنند، به طوری که هزینه محاسباتی ناچیز است.

اگر هیچ پیش‌ساخت معتبری برای یک ترکیب شاخه و منطقه مشخص وجود نداشته باشد، Codespaces به ایجاد استاندارد برمی‌گردد. توسعه‌دهندگان خطایی نمی‌بینند؛ آنها فقط مدت بیشتری منتظر می‌مانند. ارزش دارد قبل از اینکه فرض کنید تیم از مزیت سرعت بهره‌مند می‌شود، تأیید کنید که پیش‌ساخت شما واقعاً موفق بوده است.

ادغام پیش‌ساخت‌ها با GitHub Actions CI/CD

اعتبارسنجی پیکربندی devcontainer شما در CI از ارسال یک پیکربندی معیوب به main و ایجاد یک prebuild ناموفق که هیچ کس تا چند روز متوجه آن نمی‌شود، جلوگیری می‌کند. devcontainers/ci GitHub Action، devcontainer را می‌سازد و به صورت اختیاری یک دستور را درون آن اجرا می‌کند و یک حلقه بازخورد سریع در مورد PRها به شما می‌دهد.

 name: Codespace Prebuild CI
on: pull_request: paths: - '.devcontainer/**' - 'package-lock.json' push: branches: [main] paths: - '.devcontainer/**' - 'package-lock.json'
jobs: validate-devcontainer: runs-on: ubuntu-latest if: github.event_name == 'pull_request' steps: - uses: actions/checkout@v4 - name: Validate devcontainer.json uses: devcontainers/ci@v0.3 with: runCmd: node --version && npm --version push: never
 notify-prebuild-ready: runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' && github.event_name == 'push' steps: - uses: actions/checkout@v4 - name: Confirm devcontainer builds uses: devcontainers/ci@v0.3 with: runCmd: echo "Devcontainer validated. Repo prebuild trigger will fire." push: never

نکته‌ای در مورد راه‌اندازی پیش‌ساخت برنامه‌نویسی‌شده: رابط خط فرمان gh codespace در حال حاضر زیردستور prebuild create نمایش نمی‌دهد. راه‌اندازی پیش‌ساخت به‌طور خودکار از طریق پیکربندی پیش‌ساخت مخزن هنگام وقوع رویدادهای منطبق (ارسال به شاخه پیکربندی‌شده) اتفاق می‌افتد. اگر به کنترل برنامه‌نویسی نیاز دارید، GitHub REST API برای Codespaces نقاط پایانی برای مدیریت پیکربندی‌های پیش‌ساخت ارائه می‌دهد، اما راه‌اندازی یک اجرای پیش‌ساخت ad-hoc از طریق محرک‌های داخلی بهتر از فراخوانی CLI عمل می‌کند. مخزن devcontainers/ci action را برای آخرین برچسب انتشار بررسی کنید. پین کردن به v0.3 در زمان نگارش این مطلب موجود است، اما نسخه‌های جدیدتر ممکن است در دسترس باشند.

فیلتر کردن مسیر برای تریگرهای پیش ساخته کارآمد

فیلتر paths در گردش کار بالا بیش از آنچه به نظر می‌رسد اهمیت دارد. بدون آن، هر تغییر README یا به‌روزرسانی مستندات، یک کار اعتبارسنجی devcontainer را آغاز می‌کند. مسیرهایی که در واقع بر محیط توسعه شما تأثیر می‌گذارند عبارتند از .devcontainer/** ، package-lock.json (یا yarn.lock ، pnpm-lock.yaml )، هر Dockerfile که توسط devcontainer به آن ارجاع داده می‌شود، و فایل‌های وابستگی خاص زبان مانند requirements.txt یا Gemfile.lock .

اندازه‌گیری تأثیر: قبل و بعد

ما این پیکربندی را روی یک پروژه Node.js/TypeScript با ۱۲۴۷ وابستگی، یک ساخت ۴۵ ثانیه‌ای TypeScript و چهار افزونه VS Code آزمایش کردیم. فضای کد از یک ماشین ۴ هسته‌ای در منطقه غرب ایالات متحده استفاده می‌کرد. ما با اضافه کردن date +%s مهر زمانی به هر قلاب چرخه عمر، اندازه‌گیری کردیم:

این اعداد مختص این پروژه و نوع دستگاه هستند. یک پروژه پایتون با مرحله pip install بزرگ یا یک پروژه جاوا با ساخت Gradle، خطوط پایه متفاوتی خواهند داشت. با این حال، این نسبت‌ها معمولاً ثابت می‌مانند: محیط‌های پیش‌ساخته به طور مداوم ۸۰ تا ۹۵ درصد کاهش در زمان ایجاد ارائه می‌دهند زیرا نصب وابستگی‌ها و کامپایل کردن بر چرخه عمر تسلط دارند. اعداد شما بسته به اندازه پروژه، نوع دستگاه و منطقه متفاوت خواهد بود.

محیط‌های پیش‌ساخته به طور مداوم ۸۰ تا ۹۵ درصد کاهش در زمان ایجاد را ارائه می‌دهند، زیرا نصب و کامپایل وابستگی‌ها بر چرخه حیات غالب است.

برای بررسی اینکه آیا فضای کد شما واقعاً از پیش‌ساخت استفاده کرده است یا خیر، هنگام ایجاد یک فضای کد از صفحه مخزن GitHub، برچسب "Prebuild ready" را جستجو کنید. وضعیت پیش‌ساخت همچنین در تنظیمات > Codespaces > Prebuilds قابل مشاهده است، جایی که می‌توانید آخرین پیش‌ساخت موفق را برای هر شاخه و منطقه پیکربندی شده مشاهده کنید. همچنین می‌توانید گزارش ایجاد را در ترمینال فضای کد برای نشانگرهایی که مراحل چرخه عمر را رد کرده‌اند، بررسی کنید.

مدیریت هزینه و نکات کلیدی

هزینه‌های محاسباتی پیش از ساخت

پیش‌ساخت‌ها زمان محاسباتی Codespaces (که به ازای هر ساعت هسته با همان نرخ اجرای codespaceها محاسبه می‌شود) و فضای ذخیره‌سازی Codespaces (که به ازای هر گیگابایت-ماه محاسبه می‌شود) را مصرف می‌کنند. این جدا از دقایق GitHub Actions است. می‌خواهم روی این نکته تأکید کنم زیرا این یک نقطه مشترک سردرگمی است. هر اجرای پیش‌ساخت، زمان محاسباتی معادل اجرای کل تنظیمات محیط روی نوع دستگاه پیکربندی شده، به علاوه فضای ذخیره‌سازی برای مصنوعات پیش‌ساخت حفظ شده را مصرف می‌کند. یک مونوریپو با یک مرحله نصب ۱۵ دقیقه‌ای که با هر بار ارسال به main (مثلاً ۲۰ بار ارسال در روز) فعال می‌شود، هزینه قابل توجهی را اضافه می‌کند.

توصیه‌ها: از فیلترهای مسیر در پیکربندی تریگر پیش‌ساخت خود استفاده کنید تا از بازسازی در زمانی که فقط فایل‌های غیرمحیطی تغییر می‌کنند، جلوگیری شود. شاخه‌های پیش‌ساخت را به دو یا سه محدود کنید. میزان نگهداری را روی دو نسخه پیش‌ساخت تنظیم کنید، مگر اینکه نیاز به بازگرداندن خاصی داشته باشید. سازمان‌ها می‌توانند محدودیت‌های هزینه و انواع ماشین‌های مجاز را در سیاست‌های Codespaces خود تعیین کنند تا از هزینه‌های غیرمنتظره جلوگیری شود. حساب‌های شخصی GitHub Free و Pro شامل یک سهمیه ماهانه برای استفاده از Codespaces هستند. پیش‌ساخت‌ها برای مخازن شخصی در این سهمیه محاسبه می‌شوند، در حالی که مخازن متعلق به سازمان برای سازمان صورتحساب صادر می‌کنند.

مشکلات رایج

اسرار در محیط‌های پیش‌ساخته : محیط‌های پیش‌ساخته به اسرار Codespaces سطح کاربر دسترسی ندارند. اگر onCreateCommand شما نیاز به احراز هویت داشته باشد (رجیستری خصوصی npm، ابزار دارای مجوز)، در طول پیش‌ساخته با شکست مواجه خواهد شد. مراحل وابسته به اسرار را به postCreateCommand منتقل کنید، که فقط زمانی اجرا می‌شود که یک توسعه‌دهنده فضای کد را ایجاد کند و اسرار در دسترس باشند. اسرار سطح مخزن را می‌توان از طریق پیکربندی پیش‌ساخته در دسترس قرار داد، اگر به مواردی مانند دسترسی به رجیستری خصوصی نیاز دارید.

پیش‌ساخت‌های قدیمی : اگر محرک‌های پیش‌ساخت شما بیش از حد محافظه‌کارانه باشند (تغییر پیکربندی فقط در شاخه‌ای که به‌روزرسانی‌های وابستگی مکرر را از طریق Dependabot دریافت می‌کند)، توسعه‌دهندگان ممکن است یک محیط پیش‌ساخته قدیمی دریافت کنند. Codespaces برای تطبیق، updateContentCommand اجرا می‌کند که سریع‌تر از یک بازسازی کامل است اما همچنان زمان انتظار را افزایش می‌دهد. برای شاخه‌هایی که PRهای به‌روزرسانی وابستگی خودکار دریافت می‌کنند، استفاده از محرک "در هر فشار" را در نظر بگیرید.

حجم ذخیره‌سازی : هر نسخه پیش‌ساخته حفظ‌شده، فضای ذخیره‌سازی را اشغال می‌کند. برای پروژه‌ای با دایرکتوری node_modules بزرگ و خروجی کامپایل‌شده، دو نسخه حفظ‌شده ممکن است 10 تا 20 گیگابایت فضا اشغال کنند. در داشبورد صورتحساب سازمان، میزان استفاده از فضای ذخیره‌سازی Codespaces خود را زیر نظر داشته باشید.

در دسترس بودن منطقه : پیش‌ساخت‌ها مختص منطقه هستند. اگر پیش‌ساخت‌ها را فقط برای غرب ایالات متحده پیکربندی کنید، اما یک توسعه‌دهنده فضای کدی ایجاد کند که به طور پیش‌فرض روی غرب اروپا باشد، از پیش‌ساخت بهره‌مند نخواهد شد. مطمئن شوید که مناطق پیش‌ساخت شما با جایی که اعضای تیم شما واقعاً فضاهای کد ایجاد می‌کنند، مطابقت داشته باشند.

چک لیست مرجع سریع

دستورات چرخه عمر جداگانه: نصب‌های سنگین در onCreateCommand ، کامپایل در updateContentCommand ، مراحل وابسته به رمز در postCreateCommand ، وظایف سبک و تکراری در postAttachCommand .

npm ci --prefer-offline --no-audit (یا معادل آن، نصب قطعی) در onCreateCommand استفاده کنید.

پیش‌ساخت‌ها را در main با محرک‌های هر فشار فعال کنید.

پیش‌ساخت‌ها را روی شاخه‌های ویژگی با تریگرهای فقط-تغییر-پیکربندی فعال کنید.

مناطق پیش‌ساخته را مطابق با توزیع جغرافیایی تیم خود انتخاب کنید.

یک کار اعتبارسنجی devcontainers/ci به گردش کار PR خود اضافه کنید، که به مسیرهای مربوطه فیلتر شده باشد.

میزان نگهداری پیش‌ساخت را روی ۲ نسخه تنظیم کنید.

میزان استفاده از فضای ذخیره‌سازی و محاسبات Codespaces را ماهانه (نه بر اساس دقایق استفاده از Actions) رصد کنید.

هرگز دستورات وابسته به مخفی را در onCreateCommand یا updateContentCommand قرار ندهید.

قبل از اینکه از مزایای تیم استفاده کنید، موفقیت پیش‌ساخت را در رابط کاربری گیت‌هاب تأیید کنید.

بازده مرکب

این پیکربندی یک سرمایه‌گذاری یک‌باره است. زمانی که دستورات چرخه حیات devcontainer.json به درستی تفکیک شوند و محرک‌های پیش‌ساخت تنظیم شوند، هر توسعه‌دهنده در تیم، در هر اجرای فضای کد، در هر شاخه پیکربندی‌شده، در هر منطقه پیکربندی‌شده، بدون تغییر هیچ چیزی در مورد نحوه کار آنها، ایجاد محیط را در کمتر از 30 ثانیه دریافت می‌کند.

بهترین محیط توسعه، محیطی است که هیچ‌کس مجبور نباشد به آن فکر کند. پیش‌ساخت‌ها، محیط را نامرئی می‌کنند.

برای یک تیم ۱۰ نفره، این تفاوت بین ۴ ساعت زمان انتظار روزانه جمعی و تقریباً ۵ دقیقه است. با رشد تیم، صرفه‌جویی‌ها بیشتر می‌شود: ۲۰ توسعه‌دهنده، ۵۰ توسعه‌دهنده، مشارکت‌کنندگان متن‌باز که هرگز ملاقات نکرده‌اید. بهترین محیط توسعه، محیطی است که هیچ‌کس مجبور نباشد به آن فکر کند. پیش‌ساخت‌ها محیط را نامرئی می‌کنند. تأیید کنید که پیش‌ساخت‌های شما در رابط کاربری GitHub موفق هستند، تأیید کنید که فضاهای کد جدید برچسب پیش‌ساخت را نشان می‌دهند و سپس کاملاً از فکر کردن به آن دست بردارید.

تست مسدودسازی تبلیغات