كان إعداد بيئة التطوير يستغرق أياماً: كيف أنقذتنا حاويات التطوير (Dev Containers) من جحيم ‘لا تعمل على جهازي’؟

يا أهلاً وسهلاً فيكم يا جماعة. اسمحوا لي أبدأ معكم بقصة قصيرة صارت معي قبل كم سنة، قصة بتلخص معاناة كثير مبرمجين. كنا وقتها شغالين على مشروع كبير ومعقّد شوي، فيه خدمات مصغرة (Microservices) وقواعد بيانات مختلفة وتقنيات متداخلة. في يوم، انضم لَنا مهندس جديد، شب شاطر ومتحمس، خلينا نسميه “خالد”.

أول يوم لخالد، أعطيته صلاحيات الوصول للكود وبدينا معه رحلة إعداد بيئة التطوير على جهازه الماك الجديد. يا زلمة، شو بدي أحكيلكم… “دليل الإعداد” كان عبارة عن ملف README فيه 37 خطوة! “نزّل بايثون نسخة 3.8.x”، “لازم نسخة Node تكون 14 بالزبط”، “شغّل هاي المكتبة تبعت الصور”، “اتأكد إنك مثبت PostgreSQL نسخة 12 مش 13”.

قعدنا أنا وخالد يومين كاملين، والله يومين، ونحنا بنحاول نخلي المشروع يشتغل عنده. كل شوي تطلعله مشكلة شكل: مرة مشكلة في تصريح مكتبة، ومرة تعارض بين نسخ، ومرة خدمة ما بترضى تتصل بقاعدة البيانات. كنت كل شوي أسمعه بحكي تحت أنفاسه “غريب، طبقت كل الخطوات!” وأنا أرد عليه “معلش يا خالد، هلأ بتزبط”. وفي نهاية اليوم الثاني، وبعد ما حسينا إنه انتصرنا، اكتشفنا إنه في خدمة أساسية ما بتشتغل عنده لأنه نسخته من مكتبة `lib-xml` مختلفة عن النسخة اللي عندي على جهازي اللينوكس.

وقتها قلت في نفسي: “شو هالحكي؟ مستحيل نكمل هيك. لازم يكون في حل أفضل يخلصنا من جملة ‘بس على جهازي شغّالة!’ (It works on my machine!)”. ومن هنا بدأت رحلتي مع الحل اللي أنقذنا فعلاً: حاويات التطوير.

ما هو جحيم “لا تعمل على جهازي”؟

قبل ما نغوص في الحل، خلينا نفصّل المشكلة أكثر. جملة “It works on my machine” هي أكثر جملة بتستفز مدراء المشاريع والزملاء في الفريق. هي باختصار تعني أن الكود يعمل بشكل سليم على جهاز المطور الذي كتبه، ولكنه يفشل عند تشغيله على جهاز زميل آخر، أو على خادم الاختبار (Staging Server)، أو الأسوأ من ذلك، على خادم الإنتاج (Production Server).

الأسباب كثيرة ومتشعبة:

• اختلاف أنظمة التشغيل: مطور يستخدم Windows، وآخر macOS، والثالث Linux. هذا يؤدي لاختلافات في مسارات الملفات، صلاحياتها، والمكتبات المتاحة.
• اختلاف نسخ البرامج: نسخة Python 3.9 قد لا تتوافق مع كود مكتوب لـ 3.8. نسخة Node.js 16 قد تكسر اعتماديات كانت تعمل على 14.
• الاعتماديات الخفية (Implicit Dependencies): مكتبات مثبتة على النظام نفسه يعتمد عليها المشروع بدون ما نكون ذاكرينها بشكل صريح.
• إعدادات البيئة (Environment Variables): مفاتيح API، وسلاسل الاتصال بقواعد البيانات، وغيرها من الإعدادات التي تختلف من جهاز لآخر.

هذه المشاكل لا تضيع الوقت والجهد فقط، بل تقتل الإنتاجية وتسبب إحباطاً هائلاً في الفريق.

الحلول التقليدية… ومحدوديتها

طبعاً، حاولنا نلاقي حلول قبل ما نوصل لحاويات التطوير. كل حل كان فيه ميزات وعيوب.

ملفات README الطويلة والمُملّة

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

الآلات الافتراضية (Virtual Machines)

