المستوى: محترف
Argo Rollouts: Canary Deployment يكتشف الباگ قبل العميل
لو فريقك بيـ deploy على Kubernetes بـ kubectl apply أو RollingUpdate العادي، أول pod جديد بياخد ترافيك حقيقي من المستخدم في ثوانٍ. لو فيه regression في الإصدار الجديد، الكشف بيتأخر دقايق وممكن تخسر آلاف الـ requests قبل ما الـ rollback يحصل يدوياً. Argo Rollouts بيغيّر اللعبة: بيوجّه 5% بس من الترافيك للإصدار الجديد، يقيس error rate و latency من Prometheus، ولو فيه انحراف بيرجع تلقائياً للإصدار القديم في أقل من دقيقة.
المشكلة باختصار
Kubernetes RollingUpdate بيستبدل الـ pods القديمة بالجديدة على دفعات بافتراض إن الإصدار الجديد سليم. لكن في الإنتاج، نسبة معتبرة من الـ deployments بيطلع فيها regression — حسب State of DevOps Report 2024، الفرق بين الفرق العالية والمنخفضة الأداء بيظهر في Change Failure Rate قبل أي حاجة تانية.
لو عندك تطبيق بيخدم 8000 request في الدقيقة و RollingUpdate بياخد 3 دقايق، أنت بتعرّض ~24,000 request لباگ محتمل قبل ما الـ rollback اليدوي يحصل. ده مش "أمان"، ده مقامرة على إن المستخدم ما يكتشفش الباگ قبلك.
مثال للمبتدئ علشان نفهم الفكرة
تخيّل مطعم بيغيّر صلصة الباستا. الطريقة العادية: بيقدّموا الصلصة الجديدة لكل العملاء فوراً. لو طلعت مالحة، 200 طبق بيتباع قبل ما الـ chef ياكل واحد ويكتشف. Canary deployment زي إن الـ chef يدوق الصلصة هو الأول، بعدين يقدّمها لـ 5 عملاء، بعدين 20، بعدين الكل. لو طلعت فيها مشكلة في أي مرحلة، بيرجع للصلصة القديمة قبل ما الباقي يجرّبها.
التعريف العلمي: Canary Deployment هي استراتيجية progressive delivery بتوجّه نسبة محدودة من production traffic لإصدار جديد، تقيس indicators معرّفة (error rate, latency, business metrics)، وبتقرر تلقائياً إكمال الـ rollout أو الرجوع بناءً على تحليل إحصائي. الاسم جاي من "canary in a coal mine" — العصفور اللي كان بيموت قبل عمال المنجم لو الهوا فيه غاز.
ليه RollingUpdate العادي مش كفاية
RollingUpdate بيحل مشكلة zero-downtime، لكن مش بيحل مشكلة detection. الـ readiness probe بتشيك إن الـ pod بيرد على HTTP، مش إن الإصدار الجديد بيرد بنفس الجودة. ركز على النقطة دي: pod ممكن يكون Ready و response time عنده 4x الإصدار القديم وerror rate 6%. RollingUpdate ميشوفش الفرق ده — هو بس بيشيك إن الـ liveness و readiness بيرجعوا 200.
الافتراض إن الـ unit tests و integration tests كافية لاكتشاف كل المشاكل قبل الإنتاج. ده افتراض غلط لأي تطبيق حقيقي: latency regressions، memory leaks بطيئة، behavior تحت traffic عالي، تفاعل مع cache بارد — كل ده ميتلقاش في staging.
Argo Rollouts: الـ controller اللي بياخد القرار من metrics
Argo Rollouts بيستبدل Deployment resource بـ Rollout. ده CRD بيتحكم في حركة الترافيك بـ steps واضحة، وكل step ممكن يستدعي AnalysisTemplate يقيس indicators من Prometheus, Datadog, CloudWatch أو حتى Web requests، ويقرر يكمل أو يعمل rollback.
