Enterprise DevOps: كيف تجمع شركة كبيرة الخدمات الصغيرة

مرحبا بالجميع!

تقوم Netracker بتطوير وتزويد تطبيقات الشركات للسوق العالمية لمشغلي الاتصالات لسنوات عديدة. إن تطوير مثل هذه الحلول أمر معقد للغاية: يشارك مئات الأشخاص في المشاريع ، وعدد المشاريع النشطة في العشرات.

في السابق ، كانت المنتجات متجانسة ، ولكننا نتحرك الآن بثقة نحو تطبيقات الخدمات الصغيرة. واجه DevOps مهمة طموحة إلى حد ما - لتوفير هذه القفزة التكنولوجية.

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

في الحالة العامة ، التجميع هو تحويل بعض القطع الأثرية إلى أخرى.

من سيكون مهتمًا

تلك الشركات التي تقدم برامج جاهزة إلى مؤسسة خارجية بالكامل وتدفع مقابلها.

في ما يلي الشكل الذي قد يبدو عليه التطوير بدون التسليم الخارجي:

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

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

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

مثال على الانتهاك هو أخذ كود من مكتبة بترخيص GPL3 وتضمينه في تطبيق تجاري.

يتطلب ظهور الخدمات الدقيقة التغيير

لقد اكتسبنا خبرة واسعة في تجميع وتسليم التطبيقات المتجانسة.

العديد من خوادم Jenkins ، وآلاف وظائف CI ، والعديد من خطوط التجميع المؤتمتة بالكامل استنادًا إلى Jenkins ، وعشرات من مهندسي الإصدار المخصصين ، ومجموعة الخبراء الخاصة بها في إدارة التكوين.

تاريخياً ، كان النهج في الشركة هو: يكتب المطورون رمز المصدر ، ويبتكر DevOps ويكتب تكوين نظام التجميع.

نتيجة لذلك ، كان لدينا تكوينين أو ثلاثة تكوينات نموذجية مصممة للعمل في النظام البيئي للشركة. من الناحية التخطيطية ، يبدو هذا:

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

تختلف الخدمات الصغيرة عن التطبيقات المتجانسة في المقام الأول في مجموعة متنوعة من التقنيات.

اتضح الكثير من تكوينات التجميع لكل لغة برمجة على الأقل. تصبح السيطرة المركزية مستحيلة.

مطلوب تبسيط نصوص التجميع قدر الإمكان وتمكين المطورين من تعديلها بشكل مستقل.

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

لذلك ، تقرر اعتبار التجميع بمثابة "صندوق أسود" ، حيث يمكن لبيئة التجميع "الذكية" حل جميع المشاكل ، باستثناء التجميع والتعبئة نفسها.

في بداية العمل لم يكن من الواضح كيفية الحصول على مثل هذا النظام. يتطلب اتخاذ قرارات معمارية لمهام DevOps الخبرة والمعرفة. كيف تحصل عليها؟ الخيارات الممكنة أدناه:

• ابحث عن معلومات على الإنترنت.
• الخبرة والمعرفة الخاصة بفريق DevOps. للقيام بذلك ، من الجيد جعل هذا الفريق من المبرمجين ذوي الخبرة المتنوعة.
• اكتسبت الخبرة والمعرفة خارج فريق DevOps. لدى العديد من المطورين في الشركة أفكار جيدة - تحتاج إلى سماعها. التواصل مفيد.
• نحن نخترع ونجرب!

هل أحتاج إلى أتمتة؟

للإجابة على هذا السؤال ، عليك أن تفهم في أي مرحلة من مراحل تطور نهج التجميع لدينا. بشكل عام ، تمر المهمة عبر المستويات التالية.

1. مستوى اللاوعي
   
   
   
   

   نحن بحاجة إلى إطلاق تجميع واحد في الأسبوع ، شبابنا بخير. هذا طبيعي لماذا نتحدث عنه؟