الحل الأفضل قليلاً هو استخدام الآلات الافتراضية (VMs) مثل VirtualBox أو VMware. الفكرة هنا هي إنشاء “جهاز كمبيوتر كامل” داخل جهازك، بنظام تشغيل وإعدادات موحدة للجميع. هذا يحل مشكلة التوافق بشكل ممتاز، لكنه يأتي بتكلفة باهظة:

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

باختصار، استخدام VM لتطوير تطبيق ويب بسيط يشبه استخدام شاحنة لنقل كيس خبز. يفي بالغرض، لكنه مبالغ فيه وغير عملي.

دخول البطل: حاويات التطوير (Dev Containers)

وهنا يأتي دور التقنية التي غيرت قواعد اللعبة: الحاويات (Containers)، وتحديداً Docker، وكيف تم ترويضها لتخدمنا في بيئة التطوير من خلال ما يعرف بـ Dev Containers.

ما هي الحاويات أصلاً؟ (A Quick Intro to Containers)

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

الفارق الجوهري بينها وبين الآلات الافتراضية هو أن الحاويات تتشارك نواة نظام التشغيل المضيف (Host OS Kernel). هي لا تحتاج لمحاكاة جهاز كمبيوتر كامل، بل هي مجرد عمليات معزولة على مستوى نظام التشغيل. هذا يجعلها:

• خفيفة جداً: تعمل في ثوانٍ معدودة.
• صغيرة الحجم: ملفاتها أصغر بكثير من ملفات الـ VMs.
• عالية الكفاءة: تستهلك موارد أقل بكثير.

وكيف تحولت إلى “حاويات تطوير”؟

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

وهنا جاءت الإضافة السحرية من مايكروسوفت لمحرر VS Code، وهي إضافة “Remote – Containers”. هذه الإضافة تسمح لك بفتح مجلد المشروع الخاص بك “داخل” حاوية Docker، وكأنك تعمل على جهازك المحلي تماماً. محرر VS Code يعمل على جهازك، ولكنه يتصل بالحاوية ويقوم بتشغيل كل شيء بداخلها: الطرفية (Terminal)، المصحح (Debugger)، خادم اللغة (Language Server)، وكل شيء آخر.

النتيجة؟ بيئة تطوير كاملة، معزولة، قابلة للتكرار، ومُعرَّفة بالكود. وداعاً لـ “لا تعمل على جهازي” إلى الأبد.

لنُشمّر عن سواعدنا: كيف تبدأ مع حاويات التطوير؟

الكلام النظري جميل، لكن خلينا نشوف التطبيق العملي. الأمر أبسط مما تتخيل.

المتطلبات الأساسية

1. Docker Desktop: قم بتثبيته على جهازك (Windows, macOS, or Linux). هو يوفر محرك Docker وواجهة سهلة للتعامل معه.
2. Visual Studio Code: محرر الأكواد الأشهر حالياً.
3. إضافة (Remote – Containers): ابحث عنها في متجر إضافات VS Code وقم بتثبيتها.

خطوة بخطوة: إنشاء أول حاوية تطوير لمشروع Python

لنفترض أن لديك مشروع Python بسيط. كل ما تحتاجه هو مجلد المشروع وملف `requirements.txt` بداخله.

1. افتح مجلد المشروع في VS Code.
2. اضغط على `F1` (أو `Ctrl+Shift+P`) لفتح لوحة الأوامر.
3. اكتب وابحث عن: “Dev Containers: Add Dev Container Configuration Files…”.
4. سيقوم VS Code بتحليل مشروعك ويقترح عليك قائمة من القوالب الجاهزة. اختر “Python 3”.
5. سيطلب منك تحديد نسخة Python، اختر ما يناسبك.
6. سيطلب منك إضافة ميزات إضافية (مثل أدوات سطر الأوامر لـ Azure أو Git). يمكنك تخطي هذه الخطوة الآن.
7. بعد ذلك، سيقوم VS Code بإنشاء مجلد جديد اسمه `.devcontainer` وبداخله ملف `devcontainer.json` وملف `Dockerfile`.
8. سيظهر لك إشعار في أسفل اليمين يسألك “Reopen in Container”. اضغط عليه.

