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

يا جماعة الخير، السلام عليكم ورحمة الله وبركاته.

اسمحوا لي أبدأ معكم بقصة صارت معي قبل كم سنة، قصة بتلخص معاناة كل فريق برمجي تقريباً. كنا شغالين على مشروع مهم لعميل، وكان معنا مطور جديد انضم للفريق، شب شاطر ومتحمس. أعطيناه مهمة يشتغل عليها، وبعد يومين من الشغل، عمل push للكود تبعه على الـ Git. جينا نعمل review للكود، ونشغّله عنا… ولا إشي شغال! أخطاء غريبة عجيبة بتطلع من كل مكان.

طبعاً، أول رد فعل منه كان الجملة المشؤومة اللي كلنا بنكرها: “غريب! بس هي شغّالة على جهازي!”.

قضينا يومين كاملين، والله يا جماعة يومين، ونحنا بنحاول نحل المشكلة. مرة المشكلة تطلع من إصدار Node.js المختلف عنده، ومرة من مكتبة سيستم ناقصة على جهازه اللي هو Windows بينما احنا بنشتغل على Linux و macOS، ومرة من متغير بيئة (Environment Variable) هو ضايفه وناسي يحكيلنا عنه. حسينا حالنا بنشتغل محققين مش مبرمجين. وفي النهاية، بعد ما انحرقت أعصابنا وضاع وقت ثمين، اكتشفنا إنه كان عنده إصدار فرعي مختلف من مكتبة معينة… إشي بجنّن.

هذاك اليوم، قررت إنه هيك ما بنفع نكمل. لازم نلاقي حل جذري لهذا الكابوس المتكرر. ومن هنا بدأت رحلتي مع عالم أنقذنا حرفياً، عالم “حاويات التطوير” أو الـ Dev Containers.

جحيم “إنها تعمل على جهازي”: تشريح المشكلة

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

1. اختلاف أنظمة التشغيل (OS Differences)

المطور “أ” بيستخدم Windows، والمطور “ب” بيستخدم macOS، والسيرفر شغال على Linux. هذا الثالوث كفيل بإنه يعمل مشاكل لا حصر لها. من أبسطها طريقة كتابة مسارات الملفات ( في ويندوز مقابل / في يونكس)، وصولاً إلى الأوامر المختلفة في الـ terminal ومكتبات النظام الأساسية اللي بيعتمد عليها الكود.

2. إصدارات مختلفة من اللغات والحزم (Version Mismatches)

هاي أشهر سبب. يمكن فريقك متفق يشتغل على Python 3.9، لكن جهازك عليه Python 3.10. أو يمكن مشروعك بيعتمد على Node.js v16، وزميلك نزّل بالغلط Node.js v18. تغيير بسيط في الإصدار ممكن يكسر كل المشروع بسبب تغييرات في اللغة نفسها أو في طريقة تعامل الحزم معها.

3. الإعدادات الخفية والمتغيرات البيئية (Hidden Configs & Env Variables)

كل واحد فينا عنده إعداداته الخاصة على جهازه. ممكن تكون ضفت مسار معين لمتغير الـ PATH قبل سنة ونسيت الموضوع تماماً، وهذا المسار هو اللي بيخلي أداة معينة تشتغل عندك بس. أو يمكن عندك ملف .bash_profile أو .zshrc فيه إعدادات خاصة بتأثر على سلوك الـ terminal.

4. تبعيات النظام (System-level Dependencies)

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

المنقذ وصل: ما هي “حاويات التطوير” (Dev Containers)؟

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

الـ Dev Containers هي عبارة عن استخدام حاويات Docker لإنشاء بيئة تطوير كاملة ومتكاملة ومعزولة. وبفضل التكامل الرهيب مع محرر الأكواد VS Code عبر إضافة (extension) اسمها “Dev Containers”، بصير كإنك بتكتب الكود على جهازك المحلي، لكن في الحقيقة كل شي (الـ terminal، الـ debugger، تشغيل الكود) بيتم جوا الحاوية.

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

يلا نشتغل عملي: بناء أول حاوية تطوير خاصة بك

الحكي حلو، بس خلينا نشوف كيف بنطبق هالإشي عملي. الموضوع أسهل مما بتتخيل.

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

• Docker Desktop: لازم يكون مثبت وشغال على جهازك (متاح لـ Windows, macOS, و Linux).
• Visual Studio Code: محرر الأكواد الشهير.
• إضافة Dev Containers: من داخل VS Code، ابحث عن إضافة اسمها ms-vscode-remote.remote-containers وثبتها.

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

افتح مشروعك الحالي (أو مشروع جديد) في VS Code. الآن، اتبع الخطوات التالية:

1. افتح الـ Command Palette (باستخدام Ctrl+Shift+P أو Cmd+Shift+P).
2. اكتب وابحث عن: Dev Containers: Add Dev Container Configuration Files...
3. سيقوم VS Code بتحليل مشروعك ويقترح عليك قائمة من القوالب الجاهزة. مثلاً، لو عندك ملف package.json، رح يقترح عليك بيئة Node.js. لو عندك ملف requirements.txt، رح يقترح بيئة Python.
4. اختر القالب المناسب (مثلاً “Node.js & TypeScript”).
5. سيطلب منك اختيار إصدار معين (مثلاً Node 18).
6. بإمكانك إضافة أدوات إضافية (Features) مثل Git أو Docker CLI أو Azure CLI مباشرة من الواجهة.
7. اضغط OK.

رح تلاحظ إنه VS Code أنشأ مجلد جديد في مشروعك اسمه .devcontainer وبداخله ملف اسمه devcontainer.json. هذا هو الملف السحري!