2. مستوى "الحرفي" ، يتحول في النهاية إلى مستوى "المراوغ"
   
   
   
   

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

3. مستوى المصنع
   
   
   
   

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

   
   

   في هذا المستوى ، يتم فصل المهمة عن المنفذ الملموس وبالتالي تتحول إلى عملية.

   
   

   ستكون النتيجة وصفًا واضحًا ومجهزًا وصحيحًا ومئات المرات للعملية مع النص.

4. مستوى "الإنتاج الآلي"
   
   
   
   

   تتزايد المتطلبات الحديثة للتجميعات: يجب أن يكون كل شيء سريعًا وموثوقًا به ، ويجب توفير 800 تجميع يوميًا. هذا أمر بالغ الأهمية ، لأنه بدون هذه الأحجام ستفقد الشركة مزايا تنافسية.

   
   

   تجري الأتمتة المكلفة ، ويمكن لبضع من أجهزة DevOps المؤهلة الحفاظ على سير العملية. مزيد من التحجيم لم يعد مشكلة.

لا يجب أن تصل كل مهمة إلى المرحلة الأخيرة من الأتمتة.

غالبًا ما يقوم أحد الحرفيين الذين لديهم سطر أوامر بحل المشكلات بسهولة وفعالية.

الأتمتة "تجمد" العملية ، وتقلل من تكلفة التشغيل وتزيد من تكلفة التغيير.

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

ما هي التجميعات ولماذا لا يتم حل المشكلة بواسطة أنظمة التجميع الجاهزة

نستخدم التصنيف التالي لتحديد مستويات تجميع التجميع.

• لام 1. جزء مستقل صغير من تطبيق كبير. يمكن أن يكون مكونًا واحدًا أو خدمة صغيرة أو مكتبة مساعدة واحدة. تجميع L1 هو حل للمشاكل التقنية الخطية: التجميع ، والتعبئة ، والعمل مع التبعيات. تقوم Maven و gradle و npm و grunt وأنظمة البناء الأخرى بعمل رائع في هذا الصدد. هناك المئات منهم.

  يجب أن يتم التجميع L1 باستخدام أدوات خارجية جاهزة.

• L2 +. كيانات التكامل. يتم دمج كيانات L1 في تشكيلات أكبر ، على سبيل المثال ، في تطبيقات الخدمات الصغيرة الكاملة. يمكن تجميع العديد من هذه التطبيقات كحل واحد. نستخدم علامة "+" ، لأنه بناءً على مستوى تجميع التجميع ، قد يتم تعيين مستوى L3 أو حتى L4.

  
  

  مثال على مثل هذه التجميعات في عالم الطرف الثالث هو إعداد توزيعات Linux. الحزم الفوقية هناك.

  
  

  بالإضافة إلى المهام التقنية المعقدة للغاية (مثل هذه: ru.wikipedia.org/wiki/Dependency_hell ). غالبًا ما تكون تجميعات L2 + هي المنتج النهائي ، وبالتالي لديها العديد من متطلبات العملية: نظام الحقوق ، وتحديد الأشخاص المسؤولين ، وغياب الأخطاء القانونية ، وتوفير الوثائق المختلفة.

  
  

  في L2 + ، يتم تحديد أولويات متطلبات العملية عن طريق الأتمتة.

  
  

  إذا لم يعمل الحل التلقائي لأنه مناسب للأشخاص المهتمين ، فلن يتم تنفيذه.

  
  

  من المرجح أن يتم تنفيذ تجميعات L2 + بواسطة أداة ملكية مصممة خصيصًا لعمليات الشركة. هل تعتقد أن مديري حزم Linux توصلوا إلى ذلك للتو؟

أفضل ممارساتنا

البنية التحتية

توافر الحديد الدائم

تقع البنية التحتية الكاملة للتجميع على خوادم مغلقة داخل شبكة الشركة. في بعض الحالات ، تكون الخدمات السحابية التجارية ممكنة.

الحكم الذاتي

