لدينا DevOps. دعنا نطلق جميع المختبرين

هل من الممكن لأتمتة أي شيء؟ ثم سنطلق جميع المختبرين ، بالطبع. لماذا هم بحاجة الآن ، لا يوجد اختبار "اليدوي" اليسار. مباشرة بعد كل شيء؟

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



تستند المادة إلى نسخة من تقرير Baruch jbaruch Sadogursky ، المطور Advocate في JFrog. النسخة النصية والفيديو من التقرير هي تحت الخفض.



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

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



هذا فاسيا. في صباح أحد الأيام ، يأتي إلى العمل ويمشي عبر قاعة الاجتماعات الرئيسية. وهناك يرحب رئيسه بمستشار جديد. يأتي مستشار كفاءة إلى الشركة ويقول: "سنفعل DevOps كما هو الحال في netflix *. توجهنا على وجه التحديد إلى وادي السيليكون لحضور مؤتمر ، وهناك قيل لنا كيف يفعلون في نيتفليكس. "

* إخلاء المسئولية: غالبًا ما يستخدم Netflix في هذه المقالة كمثال مثالي بعيد المنال لـ DevOps. هذا الاستخدام هو كلمة المنزلية.

إن مناقشة ما إذا كان لدى Netflix بالفعل DevOps المثالي هو خارج نطاق هذه المقالة (على الأرجح ، بالمناسبة ، لا).

يقومون بتثبيت Spinnaker ، ثم إطلاق Chaos Monkey ، وكل شيء تلقائي. وسوف نفعل ذلك وسوف نكون فعالين جدا.

يسأل رئيسه ، ماذا عن المختبرين. وهنا ، كما هو الحال في netflix - الحرية والمسؤولية . سوف يكتب المطورون الاختبارات بأنفسهم. "

ثم يصاب فاسيا ، لأنه ينظر إلى بطاقة عمله ، وهناك ...



يبدأ Vasya بالقلق: في المرة الأخيرة التي جاء فيها مستشار كفاءة ، تم إقالة صديقه ، ناتاشا ، الذي كان يعمل كمسؤول للنظام. لأنه في كل مكان DevOps. ثم يدرك أنه سيكون كل شيء سيئًا قريبًا.

لكن ، بالطبع ، تستيقظ فاسيا.



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

JFrog هي شركة ناشئة في وادي السيليكون ، وكان تقييمنا الأخير أكثر من مليار دولار. نحن يونيكورن رسميًا وننفذ أتمتة DevOps. منتجاتنا - Artifactory و Xray و Mission Control وما إلى ذلك - أدوات للتشغيل الآلي الذي يحول مصنع معالجة اللحوم Omsk إلى netflix.

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

لدي أخبار لك: 80 ٪ من المطورين يكتبون الاختبارات. راضون المطورين مع جميع أنواع استطلاعات الرأي. حسنًا ، JetBrains سعيدة بتقرير حالة النظام البيئي المطور . يسألون من يكتب اختبارات الوحدة.

• 59 ٪ الكتابة من تلقاء نفسها
• 11 ٪ يرون اختبارات الوحدة في الكود الخاص بهم ولا يعرفون من أين أتوا.

في المجموع ، يستخدم 70٪ من المطورين اختبارات الوحدة. هذا رائع.

هناك دراسة أكثر تعمقا أجراها Hubstaff حول الاختبار بمساعدة المطورين ، وهي أقدم قليلاً - 2014. حسب قوله:

• 85 ٪ من المطورين يكتبون اختبارات وحدة ،
• 15 ٪ لا ؛
• 40 ٪ تعمل وفقا لمنهجية التنمية يحركها الاختبار ؛
• تغطية جيدة - بين 34 و 66 بين 31 ٪ من المطورين.

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

منذ عام 2011 ، اقتباسنا المفضل هو: "كل شركة هي شركة برمجيات" . بما في ذلك ، بطبيعة الحال ، مصنع أومسك للحوم الذي يعمل فيه فاسيا. في كل مكان هناك برنامج وكل شخص على هذا البرنامج يحاول كسب المال. ماذا تريد الشركات؟ صف المسروقات مع مجرفة. من أين تأتي الأموال؟ من العملاء بالارتياح. ماذا يريد العملاء؟ ميزات جديدة. ومتى يريدون ميزات جديدة؟ الآن!

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

يجب أن أفرج عنه في كثير من الأحيان؟ على سبيل المثال ، في عام 2017 ، تحولت Java إلى إصدارات أكثر تكرارًا ، لأن الجميع يريدون ميزات ، ويبدو أنهم بحاجة إلى إصدارها بشكل أسرع. كل ستة أشهر تصدر جافا جديدة. ولكن لا أحد يستخدمه.

لقد أجرينا مؤخرًا Joker ، واستضفنا Java Puzzlers عليه. في البداية ، نسأل دائمًا عن من يوجد في Java ، لفهم أي قطع الألغاز التي يجب طرحها.

