يتطلب إدخال إصدار مشروع جديد إلى الإنتاج توازنًا دقيقًا بين سرعة النشر وموثوقية الحل. يُقدر Slack التكرارات السريعة ودورات التعليقات القصيرة والاستجابة السريعة لطلبات المستخدم. بالإضافة إلى ذلك، تمتلك الشركة المئات من المبرمجين الذين يسعون جاهدين ليكونوا منتجين قدر الإمكان.
يقول مؤلفو المادة، التي ننشر ترجمتها اليوم، إن الشركة التي تسعى جاهدة إلى الالتزام بهذه القيم وفي الوقت نفسه تنمو، يجب عليها تحسين نظام نشر المشروع الخاص بها باستمرار. تحتاج الشركة إلى الاستثمار في الشفافية والموثوقية في عمليات العمل، وذلك للتأكد من أن هذه العمليات تتوافق مع حجم المشروع. سنتحدث هنا عن سير العمل الذي تطور في Slack، وعن بعض القرارات التي دفعت الشركة إلى استخدام نظام نشر المشروع الموجود اليوم.
كيف تعمل عمليات نشر المشروع اليوم
يجب أن يخضع كل طلب سحب (PR) في Slack لمراجعة الكود ويجب أن يجتاز جميع الاختبارات بنجاح. فقط بعد استيفاء هذه الشروط يمكن للمبرمج دمج الكود الخاص به في الفرع الرئيسي للمشروع. ومع ذلك، يتم نشر هذا الرمز فقط خلال ساعات العمل، بتوقيت أمريكا الشمالية. ونتيجة لذلك، ونظرًا لتواجد موظفينا في أماكن عملهم، فإننا على استعداد تام لحل أي مشاكل غير متوقعة.
نقوم كل يوم بتنفيذ حوالي 12 عملية نشر مخطط لها. أثناء كل عملية نشر، يكون المبرمج المعين كقائد للنشر مسؤولاً عن إدخال البنية الجديدة إلى مرحلة الإنتاج. هذه عملية متعددة الخطوات تضمن وصول التجميع إلى مرحلة الإنتاج بسلاسة. وبفضل هذا النهج، يمكننا اكتشاف الأخطاء قبل أن تؤثر على جميع مستخدمينا. إذا كان هناك الكثير من الأخطاء، فيمكن التراجع عن نشر التجميع. إذا تم اكتشاف مشكلة معينة بعد الإصدار، فيمكن بسهولة إصدار إصلاح لها.
واجهة نظام Checkpoint المستخدم في Slack لنشر المشاريع
يمكن اعتبار عملية نشر إصدار جديد للإنتاج تتكون من أربع خطوات.
▍1. إنشاء فرع الإصدار
يبدأ كل إصدار بفرع إصدار جديد، وهي نقطة في تاريخ Git لدينا. يسمح لك هذا بتعيين علامات للإصدار ويوفر مكانًا يمكنك من خلاله إجراء إصلاحات مباشرة للأخطاء الموجودة في عملية إعداد الإصدار للإصدار للإنتاج.
▍2. النشر في بيئة التدريج
والخطوة التالية هي نشر التجميع على خوادم مرحلية وتشغيل اختبار تلقائي للأداء العام للمشروع (اختبار الدخان). البيئة المرحلية هي بيئة إنتاج لا تتلقى حركة مرور خارجية. في هذه البيئة، نقوم بإجراء اختبارات يدوية إضافية. وهذا يمنحنا ثقة إضافية بأن المشروع المعدل يعمل بشكل صحيح. الاختبارات الآلية وحدها لا تكفي لتوفير هذا المستوى من الثقة.
▍3. النشر في بيئات الطعام التجريبي والكناري
يبدأ النشر إلى الإنتاج ببيئة تجريبية، ممثلة بمجموعة من المضيفين الذين يخدمون مساحات عمل Slack الداخلية لدينا. نظرًا لأننا من مستخدمي Slack النشطين جدًا، فقد ساعدنا اتباع هذا النهج في اكتشاف الكثير من الأخطاء في وقت مبكر من النشر. بعد أن نتأكد من عدم تعطل الوظيفة الأساسية للنظام، يتم نشر التجميع في بيئة الكناري. وهو يمثل الأنظمة التي تمثل حوالي 2% من حركة الإنتاج.
▍4. إطلاق تدريجي للإنتاج
إذا تبين أن مؤشرات المراقبة للإصدار الجديد مستقرة، وإذا لم نتلق أي شكاوى بعد نشر المشروع في بيئة الكناري، فإننا نستمر في نقل خوادم الإنتاج تدريجيًا إلى الإصدار الجديد. وتنقسم عملية النشر إلى المراحل التالية: 10%، 25%، 50%، 75%، و100%. ونتيجة لذلك، يمكننا نقل حركة الإنتاج ببطء إلى الإصدار الجديد من النظام. وفي الوقت نفسه، لدينا الوقت للتحقيق في الوضع إذا تم اكتشاف أي حالات شاذة.
▍ماذا لو حدث خطأ ما أثناء النشر؟
يعد إجراء تعديلات على التعليمات البرمجية دائمًا مخاطرة. لكننا نتعامل مع هذا بفضل وجود "قادة النشر" المدربين جيدًا الذين يديرون عملية إدخال إصدار جديد إلى الإنتاج، ويراقبون مؤشرات المراقبة وينسقون عمل المبرمجين الذين يطلقون التعليمات البرمجية.
في حالة حدوث خطأ ما، نحاول اكتشاف المشكلة في أقرب وقت ممكن. نحن نحقق في المشكلة، ونبحث عن العلاقات العامة التي تسببت في الأخطاء، ونسترجعها، ونحللها بدقة، وننشئ بنية جديدة. صحيح أن المشكلة في بعض الأحيان تمر دون أن يلاحظها أحد حتى يدخل المشروع مرحلة الإنتاج. في مثل هذه الحالة، الشيء الأكثر أهمية هو استعادة الخدمة. لذلك، قبل أن نبدأ في التحقيق في المشكلة، نعود فورًا إلى بنية العمل السابقة.
اللبنات الأساسية لنظام النشر
دعونا نلقي نظرة على التقنيات التي يقوم عليها نظام نشر مشروعنا.
▍ عمليات النشر السريع
قد يبدو سير العمل الموضح أعلاه واضحًا إلى حد ما. لكن نظام النشر لدينا لم يصبح بهذه الطريقة على الفور.
عندما كانت الشركة أصغر بكثير، كان من الممكن تشغيل تطبيقنا بالكامل على 10 مثيلات من Amazon EC2. يعني نشر المشروع في هذه الحالة استخدام rsync لمزامنة كافة الخوادم بسرعة. في السابق، كان الكود الجديد على بعد خطوة واحدة فقط من الإنتاج، ممثلاً ببيئة التدريج. تم إنشاء التجميعات واختبارها في مثل هذه البيئة، ثم انتقلت مباشرة إلى الإنتاج. كان من السهل جدًا فهم مثل هذا النظام، فهو يسمح لأي مبرمج بنشر التعليمات البرمجية التي كتبها في أي وقت.
ولكن مع نمو عدد عملائنا، زاد أيضًا حجم البنية التحتية اللازمة لدعم المشروع. وسرعان ما، ونظرًا للنمو المستمر للنظام، لم يعد نموذج النشر الخاص بنا، القائم على دفع التعليمات البرمجية الجديدة إلى الخوادم، يؤدي وظيفته. أي أن إضافة كل خادم جديد يعني زيادة الوقت اللازم لإكمال النشر. حتى الاستراتيجيات القائمة على الاستخدام المتوازي لـ rsync لها قيود معينة.
لقد انتهى بنا الأمر إلى حل هذه المشكلة بالانتقال إلى نظام نشر متوازي تمامًا، والذي تم تصميمه بشكل مختلف عن النظام القديم. وهي أننا لم نرسل الآن تعليمات برمجية إلى الخوادم باستخدام برنامج نصي للمزامنة. الآن قام كل خادم بتنزيل التجميع الجديد بشكل مستقل، مع العلم أنه بحاجة إلى القيام بذلك من خلال مراقبة تغيير مفتاح Consul. قامت الخوادم بتحميل الكود بالتوازي. وقد أتاح لنا ذلك الحفاظ على سرعة نشر عالية حتى في بيئة تتسم بالنمو المستمر للنظام.
1. تقوم خوادم الإنتاج بمراقبة مفتاح القنصل. 2. التغييرات الرئيسية، وهذا يخبر الخوادم أنهم بحاجة لبدء تنزيل التعليمات البرمجية الجديدة. 3. تقوم الخوادم بتنزيل ملفات tarball مع رمز التطبيق
▍ عمليات النشر الذرية
الحل الآخر الذي ساعدنا في الوصول إلى نظام نشر متعدد المستويات هو النشر الذري.
قبل استخدام عمليات النشر الذرية، قد يؤدي كل نشر إلى عدد كبير من رسائل الخطأ. الحقيقة هي أن عملية نسخ الملفات الجديدة إلى خوادم الإنتاج لم تكن عملية ذرية. أدى ذلك إلى فترة زمنية قصيرة حيث كان الكود الذي يستدعي الوظائف الجديدة متاحًا قبل توفر الوظائف نفسها. عندما تم استدعاء هذا الرمز، أدى ذلك إلى إرجاع أخطاء داخلية. وقد تجلى ذلك في طلبات واجهة برمجة التطبيقات الفاشلة وصفحات الويب المعطلة.
قام الفريق الذي عمل على حل هذه المشكلة بحلها من خلال تقديم مفهوم الدلائل "الساخنة" و"الباردة". الكود الموجود في الدليل الساخن مسؤول عن معالجة حركة الإنتاج. وفي الدلائل "الباردة"، يتم إعداد التعليمات البرمجية للاستخدام فقط أثناء تشغيل النظام. أثناء النشر، يتم نسخ التعليمات البرمجية الجديدة إلى دليل بارد غير مستخدم. وبعد ذلك، في حالة عدم وجود عمليات نشطة على الخادم، يتم إجراء تبديل الدليل الفوري.
1. تفريغ كود التطبيق في الدليل "البارد". 2. تحويل النظام إلى دليل "بارد"، والذي يصبح "ساخن" (التشغيل الذري)
النتائج: التحول في التركيز على الموثوقية
في عام 2018، نما المشروع إلى هذا النطاق لدرجة أن النشر السريع للغاية بدأ يضر باستقرار المنتج. كان لدينا نظام نشر متقدم للغاية واستثمرنا فيه الكثير من الوقت والجهد. كل ما يتعين علينا القيام به هو إعادة بناء عمليات النشر وتحسينها. لقد تطورنا لنصبح شركة كبيرة إلى حد ما، تم استخدام تطوراتها في جميع أنحاء العالم لتنظيم اتصالات متواصلة وحل المشكلات المهمة. ولذلك، أصبحت الموثوقية محور اهتمامنا.
كنا بحاجة إلى جعل عملية نشر إصدارات Slack الجديدة أكثر أمانًا. قادتنا هذه الحاجة إلى تحسين نظام النشر لدينا. في واقع الأمر، ناقشنا هذا النظام المحسن أعلاه. وفي أعماق النظام، نواصل استخدام تقنيات النشر السريع والذري. لقد تغيرت طريقة النشر. تم تصميم نظامنا الجديد لنشر تعليمات برمجية جديدة تدريجيًا على مستويات مختلفة وفي بيئات مختلفة. نستخدم الآن أدوات دعم وأدوات مراقبة النظام أكثر تقدمًا من ذي قبل. يمنحنا هذا القدرة على اكتشاف الأخطاء وإصلاحها قبل فترة طويلة من وصولها إلى المستخدم النهائي.
لكننا لن نتوقف عند هذا الحد. نحن نعمل باستمرار على تحسين هذا النظام، باستخدام أدوات مساعدة أكثر تقدمًا وأدوات أتمتة العمل.
القراء الأعزاء! كيف تتم عملية نشر إصدارات المشروع الجديدة في مكان عملك؟
المصدر: www.habr.com