🏀 🚣🏿 🔊 منهجية نشر المشروع التي يستخدمها سلاك 🌻 💇🏻 🍦

يتطلب اختتام إصدار مشروع جديد في الإنتاج موازنة دقيقة بين سرعة النشر وموثوقية الحل. يقدر Slack التكرارات السريعة وحلقات الملاحظات القصيرة والاستجابة لطلبات المستخدمين. بالإضافة إلى ذلك ، لدى الشركة مئات المبرمجين الذين يسعون جاهدين لتحقيق أعلى إنتاجية ممكنة.

يقول مؤلفو المادة ، التي ننشر ترجمتها اليوم ، إن الشركة التي تسعى إلى الالتزام بهذه القيم وفي الوقت نفسه تنمو يجب أن تحسن باستمرار نظام نشر المشروع الخاص بها. تحتاج الشركة إلى الاستثمار في شفافية وموثوقية إجراءات العمل ، من أجل التأكد من أن هذه العمليات تتوافق مع نطاق المشروع. سنتحدث هنا عن عمليات العمل التي تم تطويرها في Slack ، وعن بعض الحلول التي دفعت الشركة إلى استخدام نظام نشر المشروع الموجود اليوم.

كيف تعمل عمليات نشر المشروع اليوم

يجب أن يخضع كل PR (طلب سحب) في Slack لمراجعة الرمز ويجب أن يجتاز جميع الاختبارات بنجاح. فقط بعد استيفاء هذه الشروط ، يمكن للمبرمج دمج شفرته مع الفرع الرئيسي للمشروع. ومع ذلك ، يتم نشر مثل هذا الرمز فقط خلال ساعات العمل وفقًا لتوقيت أمريكا الشمالية. نتيجة لذلك ، نحن ، بسبب حقيقة أن موظفينا في العمل ، على استعداد تام لحل أي مشاكل غير متوقعة.

كل يوم نكمل حوالي 12 عملية نشر مخطط لها. خلال كل عملية نشر ، يكون المبرمج ، المعين على أنه النشر الرئيسي ، مسؤولاً عن جلب التجميع الجديد إلى الإنتاج. هذه عملية متعددة الخطوات ، توفر خاتمة سلسة للتجميع في وضع العمل. بفضل هذا النهج ، يمكننا اكتشاف الأخطاء قبل أن تؤثر على جميع مستخدمينا. إذا كان هناك الكثير من الأخطاء ، يمكن إعادة نشر التجميع. إذا تم الكشف عن مشكلة معينة بعد الإصدار ، فيمكن بسهولة إصلاحها.

واجهة نظام Checkpoint التي يستخدمها Slack لنشر المشاريع ،

ويمكن تمثيل عملية نشر إصدار جديد في الإنتاج في أربع خطوات.

▍1. إنشاء فرع الإصدار

يبدأ كل إصدار بفرع إصدار جديد ، من اللحظة في تاريخ Git. يسمح لك هذا بتعيين علامات للإصدار ويوفر مكانًا يمكنك فيه إجراء تصحيحات تشغيلية للأخطاء الموجودة في عملية إعداد الإصدار للإصدار في الإنتاج.

▍2. الانتشار المتوسط

الخطوة التالية هي نشر التجميع على خوادم التدريج وتشغيل اختبار تلقائي للأداء العام للمشروع (اختبار الدخان). البيئة الوسيطة هي بيئة إنتاج لا تقع فيها حركة المرور الخارجية. في هذه البيئة ، نقوم بإجراء اختبار يدوي إضافي. وهذا يمنحنا ثقة إضافية بأن المشروع المعدل يعمل بشكل صحيح. الاختبارات الآلية وحدها ليست كافية لاكتساب هذه الثقة.

▍3. الانتشار في طعام الكلاب وبيئات الكناري

يبدأ النشر في الإنتاج ببيئة تجريبية ممثلة بمجموعة من المضيفين الذين يخدمون مساحات عمل Slack الداخلية لدينا. نظرًا لأننا مستخدمون نشطون جدًا لـ Slack ، فقد ساعد استخدام هذا النهج على اكتشاف العديد من الأخطاء في المراحل الأولى من النشر. بعد أن نتأكد من أن الوظيفة الأساسية للنظام ليست معطلة ، يتم نشر التجميع في بيئة الكناري. إنه نظام يتلقى حوالي 2٪ من حركة الإنتاج.

