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

السلام عليكم يا جماعة، معكم أبو عمر.

قبل كم سنة، كنا بنشتغل على مشروع كبير شوي، وكان معنا شب جديد بالفريق، خلينا نسميه “سالم”. سالم شب شاطر ومتحمس، بس خبرته لسا على قدها. أعطيته المهمة الأولى: “يا سالم، اعمل clone للمشروع من الـ Git، وجهّز بيئة العمل عندك، وابدأ بأول bug بسيط عشان تاخد ع الجو”. توقعت الموضوع ياخد معه ساعتين ثلاث، ويبدأ بالشغل.

مر اليوم الأول، وسالم لسا بحاول. تجيني رسالة: “مهندس، نسخة الـ Node.js عندي أحدث من المطلوبة والمشروع مش راضي يعمل build”. قلتله بسيطة، استخدم nvm ونزّل النسخة الصح. بعدها بشوي: “الـ Python مش لاقي مكتبة معينة مع إنه نزلتها بـ pip”. هون بلشت أحس إنه اليوم راح. ثاني يوم الصبح، نفس الموال: “قاعدة البيانات مش راضية تتصل، الدرايفر فيه مشكلة توافق”.

بصراحة، ولّعت معي. مش من سالم، الشب ما عليه لوم. ولّعت من الوضع نفسه. يومين كاملين ضاعوا بس عشان نجهز جهاز واحد يشتغل على المشروع! يومين من الإنتاجية راحت هدر، ومعها حماس المطور الجديد. كلنا مرينا بهالموقف، جملة “غريبة، عندي شغّال!” صارت نكتة سوداء بين المبرمجين. وقتها قلت لحالي: “يا زلمة، أكيد في حل أحسن من هيك. مش معقول في 2024 لسا بنعاني من هاي المشاكل البدائية”. وهون كانت بداية رحلتي مع ما يسمى بـ “حاويات التطوير” أو الـ Dev Containers.

ما هي حاويات التطوير (Dev Containers)؟ ببساطة شديدة

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

هذا بالضبط هو مبدأ الـ Dev Containers. هي عبارة عن بيئة تطوير كاملة ومعزولة تعمل داخل حاوية دوكر (Docker Container)، لكنها مدمجة بشكل عبقري مع محرر الأكواد المفضل لدى الكثيرين: Visual Studio Code.

أنت لا تكتب الكود داخل الحاوية بشكل مباشر ومعقد، بل تستخدم VS Code على جهازك كالمعتاد، ولكن VS Code يقوم “عن بعد” بالاتصال بالحاوية وتشغيل كل شيء بداخلها: الطرفية (terminal)، المصحح (debugger)، الخوادم، كل شيء. جهازك الأصلي يبقى نظيفًا، وبيئة المشروع تكون موحدة 100% عند كل أفراد الفريق.

كيف يعمل هذا “السحر”؟ (The Mechanics)

الأمر ليس سحراً بالطبع، بل هو تكامل ذكي بين عدة تقنيات. الفكرة مبنية على ثلاثة أعمدة رئيسية:

1. ملف Dockerfile أو صورة جاهزة: هذا هو “كتالوج” بناء البيئة. ملف نصي يخبر Docker بالخطوات اللازمة لإنشاء بيئة العمل: ما هو نظام التشغيل الأساسي (مثلاً Ubuntu)، ما هي البرامج التي يجب تثبيتها (مثل Node.js 18, Python 3.9)، وما هي الأوامر التي يجب تنفيذها.
2. ملف الإعدادات devcontainer.json: هذا هو العقل المدبر. ملف JSON بسيط يخبر VS Code بكيفية استخدام الحاوية. يحدد أشياء مثل:
   • أي Dockerfile يجب استخدامه.
   • ما هي إضافات VS Code التي يجب تثبيتها تلقائيًا داخل الحاوية.
   • ما هي الأوامر التي يجب تشغيلها بعد إنشاء الحاوية (مثل npm install).
   • إعدادات إعادة توجيه المنافذ (Port Forwarding) لتتمكن من الوصول إلى تطبيقك من متصفح جهازك.
3. إضافة (Dev Containers) في VS Code: هذه هي الجسر الذي يربط محرر الأكواد على جهازك بالحاوية التي تعمل في الخلفية. هي التي تتولى كل التفاصيل المعقدة وتجعل التجربة سلسة للغاية.

لنبدأ العمل: إعداد أول Dev Container لك

الكلام النظري جميل، لكن خلينا نشوف الموضوع عمليًا. الموضوع أسهل بكثير مما تتخيل.

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

• محرر Visual Studio Code.
• Docker Desktop على Windows/Mac أو Docker Engine على Linux. تأكد من أنه يعمل في الخلفية.
• تثبيت إضافة Dev Containers من متجر VS Code.

الخطوات العملية

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

الآن، انتظر قليلاً. في المرة الأولى، سيقوم VS Code ببناء صورة Docker (قد يستغرق بضع دقائق)، ثم سيشغل الحاوية ويتصل بها. عندما ينتهي، انظر إلى الزاوية السفلية اليسرى من VS Code، ستجد شيئًا مثل “Dev Container: Node.js & TypeScript”.