في جميع عمليات CI ، لا يتوفر الإنترنت. يتم نسخ جميع الموارد اللازمة وتخزينها مؤقتًا داخليًا. جزئيًا حتى github.com (شكرًا لك ، npm!) تم حل معظم هذه المشكلات بواسطة Artifactory.

لذلك ، نحن هادئون عند حذف القطع الأثرية من وسط مخضرم أو إغلاق المستودعات الشعبية. هناك مثال: community.oracle.com/community/java/javanet-forge-sunset .

إن النسخ المطابق يقلل بشكل كبير من وقت التجميع ، ويحرر قناة الإنترنت للشركات. إن قلة موارد الشبكة الحرجة تزيد من بناء الاستقرار.

ثلاثة مستودعات لكل نوع من القطع الأثرية

1. ديف هو مستودع حيث يمكن لأي شخص نشر القطع الأثرية من أي أصل. هنا يمكنك تجربة مناهج جديدة بشكل أساسي دون تكييفها مع معايير الشركة من اليوم الأول.
2. التدريج عبارة عن مستودع يتم ملؤه فقط بخط أنابيب تجميع.
3. تحرير - تجميعات فردية ، جاهزة للتسليم الخارجي. إنها مليئة بعملية نقل خاصة مع تأكيد يدوي.

حكم 30 يوما

من مستودعات Dev و Staging- نحذف كل شيء مضى عليه أكثر من 30 يومًا. وهذا يساعد على ضمان حصول الجميع على فرص نشر متساوية من خلال إنفاق كمية محدودة من مساحة قرص الخادم.

يتم تخزين الإصدار إلى الأبد ، ويتم الأرشفة إذا لزم الأمر.

بيئة تجميع نظيفة

غالبًا بعد التجميعات ، تبقى الملفات الإضافية في النظام ، والتي يمكن أن تؤثر على عمليات التجميع الأخرى. أمثلة نموذجية:

• المشكلة الأكثر شيوعًا هي ذاكرة التخزين المؤقت التي تضررت من تجميع واحد غير صحيح (كيفية التعامل مع ذاكرة التخزين المؤقت ، الموضحة أدناه) ؛
• بعض الأدوات المساعدة ، مثل npm ، تترك ملفات الخدمة في دليل $ HOME الذي يؤثر على جميع عمليات التشغيل اللاحقة لهذه الأدوات ؛
• يمكن أن تقوم مجموعة معينة بإنفاق كل مساحة القرص في قسم / tmp ، مما يؤدي إلى عدم توفر البيئة بشكل عام.

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

تحتفظ DevOps بمجموعة من صور أرصفة التجميع ، والتي يتم تحديثها باستمرار. في البداية كان هناك حوالي ستة ، ثم كان أقل من 30 ، ثم قمنا بإعداد الجيل التلقائي للصور من قائمة البرامج. الآن فقط حدد المتطلبات مثل متطلبات ("maven 3.3.9" و "python") - والبيئة جاهزة.

التشخيص الذاتي

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

في نظام "مباشر" ، يكفي كتابة 20-30 تعبيرًا عاديًا حتى تتمكن من تحديد سبب سقوطه على كل مجموعة:

• تحطم الخادم Git
• نفدت مساحة القرص هناك.
• بناء خطأ بسبب خطأ المطور ؛
• خطأ معروف في Docker.

إذا سقط شيء ما ، ولكن لم يتم اكتشاف مشكلة واحدة معروفة ، فهذه مناسبة لتجديد مجموعة الأقنعة.

ثم نذهب إلى المستخدم ونقول أن لديه بناء ويمكن إصلاح ذلك بهذه الطريقة.

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

نختار بعناية الأنظمة التي تعتمد عليها الجمعية

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

واجهة خط التجميع

واجهة واحدة لاستدعاء التجميع

نقوم بعمل أي نوع من التجميع مع نظام واحد. يتم وصف التجميعات من جميع المستويات (L1 ، L2 +) بواسطة رمز البرنامج ويتم استدعاؤها من خلال وظيفة واحدة في Jenkins.

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

