mise، Nix و devcontainers همگی مشکل «روی ماشین من کار می‌کند» را حل می‌کنند — فقط در روش آن اختلاف نظر دارند

عبارت «روی ماشین من کار می‌کند» دهه‌ها است که تیم‌های نرم‌افزاری را آزار می‌دهد. یک عضو جدید به تیم ملحق می‌شود، دو روز وقت صرف راه‌اندازی محیط خود می‌کند. یک توسعه‌دهنده ارشد پایتون را ارتقا می‌دهد، سه پروژه خراب می‌شود. CI به دلیل نسخه کتابخانه‌ای که هیچ‌کس به خاطر نداشت آن را قفل کند، شکست می‌خورد. ریشه مشکل همیشه یکسان است: محیط‌های توسعه‌دهنده وضعیتی، ضمنی و دستی هستند.

در سال 2026، این مشکل واقعاً حل شده است — اما «حل شده» به معنای سه ابزار رقیب با فلسفه‌های کاملاً متفاوت است. درک معاوضه‌ها مهارت واقعی است.

Tier 1 — mise: نقطه شروع عمل‌گرایانه

mise (که قبلاً rtx نام داشت) یک مدیر نسخه چندزبانه است که به زبان Rust نوشته شده است. این ابزار جایگزین asdf می‌شود و به دلیل هسته کامپایل‌شده و حل هم‌زمان افزونه‌ها، ۱۰ تا ۲۰ برابر سریع‌تر عمل می‌کند. از Node.js، Python، Go، Ruby، Java و ده‌ها زمان اجرای دیگر با یک ابزار پشتیبانی می‌کند.

مکانیزم اصلی فایل .mise.toml در ریشه پروژه است:

[tools]
node = "22.3.0"
python = "3.12.4"
go = "1.22.5"

[env]
DATABASE_URL = "postgres://localhost/myapp_dev"

با اجرای mise install، این ابزار پیکربندی را می‌خواند، نسخه‌های مشخص شده را در حافظه پنهان محلی با آدرس محتوا دانلود می‌کند (~/.local/share/mise/installs/) و آن‌ها را برای دایرکتوری جاری فعال می‌کند. دیگر خبری از دست‌کاری symlink یا ترفندهای shell فراتر از افزودن mise activate به پروفایل شما نیست.

تفاوت عملکرد نسبت به asdf قابل توجه است. نصب یک نسخه Node.js که asdf ۴۵ ثانیه زمان نیاز دارد تا آن را حل و نصب کند، mise در کمتر از ۴ ثانیه انجام می‌دهد. برای تیم‌هایی که مدام بین پروژه‌هایی با نیازهای زمان اجرای متفاوت جابجا می‌شوند، این به صرفه‌جویی واقعی در زمان منجر می‌شود.

آنچه mise انجام نمی‌دهد: این ابزار زمان‌های اجرای زبان را مدیریت می‌کند، نه کتابخانه‌های سیستمی را. اگر پروژه شما به نسخه خاصی از libpq، openssl یا ffmpeg نیاز داشته باشد، mise نمی‌تواند کمک کند. همچنین نمی‌تواند نسخه دقیق glibc در لینوکس یا Xcode toolchain دقیق در مک‌اواس را بازتولید کند. برای اکثر توسعه‌دهندگان برنامه، این شکاف‌ها مهم نیستند. برای بقیه، ادامه دهید.

Tier 2 — Nix و Nix Flakes: بازتولیدپذیری کامل

Nix یک مدیر بسته تابعی است که حول یک ایده ساخته شده است: هر بسته تابعی خالص از ورودی‌های خود است. با ورودی‌های یکسان، همیشه خروجی یکسان دریافت می‌کنید. بسته‌ها در /nix/store/ با مسیرهای مبتنی بر محتوا مانند /nix/store/ybmrfz0-nodejs-22.3.0/ ذخیره می‌شوند. دو بسته می‌توانند به نسخه‌های مختلف از یک کتابخانه بدون تداخل وابسته باشند زیرا به معنای واقعی در مسیرهای مختلف قرار دارند.

nixpkgs مخزن بسته‌ها است: بیش از ۹۰,۰۰۰ بسته، همه به صورت قابل بازتولید ساخته شده‌اند، که هر اکوسیستم زبان اصلی به علاوه ابزارهای سیستمی، فونت‌ها، پایگاه‌های داده و کامپایلرها را پوشش می‌دهد. این بزرگترین مجموعه بسته تک‌منبع در میان توزیع‌های لینوکس است.

