حاويات التطوير (Dev Containers): كيف تخلصنا من كابوس “إنها تعمل على جهازي”؟

بتذكر قبل كم سنة، كنا شغالين على مشروع لعميل مهم، وكان الفريق موزع بين شباب بتشتغل على ويندوز، وناس على ماك، وأنا طبعاً كنت على لينكس. المشروع كان فيه شوية تعقيدات: الواجهة الخلفية مكتوبة بلغة Python مع Django، والواجهة الأمامية بـ React، وقاعدة بيانات PostgreSQL، وكمان Redis للكاش. يا جماعة، الكابوس الحقيقي ما كان في كتابة الكود، الكابوس كان في تشغيل المشروع!

كل عضو جديد في الفريق كان يقضي يومين أو ثلاثة بس وهو يحاول يثبت كل المكتبات والإعدادات الصحيحة. واحد تطلعله مشكلة في نسخة بايثون، والثاني مشكلة في تعريفات الدرايفر تبع قاعدة البيانات على ويندوز، والثالث عنده نسخة Node.js أقدم من اللازم. كنت أقضي نص وقتي أحل مشاكل إعداد بيئة العمل بدل ما أكتب كود. وذروة المأساة كانت لما يجي حدا من الشباب ويقولي: “أبو عمر، الكود ضرب عندي”، وأرد عليه: “كيف يا زلمة؟ ما هو شغال عندي زي الحلاوة!”. وهون تبدأ رحلة البحث عن السبب اللي هو 99% من المرات مشكلة في بيئة التطوير ومش في الكود نفسه. بصراحة، كان وضع “كل مين إيده إله”. لحد ما اكتشفنا الحل اللي غير طريقة شغلنا كلها: حاويات التطوير.

ما هو كابوس “إنها تعمل على جهازي”؟

خلونا نكون صريحين، كل مبرمج فينا إما قال هالجملة أو سمعها. هذه الجملة هي إعلان عن بداية ساعات طويلة من التنبيش والبحث عن مشكلة غير موجودة في الكود، بل في البيئة المحيطة به. المشكلة تتلخص في أن الكود الذي تكتبه لا يعمل في فراغ، بل يعتمد على عشرات العوامل الخارجية:

• نظام التشغيل: الفروقات بين Windows, macOS, و Linux في التعامل مع الملفات والشبكات والصلاحيات يمكن أن تسبب مشاكل غير متوقعة.
• إصدارات اللغات والمكتبات: قد يعمل مشروعك بشكل مثالي على Node.js v16، ولكنه ينهار تماماً على v18 بسبب تغييرات في اللغة أو المكتبات.
• الاعتماديات المخفية (Global Dependencies): أحياناً، يكون هناك برنامج أو مكتبة مثبتة على جهازك بشكل عام (globally) يعتمد عليها مشروعك بدون ما تكون موثقة، وعندما يأتي زميلك لتشغيل المشروع على جهازه النظيف، يفشل كل شيء.
• متغيرات البيئة (Environment Variables): مفاتيح الـ API، مسارات الملفات، وإعدادات قواعد البيانات التي تكون معرفة على جهازك ولكنها غير موجودة عند باقي الفريق.

هذا التضارب لا يستهلك الوقت والجهد فقط، بل يقتل الإنتاجية ويسبب الإحباط في الفريق. كل ساعة تقضيها في حل مشكلة “بيئة” هي ساعة ضائعة كان من الممكن أن تستثمر في بناء ميزة جديدة أو إصلاح خطأ حقيقي.

الحل السحري: لنتعرف على حاويات التطوير (Dev Containers)

هنا يأتي دور المنقذ: حاويات التطوير أو Dev Containers. الفكرة بسيطة وعبقرية في نفس الوقت: بدلاً من أن يحاول كل مبرمج بناء بيئة التطوير على جهازه الخاص، نقوم ببناء بيئة تطوير “مثالية” ومعزولة مرة واحدة داخل حاوية (Container)، ثم يشاركها كل أعضاء الفريق.

ببساطة، الـ Dev Container هو بيئة تطوير كاملة وشاملة تعمل داخل حاوية Docker. هذه البيئة تحتوي على كل شيء يحتاجه المشروع: نظام التشغيل (عادةً نسخة خفيفة من لينكس)، لغة البرمجة بالإصدار المحدد، المكتبات، الأدوات، وحتى إعدادات محرر الأكواد وامتدادات VS Code نفسها!