مبروك! أنت الآن تعمل “داخل” الحاوية. افتح الطرفية المدمجة (Ctrl+` ) واكتب node -v أو uname -a. ستجد أن إصدار Node هو الذي حددته، ونظام التشغيل هو Linux (غالبًا Debian) حتى لو كنت تستخدم Windows على جهازك!

تخصيص البيئة: القوة الحقيقية تكمن هنا

القوالب الجاهزة هي مجرد بداية. القوة الحقيقية تظهر عندما تبدأ بتخصيص ملف devcontainer.json ليناسب احتياجات مشروعك تمامًا.

تثبيت إضافات VS Code تلقائيًا

لا داعي لأن تطلب من كل مطور تثبيت قائمة من الإضافات يدويًا. ببساطة أضفها إلى ملف devcontainer.json:

{
  "name": "Node.js & TypeScript",
  "image": "mcr.microsoft.com/devcontainers/typescript-node:18",
  "customizations": {
    "vscode": {
      "extensions": [
        "dbaeumer.vscode-eslint",
        "esbenp.prettier-vscode",
        "Prisma.prisma",
        "humao.rest-client"
      ]
    }
  }
}

الآن، أي شخص يفتح المشروع في الحاوية، سيتم تثبيت هذه الإضافات الأربعة تلقائيًا له داخل بيئة التطوير.

تشغيل الأوامر بعد إنشاء الحاوية (Post-Create Command)

هل تريد تثبيت كل الاعتماديات تلقائيًا بعد بناء الحاوية؟ استخدم postCreateCommand.

{
  // ... باقي الإعدادات
  "postCreateCommand": "npm install"
  // أو لو مشروع بايثون مثلاً
  // "postCreateCommand": "pip install -r requirements.txt"
}

هذا الأمر سيوفر على المطور الجديد خطوة “لا تنس أن تشغل npm install”.

التعامل مع قواعد البيانات والخدمات الأخرى

ماذا لو كان مشروعك يتطلب قاعدة بيانات مثل Postgres وخادوم Caching مثل Redis؟ هنا يأتي دور Docker Compose.

يمكنك إنشاء ملف docker-compose.yml لوصف كل خدماتك، ثم إخبار devcontainer.json باستخدامه.

مثال لملف docker-compose.yml:

version: '3.8'
services:
  app:
    build: 
      context: .
      dockerfile: Dockerfile
    volumes:
      - ..:/workspace:cached
    command: sleep infinity

  db:
    image: postgres:14
    environment:
      - POSTGRES_USER=myuser
      - POSTGRES_PASSWORD=mypassword
      - POSTGRES_DB=mydb

ثم في devcontainer.json:

{
  "name": "My Fullstack App",
  "dockerComposeFile": "docker-compose.yml",
  "service": "app", // اسم الخدمة التي سيتصل بها VS Code
  "workspaceFolder": "/workspace",
  // ... باقي الإعدادات مثل الإضافات والمنافذ
}

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

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

• ابدأ بالقوالب الجاهزة: لا تحاول بناء كل شيء من الصفر. مايكروسوفت توفر قوالب ممتازة لمعظم لغات البرمجة والمنصات. ابدأ بواحد منها ثم قم بتخصيصه.
• حافظ على خفة الـ Dockerfile: لا تقم بتثبيت كل برامج الدنيا في صورة الدوكر. اجعلها تحتوي فقط على ما هو ضروري لـ”التطوير”. الأدوات التي تستخدمها بشكل نادر يمكن تثبيتها يدويًا داخل الحاوية عند الحاجة.
• شارك الإعدادات مع فريقك: هذه هي الفائدة الكبرى! قم بعمل commit لمجلد .devcontainer وادفعه إلى مستودع Git الخاص بك. الآن، المطور الجديد (مثل سالم في قصتنا) كل ما عليه فعله هو:
  1. git clone <your-repo>
  2. Open in VS Code
  3. Click “Reopen in Container”

  وفي غضون دقائق، سيحصل على بيئة تطوير مطابقة 100% لبيئتك، مع كل الأدوات والاعتماديات والإضافات. لا مزيد من “عندي شغال!”.

• استخدم المتغيرات السرية (Secrets): لا تضع مفاتيح API أو كلمات المرور مباشرة في ملفات الإعداد. استخدم ميزات إدارة الأسرار في Dev Containers أو ملفات .env التي لا يتم إضافتها إلى Git.

الخلاصة: وداعاً لـ “عندي شغال!” 👋

بعد اعتمادنا على Dev Containers، تحولت عملية إعداد المطورين الجدد من كابوس يستغرق يومين إلى عملية سلسة تستغرق 15 دقيقة (معظمها وقت انتظار بناء الحاوية لأول مرة). الإنتاجية زادت، والإحباط قل، والتركيز أصبح على كتابة الكود وحل المشاكل الحقيقية بدلاً من محاربة إعدادات البيئة.

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

جرّبها اليوم، وصدقني، ستشكرني لاحقًا. بالتوفيق في رحلتكم البرمجية!