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

مقدمة: “يا أبو عمر، صارلي يومين بحاول أشغّل المشروع ومش زابط!”

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

مرّ أول يوم، وما سمعت من سائد إشي. قلت في بالي “تمام، الشب شغال وبده يركز”. تاني يوم، وصلني إيميل منه عنوانه “مشكلة في إعداد البيئة”. دخلت أقرأ، ولقيت قائمة بالمشاكل اللي واجهته: إصدار Python مش متوافق، مكتبة TensorFlow بتعطي خطأ غريب على نظام Windows تبعه مع إنه المشروع شغال تمام على أجهزتنا اللي بتستخدم Linux، مشاكل في تعريفات المتغيرات البيئية (Environment Variables)… باختصار، وجع راس ما بعده وجع راس.

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

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

ما هي حاويات التطوير (Dev Containers)؟ وليش لازم تهتم؟

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

• نظام التشغيل (عادةً نسخة خفيفة من Linux).
• لغة البرمجة بالإصدار المحدد (Python 3.9.7 مثلاً، مش أي إصدار تاني).
• كل المكتبات والاعتماديات (Dependencies) اللي بيحتاجها المشروع.
• الأدوات المساعدة (مثل Git, CLIs, Linters).
• حتى إضافات (Extensions) وإعدادات محرر الأكواد (VS Code) نفسها!

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

الفرق الجوهري: وداعاً لعبارة “لكنه يعمل على جهازي!”

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

“عندما يستخدم الجميع نفس الحاوية، تختفي عبارة ‘لكنه يعمل على جهازي’ وتتحول إلى ‘إنه يعمل في كل مكان’. وهذا يا جماعة، هو قمة الإنتاجية.”

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

الموضوع أسهل مما بتتخيلوا، خصوصاً مع التكامل الرهيب بين VS Code و Docker. كل اللي بتحتاجه هو ملفين رئيسيين داخل مجلد اسمه .devcontainer في مشروعك.

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

هذا هو ملف التكوين الرئيسي. هو اللي بيحكي لـ VS Code كيف يبني ويشغّل بيئة التطوير تبعتك. خلينا نشوف مثال بسيط لمشروع Python:

// .devcontainer/devcontainer.json
{
    "name": "My Python Project",
    "build": {
        "dockerfile": "Dockerfile"
    },

    // إعدادات VS Code الخاصة بالحاوية
    "settings": { 
        "python.pythonPath": "/usr/local/bin/python",
        "python.linting.pylintEnabled": true,
        "python.linting.enabled": true
    },

    // الإضافات (Extensions) اللي بدك VS Code يثبتها داخل الحاوية
    "extensions": [
        "ms-python.python",
        "ms-python.vscode-pylance",
        "njpwerner.autodocstring"
    ],

    // أمر يتم تنفيذه بعد إنشاء الحاوية (مهم جداً!)
    "postCreateCommand": "pip install -r requirements.txt"
}

شرح سريع للكود:

• name: اسم بيظهرلك في VS Code.
• build.dockerfile: بيحدد مكان ملف الـ Dockerfile اللي رح نستخدمه لبناء الصورة.
• settings: هنا بتحط أي إعدادات خاصة بـ VS Code بدك تطبقها بس داخل هاي الحاوية (مثلاً، مسار مفسر بايثون).
• extensions: قائمة بالإضافات اللي لازم تتثبت تلقائياً لكل مطور بيفتح المشروع. وداعاً لسؤال “شو الإضافات اللي بتستخدمها؟”.
• postCreateCommand: هذا هو الكنز الحقيقي. أمر بيتم تشغيله مرة واحدة بعد ما الحاوية تجهز. في مثالنا، هو بيثبت كل مكتبات المشروع من ملف requirements.txt.

2. وصفة البناء: Dockerfile

إذا كان devcontainer.json هو العقل، فالـ Dockerfile هو العضلات. هو الملف اللي بيحتوي على تعليمات بناء صورة دوكر (Docker Image) اللي رح تصير حاويتنا.

# .devcontainer/Dockerfile

# ابدأ من صورة بايثون 3.9 الرسمية
FROM mcr.microsoft.com/vscode/devcontainers/python:3.9

# يمكنك إضافة أي أوامر لتثبيت أدوات على مستوى نظام التشغيل
# مثلاً، تثبيت أدوات مساعدة باستخدام apt-get
# RUN apt-get update && apt-get install -y some-tool another-tool

في أبسط صوره، ممكن يكون سطر واحد زي ما شفتوا. إنت بتختار صورة أساسية (Base Image) جاهزة من مايكروسوفت أو دوكر هب (مثلاً، صورة فيها Python 3.9 مثبت وجاهز)، وبعدها ممكن تضيف عليها أي أدوات خاصة بتحتاجها على مستوى نظام التشغيل.

طيب يا أبو عمر، كيف أبدأ عملياً؟

الأمر بسيط جداً مع VS Code:

1. تأكد من تثبيت Docker Desktop على جهازك.
2. ثبّت إضافة “Remote – Containers” في VS Code.
3. افتح مشروعك في VS Code.
4. اضغط على F1 واكتب: Dev Containers: Add Dev Container Configuration Files....
5. رح يطلعلك قائمة، اختار منها التكنولوجيا اللي بتستخدمها (Python, Node.js, Go, etc.).
6. VS Code رح يسألك شوية أسئلة (زي إصدار اللغة) ورح ينشئلك ملفات .devcontainer الأساسية تلقائياً.
7. بعدها، رح يسألك إذا بدك تفتح المشروع في الحاوية (Reopen in Container). اضغط نعم.

انتظر قليلاً في المرة الأولى بينما يقوم Docker ببناء الحاوية، وبعدها… مبروك! أنت الآن تطوّر داخل حاوية معزولة وموحدة. أي Terminal بتفتحه داخل VS Code هو فعلياً Terminal داخل الحاوية.

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

بعد استخدامنا للـ Dev Containers في كل مشاريعنا تقريباً، هاي شوية نصائح من الآخر:

• ابدأ بالجاهز: مايكروسوفت بتوفر عشرات القوالب الجاهزة لمختلف اللغات والتقنيات. دائماً ابدأ من هناك وعدّل عليه بدل ما تبني كل إشي من الصفر.
• استغل الـ postCreateCommand: استخدم هذا الأمر لتشغيل أي سكربت إعداد بعد بناء الحاوية، مثل تثبيت المكتبات (npm install, pip install)، عمل migrations للداتابيز، إلخ. هذا يضمن أن البيئة جاهزة للعمل 100% بعد الفتح مباشرة.
• لا تخف من Docker Compose: إذا مشروعك بيحتاج خدمات تانية (زي قاعدة بيانات PostgreSQL أو Redis)، استخدم Docker Compose. ملف devcontainer.json بيدعم التكامل معه بشكل ممتاز، وبيخليك تشغل كل خدمات مشروعك بضغطة زر.
• اجعل .devcontainer جزءاً من الكود: هذا المجلد لازم يكون جزء من الـ Git repository تبعك. بيئة التطوير هي جزء لا يتجزأ من المشروع، ولازم تكون خاضعة لنفس إدارة الإصدارات (Version Control).
• حافظ على نظافة جهازك: الجمال في هاي الطريقة إنك ما بتحتاج تثبت Python أو Node.js أو أي إشي على جهازك المحلي (فقط Docker و VS Code). جهازك بضل نظيف ومستقر.

الخلاصة: استثمار لا يُقدّر بثمن

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

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

نصيحتي لك: لا تتردد. ابدأ اليوم بمشروع جانبي صغير، جرب الأمر بنفسك. جربوها، ومش رح تندموا. 👍