كيف تعمل هذه التقنية؟

تعتمد هذه التقنية بشكل أساسي على مكونين رئيسيين: محرر الأكواد VS Code وتقنية Docker.

توضيح بسيط: تخيل Docker كأنه طريقة لتغليف تطبيقك وكل ما يحتاجه للعمل (مكتبات، إعدادات) في صندوق معزول وخفيف الوزن يسمى “حاوية”. هذا الصندوق يمكن تشغيله على أي جهاز يدعم Docker بنفس الطريقة تماماً.

عندما تفتح مشروعاً مهيأً للعمل مع Dev Containers، يقوم VS Code بالآتي:

1. يقرأ ملفات الإعداد الموجودة في مجلد خاص اسمه .devcontainer.
2. يقوم ببناء أو تحميل “صورة” (Image) Docker التي تحتوي على كل الأدوات والمكتبات المحددة.
3. يشغل حاوية من هذه الصورة.
4. يقوم بتثبيت خادم صغير داخل الحاوية ليتصل به محرر VS Code الموجود على جهازك.

والنتيجة؟ أنت ما زلت تستخدم واجهة VS Code الجميلة والسريعة على جهازك (ويندوز، ماك…)، ولكن كل العمليات الفعلية – مثل تشغيل الكود، والوصول للـ Terminal، والتصحيح (Debugging) – تحدث داخل الحاوية المعزولة والموحدة. لقد حصلت على أفضل ما في العالمين: تجربة استخدام محلية وسلسة، مع بيئة تطوير موحدة وقوية.

لنبني أول حاوية تطوير خاصة بنا (خطوة بخطوة)

الأمر أسهل مما تتخيل. كل ما تحتاجه هو:

• محرر الأكواد VS Code.
• برنامج Docker Desktop مثبت وشغال.
• امتداد (Extension) Dev Containers في VS Code.

الآن، لنقم بتجهيز مشروع بسيط:

1. أنشئ مجلداً جديداً لمشروعك وافتحه في VS Code.
2. اضغط على Ctrl+Shift+P (أو Cmd+Shift+P على ماك) لفتح لوحة الأوامر (Command Palette).
3. اكتب “Dev Containers: Add Dev Container Configuration Files…” واختر هذا الأمر.
4. سيقوم VS Code بعرض قائمة طويلة من القوالب الجاهزة (Python, Node.js, Go, Rust, وغيرها). اختر القالب الذي يناسبك. لنختر على سبيل المثال “Node.js & TypeScript”.
5. سيسألك عن إصدار Node.js الذي تريده، اختر الإصدار المناسب. ثم قد يسألك عن ميزات إضافية (مثل أدوات سطر الأوامر لـ Azure أو Docker)، يمكنك تجاهلها الآن.
6. بعد الضغط على “OK”، سيقوم VS Code بإنشاء مجلد .devcontainer وبداخله ملف devcontainer.json.
7. سيظهر لك إشعار في الزاوية اليمنى السفلية يقترح عليك “Reopen in Container”. اضغط عليه.