في أسفل يمين الشاشة، رح تظهرلك رسالة تسألك إذا كنت تريد إعادة فتح المشروع داخل الحاوية “Reopen in Container”. اضغط عليها.

لأول مرة، رح ياخذ الموضوع شوية وقت لأنه Docker رح يقوم بتحميل الصورة (Image) وبناء الحاوية. لكن في المرات القادمة، العملية رح تكون سريعة جداً.

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

هذا الملف هو قلب النظام. خلينا نشوف مثال لمشروع Node.js ونشرح أهم خصائصه:

{
	"name": "Node.js & TypeScript",
	// أو استخدم Dockerfile خاص فيك عبر خاصية "build"
	"image": "mcr.microsoft.com/devcontainers/typescript-node:18",

	// Features تسمح لك بإضافة أدوات بسهولة
	"features": {
		"ghcr.io/devcontainers/features/git:1": {}
	},

	// توجيه البورتات من الحاوية إلى جهازك المحلي
	// مثلاً، لو تطبيقك بيشتغل على بورت 3000 جوا الحاوية
	"forwardPorts": [3000],

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

	// تخصيص VS Code داخل الحاوية
	"customizations": {
		"vscode": {
			"settings": {
				"editor.formatOnSave": true
			},
			"extensions": [
				"dbaeumer.vscode-eslint",
				"esbenp.prettier-vscode"
			]
		}
	}

	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
	// "remoteUser": "root"
}

• image: يحدد صورة Docker الأساسية اللي رح تُبنى عليها بيئتك. مايكروسوفت توفر صور جاهزة لأغلب لغات البرمجة.
• features: طريقة جديدة وممتازة لإضافة أدوات شائعة مثل Git, Azure CLI, AWS CLI وغيرها بدون الحاجة لتعديل الـ Dockerfile.
• forwardPorts: مهم جداً لمطوري الويب. يسمح لك بفتح localhost:3000 على متصفحك المحلي والوصول للتطبيق اللي شغال جوا الحاوية.
• postCreateCommand: كنز حقيقي! أي أوامر تضعها هنا (مثل npm install أو pip install -r requirements.txt) سيتم تنفيذها تلقائياً بعد إنشاء الحاوية. هذا يضمن أن جميع التبعيات مثبتة وجاهزة.
• customizations.vscode.extensions: هنا تضع قائمة بالإضافات (extensions) التي تريد تثبيتها تلقائياً في VS Code لكل من يفتح المشروع في الحاوية. هذا يضمن أن كل الفريق يستخدم نفس أدوات الـ linting والتنسيق.

ماذا تغير في فريقنا بعد تبني حاويات التطوير؟

الفرق كان مثل الليل والنهار. المشاكل اللي كانت تاخذ منا أيام صارت من الماضي. وهذه أهم الفوائد اللي لمسناها:

1. تجهيز المطور الجديد في دقائق: بدلاً من قضاء يوم كامل في إعداد جهاز المطور الجديد، صارت العملية لا تتجاوز 15 دقيقة. كل ما عليه فعله هو: تثبيت Docker و VS Code، عمل clone للمشروع، والضغط على “Reopen in Container”. كل شي ثاني بصير تلقائي.
2. بيئة موحدة 100%: وداعاً لعبارة “شغّال عندي!”. كل الفريق، بدون استثناء، يعمل على نفس نظام التشغيل (Linux داخل الحاوية)، بنفس إصدارات اللغات، بنفس الأدوات، وبنفس إعدادات VS Code.
3. جهازي الشخصي بقي نظيفاً: ما عدت بحاجة أثبت 5 إصدارات مختلفة من Python أو Node.js على جهازي. كل تبعيات المشروع معزولة تماماً داخل الحاوية الخاصة به.
4. التجربة بدون خوف: هل تريد تجربة إصدار جديد من لغة البرمجة؟ ببساطة، غير رقم الإصدار في ملف devcontainer.json، أعد بناء الحاوية، وجرب. إذا لم تعجبك النتيجة، ارجع للإصدار القديم. كل هذا بدون أي تأثير على جهازك الأصلي أو المشاريع الأخرى.

نصائح عملية من مطبخي البرمجي (نصيحة أبو عمر)

• ابدأ بالقوالب الجاهزة: لا تعقد الأمور على نفسك في البداية. استخدم القوالب التي توفرها مايكروسوفت. هي ممتازة وتغطي 90% من الحالات.
• استخدم `postCreateCommand` بذكاء: اجعل هذا الأمر يقوم بتثبيت كل شيء يحتاجه المطور لبدء العمل فوراً.
• لا تنسى إضافات VS Code: توحيد إضافات مثل Prettier و ESLint بين أعضاء الفريق يحل نصف مشاكل تنسيق الكود وجودته. ضعها في ملف devcontainer.json.
• استفد من خاصية `features`: قبل أن تفكر في كتابة Dockerfile معقد لتثبيت أداة مثل Go أو Java، تحقق أولاً من قائمة الـ “Features” المتاحة، فهي أسهل وأسرع.
• Git يعمل مباشرة: لا تقلق بشأن إعدادات Git داخل الحاوية. إضافة VS Code ذكية كفاية لتقوم بتمرير إعدادات الـ Git من جهازك المحلي إلى الحاوية تلقائياً.

الخلاصة: وداعاً لعبارة “عندي شغّال!” إلى الأبد 🚀

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

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

بالتوفيق في رحلتكم البرمجية، وإلى لقاء في مقالة قادمة إن شاء الله.