الآن، انتظر قليلاً. في المرة الأولى، سيقوم VS Code ببناء صورة الـ Docker وتنزيل الأدوات اللازمة. بعد اكتمال العملية، ستجد أن VS Code قد أعاد فتح المشروع، ولكن انظر إلى الزاوية السفلية اليسرى، ستجد شيئاً مثل “Dev Container: Python 3”. أنت الآن تعمل داخل الحاوية! افتح الطرفية المدمجة (`Ctrl+“)، ستجد أنها طرفية لينوكس (حتى لو كنت على ويندوز) وبها نسخة Python التي حددتها مثبتة وجاهزة.

تشريح ملف `devcontainer.json`

هذا الملف هو العقل المدبر لكل شيء. هو يخبر VS Code بكيفية بناء وإعداد حاوية التطوير الخاصة بك. إليك مثال بسيط مع شرح:

{
  // اسم وصفي لحاوية التطوير الخاصة بك
  "name": "Python 3 Project",

  // كيف سيتم بناء الحاوية. هنا نستخدم Dockerfile
  "build": {
    "dockerfile": "Dockerfile",
    "context": ".."
  },

  // تخصيص VS Code داخل الحاوية
  "customizations": {
    "vscode": {
      // إضافات VS Code التي تريد تثبيتها تلقائياً داخل الحاوية
      "extensions": [
        "ms-python.python",
        "ms-python.vscode-pylance",
        "njpwerner.autodocstring"
      ],
      // إعدادات خاصة بـ VS Code داخل هذه البيئة فقط
      "settings": {
        "python.defaultInterpreterPath": "/usr/local/bin/python"
      }
    }
  },

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

  // أمر يتم تشغيله بعد إنشاء الحاوية وتشغيلها
  // مثالي لتثبيت الاعتماديات
  "postCreateCommand": "pip install -r requirements.txt",

  // المستخدم الذي سيتم تشغيل الحاوية به (لتجنب التشغيل كـ root)
  "remoteUser": "vscode"
}

تخيل قوة هذا الملف! أي مطور جديد ينضم للفريق، كل ما عليه فعله هو: `git pull`، فتح المشروع في VS Code، والضغط على “Reopen in Container”. خلال دقائق، سيحصل على بيئة تطوير متطابقة 100% مع بيئة باقي الفريق، مع تثبيت جميع الإضافات والإعدادات والاعتماديات تلقائياً.

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

على مدار السنوات، تعلمت بعض الحيل والنصائح التي تجعل تجربة حاويات التطوير أفضل وأكثر سلاسة:

• استخدم `postCreateCommand` بذكاء: لا تضع أوامر تثبيت الاعتماديات (`pip install`, `npm install`) داخل الـ `Dockerfile` مباشرة. ضعها في `postCreateCommand`. السبب هو أن Docker يقوم بتخزين الطبقات (layers) مؤقتاً. إذا غيرت الكود فقط، لا تحتاج لإعادة بناء الصورة وتثبيت كل شيء من الصفر. `postCreateCommand` يعمل بعد بناء الصورة، وهو أسرع بكثير للتحديثات الصغيرة.
• لا تُعِد اختراع العجلة: تصفح القوالب الجاهزة التي توفرها مايكروسوفت. هناك قوالب لمعظم اللغات والأطر (Node.js, Go, Rust, Java) وحتى قوالب معقدة تتضمن قاعدة بيانات (مثل Python & PostgreSQL). هي نقاط انطلاق ممتازة.
• التعامل مع الخدمات الأخرى (مثل قواعد البيانات): إذا كان مشروعك يحتاج قاعدة بيانات، لا تثبتها داخل نفس حاوية التطبيق. الحل الأمثل هو استخدام Docker Compose. يمكنك تعديل ملف `devcontainer.json` ليشير إلى ملف `docker-compose.yml` الذي يعرّف حاوية التطبيق وحاوية قاعدة البيانات معاً. هذا يبقي كل خدمة معزولة في حاويتها الخاصة، تماماً كما في بيئة الإنتاج.
• شخصنة البيئة (Personalization): قد تقول “لكن أنا أحب إعداداتي الخاصة للـ terminal وملفات الـ dotfiles!”. حاويات التطوير تدعم هذا أيضاً. يمكنك كتابة سكربت بسيط في `postCreateCommand` يقوم بسحب ملفات الإعدادات الخاصة بك (dotfiles) من مستودع Git وتطبيقها داخل الحاوية.

الخلاصة: وداعاً لـ “بس على جهازي شغّالة”! 🚀

التحول إلى حاويات التطوير كان من أفضل القرارات التقنية التي اتخذناها في فرقي. الفوائد كانت فورية وواضحة:

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

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