لم تتغير الصورة: 80٪ ، أو أكثر ، لا يزالون جالسين على Java 8 ، الذي صدر قبل مائة عام. لا أحد يأخذ التاسعة ولا العاشرة أو الحادية عشرة.



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

كيف نضع التحديثات

يصل إشعار بأن لدينا تحديثًا ، فلنقم بتثبيت نظام تشغيل جديد. هل نريد هذا؟ هل هناك شيء مفيد هناك ، أو هل لدينا سجل نقدي يعمل على نظام Windows 98 Embedded ، ولا نحتاج إلى أي شيء آخر؟

إذا كنا نريد هذا التحديث ، فإن السؤال التالي هو مدى خطورة ذلك. إنه شيء واحد عندما يتم تحديث Facebook ، ولدينا التمرير ، ولن نكون قادرين على ذلك. إنه شيء آخر تمامًا عند إيقاف تشغيل نظام دعم الحياة في المستشفى. إذا لم نتعرف على المخاطر ، فلنقم بالتحديث. إذا كانت هناك مخاطر ، فالسؤال هو الثقة في الشخص الذي يقوم بطرح التحديث.

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

نحن نفعل ما يسمى اختبارات القبول. يخبروننا هنا: تم إصدار جافا جديد ، على سبيل المثال ، نحن بايدو. Highload ، 100،500 خوادم ، سحابة ، JVM في كل مكان. نأخذ جزءًا من الخوادم ، ونبدأ في تغيير Java. يتعين على مجموعة من المهندسين القيام بشيء والتحقق من ذلك كله. مرة واحدة كل ثلاث سنوات ، يكون ذلك طبيعيًا ، لكن مرة كل ستة أشهر ... هل أنت مارس الجنس؟ سوف نتحقق منه فقط لمدة ستة أشهر. بالطبع ، لن نأخذ هذا جافا الجديد الخاص بك.

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

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

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



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

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

مسألة الثقة أمر بالغ الأهمية. كيف نحلها؟ تشير كلمة "نحن" إلى المؤسسين المشاركين لـ JFrog وفريد ​​سايمون (فريد سايمون) ويواف لاندمان (يوآف لاندمان) وعبدك المتواضع. لقد كتبنا كتابًا ينصح بكيفية حل هذه المشكلة.

لنفترض أننا أقنعنا الرئيس التنفيذي لدينا ، بقراءة Liquid Software ، والآن يفهم سبب حاجته إلى تحديث. يسأل المستشار كيف سنقوم بالتحديث أكثر من مرة. رشيقة! DevOps! ما هو DevOps؟

DevOps

اسمح لي أن أخبركم بنظرية صغيرة عن DevOps ، لأننا نجني المال من ذلك. ألقِ نظرة على الصورة ، كان لدينا هذه المجموعات والفرق والإدارات:


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

اللغة الروسية جميلة: القسم دائمًا ما يكون منفصلاً ، هذا هو أصل الكلمة. في اللغة الإنجليزية ، ليس هذا السحر ، لذلك ، تسمى هذه الأقسام المختلفة الصوامع . أفضل ترجمة لهذه الكلمة إلى الروسية قدمها أنتون فايس ، الذي كان أفضل متحدث في DevOops . يسمي الصوامع "الآبار". الإدارات المختلفة - الآبار العميقة. لتحميل بعض الأعمال هناك ، تحتاج إلى النزول ، ثم سحب العمل من هناك - الارتفاع. هو الأكثر ملاءمة للقيام بذلك في مجموعات. كيف نجمع الأشياء التي نخرجها من البئر؟

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

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

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

هذا ليس خطأي! لقد أخذت الألوان الثلاثة الأصلية فقط ، ووضعتها فوق بعضها البعض ، وانتهى هذا اللون. الآن نحن جميعا نفعل كل شيء. لدينا مثل هؤلاء المهندسين الذين هم كلا Shvets ، و Reapers ، و Dyuras. هذه هي ديف ، QA و OPS. لقد كتب واختبر الكود ، ثم طرح كل شيء على الإنتاج - مثل هذا وحيد القرن.

ما هي مشكلة حيدات؟ أنها غير موجودة. وتلك القائمة ، تم توظيفهم منذ فترة طويلة بواسطة netflix. لذلك ، يبقى لنا أن نجعل الخليط.

الخليط

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

هذا هو ، لدينا أشخاص على شكل حرف T ، "أشخاص على شكل حرف T".

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

DevOps هي:

• ثقافة ما لدينا الآن أهداف مشتركة ، ونحن نفهم ما نقوم به معا.
• أتمتة الإفراج في كثير من الأحيان.

السرعة والجودة

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

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

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

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

أولاً ، قسموا جميع المجيبين إلى ثلاث مجموعات: أصحاب الأداء المتدني والأداء المتوسط ​​والأداء العالي.

بالإضافة إلى ذلك ، هناك النخبة. هذا هو Netflix (في الواقع لا ، انظر إخلاء المسؤولية أعلاه).



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

هذا غريب نوعا ما. اتضح أن متوسط ​​يتم اختباره بمقابض أكثر من منخفض. لماذا؟ نعم ، لأن Low لا يختبر أي شيء على الإطلاق.



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

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

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



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

