دعونا نناقش سبب كون أدوات CI وCI شيئان مختلفان تمامًا.
ما هو الألم الذي تهدف CI إلى حله، ومن أين أتت الفكرة، وما هي أحدث التأكيدات على أنها تعمل، وكيف تفهم أن لديك ممارسة وليس مجرد تثبيت Jenkins.
ظهرت فكرة إعداد تقرير حول التكامل المستمر منذ عام، عندما كنت أذهب لإجراء مقابلات وأبحث عن وظيفة. لقد تحدثت إلى 10-15 شركة، واحدة منهم فقط كانت قادرة على الإجابة بوضوح على ما هو CI وشرح كيف أدركوا أنهم لا يملكونه. كان الباقون يتحدثون عن جينكينز هراء غير مفهوم :) حسنًا، لدينا جينكينز، إنه يبني، CI! خلال التقرير، سأحاول أن أشرح ما هو التكامل المستمر في الواقع ولماذا ترتبط جينكينز والأدوات المماثلة به بشكل ضعيف جدًا.
إذًا، ما الذي يتبادر إلى ذهنك عادة عندما تسمع كلمة CI؟ سوف يفكر معظم الناس في Jenkins وGitlab CI وTravis وما إلى ذلك.
حتى لو بحثنا عنها في جوجل، فسوف توفر لنا هذه الأدوات.
إذا كنت معتادًا على السؤال، فبعد إدراج الأدوات مباشرة، سيخبرونك أن CI يحدث عند إنشاء الاختبارات وتشغيلها في طلب سحب للالتزام.
التكامل المستمر لا يتعلق بالأدوات، ولا يتعلق بالتجميعات مع الاختبارات في الفرع! التكامل المستمر هو ممارسة التكامل المتكرر جدًا للتعليمات البرمجية الجديدة واستخدامها ليس من الضروري على الإطلاق تسييج Jenkins وGitLab وما إلى ذلك.
قبل أن نكتشف كيف يبدو CI الكامل، دعنا نتعمق أولاً في سياق الأشخاص الذين توصلوا إليه ونشعر بالألم الذي كانوا يحاولون حله.
وقد حلوا آلام العمل معًا كفريق واحد!
دعونا نلقي نظرة على أمثلة الصعوبات التي يواجهها المطورون عند التطوير ضمن فرق. هنا لدينا مشروع وفرع رئيسي في git واثنين من المطورين.
وذهبوا إلى العمل كما اعتاد الجميع منذ فترة طويلة. لقد أخذنا مهمة في المخطط الكبير للأشياء، وأنشأنا فرعًا مميزًا، وكتبنا الكود.
أنهى أحدهم الميزة بشكل أسرع ودمجها في الملف الرئيسي.
أما الثانية فكانت بحاجة لمزيد من الوقت، فاندمجت فيما بعد وانتهى الأمر بالصراع. الآن، بدلاً من كتابة الميزات التي يحتاجها العمل، يقضي المطور وقته وطاقته في حل النزاعات.
كلما زادت صعوبة دمج الميزة الخاصة بك مع ميزة رئيسية مشتركة، زاد الوقت الذي نقضيه في ذلك. وقد أظهرت ذلك بمثال بسيط إلى حد ما. هذا مثال حيث يوجد مطوران فقط، تخيل لو أن 2 أو 10 أو 15 شخص في الشركة يكتبون إلى مستودع واحد. سوف تصاب بالجنون لحل كل هذه الصراعات.
هناك حالة مختلفة قليلا. لدينا سيد وبعض المطورين يفعلون شيئًا ما.
لقد خلقوا غصينًا.
توفي واحد، كل شيء على ما يرام، اجتاز المهمة.
وفي الوقت نفسه، سلم المطور الثاني مهمته. لنفترض أنه أرسلها للمراجعة. العديد من الشركات لديها ممارسة تسمى المراجعة. من ناحية، هذه الممارسة جيدة ومفيدة، ومن ناحية أخرى، فإنها تبطئنا بعدة طرق. لن نخوض في ذلك، ولكن إليك مثالًا رائعًا لما يمكن أن تؤدي إليه قصة المراجعة السيئة. لقد أرسلت طلب سحب للمراجعة. لا يوجد شيء آخر يمكن للمطور القيام به. ماذا يبدأ بفعله؟ يبدأ في تولي مهام أخرى.
خلال هذا الوقت، قام المطور الثاني بشيء آخر.
الأول أكمل المهمة الثالثة.
وبعد فترة طويلة، تم اختبار مراجعته، وهو يحاول التصالح. ماذا يحصل؟ إنه يمسك بعدد كبير من الصراعات. لماذا؟ لأنه بينما كان طلب السحب الخاص به معلقًا في المراجعة، فقد تغيرت الكثير من الأشياء بالفعل في الكود.
بالإضافة إلى قصة الصراعات، هناك قصة مع الاتصالات. بينما يكون موضوعك معلقًا قيد المراجعة، بينما ينتظر شيئًا ما، بينما تعمل على ميزة ما لفترة طويلة، فإنك تتوقف عن تتبع ما يتغير أيضًا في قاعدة التعليمات البرمجية لخدمتك. ربما ما تحاول حله الآن قد تم حله بالفعل بالأمس ويمكنك استخدام بعض الطرق وإعادة استخدامها. لكنك لن ترى هذا لأنك تعمل دائمًا مع فرع قديم. ويؤدي هذا الفرع القديم دائمًا إلى اضطرارك إلى حل تعارض الدمج.
اتضح أنه إذا عملنا كفريق، أي لا يوجد شخص واحد يتجول في المستودع، ولكن 5-10 أشخاص، فكلما طالت مدة عدم إضافة الكود الخاص بنا إلى المعلم، زادت معاناتنا لأننا نحتاج في النهاية إلى شيء ثم دمجه. وكلما زاد عدد الصراعات التي نواجهها، والإصدار الأقدم الذي نعمل معه، زادت المشكلات التي نواجهها.
القيام بشيء معًا أمر مؤلم! نحن دائما نعترض طريق بعضنا البعض.
وقد لوحظت هذه المشكلة منذ أكثر من 20 عاما. لقد وجدت أول ذكر لممارسة التكامل المستمر في البرمجة المتطرفة.
البرمجة المتطرفة هي أول إطار رشيق. ظهرت الصفحة عام 96. وكانت الفكرة هي استخدام نوع ما من ممارسات البرمجة والتخطيط وأشياء أخرى، بحيث يكون التطوير مرنًا قدر الإمكان، حتى نتمكن من الاستجابة بسرعة لأي تغييرات أو متطلبات من عملائنا. وقد بدأوا في مواجهة هذا منذ 24 عامًا، وهو أنه إذا قمت بشيء ما لفترة طويلة جدًا وعلى الهامش، فإنك تقضي وقتًا أطول في ذلك لأنه سيكون لديك صراعات.
الآن سنقوم بتحليل عبارة "التكامل المستمر" بشكل فردي. وإذا ترجمناها مباشرة نحصل على التكامل المستمر. لكن مدى استمراريتها ليس واضحًا تمامًا، فهي متقطعة جدًا. ولكن مقدار التكامل الذي تتمتع به ليس واضحًا أيضًا.
ولهذا السبب أقدم لك اقتباسات من البرمجة المتطرفة الآن. وسوف نقوم بتحليل كلتا الكلمتين على حدة.
التكامل - كما قلت سابقًا، نحن نسعى جاهدين للتأكد من أن كل مهندس يعمل بأحدث إصدار من الكود، بحيث يسعى جاهداً لإضافة الكود الخاص به كلما كان ذلك ممكنًا إلى فرع مشترك، بحيث تكون هذه فروعًا صغيرة. لأنه إذا كانت كبيرة، فيمكننا بسهولة أن نتعثر في تعارضات الدمج لمدة أسبوع. هذا صحيح بشكل خاص إذا كانت لدينا دورة تطوير طويلة مثل الشلال، حيث ذهب المطور بعيدًا لمدة شهر لقص بعض الميزات الضخمة. وسوف يبقى عالقاً في مرحلة التكامل لفترة طويلة جداً.
التكامل هو عندما نأخذ فرعنا وندمجه مع السيد، فإننا ندمجه. هناك خيار نهائي عندما نكون مطورين Transbase، حيث نسعى جاهدين للتأكد من أننا نكتب على الفور إلى المعلم دون أي فروع إضافية.
بشكل عام، التكامل يعني أخذ الكود الخاص بك وسحبه إلى الملف الرئيسي.
ما المقصود هنا بكلمة "مستمر" ما الذي يسمى الاستمرارية؟ تشير الممارسة إلى أن المطور يسعى جاهداً لدمج الكود الخاص به في أسرع وقت ممكن. هذا هو هدفه عند تنفيذ أي مهمة - وهو وضع الكود الخاص به في وضع رئيسي في أسرع وقت ممكن. في عالم مثالي، كان المطورون يقومون بذلك كل بضع ساعات. أي أنك تأخذ مشكلة صغيرة وتدمجها في المشكلة الرئيسية. كل شيء عظيم. وهذا هو ما تسعى جاهدة من أجله. ويجب أن يتم ذلك بشكل مستمر. بمجرد أن تفعل شيئًا ما، فإنك تضعه على الفور في السيد.
والمطور الذي يصنع شيئًا ما هو المسؤول عما فعله لإنجاحه وعدم كسر أي شيء. هذا هو المكان الذي تظهر فيه قصة الاختبار عادةً. نريد إجراء بعض الاختبارات على التزامنا ودمجنا للتأكد من نجاحه. وهذا هو المكان الذي يمكن أن يساعدك فيه جينكينز.
لكن مع القصص: لنجعل التغييرات صغيرة، ولنجعل المهام صغيرة، ولنصنع مشكلة ونحاول على الفور دمجها بطريقة أو بأخرى في المعلم - لن يساعد جينكينز هنا. لأن جنكينز سيساعدك فقط في إجراء الاختبارات.
يمكنك الاستغناء عنها. وهذا لن يؤذيك على الإطلاق. لأن الهدف من الممارسة هو القياس قدر الإمكان، حتى لا تضيع قدرًا كبيرًا من الوقت في أي صراعات في المستقبل.
دعونا نتخيل أننا لسبب ما في عام 2020 بدون الإنترنت. ونحن نعمل محليا. ليس لدينا جينكينز. هذا جيد. لا يزال بإمكانك المضي قدمًا وإنشاء فرع محلي. لقد كتبت بعض التعليمات البرمجية فيه. أكملنا المهمة في 3-4 ساعات. لقد تحولنا إلى الوضع الرئيسي، وقمنا بعملية سحب، ودمجنا فرعنا هناك. مستعد. إذا كنت تفعل ذلك كثيرًا، فتهانينا، فلديك تكامل مستمر!
ما هو الدليل الموجود في العالم الحديث على أن الأمر يستحق إنفاق الطاقة عليه؟ لأنه بشكل عام صعب. إذا حاولت العمل بهذه الطريقة، فسوف تفهم أن بعض التخطيط سيتأثر الآن، وسيتعين عليك تكريس المزيد من الوقت لتحلل المهام. لأنك إذا فعلت ذلك يا رجل... فلن تتمكن من التصالح بسرعة، وبالتالي ستقع في المشاكل. لن يكون لديك ممارسة بعد الآن.
وسوف تكون مكلفة. لن يكون من الممكن العمل فورًا اعتبارًا من الغد باستخدام التكامل المستمر. سوف يستغرق الأمر وقتًا طويلاً جدًا للتعود عليه، وسوف يستغرق الأمر وقتًا طويلاً للغاية للتعود على تحلل المهام، وسوف يستغرق الأمر وقتًا طويلاً للغاية للتعود على إعادة ممارسة المراجعة، إذا كان لديك واحدة . لأن هدفنا هو أن يذوب اليوم. وإذا قمت بإجراء المراجعة خلال ثلاثة أيام، فهذا يعني أن لديك مشكلات وأن التكامل المستمر لا يعمل لصالحك.
ولكن هل لدينا أي دليل ذي صلة في الوقت الحالي يخبرنا أن الاستثمار في هذه الممارسة أمر منطقي؟
أول ما يتبادر إلى ذهني هو حالة DevOps. هذه دراسة أجراها الرجال لمدة 7 سنوات. والآن يفعلون ذلك كمنظمة مستقلة، ولكن تحت إشراف جوجل.
وأظهرت دراستهم لعام 2018 وجود علاقة بين الشركات التي تحاول استخدام الفروع قصيرة العمر التي تتكامل بسرعة، وتتكامل بشكل متكرر، ولديها مؤشرات أداء أفضل لتكنولوجيا المعلومات.
ما هي هذه المؤشرات؟ هذه هي 4 مقاييس يأخذونها من جميع الشركات في استبياناتهم: تكرار النشر، والمهلة الزمنية للتغييرات، والوقت اللازم لاستعادة الخدمة، ومعدل فشل التغيير.
أولاً، هناك هذا الارتباط، فنحن نعلم أن الشركات التي تقوم بالقياس بشكل متكرر لديها مقاييس أفضل بكثير. ولديهم تقسيم الشركات إلى عدة فئات: هذه شركات بطيئة تنتج شيئًا ما ببطء، ومتوسطة الأداء، وعالية الأداء، ونخبوية. النخبة هم Netflix وAmazon، وهي شركات تتميز بالسرعة الفائقة، وتفعل كل شيء بسرعة وبشكل جميل وكفاءة.
القصة الثانية والتي حدثت قبل شهر واحد فقط. لدى Technology Radar مقالة رائعة حول Gitflow. يختلف Gitflow عن غيره من حيث أن فروعه طويلة العمر. هناك فروع الإصدار التي تعيش لفترة طويلة، وهناك فروع مميزة تعيش أيضًا لفترة طويلة. انتقلت هذه الممارسة في Technology Radar إلى HOLD. لماذا؟ لأن الناس يواجهون آلام التكامل.
إذا كان فرعك يعيش لفترة طويلة جدًا، فإنه يعلق ويتعفن، ونبدأ في قضاء المزيد من الوقت في محاولة إجراء نوع من التغيير عليه.
ومؤخرًا، قال مؤلف Gitflow إنه إذا كان هدفك هو التكامل المستمر، وإذا كان هدفك هو أنك ترغب في الاستمرار بأكبر عدد ممكن من المرات، فإن Gitflow فكرة سيئة. لقد أضاف بشكل منفصل إلى المقالة أنه إذا كان لديك خلفية حيث يمكنك السعي لتحقيق ذلك، فإن Gitflow غير ضروري بالنسبة لك، لأن Gitflow سوف يبطئك، وسيخلق Gitflow مشاكل لك في التكامل.
هذا لا يعني أن Gitflow سيء ولا ينبغي استخدامه. انها لمناسبات أخرى. على سبيل المثال، عندما تحتاج إلى دعم إصدارات متعددة من خدمة أو تطبيق ما، أي عندما تحتاج إلى دعم لفترة طويلة من الزمن.
ولكن إذا تحدثت مع الأشخاص الذين يدعمون مثل هذه الخدمات، فسوف تسمع الكثير من الألم حول حقيقة أن هذا الإصدار كان 3.2، والذي كان قبل 4 أشهر، ولكن لم يتم تضمين هذا الإصلاح فيه والآن، من أجل إجراء ذلك، تحتاج إلى إجراء مجموعة من التغييرات. والآن أصبحوا عالقين مرة أخرى، وهم الآن يعبثون لمدة أسبوع محاولين تنفيذ بعض الميزات الجديدة.
وكما لاحظ ألكسندر كوفاليف بشكل صحيح في الدردشة، فإن الارتباط ليس مثل السببية. هذا صحيح. أي أنه لا يوجد اتصال مباشر إذا كان لديك تكامل مستمر، فستكون جميع المقاييس رائعة. ولكن هناك علاقة إيجابية مفادها أنه إذا كان أحدهما واحدًا، فمن المرجح أن الآخر كذلك أيضًا. ليست حقيقة، ولكن على الأرجح. انها مجرد علاقة.
يبدو أننا نفعل شيئًا ما بالفعل، ويبدو أننا ندمج بالفعل، ولكن كيف يمكننا أن نفهم أنه لا يزال لدينا تكامل مستمر، وأننا ندمج كثيرًا؟
جيز همبل هو مؤلف كتاب Handbook وAccelerate وموقع التسليم المستمر وكتاب التسليم المستمر. ويقدم هذا الاختبار:
- يصل رمز المهندس إلى السيد كل يوم.
- لكل التزام تقوم بإجراء اختبارات الوحدة.
- سقط البناء في السيد، وتم إصلاحه في حوالي 10 دقائق.
يقترح استخدام اختبار مثل هذا للتأكد من أن لديك ما يكفي من الممارسة.
أجد هذا الأخير مثيرا للجدل بعض الشيء. أي أنه إذا تمكنت من إصلاحه في 10 دقائق، فسيكون لديك تكامل مستمر، يبدو الأمر غريبًا بعض الشيء، في رأيي، لكنه منطقي. لماذا؟ لأنه إذا تجمدت كثيرًا، فهذا يعني أن تغييراتك صغيرة. إذا كان التغيير البسيط يعني أن البنية الرئيسية الخاصة بك معطلة، فيمكنك العثور على مثال بسرعة لأن التغيير صغير. هنا كان لديك دمج صغير، تم تغيير 20-30 سطرًا فيه. وبناء على ذلك، يمكنك أن تفهم بسرعة ما هو السبب، لأن التغييرات صغيرة، لديك مساحة صغيرة جدًا للبحث عن المشكلة.
وحتى لو انهار منتجنا بعد الإصدار، فعندئذ إذا مارسنا التكامل المستمر، فسيكون من الأسهل علينا التصرف، لأن التغييرات صغيرة. نعم، هذا سوف يؤثر على التخطيط. هذا سوف يضر. وربما يكون أصعب شيء في هذه الممارسة هو التعود على تقسيم المهام، أي كيفية القيام بذلك حتى تتمكن من أخذ شيء ما والقيام به في غضون ساعات قليلة وفي نفس الوقت اجتياز المراجعة، إذا لديك واحدة. المراجعة هي ألم منفصل.
تعد اختبارات الوحدة مجرد مساعد يساعدك على فهم ما إذا كان التكامل الخاص بك ناجحًا وما إذا لم يتم كسر أي شيء. في رأيي، هذا أيضًا ليس إلزاميًا تمامًا، لأن هذا ليس الهدف من الممارسة.
هذه مقدمة مختصرة عن التكامل المستمر. هذا كل ما في هذه الممارسة. أنا مستعد للأسئلة.
سألخص بإيجاز مرة أخرى:
- التكامل المستمر ليس جينكينز، وليس Gitlab.
- هذه ليست أداة، إنها ممارسة نقوم فيها بدمج الكود الخاص بنا في البرنامج الرئيسي كلما كان ذلك ممكنًا.
- نحن نفعل ذلك لكي نتجنب الألم الهائل الذي ينشأ مع عمليات الدمج في المستقبل، أي أننا نعاني من القليل من الألم الآن حتى لا نعاني المزيد في المستقبل. هذا هو بيت القصيد.
- يوجد على الجانب اتصال من خلال الكود، لكنني نادرًا ما أرى هذا، ولكن هذا أيضًا ما تم تصميمه من أجله.
الأسئلة
ماذا تفعل مع المهام غير المتحللة؟
تتحلل. ما المشكلة؟ هل يمكنك إعطاء مثال على أن هناك مهمة وهي غير متحللة؟
هناك مهام لا يمكن فصلها عن كلمة "تمامًا"، على سبيل المثال، تلك التي تتطلب خبرة عميقة جدًا والتي يمكن حلها فعليًا على مدار شهر لتحقيق نتيجة سهلة الهضم.
إذا فهمت بشكل صحيح، فهناك بعض المهام الكبيرة والمعقدة، والنتيجة التي ستكون مرئية فقط في شهر واحد؟
نعم هذا صحيح. نعم، سيكون من الممكن تقييم النتيجة في موعد لا يتجاوز شهر واحد.
بخير. بشكل عام هذه ليست مشكلة. لماذا؟ لأنه في هذه الحالة، عندما نتحدث عن الأغصان، فإننا لا نتحدث عن غصين ذو خاصية. يمكن أن تكون الميزات كبيرة ومعقدة. يمكن أن تؤثر على عدد كبير من المكونات. وربما لا يمكننا القيام بها بالكامل في فرع واحد. هذا جيد. نحن بحاجة فقط إلى كسر هذه القصة. إذا لم تكن الميزة جاهزة تمامًا، فهذا لا يعني أنه لا يمكن دمج بعض أجزاء التعليمات البرمجية الخاصة بها. لقد أضفت، على سبيل المثال، الهجرة وهناك بعض المراحل داخل الميزة. لنفترض أن لديك مرحلة - قم بالترحيل وأضف طريقة جديدة. ويمكنك بالفعل قياس هذه الأشياء كل يوم.
بخير. ما الفائدة إذن؟
ما الفائدة من قتل الأشياء الصغيرة كل يوم؟
نعم.
إذا كسروا شيئا، تراه على الفور. لديك قطعة صغيرة كسرت شيئًا ما، فمن الأسهل عليك إصلاحها. النقطة المهمة هي أن دمج قطعة صغيرة الآن أسهل بكثير من دمج قطعة كبيرة في بضعة أسابيع. والنقطة الثالثة هي أن المهندسين الآخرين سيعملون مع الإصدار الحالي من الكود. سيرون أنه تمت إضافة بعض عمليات الترحيل هنا، ثم ظهرت بعض الطرق التي قد يرغبون في استخدامها أيضًا. سيرى الجميع ما يحدث في التعليمات البرمجية الخاصة بك. لهذه الأشياء الثلاثة تتم الممارسة.
شكرا لك، تم إغلاق الموضوع!
(أوليج سوروكا) هل يمكنني أن أضيف؟ لقد قلت كل شيء بشكل صحيح، أريد فقط أن أضيف عبارة واحدة.
هكذا.
من خلال التكامل المستمر، يتم دمج التعليمات البرمجية في فرع مشترك ليس عندما تكون الميزة جاهزة تمامًا، ولكن عندما يتوقف البناء عن الانهيار. ويمكنك الالتزام بأمان بإتقانها عدة مرات في اليوم كما تريد. الجانب الثاني هو أنه إذا لم تتمكن لسبب ما من تقسيم المهمة الشهرية إلى مهام لمدة ثلاثة أيام على الأقل، فأنا صامت لمدة ثلاث ساعات، فهذا يعني أن لديك مشكلة كبيرة. وحقيقة عدم وجود تكامل مستمر لديك هو أقل هذه المشاكل. هذا يعني أن لديك مشاكل في الهندسة المعمارية وعدم وجود ممارسات هندسية. لأنه حتى لو كان هذا بحثًا، ففي أي حال يجب صياغته في شكل فرضيات أو دورة.
تحدثنا عن 4 مقاييس تميز الشركات الناجحة عن الشركات المتخلفة. لا يزال يتعين علينا أن نعيش لنرى هذه المقاييس الأربعة. إذا كانت مهمتك المتوسطة تستغرق شهرًا لإكمالها، فسأركز على هذا المقياس أولاً. سأخفضه إلى 4 أيام أولاً. وبعد ذلك بدأت أفكر في الاستمرارية.
هل فهمت بشكل صحيح أنك تعتقد أنه بشكل عام لا فائدة من الاستثمار في الممارسات الهندسية إذا كانت أي مهمة تستغرق شهرًا لإكمالها؟
لديك التكامل المستمر. وهناك موضوع يمكنك خلال 10 دقائق إما إصلاح الإصلاح أو إعادته. تخيل أنك طرحتها. علاوة على ذلك، لديك أيضًا نشر مستمر، وقمت بطرحه للحث وعندها فقط لاحظت حدوث خطأ ما. وتحتاج إلى استرجاعها، ولكنك قمت بالفعل بترحيل قاعدة البيانات الخاصة بك. لديك بالفعل مخطط قاعدة البيانات للإصدار التالي، علاوة على ذلك، كان لديك أيضًا نوع من النسخ الاحتياطي، وتمت كتابة البيانات أيضًا هناك.
وما هو البديل لديك؟ إذا قمت باستعادة التعليمات البرمجية، فلن يعد بإمكانها العمل مع قاعدة البيانات المحدثة هذه.
القاعدة تتحرك للأمام فقط، نعم.
من المرجح أن الأشخاص الذين لديهم ممارسات هندسية سيئة لم يقرؤوا الكتاب السميك حول ... أيضًا. ما يجب القيام به مع النسخة الاحتياطية؟ إذا قمت بالاستعادة من نسخة احتياطية، فهذا يعني أنك ستفقد البيانات التي تراكمت لديك خلال تلك اللحظة. على سبيل المثال، عملنا لمدة ثلاث ساعات مع الإصدار الجديد من قاعدة البيانات، حيث تم تسجيل المستخدمين هناك. أنت ترفض النسخة الاحتياطية القديمة لأن النظام لا يعمل مع الإصدار الجديد، وبالتالي تكون قد فقدت هؤلاء المستخدمين. وهم غير راضين، وأقسموا.
من أجل إتقان مجموعة كاملة من الممارسات التي تدعم التكامل المستمر والتسليم المستمر، لا يكفي أن تتعلم كيفية الكتابة فقط.... أولا، يمكن أن يكون هناك الكثير منهم، سيكون غير عملي. بالإضافة إلى أن هناك مجموعة من الممارسات الأخرى مثل العلمية. هناك مثل هذه الممارسة، وقد شاعها GitHub في وقت واحد. يحدث هذا عندما يكون لديك كل من التعليمات البرمجية القديمة والتعليمات البرمجية الجديدة قيد التشغيل في نفس الوقت. يحدث هذا عندما تقوم بإنشاء ميزة غير مكتملة، ولكن يمكنها إرجاع بعض القيمة: إما كدالة أو كواجهة برمجة تطبيقات بقية. تقوم بتنفيذ كل من الكود الجديد والكود القديم، ومقارنة الفرق بينهما. وإذا كان هناك اختلاف، فقم بتسجيل هذا الحدث. وبهذه الطريقة ستعرف أن لديك ميزة جديدة جاهزة للنشر فوق الميزة القديمة إذا لم يكن لديك تناقض بين الاثنين لفترة معينة.
هناك المئات من هذه الممارسات. أود أن أقترح البدء بتطوير Transbase. إنها ليست على التكامل المستمر بنسبة 100%، لكن الممارسات هي نفسها، لا يمكن لأحدهما أن يعيش بشكل جيد بدون الآخر.
هل أعطيت تطوير transbase كمثال حيث يمكنك رؤية الممارسات أو هل تقترح أن يبدأ الأشخاص في استخدام transbase debelopment؟
ألقِ نظرة، لأنهم لن يتمكنوا من استخدامه. من أجل استخدامها، تحتاج إلى قراءة الكثير. وعندما يسأل شخص ما: "ماذا تفعل بميزة تستغرق شهرًا، فهذا يعني أنه لم يقرأ عن تطوير ترانسباسيز". أنا لا أوصي به حتى الآن. أنصح بالتركيز فقط على موضوع كيفية تقسيم المهام الكبيرة بشكل صحيح إلى مهام أصغر. هذا هو جوهر التحلل.
التحلل هو إحدى أدوات المهندس المعماري. نقوم أولًا بالتحليل، ثم التحليل، ثم التركيب، ثم التكامل. وهذه هي الطريقة التي يسير بها كل شيء بالنسبة لنا. وما زلنا بحاجة إلى النمو نحو التكامل المستمر من خلال التحلل. تطرح الأسئلة في المرحلة الأولى، ونحن نتحدث بالفعل عن المرحلة الرابعة، أي كلما قمنا بالتكامل أكثر، كلما كان ذلك أفضل. ما زال الوقت مبكرًا للقيام بذلك، سيكون من الجيد قطع قطعة متراصة أولاً.
تحتاج إلى رسم عدد من الأسهم والمربعات على بعض المخططات. لا يمكنك القول أنني الآن سأعرض المخطط المعماري لتطبيق جديد وأظهر مربعًا واحدًا يوجد بداخله زر أخضر للتطبيق. على أية حال، سيكون هناك المزيد من المربعات والسهام. كل رسم تخطيطي رأيته كان به أكثر من واحد. والتحلل، حتى على مستوى التمثيل الرسومي، يحدث بالفعل. لذلك، يمكن جعل المربعات مستقلة. إذا لم يكن الأمر كذلك، لدي أسئلة كبيرة للمهندس المعماري.
هناك سؤال من الدردشة: "إذا كانت المراجعة إلزامية وتستغرق وقتا طويلا، ربما يوم أو أكثر؟"
لديك مشاكل في الممارسة. يجب ألا تستمر المراجعة يومًا أو أكثر. هذه هي نفس قصة السؤال السابق، ولكن بشكل أكثر ليونة قليلاً. إذا استمرت المراجعة لمدة يوم، فمن المرجح أن هذه المراجعة ستحدث تغييرًا كبيرًا جدًا. وهذا يعني أنه يجب أن يكون أصغر. في تطوير Transbase، الذي أوصى به أوليغ، هناك قصة تسمى المراجعة المستمرة. فكرتها هي أننا نقوم بتقديم مثل هذا الطلب الصغير عن قصد، لأننا نسعى جاهدين للدمج باستمرار وقليلًا في كل مرة. وبالتالي فإن طلب السحب يغير تجريدًا واحدًا أو 10 أسطر. بفضل هذه المراجعة، يستغرق الأمر منا بضع دقائق.
إذا استغرقت المراجعة يومًا أو أكثر، فهذا يعني أن هناك خطأ ما. أولا، قد يكون لديك بعض المشاكل مع الهندسة المعمارية. أو هذا جزء كبير من التعليمات البرمجية، 1 سطر، على سبيل المثال. أو أن الهندسة المعمارية الخاصة بك معقدة للغاية بحيث لا يستطيع الشخص فهمها. هذه مشكلة جانبية بعض الشيء، ولكن يجب أيضًا حلها. ربما ليست هناك حاجة للمراجعة على الإطلاق. نحن بحاجة إلى التفكير في هذا أيضا. المراجعة هي الشيء الذي يبطئك. بشكل عام، لها مزاياها، لكن عليك أن تفهم سبب قيامك بذلك. هل هذه هي الطريقة بالنسبة لك لنقل المعلومات بسرعة، هل هذه هي الطريقة بالنسبة لك لوضع بعض المعايير داخليًا أم ماذا؟ لماذا تحتاج هذه؟ لأن المراجعة يجب أن تتم إما بسرعة كبيرة أو إلغاؤها تمامًا. إنه مثل تطوير Transbase - القصة جميلة جدًا، ولكن فقط للرجال الناضجين.
فيما يتعلق بالمقاييس الأربعة، ما زلت أوصي بإزالتها لفهم ما يؤدي إليه ذلك. انظر إلى الأرقام، انظر إلى الصورة، كم هو سيء كل شيء.
(ديمتري) أنا مستعد للدخول في مناقشة حول هذا الأمر معك. الأرقام والمقاييس كلها رائعة، والممارسات رائعة. لكن عليك أن تفهم ما إذا كان العمل يحتاج إليه. هناك شركات لا تحتاج إلى هذا النوع من سرعة التغيير. أعرف شركات لا يمكن إجراء التغييرات فيها كل 15 دقيقة. وليس لأنهم سيئون للغاية. هذه هي دورة الحياة. ولجعل ميزة الفروع، ميزة التبديل، تحتاج إلى معرفة عميقة.
انه لامر معقد. إذا كنت ترغب في قراءة القصة حول ميزة التبديل بمزيد من التفاصيل، فأنا أوصي بها بشدة . وهناك مقالة رائعة كتبها مارتن فاولر حول ميزات التبديل: ما هي الأنواع الموجودة، ودورات الحياة، وما إلى ذلك. ميزة التبديل معقدة.
وما زلت لم تجب على السؤال: "هل هناك حاجة إلى جينكينز أم لا؟"
ليست هناك حاجة لجينكينز في أي حال من الأحوال حقا. على الرغم من ذلك، فإن الأدوات: Jenkins وGitlab ستوفر لك الراحة. سترى أن التجميع قد تم تجميعه أو لم يتم تجميعه. يمكنهم مساعدتك، لكنهم لن يعطوك التدريب. يمكنهم فقط إعطاؤك دائرة - حسنًا، ليس حسنًا. وبعد ذلك، إذا كتبت أيضًا اختبارات، لأنه إذا لم تكن هناك اختبارات، فهذا لا معنى له تقريبًا. لذلك، هناك حاجة إليها لأنها أكثر ملاءمة، ولكن بشكل عام يمكنك العيش بدونها، فلن تخسر الكثير.
بمعنى، إذا كان لديك ممارسات، فهل هذا يعني أنك لا تحتاج إليها؟
صحيح. أوصي باختبار Jez Humble. هناك لدي موقف متناقض تجاه النقطة الأخيرة. لكن بشكل عام، إذا كان لديك ثلاثة أشياء، وتدمجها باستمرار، وتجري اختبارات على الالتزامات في البرنامج الرئيسي، وتصلح البناء بسرعة في البرنامج الرئيسي، فربما لا تحتاج إلى أي شيء آخر.
وبينما نحن في انتظار أسئلة المشاركين، لدي سؤال. كنا نتحدث فقط عن رمز المنتج. هل استخدمته لرمز البنية التحتية؟ هل هو نفس الكود، هل له نفس المبادئ ونفس دورة الحياة، أم أن هناك دورات حياة ومبادئ مختلفة؟ عادة، عندما يتحدث الجميع عن التكامل والتطوير المستمر، ينسى الجميع أن هناك أيضًا كود البنية التحتية. وفي الآونة الأخيرة كان هناك المزيد والمزيد منه. وهل يجب إحضار كل هذه القواعد إلى هناك؟
حتى أنه لا ينبغي أن يكون كذلك، سيكون رائعًا لأنه سيجعل الحياة أسهل بنفس الطريقة. بمجرد أن نعمل مع التعليمات البرمجية، وليس مع البرامج النصية bash، ولكن لدينا كود عادي.
توقف، توقف، نص bash هو أيضًا رمز. لا تلمس حبي القديم.
حسنًا، لن أدوس على ذكرياتك. لدي كراهية شخصية لباش. إنه يكسر قبيحًا ومخيفًا طوال الوقت. وغالبًا ما ينكسر بشكل غير متوقع، ولهذا السبب لا أحبه. لكن حسنًا، لنفترض أن لديك رمز bash. ربما لا أفهم حقًا وهناك أطر اختبار عادية. أنا لست على علم. ونحصل على نفس الفوائد.
بمجرد أن نعمل مع البنية التحتية كتعليمات برمجية، فإننا نواجه نفس المشكلات التي يواجهها المطورون. قبل بضعة أشهر، واجهت موقفًا حيث أرسل لي أحد الزملاء طلب سحب لـ 1 سطر في باش. وأنت تتسكع في المراجعة لمدة 000 ساعات. تنشأ نفس المشاكل. لا يزال رمزًا. وما زال التعاون. نحن نتعثر في طلب السحب ونتعثر في حقيقة أننا نحل نفس تعارضات الدمج في نفس bash، على سبيل المثال.
أنا الآن أبحث بنشاط كبير في هذا الأمر برمته من خلال أجمل برمجة الأشعة تحت الحمراء. لقد قمت الآن بإحضار Pulumi إلى البنية التحتية. هذه هي البرمجة في أنقى صورها. هناك الأمر أجمل، لأن لدي كل إمكانيات لغة البرمجة، أي لقد قمت بالتبديل بشكل جميل من اللون الأزرق باستخدام نفس ifs وكل شيء على ما يرام. أي أن التغيير الخاص بي موجود بالفعل في السيد. يمكن للجميع رؤيته بالفعل. مهندسون آخرون يعرفون ذلك. لقد أثر بالفعل على شيء ما هناك. ومع ذلك، لم يتم تمكينه لجميع البنى التحتية. تم تشغيله لمقاعد الاختبار الخاصة بي، على سبيل المثال. لذلك، للإجابة على سؤالك مرة أخرى، فمن الضروري. إنه يجعل الحياة أسهل بالنسبة لنا، كمهندسين يعملون مع الكود، بنفس الطريقة.
إذا كان أي شخص آخر لديه أسئلة؟
عندي سؤال. أريد مواصلة المناقشة مع أوليغ. بشكل عام، أعتقد أنك على حق، إذا كانت المهمة تستغرق شهرًا لإكمالها، فهذا يعني أن لديك مشكلة في الهندسة المعمارية، ولديك مشكلة في التحليل والتحليل والتخطيط وما إلى ذلك. ولكن لدي شعور أنك إذا بدأت تحاول العيش وفق التكامل المستمر، عندها ستبدأ بتصحيح الألم بالتخطيط، لأنك لن تفلت منه في أي مكان آخر.
(أوليغ) نعم، هذا صحيح. هذه الممارسة قابلة للمقارنة من حيث الجهد مع أي ممارسة جادة أخرى لتغيير الثقافة. أصعب ما يجب التغلب عليه هو العادات، وخاصة العادات السيئة. وإذا كان تنفيذ هذه الممارسة يتطلب تغييرًا جديًا في عادات من حولك: المطورين، والإدارة، ومدير الإنتاج، فإن المفاجآت تنتظرك.
ما هي المفاجآت التي يمكن أن تكون هناك؟ لنفترض أنك قررت الاندماج في كثير من الأحيان. ولديك بعض الأشياء الأخرى المرتبطة بالتكامل، على سبيل المثال، المصنوعات اليدوية. وفي شركتك، على سبيل المثال، هناك سياسة تنص على أنه يجب مراعاة كل قطعة أثرية بطريقة ما في نظام تخزين القطع الأثرية. ويستغرق الأمر بعض الوقت. يحتاج الشخص إلى تحديد المربع الذي اختبر فيه، بصفته مدير الإصدار، هذه القطعة الأثرية للتأكد من أنها جاهزة للإصدار في الإنتاج. إذا استغرق الأمر من 5 إلى 10 إلى 15 دقيقة، لكنك تقوم بالتخطيط مرة واحدة في الأسبوع، فإن إنفاق نصف ساعة مرة واحدة في الأسبوع يمثل ضريبة بسيطة.
إذا قمت بإجراء التكامل المستمر 10 مرات في اليوم، فيجب ضرب 10 مرات في 30 دقيقة. وهذا يتجاوز مقدار وقت العمل لمدير الإصدار هذا. لقد سئم من القيام بذلك. هناك تكاليف ثابتة لبعض الممارسات. هذا كل شئ.
وتحتاج إما إلى إلغاء هذه القاعدة حتى لا تفعل مثل هذه القمامة بعد الآن، أي أنك لا تقوم بتعيين درجة يدويًا لتتوافق مع شيء ما. أنت تعتمد كليًا على مجموعة من اختبارات الاستعداد الآلية.
وإذا كنت بحاجة إلى دليل من شخص ما، حتى يوقعه رئيسك، ولا تدخل في الإنتاج دون أن يقول فاسيا إنه يسمح بذلك، وما إلى ذلك - كل هذا الهراء يعيق الممارس. لأنه إذا كانت هناك بعض الأنشطة المرتبطة بالضريبة، فكل شيء يزيد 100 مرة. ولذلك، فإن التحول في كثير من الأحيان لن يتم الترحيب به بفرح من قبل الجميع. لأن عادات الناس يصعب تغييرها.
عندما يقوم الإنسان بعمله المعتاد فإنه يقوم به تقريباً دون تفكير. حملها المعرفي صفر. إنه يتلاعب بالأمر فحسب، ولديه بالفعل قائمة مرجعية في رأسه، وقد فعل ذلك ألف مرة. وبمجرد أن تأتي وتقول له: "دعونا نلغي هذه الممارسة ونقدم ممارسة جديدة ابتداءً من يوم الاثنين،" يصبح الأمر بمثابة حمل معرفي قوي بالنسبة له. ويأتي للجميع في وقت واحد.
لذلك، أبسط شيء، على الرغم من أنه لا يستطيع الجميع تحمل هذه الرفاهية، ولكن هذا ما أفعله دائمًا، وهذا هو ما يلي. إذا بدأ مشروع جديد، فعادةً ما يتم حشر جميع الممارسات غير المختبرة على الفور في هذا المشروع. على الرغم من أن المشروع لا يزال صغيرًا، إلا أننا لا نخاطر حقًا بأي شيء. لا يوجد منتج بعد، ولا يوجد شيء يمكن تدميره. لذلك يمكن استخدامه كتدريب. هذا النهج يعمل. ولكن ليس كل الشركات لديها الفرصة لبدء مثل هذه المشاريع في كثير من الأحيان. وعلى الرغم من أن هذا أيضًا غريب بعض الشيء، لأنه الآن هناك تحول رقمي كامل، يجب على الجميع إطلاق التجارب حتى يتمكن من مواكبة المنافسين.
هنا تتوصل إلى استنتاج مفاده أنه يجب عليك أولاً أن تفهم ما عليك القيام به. إن العالم ليس مثاليًا، كما أن المنتج ليس مثاليًا أيضًا.
نعم، هذه الأشياء مترابطة.
كما أن الشركات لا تفهم دائمًا أنها بحاجة إلى السير على هذا النحو.
هناك موقف لا يمكن فيه إجراء تغييرات على الإطلاق. هذا هو الوضع الذي يوجد فيه ضغط أكبر على الفريق. الفريق بالفعل محترق تمامًا. ليس لديها وقت فراغ لأية تجارب. يعملون على الميزات من الصباح إلى المساء. والإدارة لديها ميزات أقل وأقل. مطلوب المزيد والمزيد. في مثل هذه الحالة، لا توجد تغييرات ممكنة على الإطلاق. لا يمكن إخبار الفريق إلا أننا سنفعل غدًا نفس ما فعلناه بالأمس، نحتاج فقط إلى تقديم المزيد من الميزات. وبهذا المعنى، لا يمكن الانتقال إلى أي ممارسات. هذا هو الوضع الكلاسيكي عندما لا يكون هناك وقت لشحذ الفأس، يجب قطع الأشجار، لذلك يتم قطعها بفأس مملة. لا توجد نصائح بسيطة هنا.
(ديمتري) سأقرأ توضيحًا من الدردشة: "لكننا نحتاج إلى الكثير من تغطية الاختبار على مستويات مختلفة. ما هو الوقت المخصص للاختبارات؟ إنها مكلفة بعض الشيء وتستغرق الكثير من الوقت."
(أوليغ) هذا مفهوم خاطئ كلاسيكي. يجب أن يكون هناك ما يكفي من الاختبارات لتكون واثقًا. التكامل المستمر ليس شيئًا يتم فيه إجراء 100% من الاختبارات أولاً وعندها فقط تبدأ في تطبيق هذه الممارسة. التكامل المستمر يقلل من العبء المعرفي لديك نظرًا لحقيقة أن كل التغييرات التي تراها بعينيك واضحة جدًا بحيث تفهم ما إذا كانت ستكسر شيئًا ما أم لا، حتى بدون اختبارات. يمكنك اختبار ذلك بسرعة في رأسك لأن التغييرات صغيرة. حتى لو كان لديك فقط مختبرين يدويين، فالأمر أسهل بالنسبة لهم أيضًا. تدحرجت وقلت: "انظر، هل هناك شيء مكسور؟" فحصوا وقالوا: "لا، لم يتم كسر أي شيء". لأن المختبر يعرف أين يبحث. لديك التزام واحد مرتبط بقطعة واحدة من التعليمات البرمجية. ويتم استغلال ذلك بسلوك محدد.
هنا أنت، بالطبع، منمق.
(ديمتري) أنا لا أتفق معك هنا. هناك ممارسة - التطوير القائم على الاختبار، والذي سيوفر لك من هذا.
(أوليغ) حسنًا، لم أصل إلى هذه النقطة بعد. الوهم الأول هو أنك تحتاج إلى كتابة 100% من الاختبارات أو أنك لا تحتاج إلى إجراء التكامل المستمر على الإطلاق. هذا غير صحيح. وهاتان ممارستان متوازيتان. وهم لا يعتمدون بشكل مباشر. يجب أن تكون تغطية الاختبار الأمثل. الأمثل - هذا يعني أنك واثق بنفسك من أن جودة المعلم الذي ظل فيه سيدك بعد الالتزام تسمح لك بالضغط بثقة على زر "نشر" في أمسية جمعة مخمور. كيف يمكن تحقيق ذلك؟ من خلال المراجعة، من خلال التغطية، من خلال المراقبة الجيدة.
لا يمكن تمييز المراقبة الجيدة عن الاختبارات. إذا قمت بإجراء الاختبارات مرة واحدة على منتج ما قبل المنتج، فسيقومون بفحص جميع نصوص المستخدم الخاصة بك مرة واحدة وهذا كل شيء. وإذا قمت بتشغيلها في حلقة لا نهاية لها، فهذا هو نظام المراقبة المنتشر الخاص بك، والذي يختبر كل شيء إلى ما لا نهاية - سواء تعطل أم لا. في هذه الحالة، الفرق الوحيد هو ما إذا كان يتم ذلك مرة أو مرتين. مجموعة جيدة جدًا من الاختبارات... تعمل بلا نهاية، وهذه هي المراقبة. والمراقبة الصحيحة يجب أن تكون هكذا.
وبالتالي، كيف ستحقق هذه الحالة بالضبط عندما تستعد مساء الجمعة وتعود إلى المنزل، سؤال آخر. ربما أنت مجرد حثالة جريئة.
دعونا نعود قليلا إلى التكامل المستمر. لقد هربنا إلى ممارسة معقدة مختلفة قليلاً.
والوهم الثاني هو أن MVP، كما يقولون، يجب أن يتم إجراؤه بسرعة، لذلك ليست هناك حاجة للاختبارات هناك على الإطلاق. ليس بالتأكيد بهذه الطريقة. الحقيقة هي أنه عندما تكتب قصة مستخدم في MVP، يمكنك إما تطويرها على الكرة، أي أنك سمعت أن هناك نوعًا ما من قصة المستخدم وركضت على الفور لتشفيرها، أو يمكنك العمل باستخدام TDD. ووفقًا لـ TDD، كما تظهر الممارسة، فإن الأمر لا يستغرق وقتًا أطول، أي أن الاختبارات هي أحد الآثار الجانبية. ممارسة TDD لا تتعلق بالاختبار. على الرغم مما يسمى التطوير الموجه بالاختبار، إلا أن الأمر لا يتعلق بالاختبارات على الإطلاق. وهذا أيضًا نهج معماري. هذا أسلوب لكتابة ما هو مطلوب بالضبط وليس كتابة ما ليس هناك حاجة إليه. هذه ممارسة للتركيز على التكرار التالي لتفكيرك فيما يتعلق بإنشاء بنية التطبيق.
لذلك، ليس من السهل التخلص من هذه الأوهام. MVP والاختبارات لا تتعارض مع بعضها البعض. بل على العكس من ذلك، إذا قمت بأداء MVP باستخدام تدريب TDD، فستفعل ذلك بشكل أفضل وأسرع مما لو كنت تفعل ذلك بدون تدريب على الإطلاق، ولكن على الكرة.
هذه فكرة غير واضحة ومعقدة للغاية. عندما تسمع أنني الآن سأكتب المزيد من الاختبارات وفي نفس الوقت سأفعل شيئًا أسرع، يبدو الأمر غير مناسب على الإطلاق.
(ديمتري) كثير من الناس هنا، عندما يتصلون بـ MVP، يكون الناس كسالى جدًا بحيث لا يمكنهم كتابة شيء عادي. وهذه لا تزال أشياء مختلفة. ليست هناك حاجة لتحويل MVP إلى شيء سيئ لا يعمل.
نعم، نعم، أنت على حق.
ثم فجأة MVP في همز.
إلى الأبد.
ويبدو TDD غير معتاد جدًا عندما تسمع أنك تكتب اختبارات ويبدو أنك تقوم بالمزيد من العمل. قد يبدو الأمر غريبًا جدًا، لكنه في الواقع يصبح أسرع وأجمل بهذه الطريقة. عندما تكتب اختبارًا، فإنك تفكر كثيرًا بالفعل في الكود الذي سيتم استدعاؤه وكيف، وكذلك السلوك الذي نتوقعه منه. أنت لا تقول فقط أنني كتبت بعض الوظائف وهي تفعل شيئًا ما. في البداية ظننت أن لديها كذا وكذا، فستُدعى بكذا وكذا. يمكنك تغطية هذا بالاختبارات ومن هنا تفهم كيف ستبدو واجهاتك داخل التعليمات البرمجية الخاصة بك. وهذا له تأثير كبير على الهندسة المعمارية. يصبح الكود الخاص بك تلقائيًا أكثر نمطية، لأنك تحاول أولاً فهم كيفية اختباره، وبعد ذلك فقط تكتبه.
ما حدث لي مع TDD هو أنني في مرحلة ما قمت بتعيين مرشد روبي عندما كنت لا أزال مبرمجًا لروبي. ويقول: "دعونا نفعل ذلك وفقًا لـ TDD." فكرت: "اللعنة، الآن يجب أن أكتب شيئًا إضافيًا". واتفقنا على أنه في غضون أسبوعين سأكتب جميع أكواد العمل في بايثون باستخدام TDD. وبعد أسبوعين، أدركت أنني لا أريد العودة. وبعد أسبوعين من محاولة تطبيق ذلك في كل مكان، تدرك مدى سهولة مجرد التفكير بالنسبة لك. لكن هذا ليس واضحًا، لذا أوصي الجميع أنه إذا كان لديك شعور بأن TDD صعب ويستغرق وقتًا طويلاً وغير ضروري، فحاول الالتزام به لمدة أسبوعين فقط. اثنان كانا كافيين بالنسبة لي.
(ديمتري) يمكننا توسيع هذه الفكرة من وجهة نظر تشغيل البنية التحتية. قبل أن نطلق أي شيء جديد، نقوم بالمراقبة ثم الإطلاق. في هذه الحالة، يصبح الرصد اختبارًا عاديًا بالنسبة لنا. وهناك تنمية من خلال المراقبة. لكن الجميع تقريبًا يقولون إن الأمر طويل، وأنا كسول، وقمت بعمل مسودة مؤقتة. إذا قمنا بالمراقبة العادية، فإننا نفهم حالة نظام CI. ونظام CI لديه الكثير من المراقبة. نحن نفهم حالة النظام، ونفهم ما بداخله. وأثناء التطوير، نقوم فقط بصنع النظام حتى يصل إلى الحالة المطلوبة.
هذه الممارسات معروفة منذ زمن طويل. لقد ناقشنا هذا منذ حوالي 4 سنوات. ولكن في 4 سنوات عمليا لم يتغير شيء.
ولكن في هذا الصدد، أقترح إنهاء المناقشة الرسمية.
الفيديو (تم إدراجه كعنصر وسائط، لكنه لا يعمل لسبب ما):
المصدر: www.habr.com