▍4. الاستنتاج التدريجي في الإنتاج

إذا تبين أن مؤشرات المراقبة للإصدار الجديد مستقرة ، وإذا لم نتلق شكاوى بعد نشر المشروع في بيئة الكناري ، فإننا نواصل النقل التدريجي لخوادم الإنتاج إلى الإصدار الجديد. تنقسم عملية النشر إلى المراحل التالية: 10٪ و 25٪ و 50٪ و 75٪ و 100٪. ونتيجة لذلك ، يمكننا نقل حركة مرور الإنتاج ببطء إلى إصدار نظام جديد. في الوقت نفسه ، لدينا الوقت للتحقيق في الوضع في حالة الكشف عن بعض الشذوذ.

hat ماذا لو حدث خطأ أثناء النشر؟

إجراء تعديلات على التعليمات البرمجية دائمًا مخاطرة. ولكن يمكننا التعامل مع هذا بفضل "مدراء النشر" لدينا المدربين تدريباً جيداً والذين يديرون عملية إدخال إصدار جديد في الإنتاج ومراقبة مراقبة الأداء وتنسيق عمل المبرمجين الذين يطلقون الشفرة.

في حالة حدوث خطأ ما ، نحاول الكشف عن المشكلة في أقرب وقت ممكن. نحن نحقق في المشكلة ، ونعثر على العلاقات العامة التي تسبب الأخطاء ، ثم نعيدها ونحللها بعناية وننشئ تجميعًا جديدًا. صحيح ، في بعض الأحيان تمر المشكلة دون أن يلاحظها أحد قبل وضع المشروع في الإنتاج. في مثل هذه الحالة ، فإن أهم شيء هو استعادة الخدمة. لذلك ، قبل البدء في التحقيق في المشكلة ، نعود على الفور إلى جمعية العمل السابقة.

وحدات بناء النشر

فكر في التقنيات التي يقوم عليها نظام نشر مشروعنا.

deploy عمليات النشر السريع

قد يبدو سير العمل الموصوف أعلاه ، في وقت لاحق ، شيئًا واضحًا تمامًا. لكن نظام النشر الخاص بنا لم يصبح بعيدًا على الفور.

عندما كانت الشركة أصغر بكثير ، يمكن أن يعمل تطبيقنا بالكامل على 10 حالات من Amazon EC2. يعني نشر مشروع في هذه الحالة استخدام rsync لمزامنة جميع الخوادم بسرعة. في السابق ، تم فصل الرمز الجديد عن الإنتاج بخطوة واحدة فقط ، ممثلة ببيئة وسيطة. تم إنشاء التجميعات واختبارها في مثل هذه البيئة ، ثم انتقلت مباشرة إلى الإنتاج. كان فهم مثل هذا النظام بسيطًا للغاية ؛ فقد سمح لأي مبرمج بنشر الشفرة التي كتبها في أي وقت.

ولكن مع نمو عدد عملائنا ، ازداد حجم البنية التحتية اللازمة لضمان تشغيل المشروع. قريبًا ، نظرًا للنمو المستمر للنظام ، توقف نموذج النشر ، القائم على إرسال رمز جديد إلى الخوادم ، عن التعامل مع مهمته. أي أن إضافة كل خادم جديد يعني زيادة في الوقت المطلوب لإكمال النشر. حتى الاستراتيجيات القائمة على الاستخدام الموازي لـ rsync لها قيود معينة.

ونتيجة لذلك ، قمنا بحل هذه المشكلة عن طريق التبديل إلى نظام نشر متوازي تمامًا ، والذي لم يتم ترتيبه مثل النظام القديم. وبالتحديد ، لم نرسل الرمز إلى الخوادم باستخدام البرنامج النصي للمزامنة. الآن قام كل خادم بشكل مستقل بتنزيل تجميع جديد ، مع العلم أنه يجب القيام به ، وذلك بفضل ملاحظة تغيير مفتاح القنصل. قامت الخوادم بتنزيل الكود بالتوازي. هذا سمح لنا بالحفاظ على سرعة نشر عالية حتى في بيئة النمو المستمر للنظام.

