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

يا أهلاً وسهلاً فيكم، معكم أبو عمر.

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

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

في نهاية اليوم الثاني، جمعت الفريق وحكيتلهم: “يا جماعة، هذا الوضع ما بنفع. احنا بنحرق وقت ومجهود ومواهب على الفاضي. من بكرة، بدنا نوحد كل بيئات التطوير عنا، وما بدي أسمع جملة ‘شغالة عندي’ مرة ثانية”. ومن هنا، بدأت رحلتنا مع ما يسمى بـ “حاويات التطوير” أو الـ Dev Containers، وهي التقنية اللي أنقذت إنتاجيتنا وحافظت على صحتنا النفسية كمبرمجين.

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

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

هذا بالضبط هو المبدأ خلف حاويات التطوير. هي عبارة عن بيئة تطوير كاملة ومعزولة تعمل داخل حاوية دوكر (Docker Container)، لكنها مدمجة بشكل سحري مع محرر الأكواد المفضل عندك، مثل VS Code.

الفكرة هي أنك لا تقوم بتثبيت (Node.js, Python, Go, Rust, قواعد البيانات، إلخ) على جهازك مباشرة، بل تقوم بتعريف كل هذه المتطلبات في ملف إعدادات بسيط. عندما تفتح المشروع، يقوم VS Code ببناء هذه البيئة داخل حاوية Docker وتشغيل نفسه “داخلها”. أنت كمبرمج، لن تشعر بالفرق تقريباً، ستكتب الكود في VS Code كالمعتاد، لكن كل الأوامر، والطرفية (Terminal)، والمصحح (Debugger) ستعمل داخل تلك الحاوية الموحدة.

الوداع لجملة “بس شغالة عندي!”: كيف تحل المشكلة؟

قد تبدو الفكرة معقدة للوهلة الأولى، لكن الفوائد اللي بتقدمها بتخليها تستاهل وبقوة. خلونا نلخص أهم المزايا:

توحيد البيئة (Standardization)

هذه هي الميزة القاتلة. كل عضو في الفريق، سواء كان يستخدم Windows, macOS, أو Linux، سيحصل على نفس بيئة التشغيل بالضبط (عادةً توزيعة لينكس معينة)، ونفس إصدارات اللغات، ونفس المكتبات، وحتى نفس إضافات (extensions) محرر الأكواد. هذا يقضي تماماً على مشاكل “البيئة المختلفة”.

الإعداد السريع للمطورين الجدد (Rapid Onboarding)

تذكروا قصة “خالد” ومعاناته ليومين؟ مع حاويات التطوير، العملية تصبح كالتالي:

1. git clone <repository_url>
2. افتح المشروع في VS Code.
3. سيظهر لك إشعار يسألك: “هل تريد إعادة فتح المشروع في الحاوية؟”.
4. اضغط “Reopen in Container”.
5. انتظر بضع دقائق لأول مرة فقط… وهذا كل شيء! خالد الآن جاهز لكتابة الكود في بيئة مطابقة 100% لبيئة باقي الفريق.

العزل التام (Isolation)

هل تعمل على مشروع قديم يحتاج Python 2.7 ومشروع جديد يتطلب Python 3.11؟ لا مشكلة على الإطلاق. كل مشروع يعمل في حاويته المعزولة، فلا يوجد أي تعارض بين متطلبات المشاريع المختلفة. جهازك المحلي يبقى نظيفاً ومرتباً.

التناسق بين التطوير والإنتاج (Dev/Prod Parity)

يمكنك تصميم حاوية التطوير لتكون شبيهة جداً ببيئة الإنتاج (Production) التي سيعمل عليها تطبيقك في النهاية. هذا يقلل من المفاجآت والمشاكل التي تظهر فقط عند نشر التطبيق.

لنبدأ العمل: كيف تنشئ أول حاوية تطوير خاصة بك؟

الكلام النظري جميل، لكن خلينا نشوف كيف بنطبق هذا الحكي عملياً. العملية أسهل بكثير مما تتوقع.

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

• محرر الأكواد Visual Studio Code.
• Docker Desktop (أو أي محرك Docker آخر متوافق). تأكد من أنه يعمل في الخلفية.
• إضافة (Extension) اسمها “Dev Containers” من مايكروسوفت، قم بتثبيتها داخل VS Code.

الخطوة الأولى: إضافة إعدادات الحاوية لمشروعك

افتح مشروعك الحالي في VS Code. الآن، افتح لوحة الأوامر (Command Palette) بالضغط على Ctrl+Shift+P (أو Cmd+Shift+P على الماك) وابحث عن الأمر التالي:

