كم موظف يجلس الآن ينتظر النشر التالي؟
أول سؤال أطرحه على عميل جديد هو: كم شخصاً يلزمك لنشر تحديث إلى الإنتاج؟ معظم الإجابات تقع بين شخص واحد و4 أشخاص. ثم أطرح السؤال الثاني: كم مرة يفشل النشر ويضطر شخص ما للعودة والتصحيح قبل الانتهاء؟ هنا يبدأ المدير في الضحك بعصبية.
هذا هو الوضع الذي تريد الخروج منه.
DevOps لا تعني شخص يجلس يراقب سيرفرات طول اليوم. معناها: أنت تضع قواعد واضحة للكود والبيئات، تأتمتة القبيح، ثم تنسى الأمر. الكود يختبر نفسه. التحديثات تنشر نفسها. الأشياء لا تنهار في الليل.
من تجربتي في قيادة مشاريع في الكويت والخليج، الشركات التي بنت هذا من البداية نمت أسرع، وظفت أقل، وخسرت عملاء أقل. الشركات التي أرجلت الموضوع؟ انتهى بها الحال تفعل إجراء عاجل يستغرق 3 أشهر وينسفون 2 مشروع في الطريق.
CI/CD: لماذا هذا أهم من الكود نفسه
CI = Continuous Integration. كل ما يعني هذا هو: عندما يكتب أحد فريقك كود جديد، النظام تلقائياً يختبره ويقول "OK" أو "مشكلة". لا أحد ينتظر شخص آخر. لا أحد يقول "آه، نسيت أختبر هذا الملف". النظام يفعله.
CD = Continuous Deployment. عندما يكون الكود OK، يُنشر تلقائياً. ليس يدوياً. ليس "غداً". الآن.
سبب أهمية هذا بسيط: معظم الأخطاء تحدث في الانتقال من بيئة تطوير إلى إنتاج. مهندس كتب كود يعمل على جهازه، لكن على السيرفر الفعلي لا. قاعدة البيانات إصدار مختلف. متغيرات البيئة ناقصة. مكتبة سطر واحد ناسية. يقضي الفريق ساعات في التصحيح.
عندما تأتمت هذا: كل هذه الأخطاء تكتشفها في بيئة تماثل الإنتاج قبل أن يرى أي عميل المشكلة. الفريق ينام الليل براحة نفسية.
رأيت هذا الخطأ بالذات يُغرق مشاريع كانت ممولة تمويلاً جيداً في الكويت والإمارات. شركات ناشئة كانت لها فكرة عظيمة لكن لا يمكنها نشر أكثر من مرة أسبوع. عملاء ينتظرون. منافسون يتقدمون. بعد 6 أشهر انتهوا.
الحد الأدنى الذي تحتاجه فعلاً
لا تحتاج GitHub Actions مع ArgoCD مع Kubernetes ومجموعة أدوات ضخمة. ابدأ بـ GitHub Actions (مجاني للمشاريع العام)، واكتب workflow بسيط:
- عندما يدفع أحدهم كود: اختبره
- إذا نجحت الاختبارات: اجمعه وأنشر نسخة
- عندما يُدمج الكود مع الفرع الرئيسي: انشره إلى الإنتاج
هذا. ثلاث خطوات. لا تعقيد. فريق من 3 مهندسين يمكنه نشر 50 تحديث يومي بهذا. بثقة. بدون أخطاء.
البنية كرمز: لا تجلس تكتب الأوامر يدوياً مرة ثانية
Infrastructure as Code معناه: بدل ما تجلس مع سيرفر يكتبك كل command يدوياً (تثبيت Node، تثبيت Nginx، نسخ الملفات، تفعيل SSL...)، أنت تكتب ملف واحد يقول للنظام بالضبط ما يحتاج.
لماذا؟ لأنك لو احتجت سيرفر جديد غداً (العميل نما كثير، أو سيرفر الحالي انهار)، أنت بضغطة زر لديك نسخة مطابقة تماماً. لا أخطاء بشرية. لا نسيان خطوة. لا اختلافات غريبة بين السيرفرات.
البدائل الشهيرة: Terraform (أسهل)، Docker Compose (إذا استخدمت Docker)، Ansible (إذا أردت أتمتة أكثر تعقيداً). شخصياً، بدأت Terraform لأنها بسيطة والملفات واضحة.
ملاحظة من الميدان
عميل كويتي أتاني السنة الماضية يقول: بنينا سيرفر الإنتاج يدوياً من 3 سنوات. الآن نحتاج سيرفر ثاني للحمل. المهندس الوحيد اللي يعرف الإعدادات الدقيقة ترك الشركة. استغرقنا 10 أيام لإعادة بنائه — والأتوماتيكي كان ممكن ينجزها في 15 دقيقة. ما ضيعوا أموالاً على التقنية. ضيعوها على عدم توثيق الطريقة من الأول. البنية كرمز فحلت هالمشكلة جذرياً.
ما يحتاجه الفريق الصغير بالضبط
فريقك عددهم 3-5 مهندسين. ميزانيتك محدودة. تحتاج تركز على الأساسيات:
نظام التحكم بالإصدارات
GitHub أو GitLab. لا نقاش. كل كود يدخل الريبو. كل حاجة موثقة. كل تحديث له تاريخ واضح. وإذا حصلت مصيبة، تراجع لإصدار سابق بـ 10 ثوان.
CI/CD Pipeline
GitHub Actions أو GitLab CI. مجاني. تكتب ملف YAML بسيط يقول: اختبر، اجمع، انشر. في الأسبوع الأول قد يستغرق 4 ساعات. بعده تنسى الموضوع لأنه يعمل وحده.
بيئات منفصلة
Development (تطوير)، Staging (اختبار)، Production (حي). الكود يسير في سلسلة: التطويرون يعملون على Development، الفريق يختبر على Staging، العملاء يرون Production. أخطاء تُكتشف قبل أن تصل للزوار.
هذا يكفيك للسنة الأولى والثانية. لا تزيد تعقيد إذا لم تحتج. الكثير من الفرق تبني بنية معقدة من البداية وتندم بعد 6 أشهر.
الأخطاء اللي رأيتها بالفعل (وساعدتك على تجنبها)
الخطأ الأول: البدء بـ Kubernetes. مهندس جديد حماس يقول "Kubernetes أفضل ممارسة". معظم الفرق الناشئة لا تحتاج Kubernetes. أنت تحتاج Docker Compose أو حتى Docker عادي. Kubernetes تأتي عندما يكون لديك 50+ ألف مستخدم يومي والنطاق الترقي حقيقي. قبل كده هي خطأ مكلف.
الخطأ الثاني: لا توثق خطواتك. بنيت pipeline جميلة، لكن لا أحد في الفريق يفهم كيف هي تعمل. سنة بعد كده مهندس جديد يسأل: "ليش يعني هالملف موجود؟" لا أحد يجاوب. البنية كرمز لا تُفيد إذا الناس لا تفهم الملفات.
الخطأ الثالث: الاختبارات ضعيفة. Pipeline سريع وحلو، لكن الاختبارات تقبل كود كسّول. بعد أسبوع كود سيء يصل الإنتاج والنظام ينهار. استثمر وقت في كتابة اختبارات حقيقية — unit tests على الأقل، وintegration tests إذا أمكنت.
خطوات عملية: كيف تبدأ هذا الأسبوع
اليوم الأول: سجل في GitHub
أنشئ organization جديدة (مجاني). ادفع الكود الحالي إليها. هذا. انتهيت من 30% من المسألة.
اليوم الثاني: اكتب ملف CI/CD
في المجلد .github/workflows اكتب ملف deploy.yml يقول: عندما يدفع شخص كود، اختبره. ابحث عن قالب بسيط لتكنولوجيتك (Laravel, Next.js, إلخ). 90% من العملية نسخ واللصق.
اليوم الثالث والرابع: جرّب
ادفع كود تجريبي. شوف الـ Pipeline هل تعمل أم لا. أصلح الأخطاء. بعد 20 دفعة ستكون خبير.
الأسبوع الثاني: بنية كرمز
ابدأ تكتب ملفات البيئة (Terraform أو Docker Compose). لا تجعلها مثالية. اكتب ما تحتاجه الآن: سيرفر، قاعدة بيانات، إعدادات أساسية.
الأسبوع الثالث: وثق
اكتب README شامل يشرح: كيف يضيف مهندس جديد كود؟ كيف نشر؟ إذا حصلت مصيبة، كيف نتراجع؟ ثق بي، المهندس الجديد السنة القادمة (أو أنت بعد 3 أشهر نسيت) سيشكرك.
التكلفة: هل هي فعلاً مجاني؟
GitHub Actions: مجاني (في حد معقول من الاستخدام). Docker Hub: مجاني. Terraform: مجاني. السيرفرات نفسها تحتاج ميزانية (AWS، DigitalOcean، Hetzner)، لكن DevOps نفسه لا يضيف تكلفة.
الاستثمار الفعلي: وقت المهندسين — أسبوعين في البناء، ساعة شهرياً في الصيانة. مقابل ده: توفير 10 ساعات شهرية من "الأخطاء اليدوية" و"المشاريع المتأخرة". الحساب واضح.
بصراحة، معظم الشركات الناشئة في الكويت لا تحتاج استشاري DevOps مقابل 5000 دولار شهري. تحتاج مهندس واحد يعرف الأساسيات ويستثمر أسبوع. ده كل حاجة.
متى تطلب مساعدة؟
إذا فريقك وصل 10+ مهندسين، أو عملاء كثيرين وضغط عالي على الخدمة، تحتاج فكرة DevOps أكثر تعقيداً. Kubernetes قد تصير معقولة. Monitoring متقدم قد يصير ضروري. لكن في المرحلة الناشئة: البسيط هو الأفضل.
نحن في Tech Vision Era نساعد الشركات الناشئة والمشاريع على بناء هذا من الأول. لو كنت تبني تطبيق جديد أو تحديث pipeline موجود، اتواصل معنا عبر واتساب — ساعات قليلة استشارة توفر لك شهور صداع لاحقاً.