Nix flakes (که در NixOS 23.11 تثبیت شد) یک مدل وابستگی مبتنی بر lockfile به خود Nix اضافه می‌کند. یک فایل flake.nix در ریشه پروژه دقیقاً commit nixpkgs را قفل می‌کند و یک devShell تعریف می‌کند:

{
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-24.05";

  outputs = { self, nixpkgs }: {
    devShells.x86_64-linux.default = nixpkgs.legacyPackages.x86_64-linux.mkShell {
      packages = with nixpkgs.legacyPackages.x86_64-linux; [
        nodejs_22
        python312
        go_1_22
        postgresql_16
        ffmpeg
      ];
    };
  };
}

با اجرای nix develop وارد یک shell می‌شوید که در آن هر ابزار دقیقاً مطابق مشخصات است — تا سطح نسخه‌های کتابخانه C. فایل flake.lock commit SHA nixpkgs را قفل می‌کند. شش ماه بعد، روی ماشینی دیگر، در کشوری دیگر، nix develop همان محیط را تولید می‌کند.

منحنی یادگیری صادقانه: Nix زبان تابعی خود را دارد (که آن هم Nix نامیده می‌شود)، مدل ذهنی خود برای نحوه کار ساخت‌ها، و مستنداتی که آشنایی با مفاهیم برنامه‌نویسی تابعی را فرض می‌کند. اکثر توسعه‌دهندگان ۱ تا ۲ هفته وقت صرف می‌کنند تا از نوشتن flake از پایه احساس راحتی کنند. ابزارهایی مانند devenv.sh و flake-parts این را به طور قابل توجهی کاهش می‌دهند، اما هیچ میانبری برای مفاهیم بنیادی وجود ندارد.

پاداش واقعی است. تیم‌هایی که از Nix flakes استفاده می‌کنند هیچ مشکل «انحراف محیطی» را در گزارش‌های پس از حادثه گزارش نمی‌دهند. CI همان shell nix develop را که در توسعه محلی استفاده می‌شود اجرا می‌کند. اعضای جدید تیم در روز اول nix develop را اجرا می‌کنند و در عرض چند دقیقه یک محیط کاری دارند، نه روزها.

Tier 3 — devcontainers: راه‌اندازی و توسعه ابری

devcontainers یک مشخصات باز (با پشتیبانی مایکروسافت و استفاده در VS Code و GitHub Codespaces) است که یک محیط توسعه را به عنوان یک کانتینر Docker تعریف می‌کند. پیکربندی در .devcontainer/devcontainer.json قرار دارد:

{
  "name": "My Project",
  "image": "mcr.microsoft.com/devcontainers/javascript-node:22",
  "features": {
    "ghcr.io/devcontainers/features/python:1": { "version": "3.12" },
    "ghcr.io/devcontainers/features/go:1": { "version": "1.22" }
  },
  "postCreateCommand": "npm install",
  "customizations": {
    "vscode": {
      "extensions": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"]
    }
  }
}

افزونه Remote - Containers VS Code فایل‌های محلی شما را به کانتینر متصل می‌کند و کل ویرایشگر شما را داخل آن اجرا می‌کند —سرورهای زبان، دیباگرها، ترمینال‌ها، همه در محیط کانتینر اجرا می‌شوند. GitHub Codespaces این را فراتر می‌برد: با کلیک روی «Open in Codespaces» کل محیط توسعه در زیرساخت ابری گیت‌هاب، نه لپ‌تاپ شما، اجرا می‌شود.

نقاط قوت devcontainers: راه‌اندازی واقعاً یک کلیکی است. انزواي امنیتی واقعی است — فایل‌سیستم کانتینر از ميزبان جدا است. برای کارهای سنگین محاسباتی (آموزش مدل‌های بزرگ، رندر ویدئو، کامپایل کدهای عظیم C++)، استفاده از Codespaces با ماشین‌های ابری ۳۲ هسته‌ای بهره‌وری واقعی است.

نقاط ضعف devcontainers: سربار Docker در سیستم‌عامل مک واقعی است. عملکرد فایل‌سیستم از طریق لایه VM Docker می‌تواند برای کارهای I/O-intensive مانند اجرای یک مجموعه تست بزرگ، ۲ تا ۳ برابر کندتر از حالت بومی باشد. همچنین به اتصال شبکه و عملیاتی بودن Docker وابسته هستید — که هیچکدام در تمام زمینه‌های توسعه تضمین نمی‌شود.

چگونه تیم‌های واقعی این ابزارها را ترکیب می‌کنند