Dev Containers: Add Dev Container Configuration Files to Workspace…

سيقوم VS Code بتحليل مشروعك ويقترح عليك مجموعة من القوالب الجاهزة (Node.js, Python, Java, Go, Rust, وغيرها الكثير). اختر القالب الأنسب لمشروعك. على سبيل المثال، لو كان مشروعك Node.js، اختر “Node.js”.

بعد اختيار القالب، سيقوم VS Code بإنشاء مجلد جديد في مشروعك اسمه .devcontainer وبداخله ملف أو ملفين، أهمهم هو devcontainer.json.

تشريح الملف السحري: devcontainer.json

هذا الملف هو العقل المدبر لكل شيء. إنه ملف JSON بسيط يخبر VS Code كيف يبني ويُكوّن حاوية التطوير الخاصة بك. لنلقِ نظرة على مثال لمشروع Node.js:

{
	"name": "Node.js & TypeScript",

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

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

	// الإضافات التي سيتم تثبيتها تلقائياً في VS Code داخل الحاوية
	"extensions": [
		"dbaeumer.vscode-eslint"
	],

	// منافذ (Ports) من الحاوية ليتم توجيهها إلى جهازك المحلي
	"forwardPorts": [3000],

	// أمر يتم تنفيذه بعد إنشاء الحاوية (مثالي لتثبيت المكتبات)
	"postCreateCommand": "npm install",

	// المستخدم الذي ستعمل به داخل الحاوية
	"remoteUser": "node"
}

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

نصيحة من أبو عمر: الخاصية postCreateCommand هي كنز حقيقي. استخدمها دائماً لتشغيل أوامر مثل npm install, pip install -r requirements.txt, أو bundle install. بهذا، تضمن أن أي شخص يفتح المشروع ستكون جميع اعتماداته (dependencies) مثبتة وجاهزة تلقائياً.

مثال عملي متقدم: مشروع مع قاعدة بيانات

ماذا لو كان مشروعك أكثر تعقيداً ويحتاج إلى قاعدة بيانات مثل PostgreSQL؟ هنا يأتي دور Docker Compose.

بدلاً من تعريف حاوية واحدة، يمكنك استخدام ملف docker-compose.yml لتعريف عدة خدمات (مثلاً، خدمة للتطبيق وخدمة لقاعدة البيانات)، ثم تطلب من Dev Container استخدام هذا الملف.

1. إنشاء ملف docker-compose.yml

أنشئ ملف docker-compose.yml في جذر مشروعك:

version: '3.8'
services:
  # خدمة التطبيق (التي سيعمل VS Code بداخلها)
  app:
    build:
      context: .
      dockerfile: .devcontainer/Dockerfile
    volumes:
      - ..:/workspace:cached
    command: sleep infinity # لإبقاء الحاوية تعمل
    depends_on:
      - db

  # خدمة قاعدة البيانات
  db:
    image: postgres:14
    restart: unless-stopped
    environment:
      - POSTGRES_USER=myuser
      - POSTGRES_PASSWORD=mypassword
      - POSTGRES_DB=mydb
    volumes:
      - postgres-data:/var/lib/postgresql/data

volumes:
  postgres-data:

2. تحديث ملف devcontainer.json

الآن، عدّل ملف .devcontainer/devcontainer.json ليشير إلى ملف الـ Compose:

{
	"name": "My App with Postgres",
	"dockerComposeFile": "../docker-compose.yml",
	"service": "app", // اسم الخدمة التي سيعمل VS Code بداخلها
	"workspaceFolder": "/workspace",

	// ... باقي الإعدادات مثل extensions, forwardPorts, etc.
	"extensions": [
		"ms-python.python",
		"cweijan.vscode-postgresql-client2"
	],
	"forwardPorts": [8000],
	"postCreateCommand": "pip install -r requirements.txt"
}

بهذه الطريقة، عندما تقوم بـ “Reopen in Container”، سيقوم Docker Compose بتشغيل حاويتين: واحدة لتطبيقك وواحدة لقاعدة البيانات، وسيربطهما معاً في نفس الشبكة. يمكنك الآن الاتصال بقاعدة البيانات من تطبيقك باستخدام اسم الخدمة `db` كـ host. أصبح لديك بيئة تطوير كاملة ومعقدة، قابلة للتكرار بنقرة زر واحدة.

الخلاصة: استثمار يستحق كل دقيقة 🤓

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

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

ودمتم سالمين يا جماعة.