كفريق للتوصيل لدينا ، باستخدام مواردنا الخاصة فقط ، أعيد تصميم نظامنا تحت CI / CD.
تتعرض فرق المهندسين لضغط مستمر: تحتاج إلى إعطاء وظائف جديدة في شكل منتج جيد وفي نفس الوقت تقلل وقت الدورة إلى الحد الأدنى. في كثير من الأحيان ، الخبراء دون فهم الاستيلاء على الأدوات الحديثة. تم دمج التكامل المستمر والتسليم (CI / CD) في GitLab ، تطبيق دورة حياة DevOps الوحيد لدينا ، والآن نحن ننتقل إلى Kubernetes لتقليل وقت الدورة إلى أبعد من ذلك. ومع ذلك ، إلى CI / CD - وفي النهاية Kubernetes - ذهبنا بطريقة غير عادية إلى حد ما. قام فريق التسليم ، بنقلنا إلى التسليم المستمر لـ GitLab.com ، بتوتر النظام القديم ، وعندها فقط انتقلنا تمامًا إلى Kubernetes.
كيف أصدرنا الإصدارات قبل CI / CD
بين 7 آب (أغسطس) و 27 أيلول (سبتمبر) 2019 ، وصل مجتمع GitLab الضخم وأعضاء فريقنا إلى 55 طلبًا في المتوسط يوميًا - هذه تكرارات مستمرة لمنتجنا لإنشاء ميزات جديدة. ولكن قبل أن نتقن التسليم المستمر ، استخدمنا فترات تجميد الوظائف الجديدة بدءًا من السابع من كل شهر: في هذا الوقت ، حوّل مهندسونا انتباههم من تطوير وظائف جديدة إلى تصحيح الأخطاء إلى إعداد الإصدارات القادمة التي ستصدر بثبات في 22 من كل شهر.
من خلال تقديم موعد نهائي صارم ، غرسنا في المطورين سلوكًا ساعدهم في النهاية على التركيز على تاريخ محدد ، بدلاً من التركيز على الاستعداد.
وقال مارين "... بدأ المطورون الرقص من التاريخ السابع ، لأنهم نظروا إلى التقويم والتفكير: حسنًا ، ما زال هناك وقت ، اليوم السابع في الأسبوع ، ثم ، عند منتصف الليل في السادس ، اندمجوا بشكل محموم". Jankowski ، CTO لفريق التسليم. "إنهم يعلمون أنه إذا انتهوا من المواعيد النهائية ، فسيتعين عليهم الانتظار لمدة شهر آخر ، وإذا تمكنوا من القيام بذلك في الوقت المناسب ، فسيكون أمامهم أسبوعان آخران لتصحيح الأخطاء".
منذ بداية GitLab.com ، استخدمت فترات تجميد الميزات الجديدة كوقت للاستقرار "، أوضح مارين.
ومع ذلك ، كان عدد المستخدمين ينمو والحاجة إلى ميزات جديدة أجبرنا على تسريع وتيرة التنمية. أدت فترة التثبيت إلى إبطاء الدورة وتأخرت إلى حد كبير في الانتقال إلى تصحيح الأخطاء والانحدار وتقديم المهام - للمستخدمين على موقع Gitlab.com والعملاء الفرديين.
وقال مارين "في بعض الحالات ، أثار [تجميد الميزات الجديدة] حتى عدم استقرار النظام الأساسي - بسبب حقيقة أن الإصلاحات ذات الأولوية العليا لم تصل إلى العميل في الوقت المحدد". - "بالانتقال إلى CI / CD ، نقدم منتجات جديدة ونصححها بشكل أسرع بكثير."
قبل تشكيل فريق التسليم لنقل GitLab.com إلى التسليم المستمر - وفي النهاية إلى Kubernetes - اعتمدنا على مدير الإصدار . كان هذا موقفًا انتقاليًا بين المطورين الذي كان يحتفظ به الشخص الذي كان يعد الإصدار الجديد. لقد تم تكرار هذه العملية لأكثر من 5 سنوات ، لكن مديري الإصدار أنشأوا قاعدة معارف وقاموا بتطبيقها بشكل آلي أو أقل.
ومع ذلك ، فقد تبين أن هذه الطريقة غير فعالة ، لأن جدول النشر والتحضير للإصدار طرحت: من نصف يوم إلى عدة أيام بسبب حقيقة أن مهام التنفيذ اليدوي كانت تتراكم في هذه العملية .
وقال مارين: "تلقى مدير الإصدار قائمة ثابتة من المهام ، وموعد نهائي ، وكرر الخطوات المذكورة أعلاه مرارًا وتكرارًا حتى تم الحصول على إصدار جاهز ومستقر تمامًا على GitLab.com". بمعنى عام ، كان ما يلي مطلوبًا من مدير الإصدار:
- مزامنة مستودعات التخزين التي تشكل GitLab يدويًا.
- تأكد من تضمين الإصدارات الصحيحة في فروع Git التي تم إنشاؤها يدويًا.
- عندما يتلقى الإصدار العلامات ، قم بنشر بيئات الاختبار والإنتاج يدويًا على GitLab.com.
- تأكد من أن كل شيء يعمل ، وانشر الحزم يدويًا للمستخدمين الفرديين.
في عرض تقديمي في بروكلين خلال GitLab Commit المخصص لهذا الموضوع ، شارك مارين نتائج الملاحظات لعام 2018: في فترة الأسبوعين السابقين قبل الإصدار ، أمضى فريق التسليم 60 ٪ من الوقت في التفاعل مع عمليات النشر ، و 26 ٪ أخرى تنفق على المهام اليدوية وشبه اليدوية مثل كتابة مراجعة الافراج الشهري.
نتائج المراقبة لعام 2018 ، قبل الانتقال إلى التسليم المستمر: هكذا قضى فريق التسليم الوقت قبل أسبوعين من الإصدار.
وقال مارين: "عند التحدث عمومًا ، ثم 14 يومًا ، قبل أسبوعين من الإصدار ، لم يفعل الفريق سوى ما كان يحدق في الشاشات ، ومشاهدة كيف أن الطلاء كان يجف ، أو أي شيء".
لكن مع تحمل 86٪ من هذه الكعكة (60٪ لعمليات النشر + 26٪ للمهام اليدوية) ، سيحل فريق التسليم عددًا من المشكلات:
- الإصدارات الجديدة دون تأخير.
- عمليات نشر متكررة وأسرع دون توقف.
- مزيد من الوقت لترحيل GitLab.com إلى Kubernetes.
- مزيد من الحرية لإعداد مؤسستك للتسليم المستمر.
على الرغم من أن القرص المضغوط متاح فقط على GitLab.com ، فإن عملائنا الفرديين يستفيدون أيضًا من انتقالنا إليه. الآن يتم اختبار كل شيء لا يتأثر باختبار CI تلقائيًا ويدويًا في البيئات - قبل الوصول إلى GitLab.com. كل ما يصل إلى GitLab.com ويحتاج إلى تصحيح الأخطاء سيتم تصحيحه في غضون ساعات قليلة. وبالتالي فإن الإصدار النهائي للعملاء الفرديين سيكون نظيفًا.
كان الانتقال من التجميد إلى القرص المضغوط مسألة وقت ، حيث نمت مجموعة الوظائف لدينا ، وبدا فريق من المهندسين بقيادة مارينا يلاحظ الانتقال: "تم تشكيل فريق التسليم بهدف وحيد هو نقل الشركة إلى نموذج القرص المضغوط ، وفي نفس الوقت نقل الشركة إلى منصة Kubernetes لتسهيل التوسع والإسراع في الدورة. "
ستبدأ معظم الشركات بدلاً من GitLab في الانتقال إلى CI / CD و Kubernetes ، حيث يتم أولاً دمج التقنيات الجديدة في سير العمل وتصحيح عملية التطوير في هذه العملية. لقد اخترنا نهجا مختلفا.
إن الانتقال إلى Kubernetes يتطلب تغيير ليس فقط في نظام الإنتاج ، ولكن أيضًا في منهج التطوير. " تقدم Kubernetes ميزات معينة متاحة بسهولة ودون استثمار إضافي. لكن لكي تستفيد حقًا من الميزات المجانية التي تقدمها Kubernetes ، فإنك تحتاج إلى نوع من CI / CD.
وافق فريق التسليم على هذا: من أجل تسهيل الانتقال إلى Kubernetes للتسليم المستمر ، ينبغي على مهندسينا العمل بالفعل مع التركيز على CI / CD ، مما يعني تحسين مراقبة الجودة (QA) وتخطيط أكثر صرامة للوظائف. وبعد ذلك اتخذ فريق التسليم قرارًا كئيبًا : صمم نظام CD مع الأدوات الحالية وأعد تنظيم البنية التحتية لتطبيق GitLab.com - بدلاً من إتقان أدوات وتقنيات CD الجديدة على الفور.
قال مارين: "كانت الفكرة بسيطة ، فنحن نستخدم الأدوات الموجودة تحت تصرفنا ، ونقوم بأتمتة معظم المهام اليدوية واختبار النظام الثابت بالكامل تحت الحمل. إذا صمد النظام الثابت ، فإننا ننتقل إلى الاختبار الديناميكي".
يوفر هذا النهج فائدتين رئيسيتين:
أولاً ، لقد حددنا جميع نقاط الضعف في نهجنا واستقرناها من خلال التشغيل الآلي مع CI ، بحيث أصبح تطبيقنا أقوى ، وأصبح نجاح الانتقال إلى Kubernetes أكثر واقعية.
ثانياً ، من خلال إنشاء فريق من المهندسين على أقراص مدمجة ، قمنا بتطبيق أذهان مهندسي GitLab ، الذين اعتادوا على نشر كل أسبوع والانتظار ، وأحيانًا طوال اليوم ، حيث يؤثرون على الدمج ، هو تحول ثقافي حقيقي.
قال مارين: "منذ أن أتقنا CI / CD ، بدأ مطورونا يفهمون بطريقة جديدة ما يعنيه القيام به".
قبل إدخال CI / CD ، كان التغيير جاهزًا بمجرد الانتهاء من المراجعة. هذا القضاء على نشر في بيئات مختلفة ، والتي كانت تستغرق وقتا طويلا. اليوم ، يتم تسليم عمليات النشر في غضون ساعات قليلة ، لذلك لا يوجد سبب لعدم تأكيد أن التغييرات قابلة للتطبيق في بيئات الاختبار والإنتاج.
يتيح نشر تطبيقات مراجعة Kubernetes للمطورين تشغيل اختبارات الجودة حرفيًا في الوقت الفعلي ، كما يؤدي استخدام علامات المعالم للتسليم التدريجي إلى تسريع عملية التطوير.
"من الخطوة الأولى في القرص المضغوط ، يتعين على المطورين الاستجابة لكل مراقبة جودة تلقائية وأيضًا لإجراء تأكيدات يدوية على مستوى جديد في كل من بيئات الإنتاج والاختبار. بالإضافة إلى ذلك ، يمكن للمطورين إجراء تغييرات على بيئة الإنتاج خلال يوم واحد في وقت سابق استغرق الأمر عدة أيام (أو حتى أسابيع). "
باستخدام القرص المضغوط ، يمكنك إجراء اختبارات جودة الرمز في كثير من الأحيان. وبما أن تغييرات نظام CI / CD الخاصة بنا يتم تسليمها على مدار الساعة ، فإن المطورين يتناوبون عند الطلب على أي مشاكل غير قياسية تظهر في الوقت الفعلي ، لأن "فترة الحضانة" قد تقلصت إلى حد كبير.
طريقة جديدة لدينا
بعد تنفيذ نظام CI / CD ، قمنا بتجهيز 90٪ من العملية تلقائيًا . تتطلب الـ 10٪ المتبقية تدخلًا بشريًا - التنسيق مطلوب بين العديد من الأشخاص الذين لديهم حق الوصول.
وقال مارين: "إننا نخفض هذه النسبة تدريجيًا بنسبة 10٪ - حتى نحتاج إلى موافقة فقط على نشر الإصدار". في التكرار الحالي ، تعمل عملية CI / CD على النحو التالي :
- يبحث CI تلقائيًا عن علامات محددة في طلبات الدمج المعتمدة من المراجعين والمطورين.
- تقوم CI تلقائيًا بمزامنة المستودعات المطلوبة وفي نفس الوقت تقوم بإنشاء فروع Git وعلاماتها ، وتتضمن أيضًا إصدارات الإصدار الصحيحة التي نريد تسليمها.
- عند اكتمال عمليات الإنشاء ، يتم نشر الحزم تلقائيًا لاختبار البيئات.
- يتم إجراء اختبارات الجودة التلقائية ، وإذا سارت الأمور على ما يرام ، يتم تسليم النشر إلى شريحة صغيرة من المستخدمين في بيئة الإنتاج.
- بالتوازي مع هذا ، يقوم المطورون بمراقبة الجودة بمستوى مختلف يدويًا - للتأكد من أن الوظائف الجديدة تعمل كما ينبغي.
- في حالة اكتشاف مشكلة ذات أولوية عالية أثناء التأكيد اليدوي ، تتوقف عمليات النشر.
- عند اكتمال الخطوة السابقة ، سيبدأ عضو فريق التسليم تسليم النشر لجميع مستخدمي GitLab.com.
- بعد ذلك ، استنادًا إلى أحدث نشر إنتاج تم إطلاقه على GitLab.com ، يتم إنشاء إصدار عميل فردي.
كما هو الحال مع أي فريق هندسي آخر ، فإن التوسع يمثل تحديًا حقيقيًا لنا. ومع ذلك ، فإن أحد أكبر التحديات التي تواجه التقنيين هو التأكد من أن مراقبة الجودة تغطي كل شيء ، لكن بالنسبة لمشروع كبير مثل GitLab.com ، فهذا عمل مكثف. وتحتاج أيضًا إلى التأكد من وجود ما يكفي من المراقبة والإخطار ، بحيث لا يعمل المشروع فقط على قواعد محددة مسبقًا.
التحدي الرئيسي الثاني بالنسبة لنا هو تعقيد نظام GitLab.com ونقل التغييرات في هذه العملية إلى جميع الفرق الهندسية. وقال مارين "كسر العملية والعادات التي تم تأسيسها على مر السنين ليس بالأمر السهل".
النتائج
يستفيد GitLab بالفعل كثيرًا من التبديل إلى CI / CD.
أظهرت الملاحظات والتقييم في عام 2019 أنه خلال الـ 14 يومًا السابقة للإصدار ، يقضي فريق التسليم 82٪ من الوقت أكثر إنتاجية: تم تحريره للعمل في مهام مهمة أخرى.
أظهرت المراقبة لعام 2019 أنه في نفس الأسبوعين ، تم تحرير الكثير من الوقت الثمين من المطورين بفضل الانتقال إلى القرص المضغوط c.
من خلال أتمتة العمل اليدوي ، تحول فريق التسليم أخيرًا إلى تغيير البنية التحتية لـ GitLab.com لتحسين الدعم لسرعة التطوير وحركة المستخدم ، وفي الوقت نفسه ، الانتقال إلى Kubernetes.
"كما قلت سابقًا ، كل هذا بدون Kubernetes. لقد تم كل شيء على نظام السلف القديم" ، هذا ما قاله مارين للضيوف في Commit GitLab Brooklyn. - "لكننا فزنا بالوقت ، حتى الآن يشارك فريقي عن كثب في الهجرة. ومع ذلك ، فقد حدث أحد أكبر التغييرات على وجه التحديد في العادة في تنظيم التطوير."
النتائج بعد الانتقال كبيرة. إذا كان النظام القديم في أيار (مايو) 2019 قد قدم 7 عمليات نشر في مكان ما ، فإن هذا الرقم ارتفع في أغسطس 2019 إلى 35. وهذا ليس الحد الأقصى: ستزداد الأرقام بشكل كبير - الآن بعد أن يقوم الفريق بتسليم العديد من عمليات النشر يوميًا.
وقال مارين: "لقد قمنا للتو بترحيل خدمة التسجيل الخاصة بنا إلى Kubernetes ، وإذا كنت تستخدم سجل الحاويات على GitLab.com ، فسيتم تنفيذ جميع طلباتك على منصة Kubernetes". - "GitLab هو نظام متعدد المكونات ، ونحن نواصل عزل ونقل الخدمات الأخرى."
يتضمن كل إصدار جديد ميزات CI / CD جديدة. على سبيل المثال ، في الإصدار 12.3 ، قمنا بتوسيع GitLab Container Registry - مما يسمح للمستخدمين باستخدام CI / CD وجمع الصور / العلامات ودمجها في مشاريعهم الخاصة . كانت هناك ابتكارات جديدة مثيرة.
أيضا نقل النظام إلى التسليم المستمر؟
نصحت مارين الشركات التي هي على وشك التحول إلى القرص المضغوط لتبدأ مع ما لديهم.
وقال مارين "بالنسبة لي ، الجلوس وانتظار الهجرة إلى منصة جديدة هو إيذاء نفسك". "يمكن تغيير معظم الأنظمة بطريقة ما وتسريع دورة المعالجة دون الانتقال إلى نظام جديد تمامًا. إن تسريع دورة التطوير / الإصدار يزيد بشكل كبير من كفاءة كل مهندس في النظام ويوفر مزيدًا من الوقت للانتقال إلى منصة جديدة ، مثل Kubernetes."
إذا كنت مهتمًا بما هو التالي ، فقم بإلقاء نظرة على هذا الملخص التفصيلي لميزات CI / CD الجديدة والمثيرة التي تنتظر في الأجنحة - مع الإصدار 12.4 وما بعده.
غاب عن بروكلين GitLab الالتزام؟
إذا كنت غير قادر على حضور العرض التقديمي مارينا مع خلفية انتقالنا إلى Kubernetes ، شاهد الفيديو الكامل أدناه ، والانضمام إلينا في Commit GitLab الأوروبية في لندن ، 9 أكتوبر .