انتخاب نادرست این است که یکی را انتخاب کرده و همه چیز را به آن بسپارید. تیم‌هایی که این را فهمیده‌اند معمولاً لایه‌بندی می‌کنند:

• mise برای جابجایی روزانه زبان. هر توسعه‌دهنده‌ای آن را دارد. این ابزار ۹۰٪ از سوالات «کدام نسخه Node/Python/Go» را با کمترین اصطکاک حل می‌کند. فایل .mise.toml به مخزن commit می‌شود.
• Nix flakes برای تیم‌هایی با نیازهای سطح سیستم. اگر به نسخه‌های خاصی از کتابخانه‌های بومی نیاز دارید، یا اگر در لینوکس و مک‌اواس می‌سازید و به محیط‌های یکسان نیاز دارید، flake.nix ارزش سرمایه‌گذاری را دارد. برخی تیم‌ها فقط برای CI از Nix استفاده می‌کنند و بازتولیدپذیری را در جایی که بیشتر اهمیت دارد به دست می‌آورند.
• devcontainers برای راه‌اندازی و برابری CI. پیکربندی .devcontainer/ برای روز اول اعضای جدید و برای دسترسی به GitHub Codespaces نگه داشته می‌شود. این جایگزین ابزارهای توسعه محلی نیست اما یک fallback تضمینی فراهم می‌کند.

یک مثال عینی: یک تیم ۱۲ نفره از توسعه‌دهندگان از mise به صورت محلی برای جابجایی سریع نسخه استفاده می‌کند، از Nix flakes در CI (GitHub Actions دستور nix develop --command make test را اجرا می‌کند)، و یک devcontainer برای دسترسی به Codespaces زمانی که اعضای تیم در سفر هستند یا روی ماشین‌های شرکتی محدودشده کار می‌کنند.

معاوضه‌های صادقانه

• mise: در ۳۰ ثانیه نصب می‌شود، همه جا کار می‌کند، ۹۰٪ مشکلات واقعی را حل می‌کند، اما نمی‌تواند کتابخانه‌های سیستمی را مدیریت کند یا بازتولیدپذیری باینری زیر سطح زمان اجرای زبان را تضمین کند.
• Nix: قدرتمندترین گزینه موجود است، محیط‌های واقعاً قابل بازتولید بیت‌به‌بیت تولید می‌کند، همه لایه‌های پشته را پوشش می‌دهد، اما نیاز به سرمایه‌گذاری واقعی برای یادگیری دارد و می‌تواند کارهای ساده (افزودن وابستگی یک بسته جدید) را تا زمانی که مفاهیم جا بیفتند، سنگین جلوه دهد.
• devcontainers: کمترین مانع برای ورود به راه‌اندازی، بومی ابر، بومی VS Code، اما سربار Docker را به همراه دارد، نیاز به اتصال دارد و می‌تواند جزئیات محیط را به گونه‌ای پنهان کند که اشکال‌زدایی را دشوارتر کند.

از کجا شروع کنیم

اگر تیم شما کمتر از ۵ توسعه‌دهنده دارد و درد «همه روی نسخه‌های مختلف Node/Python هستند» است: همین امروز mise را نصب کنید، یک .mise.toml commit کنید، تمام. شما ۹۰٪ شکایت‌های محیطی را در یک بعدازظهر برطرف خواهید کرد.

اگر تیم شما بیش از ۱۰ توسعه‌دهنده دارد، محصول را به لینوکس ارسال می‌کنید، وابستگی‌های کتابخانه بومی دارید و انحراف محیطی باعث حوادث واقعی تولید شده است: روی Nix flakes سرمایه‌گذاری کنید. ۲ تا ۳ هفته برای یک توسعه‌دهنده بودجه در نظر بگیرید تا متخصص Nix تیم شود. بازگشت سرمایه واقعی است.

اگر مشکل اصلی شما زمان راه‌اندازی است، زیاد با گیت‌هاب کار می‌کنید یا به انزوای امنیتی برای پیمانکاران نیاز دارید: devcontainers اهرم مناسب است. آنها با mise و Nix به خوبی ترکیب می‌شوند — می‌توانید mise را درون یک devcontainer اجرا کنید، یا تصویر devcontainer خود را از یک Nix derivation بسازید.

مشکل «روی ماشین من کار می‌کند» حل شده است. سوال باقی‌مانده این است که کدام راه‌حل با محدودیت‌های واقعی تیم شما مطابقت دارد — و آیا حاضرید هزینه‌های یادگیری را که گزینه‌های قدرتمندتر نیاز دارند، بپردازید.