ما الفرق الحقيقي بين GitOps وخط الأنابيب التقليدي؟
في خط الأنابيب التقليدي (Push) يبني نظام CI مثل Jenkins أو GitHub Actions الصورة ثم «يدفع» التغيير إلى العنقود بأمر kubectl apply أو helm upgrade. هذا يعني أن خادم CI يحتاج بيانات اعتماد كاملة للوصول إلى عناقيد الإنتاج، وأن حالة العنقود الفعلية قد تنحرف بصمت عمّا هو موصوف في المستودع كلما عدّل أحد شيئًا يدويًا. أما GitOps فيقلب الاتجاه: يعيش داخل العنقود وكيل (Argo CD أو Flux) «يسحب» الحالة المطلوبة من Git ويطبّقها، ثم يستمر في مطابقة الواقع مع المستودع في حلقة تسوية (Reconciliation) مستمرة، فيكتشف الانحراف ويصلحه أو ينبّه إليه.
النتيجة العملية ثلاث مزايا يصعب الحصول عليها بالطريقة التقليدية: أولًا، يصبح Git سجل التدقيق الوحيد لكل ما يجري في الإنتاج، وهو ما تحتاجه المؤسسات السعودية عند الردّ على متطلبات الهيئة الوطنية للأمن السيبراني بشأن إدارة التغيير. ثانيًا، يصبح التراجع عن أي نشر مجرد إعادة (revert) لالتزام في المستودع. ثالثًا، لا تغادر أسرار الوصول إلى العنقود حدود العنقود نفسه، لأن أحدًا خارجه لا يحتاج إلى تطبيق شيء. وهذا لا يلغي خط CI، بل يقصره على مهمته الأصلية: البناء والاختبار وفحص الأمان، ويترك النشر للوكيل.
أرقام 2025-2026: Argo CD يتصدّر... وFlux لا يختفي
كشف مسح المستخدمين النهائيين الذي نشرته مؤسسة CNCF في يوليو 2025 أن Argo CD يدير نحو 60% من عناقيد Kubernetes لدى المشاركين، وأن 97% منهم يستخدمونه في الإنتاج (مقارنة بـ 93% في 2023)، بمؤشر رضا NPS بلغ 79. والأهم من الحصة هو الحجم: 42% من المستخدمين يديرون أكثر من 500 تطبيق في النسخة الواحدة (كانوا 15% فقط في 2023)، وربعهم يربط النسخة بأكثر من 20 عنقودًا، فيما بات مهندسو المنصات 37% من قاعدة المستخدمين، ما يؤكد أن Argo CD صار مكوّنًا أساسيًا في منصات المطوّر الداخلية.
في المقابل تُقدّر تحليلات مبنية على بيانات CNCF نُشرت في مارس 2026 حصة Flux بنحو 11% من عمليات النشر، ويبلغ الفارق في مجتمع GitHub نحو 23 ألف نجمة لـ Argo CD مقابل 8 آلاف لـ Flux. لكن هذا الفارق لا يعني أن Flux خيار أدنى: كلاهما مشروع «متخرّج» من CNCF ويشحن إصدارات منتظمة (Argo CD 3.4 وFlux 2.9 بحلول منتصف 2026)، والفرق معماري في جوهره. Argo CD منصة مركزية بواجهة رسومية وتحكّم RBAC موحّد وعرض واحد لكل العناقيد، بينما Flux مجموعة وحدات تحكّم خفيفة تعمل داخل كل عنقود من دون خادم مركزي، وهو ما تفضّله الفرق التي تدير أساطيل كبيرة أو تبني أدواتها فوق واجهة Kubernetes مباشرة.
GitOps كخدمة مُدارة: ماذا يقدّم كل من EKS وAKS وGKE؟
أهم تحوّل في 2026 أن مزوّدي السحابة الثلاثة الكبار صاروا يقدّمون GitOps كميزة أصلية لا كأداة تثبّتها بنفسك. في 30 نوفمبر 2025 أعلنت AWS التوفّر العام لـ Amazon EKS Capabilities، وهي ثلاث قدرات مُدارة: Argo CD للنشر المستمر، وAWS Controllers for Kubernetes (ACK) لإدارة موارد AWS مثل S3 وRDS من داخل Kubernetes، وkro لتركيب الموارد المخصّصة. اللافت أن وحدات التحكّم هذه تعمل في حسابات تملكها خدمة EKS نفسها لا داخل عنقودك، فتخفّف عنك ترقيتها وتأمينها وتوسيعها.
على أزور، تقدّم AKS امتداد GitOps الرسمي (microsoft.flux) الذي يثبّت Flux ويديره كميزة من الدرجة الأولى بترقيات تلقائية ودعم من مايكروسوفت وتكامل مع Azure Policy لفرض الامتثال، وهو ما يهم المؤسسات التي تنتظر افتتاح منطقة أزور السعودية. وعلى قوقل، تعتمد GKE على Config Sync، الحل الأصلي لمزامنة إعدادات أسطول كامل من العناقيد من مستودع واحد، مع حزم الأسطول (Fleet Packages) وPolicy Controller لمنع الانحراف وفرض السياسات عبر العناقيد كافة. الخلاصة: إن كانت مؤسستك تعمل على مزوّد واحد، فالخيار المُدار لديه هو نقطة البداية الأقل كلفة تشغيلية؛ وإن كانت تعمل عبر أكثر من مزوّد أو تملك عناقيد محلية سيادية، فسيمنحك Argo CD أو Flux المثبّت ذاتيًا طبقة موحّدة فوق الجميع.
متى تختار Argo CD ومتى Flux؟ وخارطة تبنٍّ للفرق السعودية
اختر Argo CD إذا كان فريقك يحتاج واجهة مرئية يفهمها المطوّرون وفرق التدقيق معًا، أو يدير مئات التطبيقات عبر ApplicationSets، أو يبني منصة مطوّر داخلية تحتاج إلى RBAC مركزي وتسجيل دخول موحّد. واختر Flux إذا كنت تفضّل بصمة موارد أخف على العناقيد، أو تعتمد أزور كمزوّد رئيسي، أو تريد بناء التشغيل الآلي بأسلوب Kubernetes الصِّرف بلا خادم مركزي يُعدّ نقطة فشل واحدة. وفي الحالتين، لا تنقل خط النشر كله دفعة واحدة.
خارطة عملية من أربع خطوات: أولًا، افصل مستودع الإعدادات (manifests/Helm/Kustomize) عن مستودع الكود، لأن هذا الفصل هو حجر أساس GitOps وسجل التدقيق. ثانيًا، ابدأ ببيئة غير إنتاجية واحدة بوضع المزامنة اليدوية قبل تفعيل auto-sync وself-heal. ثالثًا، اربط بوابات الأمان بخط CI لا بوكيل النشر: فحص الصور وIaC وسياسات OPA يجب أن تمنع الالتزام السيئ من الوصول إلى الفرع الرئيسي أصلًا، وهو الامتداد الطبيعي لما تناولناه في مقال DevSecOps السعودي. رابعًا، قِس الأثر بمقاييس DORA: زمن التسليم ومعدل فشل التغيير ووقت الاستعادة، فهذه هي الأرقام التي تُقنع الإدارة بأن الانتقال إلى GitOps لم يكن ترفًا تقنيًا بل رافعة لاستقرار الإنتاج.