1. خوادم الإنتاج تراقب مفتاح القنصل. 2. المفتاح يتغير ، هذا يخبر الخوادم أنهم بحاجة لبدء تنزيل رمز جديد. 3. تقوم الخوادم بتحميل ملفات tarball برمز التطبيق

deploy عمليات النشر الذرية

الحل الآخر الذي ساعدنا في الوصول إلى نظام نشر متعدد المستويات كان النشر الذري.

قبل استخدام عمليات النشر الذرية ، قد ينتج عن كل عملية نشر عدد كبير من رسائل الخطأ. والحقيقة هي أن عملية نسخ الملفات الجديدة إلى خوادم الإنتاج لم تكن ذرية. أدى ذلك إلى وجود فترة زمنية قصيرة عندما كان الرمز الذي تم استدعاء الوظائف الجديدة فيه متاحًا قبل أن تصبح الوظائف نفسها متاحة. عندما تم استدعاء هذا الرمز ، أعاد أخطاء داخلية. وقد تجلى ذلك في طلبات واجهة برمجة التطبيقات غير الناجحة وفي صفحات الويب المعطلة.

قام الفريق الذي تعامل مع هذه المشكلة بحلها من خلال تقديم مفهوم الدلائل "الساخنة" (الساخنة) و "الباردة" (الباردة). التعليمات البرمجية في الدليل "hot" مسؤولة عن معالجة حركة مرور الإنتاج. وفي الدلائل "الباردة" ، يستعد الرمز ، أثناء تشغيل النظام ، للاستخدام فقط. أثناء النشر ، يتم نسخ الرمز الجديد إلى الدليل "البارد" غير المستخدم. ثم ، عندما لا تكون هناك عمليات نشطة على الخادم ، يتم تبديل الدلائل على الفور.

1. فك شفرة التطبيق في دليل "بارد". 2. تحويل النظام إلى دليل "بارد" ، يصبح "ساخنًا" (التشغيل الذري)

خلاصة القول: تحول في التركيز على الموثوقية

في عام 2018 ، نما المشروع إلى هذا النطاق الذي بدأ النشر السريع جدًا فيه يضر باستقرار المنتج. كان لدينا نظام نشر متقدم للغاية استثمرنا فيه الكثير من الوقت والجهد. نحن بحاجة فقط إلى إعادة هيكلة وتحسين عمليات تنظيم النشر. لقد أصبحنا شركة كبيرة إلى حد ما ، تم استخدام تطويرها في جميع أنحاء العالم لتنظيم اتصالات غير متقطعة وحل المشكلات الهامة. لذلك ، كان تركيز انتباهنا على الموثوقية.

كنا بحاجة إلى جعل عملية نشر إصدارات Slack الجديدة أكثر أمانًا. قادتنا هذه الحاجة إلى تحسين نظام النشر لدينا. في الواقع ، أعلاه ناقشنا هذا النظام المحسن. في أحشاء النظام ، نواصل استخدام تقنيات النشر السريع والذري. تم تغيير طريقة تنفيذ النشر بالضبط. تم تصميم نظامنا الجديد لنشر رمز جديد تدريجيًا على مستويات مختلفة في بيئات مختلفة. الآن نستخدم أدوات وأدوات مساعدة أكثر تقدمًا من ذي قبل لمراقبة النظام. وهذا يمنحنا الفرصة لالتقاط الأخطاء وإزالتها قبل وقت طويل من حصولها على فرصة الوصول إلى المستخدم النهائي.

لكننا لن نتوقف عند هذا الحد. نحن نعمل باستمرار على تحسين هذا النظام باستخدام أدوات مساعدة وأدوات أتمتة أكثر تقدمًا.

القراء الأعزاء! كيف تتم عملية نشر إصدارات المشروع الجديدة حيث تعمل؟

منهجية نشر المشروع التي يستخدمها سلاك