تعريف DevOps معقد للغاية ، لذلك يجب عليك إعادة بدء النقاش حوله في كل مرة. فقط على Habré ألف منشورات حول هذا الموضوع. ولكن إذا قرأت هذا ، فربما تعرف ما هو DevOps. لأنني لا أفعل. مرحبًا ، اسمي
ألكسندر تيتوف (@ osminog )
وسنتحدث فقط عن
DevOps وسأشارك تجربتي.
لقد فكرت لفترة طويلة في كيفية جعل قصتي مفيدة ، لذلك سيكون هناك العديد من الأسئلة هنا - تلك التي أسألها عن نفسي والأسئلة التي أطرحها على عملاء شركتنا. عن طريق الإجابة على هذه الأسئلة ، فهم يتحسن. سأخبرك لماذا هناك حاجة إلى DevOps من وجهة نظري ، وما هو عليه ، مرة أخرى ، من موقفي ، وكيف أفهم أنك تنتقل إلى DevOps مرة أخرى من وجهة نظري. العنصر الأخير سيكون من خلال الأسئلة. من خلال الإجابة عليها بنفسك ، يمكنك أن تفهم ما إذا كانت شركتك تتجه نحو DevOps أو إذا كانت هناك مشاكل في شيء ما.
في وقت واحد مشيت على طول موجات عمليات الدمج والاستحواذ. في البداية كنت أعمل في شركة صغيرة Qik ، ثم تم شراؤها من قبل شركة Skype أكبر قليلاً ، ثم تم شراؤها من قبل شركة أكبر قليلاً من Microsoft. في تلك اللحظة ، أصبحت رؤية متاحة لي كيف تم تحويل فكرة DevOps في شركات مختلفة. بعد ذلك ، أصبح من الممتع بالنسبة لي أن أنظر إلى DevOps من وجهة نظر السوق ، ونظمنا أنا وزملائي شركة Express 42. منذ 6 سنوات ، كنا نتحرك على طول موجات السوق.
من بين أشياء أخرى ، أنا واحد من منظمي مجتمع DevOps Moscow ومنظم DevOps-Days 2017 ، لكنني لم أقم بتنظيم 2018. Express 42 يعمل مع العديد من الشركات. نحن ننشئ DevOps هناك ، ونرى كيف يحدث ذلك ، ونستخلص النتائج ، ونحلل ، ونخبر النتائج التي توصلنا إليها للجميع ، ونعلم الأشخاص ممارسات DevOps. بشكل عام ، في كل طريقة نزرع الخبرة والخبرة.
لماذا DevOps
السؤال الأول الذي يطارد الجميع ودائما - لماذا؟ يعتقد الكثير من الناس أن DevOps هي مجرد أتمتة أو شيء مشابه كان لدى كل شركة بالفعل.
- كان لدينا تكامل مستمر - وهذا يعني ، كان هناك بالفعل DevOps ، ولماذا كل هذه القمم مطلوبة؟ يستمتعون بالخارج ، لكنهم يتعارضون مع عملنا!خلال 9 سنوات من تطور المجتمع والمنهجية ، أصبح من الواضح بالفعل أن هذه ليست تسويقات ، ولكن لا يزال من غير الواضح تمامًا سبب الحاجة إليها. مثل أي أداة وعملية ، فإن DevOps لها أهداف محددة تحلها في النهاية.
كل هذا يرجع إلى حقيقة أن العالم يتغير. يبتعد عن نهج المؤسسة ، عندما تتجه الشركات مباشرة إلى الحلم ، حيث غنت أعمالنا الكلاسيكية في سان بطرسبرغ ، من النقطة أ إلى النقطة ب وفقًا لاستراتيجية معينة ، مع بنية معينة مصممة لهذا الغرض.
من حيث المبدأ ، في تكنولوجيا المعلومات يجب أن يبنى كل شيء لهذا النهج. هنا يتم استخدام تكنولوجيا المعلومات حصريًا لأتمتة العمليات.
الأتمتة لا تتغير في كثير من الأحيان ، لأنه عندما تتحرك الشركة على مسار متعرج - ما الذي يجب تغييره؟ كان يعمل - لا تلمس. الآن في العالم ، تتغير المناهج ، وتسمى الكلمة المسماة Agile أن نقطة النهاية B غير مرئية على الفور.
عندما تتنقل شركة ما في السوق ، وتعمل مع عميل ، فإنها تقوم دائمًا بالبحث في السوق وتغيير نقطة نهايتها B. علاوة على ذلك ، كلما غيّرت الشركة اتجاهها ، زادت نجاحها في النهاية ، لأنها تختار عددًا أكبر من الأسواق.
تم توضيح الاستراتيجية من قبل شركة مثيرة للاهتمام ، والتي تعلمت عنها مؤخرًا. One Box Shave - خدمة توصيل للحلاقة وماكينات الحلاقة حسب الصندوق. إنهم يعرفون كيفية تخصيص "المربع" الخاص بهم للعملاء المختلفين. يتم ذلك عن طريق برامج معينة ، والتي ترسل بعد ذلك طلبًا إلى مصنع كوري ينتج بضائع.
اشترت شركة يونيليفر هذا المنتج بمبلغ مليار دولار. يتنافس الآن مع Gillette وسرقه من حصة كبيرة من المستهلكين في السوق الأمريكية. صندوق واحد حلاقة يقول:
- 4 ريش؟ هل انت جاد لماذا تحتاج هذا - فهو لا يحسن جودة الحلاقة. الكريمات والعطور وشفرة الحلاقة عالية الجودة المختارة بشفرتين تحل أسئلة أكثر بكثير من هذه الشفرات الغبية 4 من جيليت! قريبا جدا سنصل إلى 10؟لذلك العالم يتغير. تدعي شركة Unilever أن لديها نظامًا رائعًا لتكنولوجيا المعلومات يسمح بذلك. في النهاية ، يبدو كمفهوم
"الوقت للسوق" الذي لم يتحدث عنه أحد بالفعل.
ليس الهدف من وقت السوق هو عدد مرات نشرنا. يمكنك النشر غالبًا ، لكن دورات الإطلاق ستكون طويلة. إذا تداخلت دورات الإصدار لمدة ثلاثة أشهر مع بعضها البعض ، وتحوّلت لمدة أسبوع ، فقد اتضح أن الشركة قد تم نشرها مرة واحدة في الأسبوع. ومن الفكرة إلى التنفيذ النهائي ، 3 أشهر تمر.
الوقت إلى السوق يدور حول تقليل الوقت من الفكرة إلى التنفيذ النهائي.
في هذه الحالة ، يتفاعل البرنامج مع السوق. هذه هي الطريقة التي يتفاعل بها One Box Shave مع الموقع. ليس لديهم بائعون - مجرد موقع ينقر فيه الزائر ويترك أمنياته. وفقًا لذلك ، يجب على الموقع نشر شيء جديد باستمرار ، وتحديثه وفقًا للرغبات. على سبيل المثال ، في كوريا الجنوبية ، يحلقون بطريقة مختلفة عن روسيا ، ويحبون رائحة الصنوبر ، على سبيل المثال ،
جزر الفانيليا في العطر.
نظرًا لأنك تحتاج إلى تغيير محتوى الموقع بسرعة ، فإن تطوير البرمجيات يتغير إلى حد كبير. من خلال البرنامج ، يجب علينا معرفة ما يريده العميل. في السابق ، تعلمنا ذلك من خلال بعض الحلول ، على سبيل المثال ، من خلال إدارة الأعمال. ثم صمموا ، ووضعوا المتطلبات في نظام تكنولوجيا المعلومات ، وكان كل شيء رائعًا. أصبح الأمر مختلفًا الآن - تم تصميم البرنامج من قِبل كل من يشارك في العملية ، بما في ذلك المهندسين ، لأنهم يتعلمون من خلال المواصفات الفنية كيفية عمل السوق ، وكذلك تبادل وجهات نظرهم مع رجال الأعمال.
على سبيل المثال ، في Qik ، اكتشفنا فجأة أن الأشخاص يحبون حقًا تحميل قوائم جهات الاتصال على الخادم ، ويضعوننا التطبيق. في البداية ، لم نفكر في هذا. في شركة كلاسيكية ، يقرر الجميع أنه كان خطأً ، نظرًا لأن المواصفات لا تقول أنه يجب أن تعمل بشكل جيد وتم تنفيذها بشكل عام على الركبة ، فإنها ستوقف تشغيل الميزة وتقول: "هذا لا يحتاج إلى أي شخص ، والأهم هو أن الوظيفة الرئيسية تعمل" . وترى شركة التكنولوجيا هذه فرصة وتبدأ في تغيير البرنامج وفقًا لذلك.
في عام 1968 ، صاغ الرجل البصري ميلفن كونواي الفكرة التالية.
تقتصر المؤسسة التي تنشئ النظام على تصميم ينسخ بنية الاتصالات في تلك المؤسسة.
بمزيد من التفصيل ، من أجل إنتاج أنظمة من نوع مختلف ، يجب على المرء أيضًا أن يكون له هيكل اتصال داخل شركة من نوع آخر. إذا كان هيكل الاتصال الخاص بك أعلى هرميًا ، فلن يسمح لك ذلك بإنشاء أنظمة يمكنها أن توفر مؤشرًا عاليًا جدًا للوقت للسوق.
يمكنك أن
تقرأ عن قانون كونواي على الروابط . من المهم فهم ثقافة أو فلسفة DevOps ، نظرًا لأن
الشيء الوحيد الذي يتغير جوهريًا في DevOps هو بنية التواصل بين الفرق .
من وجهة نظر العملية ، قبل DevOps ، كانت جميع المراحل: التحليلات والتطوير والاختبار والتشغيل خطية.
في حالة DevOps ، كل هذه العمليات تسير في وقت واحد.
الوقت إلى السوق لا يمكن أن يتم إلا بهذه الطريقة. بالنسبة للأشخاص الذين عملوا في العملية القديمة ، يبدو الأمر كونيًا إلى حد ما ، وبشكل عام.
فلماذا تحتاج DevOps؟
لتطوير المنتجات الرقمية . إذا لم يكن لديك منتج رقمي في شركتك ، فلن تكون هناك حاجة إلى DevOps - هذا مهم للغاية.
تتغلب DevOps على حدود السرعة لنظام إنتاج البرامج المتسق . في ذلك ، تحدث جميع العمليات في وقت واحد.
يزيد من صعوبة. عندما يخبرك Evangelists DevOps أنه سيكون من الأسهل بالنسبة لك إصدار برنامج به ، فهذا هراء.
مع DevOps ، ستصبح الأمور أكثر تعقيدًا.
في المؤتمر الذي عقد في جناح Avito ، يمكن للمرء أن يرى ما هو نشر حاوية Docker - وهي مهمة غير واقعية. يصبح التعقيد باهظًا ، وعليك التوفيق بين العديد من الكرات في نفس الوقت.
تعمل DevOps على تغيير العملية والتنظيم في الشركة تمامًا - وبشكل أكثر دقة ، لا تغير DevOps ، ولكن المنتج الرقمي. للمجيء إلى DevOps ، ما زلت بحاجة إلى تغيير هذه العملية تمامًا.
أسئلة للأخصائي
ماذا عنك الأسئلة التي يمكنك طرحها على نفسك عند العمل في شركة وتطويرك كمتخصص.
هل لديك استراتيجية المنتج الرقمي؟ إذا كان هناك - جيد بالفعل. هذا يعني أن شركتك تتجه نحو DevOps.
هل تقوم شركتك بالفعل بإنشاء منتج رقمي؟ هذا يعني أنه يمكنك رفع درجة أخرى والقيام بأشياء أكثر إثارة للاهتمام - مرة أخرى ، من وجهة نظر DevOps. أنا أتحدث فقط من وجهة النظر هذه.
هل شركتك واحدة من الشركات الرائدة في السوق في مجال المنتجات الرقمية؟ سبوتيفي ، ياندكس ، أوبر - الشركات التي هي في ذروة التقدم التكنولوجي الآن.
اسأل نفسك هذه الأسئلة ، وإذا كانت جميع الإجابات سلبية ، فربما لا ينبغي عليك التعامل مع DevOps في هذه الشركة. إذا كان موضوع DevOps مثيرًا لك حقًا ، فربما يجب عليك الانتقال إلى شركة أخرى؟ إذا كانت شركتك تريد الانتقال إلى DevOps ، لكنك أجبت بـ "لا" على جميع الأسئلة ، فهي تشبه وحيد القرن الذي لن يتغير أبدًا.
منظمة
كما قلت ، وفقًا لقانون كونواي ، فإن المنظمة تتغير في شركة. بادئ ذي بدء ، ما الذي يمنع DevOps من دخول الشركة من وجهة نظر المنظمة.
مشكلة "الآبار"
الكلمة الإنجليزية "صومعة" تترجم هنا إلى اللغة الروسية باسم "جيد". معنى هذه المشكلة هو أنه
لا يوجد تبادل للمعلومات بين الفرق . يستنبط كل فريق خبرته بعمق ، في حين لا يبني خريطة مشتركة يمكنك من خلالها التنقل.
يشبه في بعض النواحي الشخص الذي وصل لتوه إلى موسكو وما زال لا يعرف كيفية التنقل في خريطة المترو. يعرف سكان موسكو عادة منطقتهم جيدًا ، وفي جميع أنحاء موسكو يسترشدون بخريطة المترو. عندما تأتي إلى موسكو لأول مرة ، لا توجد هذه المهارة ، وأنت ببساطة مرتبك.
تقدم DevOps لتمرير هذه اللحظة من الارتباك وإلى جميع الإدارات معا لبناء خريطة مشتركة للتفاعل.
عاملان يتداخلان مع هذا.
نتيجة لنظام إدارة الشركات. تم بناؤه بواسطة "آبار" هرمية منفصلة. على سبيل المثال ، هناك بعض مؤشرات الأداء الرئيسية في الشركات التي تدعم هذا النظام. من ناحية أخرى ، تتداخل أدمغة الشخص الذي يصعب تجاوز حدود خبراته والتنقل عبر النظام. إنه غير مريح فقط. تخيل أنك وصلت إلى مطار بانكوك - حيث لن تجد محاملك بسرعة. من الصعب التنقل في DevOps أيضًا ، وبالتالي يقول الناس أنك بحاجة إلى العثور على دليل للعثور عليه للوصول إلى هناك.
ولكن الأهم من ذلك هو أن مشكلة "الآبار" للمهندس الذي استلهم روح DevOps ، قرأها فاولر ومجموعة من الكتب الأخرى ، يتم التعبير عنها في حقيقة أن
"الآبار" لا تسمح لك بعمل أشياء "واضحة" . غالبًا ما نلتقي بعد DevOps Moscow ، ونتحدث مع بعضنا البعض ، ويشكو الناس من:
- أردنا فقط إطلاق CI ، لكن اتضح أن الإدارة لم تكن في حاجة إليها.هذا يرجع بالتحديد إلى حقيقة أن
CI وعملية التسليم المستمر تقعان على حدود العديد من الفحوصات. فقط لا تتغلب على مشكلة "الآبار" على المستوى التنظيمي ، فلن تكون قادرًا على المضي قدمًا ، مهما فعلت وكيف تشعر بالحزن.
كل مشارك في العملية في الشركة: مطورو الواجهة الخلفية ، والاختبار ، و DBA ، والتشغيل ، والشبكة ، والحفريات في اتجاهه الخاص ، وليس لأحد بطاقة مشتركة باستثناء مدير يراقب بطريقة ما طريقة الفجوة والقهر ويتحكم فيها.
يناضل الناس من أجل بعض النجوم أو الأعلام الصغيرة ، يحفر كل منهم خبرته الخاصة.
نتيجة لذلك ، عندما تظهر المهمة لربط كل هذا معًا وبناء خط أنابيب مشترك ، وليس هناك حاجة للقتال من أجل النجوم والأعلام ، فإن السؤال الذي يطرح نفسه - ما الذي يجب علي فعله؟ يجب أن نتفق بطريقة أو بأخرى ، لكن لا أحد علمنا كيفية القيام بذلك. لقد تعلمنا من المدرسة: الصف الثامن - واو! - مقارنة بالصف السابع! هو نفسه هنا.
هل هو نفسه في شركتك؟
للتحقق من ذلك ، يمكنك أن تسأل نفسك الأسئلة التالية.
هل تستخدم الفرق أدوات مشتركة ، هل تساهم في إجراء تغييرات على هذه الأدوات الشائعة؟
كم عدد المرات التي يتم فيها إصلاح الفرق؟ في بيئة DevOps ، يصبح هذا طبيعيًا ، لأنه في بعض الأحيان لا يستطيع الشخص ببساطة فهم ما تفعله منطقة أخرى من الخبرة. ينتقل إلى قسم آخر ، ويعمل هناك لمدة أسبوعين ليضع لنفسه خريطة للتوجيه والتفاعل مع هذا القسم.
هل من الممكن إنشاء لجنة للتغيير وتغيير شيء ما؟ أم أن هذا يتطلب يد قوية من أعلى القيادة والتوجيه؟ لقد كتبت مؤخرًا على Facebook كيف يقوم أحد البنوك غير المعروفة بتنفيذ الأدوات من خلال الطلبات: لقد كتبنا طلبًا ، وقمنا بتنفيذه لمدة عام ، وسنرى ما سيحدث. هذا ، بالطبع ، طويل وحزين.
ما مدى أهمية حصول المديرين على الإنجازات الشخصية دون مراعاة إنجازات الشركة؟إذا أجبت على هذه الأسئلة بنفسك ، فسيصبح الأمر أكثر وضوحًا إذا كانت لديك مشكلة في الشركة.
البنية التحتية كرمز
بعد حل هذه المشكلة ، فإن أول ممارسة مهمة ، والتي بدونها يصعب الانتقال إلى DevOps ، هي
البنية التحتية كرمز .
في معظم الأحيان ، ينظر إلى البنية التحتية كرمز على النحو التالي:
- دعنا أتمتة كل شيء على باش ، وتغطية أنفسنا مع البرامج النصية بحيث منطقة المسؤول لديه أقل العمل اليدوي!لكن هذا ليس كذلك.
تتضمن البنية التحتية كرمز أنك تصف نظام تكنولوجيا المعلومات الذي تعمل به لفهم حالته باستمرار.
إلى جانب الفرق الأخرى ، تقوم بإنشاء خريطة في شكل رمز يفهمه الجميع ، ويمكنك التنقل فيه والتنقل فيه. لا يهم ما يتم القيام به - ملفات الشيف ، Ansible ، الملح ، أو YAML المستخدمة في Kubernetes - ليس هناك فرق.
في المؤتمر ، تحدث زميل من 2GIS عن كيفية صنع الشيء الداخلي الخاص بهم ل Kubernetes ، الذي يصف بنية النظم الفردية. لوصف 500 نظام ، احتاجوا إلى أداة منفصلة تنشئ هذا الوصف. عندما يكون هناك هذا الوصف ، يمكن للجميع التحقق من بعضهم البعض ، ومراقبة التغييرات ، وكيفية تغييرها وتحسينها ، والتي هي مفقودة.
أوافق ، نصوص bash المنفصلة عادة لا تعطي هذا الفهم. في إحدى الشركات التي عملت فيها ، كان هناك اسم "الكتابة فقط" - نص - عندما يتم كتابة البرنامج النصي ، ومن المستحيل بالفعل قراءته. أعتقد أن هذا مألوف بالنسبة لك أيضًا.
البنية التحتية كرمز هي
الكود الذي يصف الحالة الحالية للبنية التحتية . تعمل العديد من فرق المنتجات والبنية التحتية والخدمات معًا على هذا الرمز ، والأهم من ذلك كله أنهم بحاجة إلى فهم كيفية عمل هذا الرمز بشكل عام.
يتم إرفاق الكود وفقًا لأفضل ممارسات العمل مع الكود : التطوير المشترك ، مراجعة الكود ، برمجة XP ، الاختبار ، أسئلة السحب ، CI للبنية التحتية للرمز - كل هذا مناسب ويمكن استخدامه.
رمز أصبح لغة مشتركة لجميع المهندسين.
تغيير البنية التحتية في الكود لا يستغرق الكثير من الوقت . نعم ، قد يكون هناك أيضًا دين تقني في كود البنية التحتية. عادةً ما تواجهها الفرق بعد عام ونصف من بدء تطبيق "البنية التحتية كرمز" في شكل مجموعة من البرامج النصية أو حتى Ansible ، والتي يكتبونها كرمز معكرونة ، وحتى نصوص bash تضعها في صندوق الإطفاء!
هام : إذا لم تكن قد جربت هذه الأشياء بعد ، فتذكر أن
Ansible ليس باش ! قراءة الوثائق بعناية ، ودراسة ما يكتبون عنه عموما.
البنية التحتية كرمز هي تقسيم رمز البنية التحتية إلى طبقات منفصلة.
في شركتنا ، نميز بين 3 طبقات أساسية واضحة وبسيطة للغاية ، ولكن قد يكون هناك أكثر من ذلك. يمكنك الاطلاع على رمز البنية الأساسية الخاصة بك وتحديد ما إذا كان لديك هذا الشرط أم لا. إذا لم يتم تسليط الضوء على أي طبقات ، فأنت بحاجة إلى تخصيص وقت و refactor قليلاً.
الطبقة الأساسية هي كيفية تكوين نظام التشغيل والنسخ الاحتياطي والأشياء الأخرى ذات المستوى المنخفض ، على سبيل المثال ، كيفية نشر Kubernetes على المستوى الأساسي.
مستوى الخدمات هو تلك الخدمات التي تقدمها للمطور: تسجيل كخدمة ، مراقبة كخدمة ، قاعدة بيانات كخدمة ، موازن كخدمة ، قائمة انتظار كخدمة ، تسليم مستمر كخدمة - مجموعة من الخدمات التي يمكن للفرق الفردية توفير التطوير. كل هذا يجب أن يوصف كوحدات منفصلة في نظام إدارة التكوين الخاص بك.
الطبقة التي يتم فيها إنشاء التطبيقات وكيف سيتم نشرها أعلى الطبقتين السابقتين.
أسئلة الأمان
هل لديك مستودع مشترك للبنية التحتية في شركتك؟ هل تتحكم في الدين الفني في البنية التحتية؟ هل تستخدم ممارسات التطوير في مستودع البنية التحتية؟ هل البنية التحتية الخاصة بك شرائح؟ يمكنك التحقق من مخطط Base-service-APP. ما مدى صعوبة إجراء تغيير؟
إذا كنت تواجه حقيقة أن إدخال التغييرات استغرق يومًا ونصف ، فهذا يعني أن لديك دينًا تقنيًا وعليك التعامل معه. لقد تعثرت للتو على مجموعة من الديون الفنية في رمز البنية التحتية. أتذكر العديد من هذه القصص عندما أقوم بتغيير أي CCTL ، من الضروري إعادة كتابة نصف رمز البنية التحتية ، لأن الإبداع والرغبة في أتمتة كل شيء أدى إلى حقيقة أنه في كل مكان يتم قص كل شيء ، تتم إزالة جميع الأقلام ، وتحتاج إلى إعادة تشكيلها.
تسليم مستمر
الخصم مماثلة مع قرض. , . , - , . , . , DevOps, , , . .
, , , , , . — «», , .
«Continuous Delivery» , 2009 , , . « », , , « ». , - , .
—
, , . , . , . , . — , -. .
, , . « », , , . — : , .
- . , - , , , . , , DevOps- : - , — Kubernetes- , - , .
- — - . , - . Continuous Delivery : , - , . , . , .
. , AB- , - «» , , , , 100 .
« » .
Dev, CI, Test, PreProd, Prod — , , .
, Base Service APP,
, ,
.
95 % ? ? , ? ?
, ! — ).
ردود الفعل
. DevOpsConf Infobip, , , , !
, -, Qik , . , Zabbix 150 000 items, . , :
— , ?, , .
. , , , , - — . 4 , «Segmentation fault».
, Zabbix, , , , API-, . , . , android-. :
— , ?, UI. , HTTP-. android- — . , 40 , , - HTTP-, . , API , , , .
. «», , . , . , , , , — , , ( ), . .
, — .
CI, - . Test, PredProd, . , , , : , — .
. , DevOps — .
, .
— ? , , , , ?
? ? ? , , , 3 ?
, , .
, , .
, .
, , . , , .
.
, IDE . IDE , , . Sublime, Atom Visual Studio Code, , , IDE.
. , - , , . - — , pull request — , . .
. , . , — .
, , . , Time-to-market.
vendor lock : , , , . , . , , vendor lock . .
, DevOps-.
, .
, CPU, , . —
: , , CI/CD Engine, , .
: , , , Load Balance , resizing , Big Data . —
, .
, , , , — , .
delivery pipeline . , — . , — : , , , , .
, , — , , . , Okmeter? , , . — , , Prometheus .
. , , , . , DevOps.
—
, , . rocket science — , . , — .
?
, .
? ? ?
. - — , , .
, DevOps...
… , :
- .
- , .
- , .
- Continuous Delivery.
- .
- .
- .
- , DevOps.
- , .
, , - : .
DevOpsConf 2019 . ++. , , DevOps-. , 20