يا جماعة الخير، السلام عليكم ورحمة الله.
بتذكر قبل كم سنة، انضم لفريقنا مطور جديد، شب اسمه “سعيد”، شعلة نشاط وحماس، وعيونه بتلمع من كثر الشغف للكود. أول يوم إله، اجتمعنا كلنا، وشربنا قهوة، وحكيتله: “أهلاً وسهلاً فيك يا سعيد، ان شاء الله هالشغل يكون خير عليك وعلينا”. كان الشب متحمس يبدأ يشتغل ويفرجينا إبداعه.
وهنا بدأت المأساة… أعطيته اللابتوب الجديد وقلتله: “يلا يا بطل، هاي قائمة بالبرامج والأدوات اللي لازم تنزلها عشان تبدأ تشتغل على المشروع”. ابتسامة سعيد العريضة بدأت تختفي شوي شوي مع كل سطر في القائمة. نسخة محددة من Node.js، ومدير حزم معين، وقاعدة بيانات بإصدار قديم شوي، ومجموعة من الإضافات لـ VS Code، وطبعاً، كومة ملفات .env اللي لازم يعبيها بالمتغيرات الصحيحة اللي نصها معي والنص الثاني مع زميل ثاني قاعد في اجتماع!
مر اليوم الأول وسعيد لسا بحاول يثبّت قاعدة البيانات اللي مش راضية تشتغل على نظام التشغيل تبعه. اليوم الثاني ضاع في صراع مع الـ dependencies اللي بتتعارض مع بعضها. اليوم الثالث، وبعد ما فكرنا إنه خلص، اكتشفنا إنه في متغير بيئة ناقص، والمشروع كله مش راضي يشتغل. كنت أسمع سعيد بحكي مع حاله: “يا زلمة اشتغل عندي على الجهاز القديم!”.
بعد ثلاث أيام من الإحباط والغلبة، سعيد كان محبط، وأنا كنت حاس بالذنب إني ضيعت حماسه الأول. ضيعنا وقت ثمين، والأسوأ، أعطينا انطباع سيء لمطور جديد وموهوب. وقتها، وقفت مع حالي وقفة جدية وقلت: “خلص! بكفي! لازم نلاقي حل لهالمعضلة اللي بتتكرر مع كل مطور جديد”.
لماذا يعتبر إعداد البيئة اليدوي كابوسًا متكررًا؟
قصة سعيد مش قصة فردية، هي قصة كل فريق برمجي ما استثمر في أتمتة عملياته. المشكلة مش في سعيد ولا فيّ، المشكلة في العملية نفسها. الإعداد اليدوي لبيئة التطوير هو وصفة مضمونة للمشاكل، وهذه بعض أسبابها:
- مضيعة للوقت: أيام كاملة من الإنتاجية تذهب هباءً منثورًا في التثبيت والإعداد بدلًا من كتابة الكود.
- معرض للأخطاء البشرية: نسيان خطوة واحدة، أو تثبيت إصدار خاطئ، أو خطأ في متغير بيئة واحد يمكن أن يسبب مشاكل تستغرق ساعات لحلها.
- بيئات غير متطابقة: هذه هي أم المشاكل، وجملة “شغال عندي!” (It works on my machine!) هي أشهر ناتج عنها. اختلاف بسيط في نظام التشغيل أو في إصدار مكتبة برمجية يمكن أن يؤدي إلى سلوك مختلف تمامًا للتطبيق.
- تجربة سيئة للمطور الجديد (Onboarding): أول أسبوع للموظف الجديد يحدد انطباعه عن الشركة وثقافتها. عندما يقضي هذا الأسبوع في صراع مع الإعدادات، فإنه يقتل حماسه ويشعره بالعجز.
- صعوبة التوثيق: من الصعب جدًا كتابة وتحديث دليل إعداد يدوي يغطي كل الحالات والأنظمة المختلفة. وغالبًا ما يصبح هذا الدليل قديمًا بعد أول تحديث للمشروع.
الحل السحري: أتمتة إعداد بيئة التطوير (Infrastructure as Code)
بعد تجربة سعيد المريرة، قررنا في الفريق أن نتبنى مبدأ “البيئة ككود” (Environment as Code). الفكرة بسيطة جدًا في مفهومها، قوية جدًا في تطبيقها: بدلًا من كتابة دليل إرشادي طويل، دعنا نكتب كودًا أو ملفات إعداد تقوم ببناء البيئة بشكل آلي.
الهدف أصبح واضحًا: أي مطور جديد ينضم للفريق، كل ما عليه فعله هو خطوتين:
git clone <project-url>- تشغيل أمر واحد فقط (مثل
docker-compose upأو فتح المجلد في VS Code).
وخلال دقائق، يجب أن تكون البيئة كاملة (كود، قاعدة بيانات، خدمات أخرى) جاهزة للعمل على جهازه، بغض النظر عن نظام التشغيل الذي يستخدمه. حلم، صح؟ لا، هذا واقع يمكن تحقيقه بالأدوات الصحيحة.
Docker و Docker Compose: سفينتنا في هذا البحر الهائج
أول أداة وأهم أداة في رحلتنا كانت Docker. ببساطة، Docker يسمح لنا بتغليف (Containerize) تطبيقنا مع كل ما يحتاجه للعمل (الكود، المكتبات، الأدوات) في حزمة واحدة معزولة اسمها “Container”. هذه الحاوية تعمل بنفس الطريقة تمامًا على جهاز أي مطور، على السيرفر، أو أي مكان آخر يدعم Docker.
ولما يكون مشروعنا مكون من أكثر من جزء (مثلاً، واجهة أمامية، واجهة خلفية، قاعدة بيانات)، هنا يأتي دور Docker Compose. هو أداة تسمح لنا بتعريف وتشغيل كل هذه الأجزاء (الحاويات) معًا بملف واحد وأمر واحد.
نصيحة أبو عمر: فكر في Docker على أنه “صندوق شحن” قياسي. ما يهمك هو أن الصندوق سيصل ويعمل بنفس الطريقة في أي ميناء (جهاز). لا يهم ما بداخله أو كيف تم تركيبه في المصنع.
مثلاً، لمشروع ويب بسيط، ملف docker-compose.yml قد يبدو هكذا:
# docker-compose.yml
version: '3.8'
services:
# خدمة الواجهة الخلفية (Backend)
api:
build: ./backend # ابني الـ image من مجلد الـ backend
ports:
- "5000:5000" # اربط منفذ 5000 على جهازي بالمنفذ 5000 داخل الحاوية
environment:
- DATABASE_URL=postgres://user:password@db:5432/mydatabase
depends_on:
- db # لا تشغل الـ api إلا بعد أن تعمل قاعدة البيانات
# خدمة قاعدة البيانات
db:
image: postgres:13 # استخدم image جاهزة من Postgres
environment:
- POSTGRES_USER=user
- POSTGRES_PASSWORD=password
- POSTGRES_DB=mydatabase
volumes:
- postgres_data:/var/lib/postgresql/data # احتفظ بالبيانات حتى لو أعدنا تشغيل الحاوية
volumes:
postgres_data:
الآن، كل ما يحتاجه المطور هو تشغيل docker-compose up، وسيقوم Docker بتنزيل Postgres، بناء الواجهة الخلفية، وتشغيل كل شيء معًا. لا حاجة لتثبيت Postgres أو Node.js على جهازه المحلي على الإطلاق!
Dev Containers (VS Code): الجنة على أرض الكود
Docker حلّ لنا مشكلة الخدمات والبرامج، لكن ماذا عن بيئة التطوير نفسها؟ إضافات VS Code، الإعدادات، الـ linters، الـ formatters؟ هنا يأتي دور الـ Dev Containers، وهي ميزة عبقرية في VS Code.
الفكرة هي أن VS Code نفسه يمكنه الاتصال والعمل بداخل حاوية Docker. هذا يعني أننا نستطيع تحديد كل شيء يتعلق ببيئة التطوير في ملف إعدادات بسيط، ووضعه مع كود المشروع.
عندما يفتح مطور جديد المشروع في VS Code، سيظهر له إشعار صغير: “This folder contains a Dev Container configuration. Reopen in container?”. بمجرد الضغط عليه، يقوم VS Code ببناء الحاوية، تثبيت كل الإضافات المحددة، تطبيق الإعدادات، وفتح نافذة جديدة حيث كل شيء جاهز وموحد للجميع.
ملف الإعداد .devcontainer/devcontainer.json قد يبدو هكذا:
// .devcontainer/devcontainer.json
{
"name": "My Node.js Project",
"dockerComposeFile": "../docker-compose.yml", // استخدم ملف الـ docker-compose الذي أنشأناه
"service": "api", // أخبر VS Code أن يتصل بخدمة ה- api
"workspaceFolder": "/workspace",
// الإضافات التي نريد تثبيتها تلقائيًا للجميع
"extensions": [
"dbaeumer.vscode-eslint",
"esbenp.prettier-vscode",
"humao.rest-client"
],
// إعدادات VS Code الخاصة بهذا المشروع فقط
"settings": {
"editor.formatOnSave": true,
"terminal.integrated.shell.linux": "/bin/bash"
},
// أمر يتم تشغيله بعد إنشاء الحاوية (مثل تثبيت المكتبات)
"postCreateCommand": "npm install"
}
هذا يضمن أن كل مطور في الفريق، بغض النظر عن جهازه، سيحصل على نفس الإضافات، نفس الإعدادات، ونفس سلوك الـ Linter و Formatter. وداعًا للنقاشات حول المسافات والـ Tabs!
ماذا جنينا من هذه الرحلة؟ (النتائج الملموسة)
بعد تطبيق هذه الحلول، انضم إلينا مطور جديد آخر بعد بضعة أشهر. هذه المرة، كنت مبتسماً وأنا أقول له: “أهلاً بك، كل ما عليك فعله هو git clone، افتح المجلد بـ VS Code، واضغط على Reopen in Container”.
جلست بجانبه وأنا أشرب قهوتي. خلال 10 دقائق، كان Docker يقوم بتنزيل وبناء الحاويات. بعد 5 دقائق أخرى، كان VS Code يعمل داخل الحاوية، والمشروع يعمل بالكامل، وقاعدة البيانات متصلة. وقبل أن أنهي فنجان قهوتي، كان المطور الجديد قد قام بإصلاح أول Bug صغير له وفتح أول Pull Request.
الفارق كان كالليل والنهار. وهذه هي الفوائد التي لمسناها بشكل مباشر:
- إعداد سريع البرق: تحول وقت الإعداد من أيام إلى دقائق.
- بيئات متطابقة 100%: اختفت جملة “شغال عندي!” من قاموس الفريق تمامًا.
- تركيز على ما هو مهم: المطورون يركزون على حل المشاكل وبناء الميزات، لا على صراع الإعدادات.
- توثيق حي ومحدث دائمًا: ملفات
docker-compose.ymlوdevcontainer.jsonهي أفضل توثيق للبيئة المطلوبة. - سعادة المطورين: تجربة الانضمام السلسة ترفع الروح المعنوية وتعطي انطباعًا احترافيًا عن الفريق والشركة.
الخلاصة: لا تضيعوا وقتكم في “التظبيط”! ⚙️
يا أصدقائي المطورين وقادة الفرق، الاستثمار في أتمتة إعداد بيئة التطوير ليس رفاهية، بل هو ضرورة قصوى في عالم البرمجة الحديث. قد يبدو الأمر معقدًا في البداية، ولكنه استثمار تدفع ثمنه مرة واحدة، وتجني ثماره كل يوم، ومع كل مطور جديد ينضم إليكم.
لا تنتظروا حتى تضيعوا أسبوعًا من وقت مطور جديد متحمس. ابدأوا اليوم، ولو بخطوات بسيطة. ابدأوا بـ Dockerize لتطبيق واحد، ثم أضيفوا Dev Container. الرحلة تبدأ بخطوة، والنتيجة تستحق كل ذرة جهد.
تذكروا دائمًا: وقت المطور أثمن من أن يضيع في “تظبيط” البيئة. دعوا الآلات تقوم بعمل الآلات، ودعوا البشر يبدعون.
