في GitLab، نقوم بمعالجة إصلاحات البرامج بطريقتين: يدويًا وتلقائيًا. تابع القراءة للتعرف على مهمة مدير الإصدار المتمثلة في إنشاء التحديثات المهمة وتقديمها عبر النشر التلقائي على gitlab.com، بالإضافة إلى التصحيحات التي يمكن للمستخدمين العمل بها على عمليات التثبيت الخاصة بهم.
أوصي بإعداد تذكير على ساعتك الذكية: في الثاني والعشرين من كل شهر، يمكن للمستخدمين الذين يعملون مع GitLab في منشآتهم رؤية تحديثات الإصدار الحالي من منتجنا. يحتوي الإصدار الشهري على ميزات جديدة، وتطويرات على الميزات الحالية، وغالبًا ما يُظهر النتيجة النهائية لطلبات المجتمع للأدوات أو عمليات الدمج.
ولكن، كما تظهر الممارسة، نادرا ما يكون تطوير البرمجيات خاليا من العيوب. عند اكتشاف خطأ أو ثغرة أمنية، يقوم مدير الإصدار في فريق التسليم بإنشاء تصحيح لمستخدمينا مع عمليات التثبيت الخاصة بهم. يتم تحديث Gitlab.com أثناء عملية القرص المضغوط. نحن نسمي عملية النشر التلقائي لعملية القرص المضغوط لتجنب الخلط مع ميزة القرص المضغوط في GitLab. يمكن أن تتضمن هذه العملية اقتراحات من طلبات السحب المقدمة من المستخدمين والعملاء وفريق التطوير الداخلي لدينا، بحيث يتم حل المشكلة المملة المتمثلة في إصدار التصحيحات بطريقتين مختلفتين تمامًا.
«نحن نضمن نشر كل ما يصنعه المطورون في جميع البيئات يوميًا قبل طرحه على GitLab.com"، يوضح ، مدير فني أول، قسم البنية التحتية. "فكر في الإصدارات الخاصة بعمليات التثبيت الخاصة بك باعتبارها لقطات لعمليات نشر gitlab.com، والتي أضفنا لها خطوات منفصلة لإنشاء حزمة بحيث يمكن لمستخدمينا استخدامها للتثبيت على عمليات التثبيت الخاصة بهم".
بغض النظر عن الخطأ أو الثغرة الأمنية، سيتلقى عملاء gitlab.com الإصلاحات بعد وقت قصير من نشرها، وهو ما يعد أحد فوائد عملية القرص المضغوط التلقائية. تتطلب التصحيحات المخصصة للمستخدمين الذين لديهم عمليات التثبيت الخاصة بهم إعدادًا منفصلاً من قبل مدير الإصدار.
يعمل فريق التسليم بجد لأتمتة معظم العمليات المتضمنة في إنشاء الإصدارات لتقليلها (متوسط الوقت حتى الإنتاج، أي الوقت المستغرق في الإنتاج)، وهي الفترة الزمنية من معالجة طلب الدمج بواسطة المطور إلى النشر على gitlab.com.
«هدف فريق التوصيل هو التأكد من قدرتنا على التحرك بشكل أسرع كشركة، أو على الأقل جعل موظفي التوصيل يعملون بشكل أسرع، أليس كذلك؟"، يقول مارين.
يستفيد كل من عملاء gitlab.com ومستخدمي عمليات التثبيت الخاصة بهم من جهود فريق التسليم لتقليل أوقات الدورات وتسريع عمليات النشر. وفي هذه المقالة سنشرح أوجه التشابه والاختلاف بين هاتين الطريقتين. ، وسنصف أيضًا كيف يقوم فريق التسليم لدينا بإعداد التصحيحات للمستخدمين الذين يعملون في منشآتهم، بالإضافة إلى كيفية ضمان تحديث gitlab.com باستخدام النشر الآلي.
ماذا يفعل مدير الإصدار؟
أعضاء الفريق شهريا إصداراتنا للمستخدمين في منشآتهم، بما في ذلك التصحيحات والإصدارات الأمنية التي قد تحدث بين الإصدارات. كما أنهم مسؤولون أيضًا عن قيادة انتقال الشركة إلى النشر الآلي والمستمر.
توضح مارين أن إصدارات التثبيت الذاتي وإصدارات gitlab.com تستخدم مسارات عمل متشابهة ولكنها تعمل في أوقات مختلفة.
أولاً وقبل كل شيء، يضمن مدير الإصدار، بغض النظر عن نوع الإصدار، أن GitLab متاح وآمن منذ لحظة تشغيل التطبيق على gitlab.com، بما في ذلك التأكد من أن نفس المشكلات لا تنتهي في البنية التحتية للعملاء مع القدرات الخاصة.
بمجرد تحديد خطأ أو ثغرة أمنية كإصلاح في GitLab، يجب على مدير الإصدار تقييم أنه سيتم تضمينها في التصحيحات أو التحديثات الأمنية للمستخدمين مع عمليات التثبيت الخاصة بهم. إذا قرر أن خطأ ما أو ثغرة أمنية تستحق التحديث، يبدأ العمل التحضيري.
يجب أن يقرر مدير الإصدار ما إذا كان سيتم إعداد الإصلاح أو متى سيتم نشره - وهذا يعتمد بشكل كبير على سياق الموقف.وفي غضون ذلك، فإن الآلات ليست جيدة في إدارة السياق مثل البشر" يقول مارين.
الأمر كله يتعلق بالإصلاحات
ما هي التصحيحات ولماذا نحتاجها؟
يقرر مدير الإصدار ما إذا كان سيتم إصدار إصلاح أم لا بناءً على خطورة الخطأ.
تختلف الأخطاء حسب خطورتها. لذلك يمكن أن تكون أخطاء S4 أو S3 أسلوبية، مثل إزاحة البكسل أو الرمز. وهذا لا يقل أهمية، ولكن ليس هناك تأثير كبير على سير عمل أي شخص، مما يعني أن احتمالية إنشاء إصلاح لمثل هذه الأخطاء S3 أو S4 ضئيلة، كما يوضح مارين.
ومع ذلك، تعني الثغرات الأمنية S1 أو S2 أنه لا ينبغي للمستخدم التحديث إلى الإصدار الأحدث، أو أن هناك خطأ كبيرًا يؤثر على سير عمل المستخدم. إذا تم تضمينها في أداة التعقب، فقد واجهها العديد من المستخدمين، لذلك يبدأ مدير الإصدار على الفور في إعداد الإصلاح.
بمجرد أن يصبح تصحيح الثغرات الأمنية S1 أو S2 جاهزًا، يبدأ مدير الإصدار في إصدار التصحيح.
على سبيل المثال، تم إنشاء تصحيح GitLab 12.10.1 بعد تحديد العديد من مشكلات الحظر وقام المطورون بإصلاح المشكلة الأساسية التي كانت تسببها. قام مدير الإصدار بتقييم صحة مستويات الخطورة المعينة، وبعد التأكيد، تم إطلاق عملية إصدار الإصلاح، والذي أصبح جاهزًا خلال XNUMX ساعة بعد اكتشاف مشكلات الحظر.
عندما يتراكم الكثير من S4 وS3 وS2، ينظر مدير الإصدار إلى السياق لتحديد مدى إلحاح إصدار الإصلاح، وعندما يتم الوصول إلى عدد معين منها، يتم دمجها جميعًا وإصدارها. يتم تلخيص إصلاحات ما بعد الإصدار أو التحديثات الأمنية في منشورات المدونة.
كيف يقوم مدير الإصدار بإنشاء التصحيحات
نحن نستخدم GitLab CI وميزات أخرى مثل ChatOps الخاصة بنا لإنشاء التصحيحات. يقوم مدير الإصدار بتشغيل إصدار الإصلاح عن طريق تنشيط فريق ChatOps على قناتنا الداخلية #releases في سلاك.
/chatops run release prepare 12.10.1يعمل ChatOps ضمن Slack لتشغيل أحداث مختلفة، والتي تتم بعد ذلك معالجتها وتنفيذها بواسطة GitLab. على سبيل المثال، قام فريق التسليم بإعداد ChatOps لأتمتة أشياء مختلفة لإصدار التصحيحات.
بمجرد أن يبدأ مدير الإصدار فريق ChatOps في Slack، فإن بقية العمل يحدث تلقائيًا في GitLab باستخدام CICD. يوجد اتصال ثنائي الاتجاه بين ChatOps في Slack وGitLab أثناء عملية الإصدار حيث يقوم مدير الإصدار بتنشيط بعض الخطوات الرئيسية في العملية.
يوضح الفيديو أدناه العملية الفنية لإعداد التصحيح لـ GitLab.
كيف يعمل النشر التلقائي على gitlab.com
تشبه العملية والأدوات المستخدمة لتحديث gitlab.com تلك المستخدمة لإنشاء التصحيحات. يتطلب تحديث gitlab.com عملًا يدويًا أقل من وجهة نظر مدير الإصدار.
بدلاً من تشغيل عمليات النشر باستخدام ChatOps، نستخدم ميزات CI، على سبيل المثال. ، والتي يمكن لمدير الإصدار من خلالها جدولة إجراءات معينة ليتم تنفيذها في الوقت المطلوب. بدلاً من العملية اليدوية، هناك مسار يتم تشغيله بشكل دوري مرة كل ساعة لتنزيل التغييرات الجديدة التي تم إجراؤها على مشاريع GitLab، وتجميعها وجدولة النشر، وتشغيل الاختبار وضمان الجودة والخطوات الضرورية الأخرى تلقائيًا.
يقول مارين: "لذا، لدينا الكثير من عمليات النشر التي كانت تعمل في بيئات مختلفة قبل gitlab.com، وبعد أن تصبح تلك البيئات في حالة جيدة ويظهر الاختبار نتائج جيدة، يبدأ مدير الإصدار في إجراءات نشر gitlab.com".
تعمل تقنية CICD لدعم تحديثات gitlab.com على أتمتة العملية بأكملها إلى النقطة التي يجب على مدير الإصدار فيها تشغيل نشر بيئة الإنتاج يدويًا على gitlab.com.
يشرح Marin بالتفصيل عملية تحديث gitlab.com في الفيديو أدناه.
ماذا يفعل فريق التوصيل أيضًا؟
يتمثل الاختلاف الرئيسي بين عمليات تحديث gitlab.com وإصدار التصحيحات للعملاء داخليًا في أن العملية الأخيرة تتطلب مزيدًا من الوقت والمزيد من العمل اليدوي من مدير الإصدار.
يقول مارين: "نقوم أحيانًا بتأخير إصدار التصحيحات للعملاء مع عمليات التثبيت الخاصة بهم بسبب مشكلات تم الإبلاغ عنها، ومشكلات في الأدوات، ولأن هناك العديد من الفروق الدقيقة التي يجب أخذها في الاعتبار عند إصدار تصحيح واحد".
أحد الأهداف قصيرة المدى لفريق التسليم هو تقليل حجم العمل اليدوي من جانب مدير الإصدار لتسريع الإصدار. يعمل الفريق على تبسيط عملية الإصدار وتبسيطها وأتمتتها، مما سيساعد في الحصول على إصلاحات للمشكلات منخفضة الخطورة (S3 وS4، تقريبا. مترجم). يعد التركيز على السرعة مؤشرًا رئيسيًا للأداء: من الضروري تقليل MTTP - الوقت من تلقي طلب دمج إلى نشر النتيجة على gitlab.com - من 50 ساعة حاليًا إلى 8 ساعات.
يعمل فريق التسليم أيضًا على ترحيل gitlab.com إلى البنية التحتية المستندة إلى Kubernetes.
محرر n.b.: إذا كنت قد سمعت بالفعل عن تقنية Kubernetes (وليس لدي شك في ذلك)، ولكنك لم تلمسها بيديك بعد، فإنني أوصي بالمشاركة في الدورات المكثفة عبر الإنترنت ، والتي ستعقد في الفترة من 28 إلى 30 سبتمبر ، و والتي ستقام في الفترة من 14 إلى 16 أكتوبر. سيسمح لك ذلك بالتنقل بثقة والعمل مع التكنولوجيا.
هذان نهجان يسعيان إلى نفس الهدف: التسليم السريع للتحديثات، لكل من gitlab.com والعملاء في منشآتهم.
أي أفكار أو توصيات بالنسبة لنا؟
الجميع مدعوون للمساهمة في GitLab، ونحن نرحب بتعليقات قرائنا. إذا كان لديك أي أفكار لفريق التوصيل لدينا، فلا تتردد ملحوظ team: Delivery.
المصدر: www.habr.com