نحن بحاجة إلى الإجابة على سؤال حول كيفية العيش دون اختبار يدوي. الجواب هو نفس السؤال عن كيفية العيش دون إعداد الخوادم. ممكن بوضوح ما الذي يتغير؟

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



نحن نحل هذا مع الأتمتة الصحيحة. إننا نقوم بأتمتة العملية ، ولدينا خط أنابيب مُعد مسبقًا ، والآن يتم طرح المنتج تلقائيًا بمجرد الانتهاء من الكتابة. هل هذا يعني أن هؤلاء الناس الآن ليست هناك حاجة؟ لا. هذا يعني أن هناك حاجة إليهم ، لكنهم يقومون بشيء آخر.

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


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

• وهذا يتطلب ، على سبيل المثال ، فرق متعددة الوظائف . هنا استيقظنا من الآبار وجلسنا معًا. الآن لدينا أسد يرقد مع خروف ، ويعمل المختبر مع المبرمج.
• نفعل اختبار مستمر . انها مثل الاختبار الآلي ، ولكن أكثر ذكاء.
• في عملية التطوير ، يتم "اختبار الدماغ" . هذا المصطلح أصح من مصطلح "الاختبار اليدوي" ، لأن الاختبار اليدوي يدور حول الدماغ وليس حول اليدين. شكرا لك على هذا المصطلح على التوأم الخاص بي على Facebook Alexey Vinogradov. اختبار الدماغ يحدث أثناء عملية التطوير. بمجرد ظهور شيء ما ، يمكنك بالفعل التحقق من التدفق الخاص به ، ويمكنك بالفعل فهم كيفية عمله ، ويمكنك بالفعل البدء في تحديد بعض الحالات الزاوية ، والتي سنقوم آليا بها.
• نحن نتابع الآن المطور. إذا لم يكتب الاختبار في البداية ، يمكننا أن نعطيه صفعة في الوجه. هذا هو اختبار يحركها التنمية .
• ملاحظات فورية مهمة. يجب أن يكون لدينا خط أنابيب يخبرنا على الفور بمجرد حدوث شيء ما. لأنه يتعين علينا الذهاب على الفور وإصلاحه على الفور.
• المشاركة في التصميم . يحدث أنك نظرت إلى شيء وفكرت كيف سنختبر هذا القرف الآن. ولكن عفوا ، أين كنت عندما قرر الجميع أنه سيكون هناك القرف؟ أتيت إلى الاجتماع وتقول إنك لا توافق ، يجب عليك أن تفعل ذلك دون وعي. يجب أن تشارك في التصميم لضمان أنه يمكنك اختباره لاحقًا.
• الأدوات ، يسخر ، مواقف - ما يفعله الكثير منكم اليوم لا يذهب إلى أي مكان. على العكس ، سيكون هذا أكثر. وفقا لذلك ، يجب أن يكتب شخص ما هذا.
• هندسة الفوضى . كنت تحلم دائمًا بتشغيل Chaos Monkey في الإنتاج ، خاصة إذا كان لديك شبكة من أجهزة الصراف الآلي على نظام التشغيل Windows 95. هذه هي فرصتك.
• وأخيرا ، تحتاج إلى تعليم الجهل لتصميم الاختبارات . قررنا أن المطورين على الأقل يدعون أنهم يكتبون الاختبارات. دعهم الآن يكتبون الاختبارات ، فقط نحتاج إلى تعليمهم كيفية القيام بذلك. من سيعلمهم ، كيف يعرفون كيفية كتابة الاختبارات؟ أنت فقط لا أحد غيرك

يبقى لأتمتة كل شيء. في الواقع ، يمكننا أتمتة الاختبار. المشكلة هي أنه يمكنك أتمتة جزء معين.


تعلمون جميعًا هذه النكتة عن الطريقة التي يدخل بها المختبر ، يطلب البيرة ، يطلب 0 بيرة ، يطلب 99999999999 البيرة ، يطلب سحلية ، يطلب -1 بيرة ويطلب ... هذا خطأ ، لأنه يجب أن يكون asdfgh ، ليس هذا القمامة.

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



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

, , , . DevOps. , . T- — , .

, - . « », , . , , , . , Selenium . , .

, .



— . , , . . , , Ops- , , , , , , , .



Developers in test — , , . , . , ; — , ; TDD , , , , . , , .



« ». , , , , , — . , , , , , , , , , , Continuous Testing .

end-to-end , . , , DevOps, .

, - , . , 70- : « DevOps, ». , , .

. -, , , , , . : ( EVP Engineering, SignalFx) , , .

70- . . , , . , . , , , , . , , , , — , netflix .

, , , , , , , , , . . , .

, . . « , », — , , .



«, — . — : , , , . , , , , , . . , - , . ? Artifactory , ?!».

, — , . , . ? !



DORA: , , , .



New Work. , New Work Low — 30%, Medium — 40%, High Elite — 50%. ( , Low) , , .

.

Heisenbug 2018 Moscow, — 17-18 Heisenbug. , . , ( ).