الآن، انتظر قليلاً. في المرة الأولى، سيقوم VS Code بتحميل صورة Docker وبناء الحاوية، وهذا قد يأخذ بضع دقائق. في المرات القادمة ستكون العملية أسرع بكثير. بمجرد انتهاء العملية، لاحظ في الزاوية اليسرى السفلية من VS Code، ستجد اسم الحاوية بدلاً من اسم نظام التشغيل المحلي. افتح الـ Terminal المدمج (Ctrl+`)… تهانينا! أنت الآن داخل حاوية لينكس معزولة ومجهزة بكل ما تحتاجه لتطوير مشروع Node.js.

مثال عملي: مشروع Node.js داخل حاوية

هذا هو ملف devcontainer.json الذي تم إنشاؤه، مع بعض الإضافات والتوضيحات مني:

// .devcontainer/devcontainer.json
{
  // اسم وصفي للحاوية يظهر في VS Code
  "name": "Node.js & TypeScript Project",

  // يمكن استخدام صورة جاهزة مباشرة أو ملف Dockerfile مخصص
  "image": "mcr.microsoft.com/devcontainers/typescript-node:18-bullseye",

  // الإعدادات التي سيتم تطبيقها على VS Code داخل الحاوية
  "settings": {
    "editor.formatOnSave": true
  },

  // قائمة بالامتدادات التي سيتم تثبيتها تلقائياً داخل الحاوية
  "extensions": [
    "dbaeumer.vscode-eslint",
    "esbenp.prettier-vscode",
    "firsttris.vscode-jest-runner"
  ],

  // منافذ من الحاوية ليتم توجيهها إلى جهازك المحلي
  // مثلاً، لو شغلت سيرفر على بورت 3000 داخل الحاوية، يمكنك الوصول إليه من متصفحك
  "forwardPorts": [3000],

  // أمر يتم تشغيله مرة واحدة فقط بعد إنشاء الحاوية بنجاح
  // مثالي لتثبيت الاعتماديات
  "postCreateCommand": "npm install",

  // المستخدم الذي سيتم تشغيل الأوامر به داخل الحاوية
  // استخدام مستخدم غير الـ root هو ممارسة أمنية جيدة
  "remoteUser": "node"
}

ماذا يعني هذا؟ يعني أن أي مبرمج جديد ينضم للفريق، كل ما عليه فعله هو:

1. عمل git clone للمشروع.
2. فتحه في VS Code (مع وجود Docker و الامتداد المطلوب).
3. الضغط على “Reopen in Container”.

هذا كل شيء! سيجد أمامه بيئة تطوير جاهزة، مع تثبيت تلقائي لـ Node.js بالإصدار الصحيح، وكل الاعتماديات (عبر npm install)، وكل امتدادات VS Code التي يستخدمها الفريق. لا مزيد من ملفات الـ README الطويلة والمعقدة التي تشرح كيفية إعداد البيئة. إنه حرفياً “يعمل من أول مرة”.

نصائح من خبرة أبو عمر

• ابدأ بالبسيط: لا تحاول بناء Dockerfile معقد من اليوم الأول. استخدم الصور الجاهزة التي توفرها مايكروسوفت (mcr.microsoft.com/devcontainers). فهي محسّنة جداً وتغطي معظم الحالات الشائعة.
• استخدم postCreateCommand بحكمة: هذا الأمر كنز حقيقي. استخدمه لتشغيل أي شيء يحتاجه المطور مرة واحدة عند إعداد المشروع، مثل npm install, pip install -r requirements.txt, أو حتى تهيئة قاعدة البيانات.
• لا تنسَ الامتدادات (Extensions): من أهم ميزات Dev Containers هي توحيد الأدوات. اتفق مع فريقك على الامتدادات الأساسية (مثل Linter, Formatter, Debugger) وأضفها إلى ملف devcontainer.json. هذا يضمن أن الكود الذي يكتبه الجميع يتبع نفس المعايير.
• إدارة الأسرار (Secrets): لا تضع مفاتيح API أو كلمات المرور في ملفات الإعدادات أو الـ Dockerfile. أفضل طريقة هي استخدام ملف .env يتم إضافته إلى .gitignore، ويقوم كل مطور بملئه بمعلوماته الخاصة.
• مشاركة الإعدادات (Settings): استخدم خاصية "settings" في ملف devcontainer.json لتوحيد إعدادات VS Code المهمة للمشروع، مثل “تنسيق الكود عند الحفظ” (Format on Save).

الخلاصة: وداعاً للفوضى، ومرحباً بالإنتاجية! 😉

في عالم تطوير البرمجيات اليوم، أصبحت المشاريع أكثر تعقيداً والفرق أكثر توزيعاً. لم يعد مقبولاً أن نضيع وقتنا الثمين في حل مشاكل بيئات التطوير. تقنية Dev Containers ليست مجرد أداة جميلة، بل هي نقلة نوعية في طريقة عملنا كمطورين.

إنها توفر لنا:

• التناسق: كل أعضاء الفريق يعملون على نفس البيئة بالضبط.
• السرعة: انضمام مطور جديد للمشروع يستغرق دقائق بدلاً من أيام.
• العزل: لا مزيد من تضارب المكتبات بين المشاريع المختلفة على جهازك.
• الموثوقية: إذا كان الكود يعمل في الحاوية على جهازك، فإنه سيعمل في الحاوية على جهاز زميلك، وعلى خادم الإنتاج.

نصيحتي لك: إذا لم تكن قد جربت حاويات التطوير بعد، فأنت تفوت على نفسك الكثير. ابدأ اليوم بمشروع شخصي صغير، جربها، وستتساءل كيف كنت تعمل بدونها طوال هذا الوقت. وداعاً لجملة “إنها تعمل على جهازي”، ومرحباً بعالم تكون فيه بيئة التطوير صديقك وليست عدوك.