• لا يتم الخلط بين السجلات من التجميعات غير المتجانسة في قصة واحدة على صفحة وظيفة Jenkins ؛
• في الواقع ، تحصل على وظائف مخصصة مريحة لفريق أو مطور ؛ يمكن تعزيز الشعور بالراحة من خلال تعديل الرسوم البيانية لنتائج junit ، cobertura ، السونار.

حرية اختيار التكنولوجيا

بدء البناء هو استدعاء لنص باش "./build.sh". ثم - أي أنظمة تجميع ولغات برمجة وكل شيء آخر مطلوب لإكمال مهمة عمل. يوفر هذا نهجًا للتجميع كمربع أسود.

مشاركة ذكية

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

يتم تنظيم المستودعات المرحلية والافراج عنها دائمًا. مطلوب لدعم تفاصيل المنشورات من أنواع مختلفة: maven ، npm ، file ، docker.

واصف التجميع

يصف Build.sh كيفية تجميع التعليمات البرمجية ، ولكن هذا لا يكفي لحاوية تجميع.

يجب أن تعرف أيضًا:

1. ما هي بيئة التجميع التي يجب استخدامها ؛
2. متغيرات البيئة المتاحة في build.sh ؛
3. ما المنشورات التي سيتم تنفيذها ؛
4. خيارات محددة أخرى.

لقد اخترنا طريقة مناسبة لوصف هذه المعلومات في شكل ملف yaml يشبه عن بعد .gitlab-ci.yaml.

معلمات التجميع

يمكن للمستخدم تحديد معلمات عشوائية دون تنفيذ الأمر git ارتكاب الحق في بداية التجميع.

قمنا بتطبيق هذا من خلال تحديد متغيرات البيئة مباشرة من واجهة عمل Jenkins.

على سبيل المثال ، ننقل إصدار المكتبة التابعة إلى معلمة التجميع هذه ، وفي بعض الحالات ، نعيد تعريف هذا الإصدار إلى إصدار تجريبي. بدون هذه الآلية ، سيتعين على المستخدم تنفيذ الأمر "git ارتكاب" في كل مرة.

قابلية النظام

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

يمكن نشر قطعة أثرية واحدة تحت أسماء مختلفة.

هناك متطلبان متعارضان للنشر قد ينشأان في وقت واحد.

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

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

يتم نشر القطع الأثرية في هذه الحالة تحت اسمين أو أكثر ، لأنها تناسب الجميع.

على سبيل المثال:

1. اسم فريد مع طابع زمني أو UUID - لأولئك الذين يحتاجون إلى الدقة ؛
2. اسم "الأحدث" - لمطوريهم ، الذين يلتقطون دائمًا أحدث رمز ؛
3. اسم "<إصدار رئيسي> .x-latest" لفريق مجاور جاهز لالتقاط أحدث الإصدارات ، ولكن فقط في إطار تخصص معين.

يقوم Maven بشيء مماثل في نهجه تجاه SNAPSHOT.

قيود أمنية أقل

يمكن للجميع بدء التجميع. لن يضر هذا أي شخص ، لأن التجميع يخلق فقط القطع الأثرية.

الامتثال القانوني

التحكم في التفاعلات الخارجية لعملية التجميع

لا يجوز للمجلس استخدام أي شيء محظور في عملية عمله.

لهذا ، يتم تنفيذ تسجيل حركة مرور الشبكة والوصول إلى ذاكرة التخزين المؤقت للملفات. نحصل على سجل نشاط الشبكة للتجميع في شكل قائمة عناوين url مع تجزئات sha256 للبيانات المستلمة. علاوة على ذلك ، يتم التحقق من كل عنوان url:

1. القائمة البيضاء الثابتة
2. قاعدة بيانات ديناميكية من القطع الأثرية المسموح بها (على سبيل المثال ، للاعتمادات maven- ، rpm- ، npm-). يعتبر كل إدمان بشكل فردي. قد ينجح التصريح التلقائي أو حظر الاستخدام ، وقد تبدأ أيضًا مناقشة طويلة مع المحامين.

