المقدمة
لما نيجي نتكلم عن الـ Deployment Strategies اللي بتستخدمها الشركات الكبيرة، الهدف الأساسي بيبقى إننا ننقل التحديثات الجديدة للـ Production Environment بأقل تأثير سلبي ممكن على المستخدمين.
فورقة وقلم وخلونا نستعرض الأنواع المختلفة من الاستراتيجيات دي مع مميزات وعيوب كل واحدة فيهم 🚀
Blue-Green Deployment
في الاستراتيجية دي بيبقى عندنا بيئتين شغالين في نفس الوقت: بيئة قديمة بتبقى هي دي الـ (Blue) وبيئة جديدة بتكون هي دي الـ (Green).
أول ما التحديث الجديد يبقى جاهز، بنحول الـ Traffic من بيئة الـ Blue للـ Green مرة واحدة. فيبدأ الناس بدل ما كانت بتروح للـ Blue Deployment تروح للـ Green وهنا بنتكلم طبعًا عن Real Traffic اتعمله Routing باستعمال Load Balancer للـ Green Deployments.
مميزات الـ Blue-Green Deployment:
- تقليل الـ Downtime لأن الـ Traffic بيتحول بالكامل مرة واحدة.
- لو حصلت مشكلة، الرجوع للبيئة القديمة بيبقى سهل وسريع لإن احنا لسه عندنا الـ Blue Environment لسه موجودة.
عيوب الـ Blue-Green Deployment:
- محتاج موارد زيادة لإن بيئتين لازم يكونوا شغالين في نفس الوقت مع بعض.
مثال على ده: شركات كتيرة زي Amazon وغيرها بتستخدم الـ Blue-Green Deployment عشان تحافظ على استمرارية الخدمات بدون تأثير على المستخدمين وعشان يبقى سهل بالنسبالهم يرجعوا للبيئة القديمة لو حصل أي مشاكل غير متوقعة.
Canary Deployment
الاستراتيجية دي بتعتمد على إننا ننقل التحديث بشكل تدريجي يعني Gradually لعدد محدود من المستخدمين الأول، ولو الأمور مشيت كويس، نكمل تعميم التحديث لباقي المستخدمين.
وليكن هنعمل Apply على التحديث الجديد لـ 20% من الـ Machines اللي عندنا و 80% هيفضلوا لسه محافظين على النسخة القديمة وبالتالي الناس لما يطلبوا الخدمة 20% منهم هيروح للجديد و 80% هيفضلوا لسه بيجيلهم النسخة القديمة والنسبة دي طبعا احنا بنتحكم فيها على حسب احتياجاتنا.
مميزات الـ Canary Deployment:
- لو فيه أي مشاكل، بتأثر على عدد محدود من المستخدمين بس.
- بتساعد في اختبار التحديث الجديد في البيئة الحقيقية.
عيوب الـ Canary Deployment:
- محتاجين Monitoring دقيق عشان نعرف إذا كان فيه مشاكل بسرعة.
مثال: شركات زي Google و Netflix بتستخدم Canary Deployment عشان تجرب الـ Features الجديدة قبل تعميمها على كل المستخدمين وبالتالي يكون فيه نسبة بس بيجيلهم التحديث الجديد ونسبة تانية لسه بيظهرلهم النسخة القديمة.
Rolling Deployment
في الـ Rolling Deployment، التحديث بيتنقل بشكل تدريجي لمجموعة من السيرفرات بدلاً من نقل التحديث بالكامل مرة واحدة.
فلو عندنا مثلا 10 Servers هيبدأ يتعمله Apply على واحد تلو الآخر بشكل تدريجي لحد مايتم على كل الأجهزة والـ Servers اللي موجودة.
مميزات الـ Rolling Deployment:
- الـ Downtime قليل جداً لإن السيرفرات بتتحدث واحدة واحدة.
- بيقلل المخاطرة لأن التحديث بيكون بشكل تدريجي.
عيوب الـ Rolling Deployment:
- لو حصلت مشكلة، صعب ترجّع التحديث لكل السيرفرات بشكل سريع وده لإن احنا محتاجين نـ Rollback كل جهاز بشكل تدريجي ونرجع للنسخة القديمة فهياخد وقت.
مثال: فيه شركات بتفضل تستخدم الـ Rolling Deployment عشان تتجنب المشاكل الناتجة عن تحديث كل السيرفرات مرة واحدة فيبقى الموضوع ماشي واحدة واحدة وبشكل تدريجي.
A/B Testing Deployment
دي استراتيجية بتساعدنا إننا نختبر التحديث الجديد على مجموعة من المستخدمين، بس الفرق هنا إننا بنقارن بين نسختين مختلفتين من الـ Feature (مثلاً واجهة جديدة مقابل واجهة قديمة) في نفس الوقت.
طب يفرق ايه ده عن الـ Canary Deployment ؟
يفرق كتير لإن هنا الغرض اننا ناخد Feedback وعشان كده بنقول A/B Testing فبنشوف مثلا لو غيرنا الوجهة بتاعة الموقع بتاعنا وعرضناه على 50% من المستخدمين هل الـ Traffic كان عامل ازاي وقتها ؟ مقارنة بالناس اللي كان لسه عندهم الواجهة القديمة .. وهكذا مع أي Feature.
وممكن يتم استعمال الـ A/B Testing عشان نشوف Features بننزلها على الـ Mobile Devices ونشوف الـ Feedback اللي هيجي مقارنة بالـ Web Version مثلا وهل هنحتاج نزودها في الـ Web Version ولا لا.
فالـ A/B Testing الغرض منه اننا اصلا عارفين الـ Functionality بس يهمنا ناخد Feedback من شكل الـ UI مثلا أو من ان الـ Feature الجديدة زودت الـ Traffic او نالت رضا الناس مقارنة بالـ Feature القديمة.
ولكن في الـ Canary Deployment احنا اصلا التغيير بنفرضه بنسبة معينة ، عشان نشوف الدنيا كويسة ولا لا مع Real Traffic ومع Users حقيقين ، ولو النتيجة كويسة نكمل ونوصل للـ 100% Deployment لكل الـ Machines.
مميزات الـ A/B Testing:
- بتساعدنا ناخد Feedback من المستخدمين ونعرف إذا كانت التغييرات مفيدة ولا لا.
- بتدينا نظرة واضحة عن تأثير التحديث الجديد ده.
عيوب الـ A/B Testing:
- محتاجة وقت ومراقبة عشان نعرف النتائج بشكل دقيق.
مثال: كتير من مواقع التجارة الإلكترونية زي eBay بتستخدم A/B Testing عشان تختبر تجارب مستخدم جديدة وكذلك شركة زي Booking.com ووضحوا المنهاج ده في أكتر من Blog تقدروا تقرأوا عنهم.
Shadow Deployment
في النوع ده، التحديث بيكون شغال جنب النسخة القديمة بدون ما المستخدمين يحسّوا بالتغيير، الهدف هنا هو إننا نراقب أداء التحديث قبل تعميمه.
فنقدر نقول اننا عندنا Environment بيحصل فيها Duplication او تكرار للـ Real Traffic على الـ Environment دي وبنبدأ نراقب السلوك هيكون عامل ازاي قبل ما نعمم التحديث اصلا والـ Users الحقيقين مش هيحسوا بأي حاجة لإن ده Duplicated Traffic والـ Traffic الاصلي هو النسخة القديمة اللي شغالة.
مميزات الـ Shadow Deployment:
- بنقدر نختبر التحديث في نفس ظروف البيئة الحقيقية.
- لو حصلت مشكلة، مفيش تأثير على المستخدمين.
عيوب الـ Shadow Deployment:
- محتاج موارد كبيرة لإن فيه نسخة موازية من التطبيق شغالة.
مثال: شركات كتيرة زي Airbnb وغيرها بتستخدم Shadow Deployment عشان تتابع أداء الـ Features الجديدة قبل ما تطرحها للمستخدمين.
Recreate Deployment
الاستراتيجية دي بتعتمد على فكرة بسيطة جدًا، وهي إننا بنوقف السيرفرات اللي عليها الإصدار القديم وبعدين نشغل التحديث الجديد مرة واحدة.
مميزات الـ Recreate Deployment:
- مش معقدة في التنفيذ لأنها بتتم مرة واحدة.
- مش محتاجة موارد كتير لإنك مش بتشغل بيئات موازية.
عيوب الـ Recreate Deployment:
- بيكون فيه Downtime خلال عملية الـ Deployment، وبالتالي ممكن يأثر على تجربة المستخدم بالسلب.
مثال: ممكن نلاقي شركات صغيرة بتستخدم الاستراتيجية دي عشان التحديثات السريعة ومش محتاجة أي تعقيدات ولا موارد كتيرة أو لما يكون عدد المستخدمين قليل، لأن الـ Downtime هنا بيبقى قصير جدًا.
في الختام
اختيار الـ Deployment Strategy بيعتمد على حجم التحديث، حجم الـ Traffic، ومدى أهمية الخدمة اللي بتقدمها.
لو كنا مهتمين بتقليل المخاطرة وتجنب الـ Downtime، ممكن نلاقي إن Blue-Green أو Canary Deployment هما الأنسب. أما لو بندور على Feedback واضح، فالـ A/B Testing هتدينا أفضل نتائج.
Discussion