محتوى شفاف من القطع الأثرية المنشورة

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

لا يمكن إزالة شفرة المصدر الصادرة من GIT

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

اللوجستيات والمحاسبة

يتم تخزين كافة التجميعات في قاعدة البيانات.

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

نحن نعلم كيفية إعادة إنتاج التجميع بأكبر قدر ممكن من الدقة

حسب نتائج التجميع نقوم بتخزين المعلومات التالية:

• الحالة الدقيقة للرمز الذي تم جمعه ؛
• ما هي المعلمات التي تم إطلاقها بها ؛
• ما يسمى الأوامر ؛
• ما حدث الوصول إلى الموارد الخارجية ؛
• تستخدم بيئة التجميع.

إذا لزم الأمر ، يمكننا الإجابة بدقة على السؤال حول كيفية تجميعه.

اتصال ثنائي الاتجاه للتجميع مع تذكرة JIRA

تأكد من قدرتك على حل المشكلات التالية:

1. للتجميع ، قم بإنشاء قائمة بتذاكر JIRA المضمنة فيه ؛
2. اكتب في تذكرة JIRA التجميعات التي يتم تضمينها فيها.

يتم توفير اتصال محكم ثنائي الاتجاه بين التجميع والتطبيق git. ثم من نص التعليقات ، يمكنك بالفعل معرفة جميع الروابط إلى JIRA.

السرعة

مخابئ نظام التجميع

يمكن أن يؤدي عدم وجود ذاكرة تخزين مؤقت مخبأة إلى زيادة وقت البناء بساعة.

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

مخابئ موارد الشبكة

يؤدي النمو الجغرافي للشركة إلى ضرورة نقل ملفات 300 ميجابايت بين القارات. يتم قضاء الكثير من الوقت ، خاصة إذا كان عليك القيام بذلك كثيرًا.

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

تجميع - بأسرع ما يمكن ، كل شيء آخر - ثم

المرحلة الأولى: نقوم بالتجميع على الفور ، وبدون إيماءات غير ضرورية ، نعطي النتيجة.

المرحلة الثانية: المصادقة والتحليل والمحاسبة والبيروقراطية الأخرى. يمكن القيام بذلك بالفعل في وظيفة Jenkins منفصلة وبدون حدود زمنية صارمة.

ما هي النتيجة

1. الشيء الرئيسي هو أن التجميع أصبح واضحًا للمطورين ، وأنفسهم يمكنهم تطويره وتحسينه.
2. تم إنشاء الأساس لبناء عمليات الأعمال التي تعتمد على التجميع: التثبيت ، وإدارة المشكلات ، والاختبار ، وإدارة الإصدار ، وما إلى ذلك.
3. لم يعد فريق DevOps يكتب البرامج النصية للتجميع: يقوم المطورين بذلك.
4. تحولت متطلبات الشركة المعقدة إلى تقرير شفاف مع قائمة نهائية من الشيكات.
5. يمكن لأي شخص بناء أي مستودع ببساطة عن طريق استدعاء build.sh من خلال واجهة واحدة. يكفي بالنسبة له ببساطة تحديد إحداثيات بوابة التعليمات البرمجية المصدر. يمكن أن يكون هذا الشخص مدير فريق ، مهندس ضمان الجودة / تقنية المعلومات ، إلخ.

وبعض الأرقام

1. . 15 Jenkins job build.sh. 15 docker-, , . . .
2. . . 2200 . — on-commit-.
3. 300 git-, .
4. 30 , (25 ) — docker.
5. , :
   
   1. glide, golang, promu;
   2. maven, gradle;
   3. python & pip;
   4. ruby;
   5. nodejs & npm;
   6. docker;
   7. rpm build tools & gcc;
   8. Android ADT;
   9. ;
   10. legacy-;
   11. .