سيتحدث التقرير عن بعض ممارسات DevOps، ولكن من وجهة نظر المطور. عادةً، يتمتع جميع المهندسين الذين ينضمون إلى DevOps بالفعل بسنوات عديدة من الخبرة الإدارية. لكن هذا لا يعني أنه لا يوجد مكان للمطور هنا. في أغلب الأحيان، ينشغل المطورون بإصلاح "الخطأ التالي الحاسم في اليوم"، وليس لديهم الوقت حتى لإلقاء نظرة سريعة على مجال DevOps. في فهم المؤلف، DevOps هو، أولا، الحس السليم. ثانياً، إنها فرصة لتكون أكثر فعالية. إذا كنت مطورًا ولديك الحس السليم وتريد أن تكون أكثر فعالية كلاعب فريق، فهذا التقرير مناسب لك.
اسمحوا لي أن أقدم نفسي، أعترف تمامًا أن هناك أشخاصًا في الغرفة لا يعرفونني. اسمي أنطون بويكو، وأنا أفضل لاعب في Microsoft Azure. ما هو أفضل لاعب؟ هذا هو مقدم عرض النموذج. Model-View-Presenter هو أنا بالضبط.
بالإضافة إلى ذلك، أشغل حاليًا منصب مهندس الحلول في Ciklum. ومؤخرًا اشتريت لنفسي نطاقًا رائعًا، وقمت بتحديث بريدي الإلكتروني، والذي أعرضه عادةً في العروض التقديمية. يمكنك الكتابة لي على: me [dog] byokoant.pro. يمكنك مراسلتي عبر البريد الإلكتروني مع الأسئلة. أنا عادة أجيبهم. الشيء الوحيد هو أنني لا أرغب في تلقي أسئلة عبر البريد الإلكتروني تتعلق بموضوعين: السياسة والدين. يمكنك الكتابة لي عن كل شيء آخر عن طريق البريد الإلكتروني. سوف يمر بعض الوقت، وسوف أجيب.
بضع كلمات عن نفسي:
- لقد كنت في هذا المجال لمدة 10 سنوات حتى الآن.
- عملت في مايكروسوفت.
- أنا الأب المؤسس لمجتمع Azure الأوكراني، الذي أسسناه في مكان ما في عام 2014. وما زال لدينا ونعمل على تطويره.
- وأنا أيضًا والد مؤسس مؤتمر Azure الذي نستضيفه في أوكرانيا.
- أساعد أيضًا في تنظيم Global Azure Bootcamp في كييف.
- كما قلت، أنا Microsoft Azure MVP.
- أنا أتحدث في المؤتمرات في كثير من الأحيان. أنا حقا أحب التحدث في المؤتمرات. خلال العام الماضي تمكنت من الأداء حوالي 40 مرة. إذا مررت بأوكرانيا أو بيلاروسيا أو بولندا أو بلغاريا أو السويد أو الدنمارك أو هولندا أو إسبانيا أو أعطت أو أخذت دولة أخرى في أوروبا، فمن المحتمل جدًا أنه عندما تذهب إلى مؤتمر يحتوي على موضوع سحابي في تدفقه، قد تراني على قائمة المتحدثين.
- أنا أيضًا من محبي ستار تريك.
دعونا نتحدث قليلا عن جدول الأعمال. جدول أعمالنا بسيط للغاية:
- سنتحدث عن ماهية DevOps. دعونا نتحدث لماذا هذا مهم. في السابق، كانت DevOps هي الكلمة الرئيسية التي كتبتها في سيرتك الذاتية وحصلت على الفور على راتب قدره +500 دولار. أنت الآن بحاجة إلى كتابة blockchain في سيرتك الذاتية، على سبيل المثال، من أجل الحصول على +500 دولار من راتبك.
- وبعد ذلك، عندما نفهم قليلاً عن ماهية هذا الأمر، سنتحدث عن ممارسات DevOps. ولكن ليس كثيرًا في سياق DevOps بشكل عام، ولكن فيما يتعلق بممارسات DevOps التي قد تكون ذات أهمية للمطورين. سأخبرك لماذا قد تكون مثيرة للاهتمام بالنسبة لك. سأخبرك لماذا يجب عليك القيام بذلك على الإطلاق وكيف يمكن أن يساعدك على تجربة ألم أقل.
صورة تقليدية يظهرها كثير من الناس. وهذا ما يحدث في العديد من المشاريع. وذلك عندما يكون لدينا أقسام التطوير والعمليات التي تدعم برامجنا. وهذه الأقسام لا تتواصل مع بعضها البعض.
ربما، إذا لم تكن قادرًا على الشعور بذلك بوضوح في أقسام DevOps والعمليات، فيمكنك إجراء تشبيه مع أقسام Dev وQA. هناك أشخاص يقومون بتطوير البرامج، وهناك أشخاص سيئون في مجال ضمان الجودة من وجهة نظر المطورين. على سبيل المثال، قمت بتسليم الكود الرائع الخاص بي إلى المستودع، وهناك بعض الأوغاد يجلسون هناك ويعيدون لي هذا الكود ويقولون إن الكود الخاص بك سيء.
كل هذا يحدث لأن الناس لا يتواصلون مع بعضهم البعض. ويقومون بإلقاء بعض الحزم، وبعض التطبيقات لبعضهم البعض من خلال جدار من سوء الفهم ويحاولون فعل شيء بها.
هذا هو بالضبط الجدار الذي صممت ثقافة DevOps لتدميره، أي. إجبار الأشخاص على التواصل مع بعضهم البعض وعلى الأقل فهم ما يفعله الأشخاص المختلفون في المشروع وسبب أهمية عملهم.
وعندما نتحدث عن DevOps، سيخبرك شخص ما أن DevOps يكون عندما يكون للمشروع تكامل مستمر؛ سيقول شخص ما أن DevOps هو إذا كان المشروع يطبق ممارسة "البنية التحتية كرمز"؛ سيقول شخص ما أن الخطوة الأولى نحو DevOps هي تفريع الميزات وإشارات الميزات.
في الأساس، كل هذا صحيح بطريقته الخاصة. لكن هذه مجرد الممارسات النهائية التي لدينا. قبل الانتقال إلى هذه الممارسات، أقترح إلقاء نظرة على هذه الشريحة، التي توضح المراحل الثلاث لتنفيذ منهجية Dev-Ops في مشروعك، في شركتك.
تحتوي هذه الشريحة أيضًا على اسم غير رسمي ثانٍ. يمكنك البحث عبر الإنترنت لمعرفة الفرسان الثلاثة في DevOps. من الممكن أن تجد هذه المقالة. لماذا 3 فرسان؟ أدناه مكتوب: الأشخاص والعمليات والمنتجات، أي. الشراكة بين القطاعين العام والخاص – بورثوس، بورثوس وبورثوس. إليكم فرسان DevOps الثلاثة. توضح هذه المقالة بمزيد من التفصيل سبب أهمية ذلك وما يستلزمه.
عند البدء في تنفيذ ثقافة DevOps، من المهم جدًا أن يتم تنفيذها بالترتيب التالي.
في البداية تحتاج إلى التحدث مع الناس. وتحتاج إلى أن تشرح للناس ما هو وكيف يمكنهم الحصول على بعض الفوائد منه.
مؤتمرنا يسمى DotNet Fest. وكما أخبرني المنظمون، قمنا بدعوة جمهور من المطورين هنا بشكل أساسي، لذلك آمل أن يشارك معظم الأشخاص في القاعة في التطوير.
سنتحدث عن الأشخاص، وسنتحدث عما يريد المطورون فعله كل يوم. ماذا يريدون أكثر؟ إنهم يريدون كتابة بعض التعليمات البرمجية الجديدة، واستخدام أطر عمل جديدة، وإنشاء ميزات جديدة. ما الذي يريده المطورون أقل؟ إصلاح الأخطاء القديمة. أتمنى أن تتفق معي. وهذا ما يريده المطورون. إنهم يريدون كتابة ميزات جديدة، ولا يريدون إصلاح الأخطاء.
يعتمد عدد الأخطاء التي ينتجها مطور معين على مدى استقامة ذراعيه ومدى نموها من كتفيه، وليس من جيوب مؤخرته. ولكن مع ذلك، عندما يكون لدينا مشروع كبير، يحدث أحيانًا أنه من المستحيل تتبع كل شيء، لذلك سيكون من الجيد بالنسبة لنا استخدام بعض الأساليب التي ستساعدنا في كتابة تعليمات برمجية أكثر استقرارًا وأعلى جودة.
ما الذي تريده جهات ضمان الجودة أكثر؟ لا أعرف إذا كانوا في القاعة. من الصعب بالنسبة لي أن أقول إنني أريد ضمان الجودة، لأنني لم أحصل عليه من قبل. ولا يوجد أي إساءة للرجال، سيقال أنني آمل ألا أفعل ذلك أبدا. ولكن ليس لأنني أعتبر عملهم بلا معنى وعديم الفائدة، ولكن لأنني لا أعتبر نفسي شخصًا يمكنه القيام بهذا العمل بكفاءة، لذلك لن أحاول حتى القيام بذلك. ولكن مما أفهمه، فإن أكثر ما لا يعجبه ضمان الجودة هو أنه سيعمل في الصباح، ويجري باستمرار نوعًا من اختبارات الانحدار، ويدوس على نفس الأخطاء التي أبلغوا عنها المطورين قبل 3 جولات سريعة ويقولون: "متى ستعمل؟ يا سيد أرتاجنان، أصلح هذا الخلل. فيجيبه السيد دارتاجنان: "نعم، نعم، نعم، لقد أصلحته بالفعل." وكيف حدث أنني أصلحت خطأً واحدًا وأنشأت 5 أخطاء على طول الطريق.
يريد الأشخاص الذين يدعمون هذا الحل في الإنتاج أن يعمل هذا الحل بدون أخطاء، بحيث لا يضطرون إلى إعادة تشغيل الخادم كل يوم جمعة، عندما يذهب جميع الأشخاص العاديين إلى الحانة. تم نشر المطورين يوم الجمعة، ويجلس المسؤولون حتى يوم السبت لمحاولة رفع هذا النشر وإصلاحه.
وعندما تشرح للناس أنهم يهدفون إلى حل نفس المهام، يمكنك الانتقال إلى إضفاء الطابع الرسمي على العمليات. انها مهمة جدا. لماذا؟ لأنه عندما نقول "إضفاء الطابع الرسمي"، من المهم بالنسبة لك أن تصف كيف تحدث عملياتك على الأقل في مكان ما على منديل. عليك أن تفهم أنه إذا قمت، على سبيل المثال، بالنشر في بيئة ضمان الجودة أو بيئة إنتاج، فإن ذلك يحدث دائمًا بهذا الترتيب؛ في هذه المراحل نقوم، على سبيل المثال، بإجراء اختبارات الوحدة التلقائية واختبارات واجهة المستخدم. بعد النشر، نتحقق مما إذا كان النشر قد تم بشكل جيد أم سيئ. ولكن لديك بالفعل قائمة واضحة بالإجراءات التي يجب تكرارها مرارًا وتكرارًا عند النشر في الإنتاج.
وفقط عندما يتم إضفاء الطابع الرسمي على عملياتك، تبدأ في تحديد المنتجات التي ستساعدك على أتمتة هذه العمليات.
ولسوء الحظ، كثيرا ما أرى أن هذا يحدث في الاتجاه المعاكس. بمجرد أن يسمع شخص ما كلمة "DevOps"، يقترح على الفور تثبيت Jenkins، لأنهم يعتقدون أنه بمجرد تثبيت Jenkins، سيكون لديهم DevOps. لقد قاموا بتثبيت جينكينز، وقرأوا مقالات "الكيفية" على موقع جينكينز الإلكتروني، وحاولوا حشو العمليات في هذه المقالات "الكيفية"، ثم جاءوا إلى الناس وأقنعوا الناس قائلين إن الكتاب يقول إن عليك القيام بذلك بهذه الطريقة، لذلك نحن نفعل ذلك بهذه الطريقة.
لا يعني ذلك أن جينكينز أداة سيئة. لا أقصد أن أقول ذلك بأي شكل من الأشكال. ولكن هذا مجرد واحد من المنتجات. ويجب أن يكون المنتج الذي تستخدمه هو قرارك الأخير، وليس القرار الأول بأي حال من الأحوال. لا ينبغي أن يكون منتجك مدفوعًا بتنفيذ الثقافة والأساليب. من المهم جدًا فهم هذا، ولهذا السبب أقضي الكثير من الوقت في هذه الشريحة وأشرح كل هذا لفترة طويلة.
دعونا نتحدث عن ممارسات DevOps بشكل عام. ما هم؟ ماهو الفرق؟ كيفية تجربتها؟ لماذا هم مهمون؟
الممارسة الأولى التي ربما سمعت عنها تسمى التكامل المستمر. ربما يكون أحد الأشخاص في المشروع لديه تكامل مستمر (CI).
المشكلة الأكبر هي أنه في أغلب الأحيان عندما أسأل شخصًا ما: "هل لديك CI في المشروع؟" فيقول: "نعم"، وعندما أسأله عما يفعل، يصف لي تمامًا عملية الأتمتة بأكملها. هذا ليس صحيحا تماما.
في الواقع، تهدف ممارسة CI فقط إلى دمج التعليمات البرمجية التي يكتبها أشخاص مختلفون في نوع من قاعدة التعليمات البرمجية الفردية. هذا كل شئ.
إلى جانب CI، عادة ما تكون هناك ممارسات أخرى على طول الطريق - مثل النشر المستمر، وإدارة الإصدار، ولكننا سنتحدث عن ذلك لاحقًا.
يخبرنا CI نفسه أن الأشخاص المختلفين يكتبون التعليمات البرمجية ويجب دمج هذا الرمز بشكل مستمر في قاعدة تعليمات برمجية واحدة.
ماذا يعطينا هذا ولماذا هو مهم؟ إذا كان لدينا DotNet، فهذا أمر جيد، إنها لغة مجمعة، يمكننا تجميع تطبيقنا. إذا تم تجميعه، فهذه بالفعل علامة جيدة. هذا لا يعني شيئًا بعد، لكنه أول علامة جيدة يمكننا تجميعها على الأقل.
وبعد ذلك يمكننا إجراء بعض الاختبارات، وهي ممارسة منفصلة أيضًا. الاختبارات كلها باللون الأخضر – وهذه هي العلامة الجيدة الثانية. ولكن مرة أخرى، هذا لا يعني أي شيء.
ولكن لماذا تفعل هذا؟ جميع الممارسات التي سأتحدث عنها اليوم تحمل نفس القيمة تقريبًا، أي نفس الفوائد تقريبًا ويتم قياسها أيضًا بنفس الطريقة تقريبًا.
أولاً، يسمح لك بتسريع عملية التسليم. كيف يسمح لك هذا بتسريع عملية التسليم؟ عندما نجري بعض التغييرات الجديدة على قاعدة التعليمات البرمجية الخاصة بنا، يمكننا على الفور محاولة القيام بشيء ما باستخدام هذا الرمز. نحن لا ننتظر حتى يأتي يوم الخميس لأننا سنصدره يوم الخميس إلى QA Environment، ونقوم بذلك هنا وهنا.
سأحكي لك قصة حزينة من حياتي. لقد مر وقت طويل، عندما كنت لا أزال شابًا ووسيمًا. الآن أنا بالفعل شابة وجميلة وذكية ومتواضعة. منذ بعض الوقت كنت في المشروع. كان لدينا فريق كبير يضم حوالي 30 مطورًا. وكان لدينا مشروع كبير جدًا تم تطويره لمدة 10 سنوات تقريبًا. وكان لدينا فروع مختلفة. في المستودع كان لدينا فرع يسير فيه المطورون. وكان هناك فرع يعرض إصدار الكود الموجود في الإنتاج.
كان فرع الإنتاج متأخرًا بثلاثة أشهر عن الفرع الذي كان متاحًا للمطورين. ماذا يعني هذا؟ هذا يعني أنه بمجرد أن يكون لدي خطأ في مكان ما يذهب إلى الإنتاج بسبب خطأ المطورين، لأنهم سمحوا بذلك، وبسبب خطأ ضمان الجودة، لأنهم نظروا إليه، فهذا يعني أنه إذا تلقيت مهمة الإصلاح العاجل للإنتاج، ثم لا بد لي من التراجع عن تغييرات التعليمات البرمجية الخاصة بي منذ 3 أشهر. يجب أن أتذكر ما كان لدي منذ 3 أشهر وأحاول إصلاحه هناك.
إذا لم تكن لديك هذه التجربة بعد، يمكنك تجربتها في مشروعك المنزلي. الشيء الرئيسي هو عدم تجربته على منتج تجاري. اكتب بضعة أسطر من التعليمات البرمجية، وانساها لمدة ستة أشهر، ثم عد وحاول أن تشرح بسرعة موضوع هذه الأسطر من التعليمات البرمجية وكيف يمكنك إصلاحها أو تحسينها. إنها تجربة مثيرة للغاية.
إذا كانت لدينا ممارسة التكامل المستمر، فهذا يسمح لنا بالتحقق من ذلك باستخدام عدد من الأدوات الآلية هنا والآن، بمجرد أن أكتب الكود الخاص بي. قد لا يعطيني هذا الصورة الكاملة، لكنه مع ذلك سيزيل بعض المخاطر على الأقل. وإذا كان هناك أي خطأ محتمل، فسوف أعرف عنه الآن، أي حرفيًا في بضع دقائق. لن أحتاج إلى التراجع لمدة 3 أشهر. سأحتاج فقط إلى التراجع لمدة دقيقتين. لن يكون لدى ماكينة القهوة الجيدة الوقت الكافي لتحضير القهوة في دقيقتين، لذا فهذا رائع جدًا.
وهذا له قيمة أنه يمكن تكراره مرة بعد مرة في كل مشروع، أي. وليس فقط الشخص الذي قمت بإعداده عليه. يمكنك تكرار الممارسة نفسها وسيتم تكرار CI نفسه لكل تغيير جديد تقوم به على المشروع. يتيح لك هذا تحسين الموارد لأن فريقك يعمل بكفاءة أكبر. لن تواجه بعد الآن موقفًا يأتي فيه خطأ إليك من الكود الذي عملت معه منذ 3 أشهر. لن يكون لديك تبديل السياق بعد الآن عندما تجلس وتقضي أول ساعتين في محاولة فهم ما حدث بعد ذلك والدخول في جوهر السياق قبل البدء في تصحيح شيء ما.
كيف يمكننا قياس مدى نجاح أو فشل هذه الممارسة؟ إذا أبلغت الرئيس الكبير بما قمنا بتنفيذه في مشروع CI، فسيسمع بلاه بلاه بلاه. لقد قمنا بتنفيذه، حسنًا، ولكن لماذا، وماذا جلب لنا، وكيف نقيسه، وما مدى صحة تنفيذه أو خطأه؟
الأول هو أنه بفضل CI، يمكننا النشر أكثر فأكثر، وفي كثير من الأحيان على وجه التحديد لأن الكود الخاص بنا من المحتمل أن يكون أكثر استقرارًا. بنفس الطريقة، يتم تقليل الوقت الذي نقضيه في العثور على خطأ، ويتم تقليل الوقت اللازم لتصحيح هذا الخطأ على وجه التحديد لأننا نتلقى إجابة من النظام هنا والآن، ما هو الخطأ في الكود الخاص بنا.
ممارسة أخرى لدينا هي ممارسة اختبار الأتمتة، والتي غالبًا ما تأتي مع ممارسة CI. يسيرون جنبا إلى جنب.
ما هو المهم أن نفهم هنا؟ من المهم أن نفهم أن اختباراتنا مختلفة. ويهدف كل اختبار آلي إلى حل مشاكله الخاصة. لدينا، على سبيل المثال، اختبارات الوحدة التي تسمح لنا باختبار الوحدة بشكل منفصل، أي. كيف يعمل في الفراغ؟ هذا جيد.
لدينا أيضًا اختبارات تكامل تتيح لنا فهم كيفية تكامل الوحدات المختلفة مع بعضها البعض. إنها جيدة أيضًا.
قد تكون لدينا اختبارات أتمتة لواجهة المستخدم تسمح لنا بالتحقق من مدى تلبية العمل مع واجهة المستخدم لمتطلبات معينة حددها العميل، وما إلى ذلك.
يمكن أن تؤثر الاختبارات المحددة التي تجريها على عدد مرات إجرائها. عادة ما تكون اختبارات الوحدة مكتوبة بشكل قصير وصغير. ويمكن إطلاقها بانتظام.
إذا كنا نتحدث عن اختبارات أتمتة واجهة المستخدم، فمن الجيد أن يكون مشروعك صغيرًا. يمكن أن تستغرق اختبارات أتمتة واجهة المستخدم الخاصة بك بعض الوقت المناسب. ولكن عادةً ما يستغرق اختبار أتمتة واجهة المستخدم عدة ساعات في مشروع كبير. ومن الجيد أن تكون بضع ساعات. الشيء الوحيد هو أنه لا فائدة من تشغيلها لكل بناء. فمن المنطقي تشغيلها في الليل. وعندما جاء الجميع إلى العمل في الصباح: كل من المختبرين والمطورين، تلقوا نوعًا من التقارير بأننا أجرينا الاختبار التلقائي لواجهة المستخدم ليلاً وحصلنا على هذه النتائج. وهنا، فإن ساعة عمل الخادم الذي سيتحقق من أن منتجك يلبي بعض المتطلبات ستكون أرخص بكثير من ساعة عمل نفس مهندس ضمان الجودة، حتى لو كان مهندس ضمان الجودة مبتدئًا يعمل من أجل الطعام والشكر. ومع ذلك، فإن ساعة تشغيل الآلة ستكون أرخص. ولهذا السبب فمن المنطقي الاستثمار فيه.
لدي مشروع آخر كنت أعمل عليه. كان لدينا سباقات السرعة لمدة أسبوعين في هذا المشروع. كان المشروع كبيراً ومهماً للقطاع المالي، ولا يمكن ارتكاب أي خطأ. وبعد سباق سريع لمدة أسبوعين، أعقبت دورة التطوير عملية اختبار استغرقت 4 أسابيع أخرى. حاول أن تتخيل حجم المأساة. نكتب التعليمات البرمجية لمدة أسبوعين، ثم نقوم بذلك على غرار CodeFreeze، ونجمعها في إصدار جديد من التطبيق ونطرحها على المختبرين. يقوم المختبرون باختباره لمدة 4 أسابيع أخرى، أي. وبينما يقومون باختباره، لدينا الوقت لإعداد نسختين إضافيتين لهم. هذه حالة حزينة حقا.
وأخبرناهم أنه إذا كنت تريد أن تكون أكثر إنتاجية، فمن المنطقي أن تنفذ ممارسات الاختبار الآلي، لأن هذا هو ما يؤذيك هنا، الآن.
ممارسة النشر المستمر. عظيم، لقد انتهيت من البناء. هذا جيد بالفعل. لقد تم تجميع التعليمات البرمجية الخاصة بك. الآن سيكون من الجيد نشر هذا البناء على بعض البيئات. دعنا نقول في بيئة للمطورين.
لماذا هو مهم؟ أولاً، يمكنك معرفة مدى نجاحك في عملية النشر نفسها. لقد التقيت بمشاريع مثل هذه، عندما سألت: "كيف يمكنك نشر إصدار جديد من التطبيق؟"، أخبرني الرجال: "نحن نجمعه ونحزمه في أرشيف مضغوط. نرسلها إلى المسؤول عن طريق البريد. يقوم المسؤول بتنزيل هذا الأرشيف وتوسيعه. ويبدأ المكتب بأكمله بالصلاة من أجل أن يلتقط الخادم الإصدار الجديد.
لنبدأ بشيء بسيط. على سبيل المثال، نسوا وضع CSS في الأرشيف أو نسوا تغيير علامة التصنيف في اسم ملف Java-Script. وعندما نتقدم بطلب إلى الخادم، يعتقد المتصفح أن لديه بالفعل ملف جافا سكريبت هذا ويقرر عدم تنزيله. وكان هناك نسخة قديمة، وكان هناك شيء مفقود. بشكل عام، يمكن أن يكون هناك العديد من المشاكل. ولذلك، فإن ممارسة النشر المستمر تسمح لك على الأقل باختبار ما يمكن أن يحدث إذا أخذت صورة مرجعية نظيفة وقمت بتحميلها إلى بيئة جديدة نظيفة تمامًا. يمكنك أن ترى إلى أين يؤدي هذا.
أيضًا، عند دمج التعليمات البرمجية بين بعضها البعض، على سبيل المثال. بين الأمر، يتيح لك هذا أيضًا رؤية كيف يبدو على واجهة المستخدم.
إحدى المشكلات التي تحدث عند استخدام الكثير من برامج Java-Script الفانيليا هي أن اثنين من المطورين أعلنا بشكل متهور عن متغير يحمل نفس الاسم في كائن النافذة. وبعد ذلك، اعتمادا على حظك. من يتم سحب ملف جافا سكريبت الثاني سوف يحل محل تغييرات الآخر. إنها أيضًا مثيرة جدًا. تدخل: شيء واحد يصلح لشخص ما، وآخر لا يصلح لشخص آخر. ومن "الرائع" أن يتم إنتاج كل ذلك.
الممارسة التالية التي لدينا هي ممارسة الاستعادة التلقائية، أي العودة إلى الإصدار السابق من التطبيق.
لماذا يعد هذا مهمًا للمطورين؟ لا يزال هناك من يتذكر التسعينيات البعيدة، عندما كانت أجهزة الكمبيوتر كبيرة والبرامج صغيرة. والطريقة الوحيدة لتطوير الويب كانت من خلال لغة PHP. لا يعني ذلك أن PHP لغة سيئة، على الرغم من أنها كذلك.
لكن المشكلة كانت مختلفة. عندما قمنا بنشر نسخة جديدة من موقع php الخاص بنا، كيف قمنا بنشرها؟ في أغلب الأحيان قمنا بفتح Far Manager أو أي شيء آخر. وقمت بتحميل هذه الملفات إلى FTP. وأدركنا فجأة أن لدينا بعض الأخطاء الصغيرة، على سبيل المثال، نسينا وضع فاصلة منقوطة أو نسينا تغيير كلمة المرور لقاعدة البيانات، وهناك كلمة مرور لقاعدة البيانات الموجودة على المضيف المحلي. وقررنا الاتصال بسرعة بـ FTP وتحرير الملفات هناك. هذه مجرد نار! وهذا ما كان شائعاً في التسعينات.
ولكن، إذا لم تنظر إلى التقويم، فستجد أن التسعينات كانت قبل 90 عامًا تقريبًا. الآن كل شيء يحدث بشكل مختلف قليلاً. وحاول أن تتخيل حجم المأساة عندما يقولون لك: "لقد انتشرنا في الإنتاج، ولكن حدث خطأ ما هناك. إليك معلومات تسجيل الدخول وكلمة المرور الخاصة بـ FTP، اتصل بالإنتاج وقم بإصلاح المشكلة بسرعة هناك." إذا كنت تشاك نوريس، فهذا سوف ينجح. إذا لم يكن الأمر كذلك، فأنت تخاطر بأنه إذا قمت بإصلاح خطأ واحد، فسوف تقوم بإنشاء 30 أخطاء أخرى، وهذا هو بالضبط السبب في أن ممارسة العودة إلى الإصدار السابق تسمح لك بتحقيق الكثير.
حتى لو حدث شيء سيء بطريقة أو بأخرى في مكان ما، فهو سيء، ولكنه ليس قاتلاً. يمكنك العودة إلى الإصدار السابق الذي لديك. أطلق عليها نسخة احتياطية، إذا كان من الأسهل إدراكها بهذه المصطلحات. يمكنك العودة إلى هذا الإصدار السابق، وسيظل المستخدمون قادرين على العمل مع منتجك، وسيكون لديك وقت تخزين مؤقت كافٍ. يمكنك بهدوء، ودون تسرع، أخذ كل هذا واختباره محليًا، وإصلاحه، ثم تحميل نسخة جديدة. من المنطقي حقًا القيام بذلك.
الآن دعونا نحاول بطريقة أو بأخرى الجمع بين الممارستين السابقتين معًا. سوف نحصل على واحد ثالث يسمى إدارة الإصدار.
عندما نتحدث عن النشر المستمر في شكله الكلاسيكي، نقول أنه يجب علينا سحب التعليمات البرمجية من فرع ما من المستودع، وتجميعها ونشرها. من الجيد أن يكون لدينا نفس البيئة. إذا كان لدينا عدة بيئات، فهذا يعني أنه يتعين علينا سحب الكود في كل مرة، حتى من نفس الالتزام. سنخرجه في كل مرة، وسنبنيه في كل مرة، وسننشره في بيئة جديدة. أولاً، هذا هو الوقت المناسب، لأنه لبناء مشروع، إذا كان لديك مشروع كبير وجاءت من التسعينيات، فقد يستغرق الأمر عدة ساعات.
علاوة على ذلك، هناك حزن آخر. عند البناء، حتى على نفس الجهاز، ستبني نفس المصادر، ولا يزال ليس لديك ضمان بأن هذا الجهاز في نفس الحالة التي كانت عليها أثناء البناء الأخير.
لنفترض أن شخصًا ما قد جاء وقام بتحديث DotNet لك، أو على العكس من ذلك، قرر شخص ما حذف شيء ما. ثم لديك تنافر معرفي من هذا الالتزام منذ أسبوعين كنا نبني بناء وكان كل شيء على ما يرام، ولكن الآن يبدو أنه نفس الجهاز، نفس الالتزام، نفس الكود الذي نحاول بناءه، لكنه لا يعمل . سوف تتعامل مع هذا لفترة طويلة وليس حقيقة أنك ستكتشف ذلك. على أقل تقدير، سوف تفسد أعصابك كثيرا.
لذلك، تقترح ممارسة إدارة الإصدار تقديم تجريد إضافي يسمى مستودع القطع الأثرية أو المعرض أو المكتبة. يمكنك أن نسميها ما تريد.
الفكرة الرئيسية هي أنه بمجرد أن يكون لدينا نوع من الالتزام هناك، على سبيل المثال، في فرع نكون مستعدين للنشر في بيئاتنا المختلفة، فإننا نجمع التطبيقات من هذا الالتزام وكل ما نحتاجه لهذا التطبيق، ونحزمه في أرشيف مضغوط واحفظه في وحدة تخزين موثوقة. ومن هذا التخزين يمكننا الحصول على هذا الأرشيف المضغوط في أي وقت.
ثم نأخذها وننشرها تلقائيًا في بيئة التطوير. نحن نتسابق هناك، وإذا كان كل شيء على ما يرام، فإننا ننتشر على المسرح. إذا كان كل شيء على ما يرام، فإننا ننشر نفس الأرشيف للإنتاج، نفس الثنائيات، التي تم تجميعها مرة واحدة بالضبط.
بالإضافة إلى ذلك، عندما يكون لدينا معرض مثل هذا، فإنه يساعدنا أيضًا على معالجة المخاطر التي تناولناها في الشريحة الأخيرة عندما تحدثنا عن العودة إلى الإصدار السابق. إذا قمت بنشر شيء خاطئ عن طريق الخطأ، فيمكنك دائمًا أخذ أي إصدار سابق آخر من هذا المعرض وإلغاء نشره في هذه البيئات بنفس الطريقة. يتيح لك هذا الرجوع بسهولة إلى الإصدار السابق في حالة حدوث خطأ ما.
هناك ممارسة عظيمة أخرى. ندرك أنا وأنت جميعًا أنه عندما نعيد تطبيقاتنا إلى إصدار سابق، فإن هذا قد يعني أننا نحتاج أيضًا إلى البنية الأساسية للإصدار السابق.
عندما نتحدث عن البنية التحتية الافتراضية، يعتقد الكثير من الناس أن هذا شيء أنشأه المسؤولون. وإذا كنت بحاجة، على سبيل المثال، إلى الحصول على خادم جديد تريد اختبار إصدار جديد من تطبيقك عليه، فيجب عليك كتابة تذكرة إلى المسؤولين أو المطورين. سوف يستغرق Devops 3 أسابيع لهذا الغرض. وبعد 3 أسابيع سيخبرونك أننا قمنا بتثبيت جهاز افتراضي لك بنواة واحدة وذاكرة وصول عشوائي (RAM) بسعة 3 غيغابايت وخادم Windows بدون DotNet. قد تقول: "لكنني أردت DotNet". قالوا: "حسنًا، عد بعد XNUMX أسابيع."
الفكرة هي أنه باستخدام البنية التحتية كممارسات للتعليمات البرمجية، يمكنك التعامل مع البنية التحتية الافتراضية الخاصة بك كمجرد مورد آخر.
ربما، إذا كان أي منكم يقوم بتطوير تطبيقات على DotNet، فربما سمعت عن مكتبة تسمى Entity Framework. وربما سمعت أن Entity Framework هو أحد الأساليب التي تدفعها Microsoft بنشاط. للعمل مع قاعدة بيانات، هذا هو النهج الذي يسمى Code First. هذا عندما تصف في الكود كيف تريد أن تبدو قاعدة البيانات الخاصة بك. ومن ثم تقوم بنشر التطبيق. إنه يتصل بقاعدة البيانات، ويحدد بنفسه الجداول الموجودة والجداول غير الموجودة، ويقوم بإنشاء كل ما تحتاجه.
يمكنك أن تفعل الشيء نفسه مع البنية التحتية الخاصة بك. لا يوجد فرق بين ما إذا كنت بحاجة إلى قاعدة بيانات لمشروع ما أو ما إذا كنت بحاجة إلى خادم Windows لمشروع ما. إنه مجرد مورد. ويمكنك أتمتة إنشاء هذا المورد، ويمكنك أتمتة تكوين هذا المورد. وفقًا لذلك، في كل مرة تريد فيها اختبار مفهوم جديد، أو نهج جديد، لن تحتاج إلى كتابة تذكرة إلى المطورين، يمكنك ببساطة نشر بنية تحتية معزولة لنفسك من قوالب جاهزة، ومن نصوص برمجية جاهزة وتنفيذها هناك كل ما تبذلونه من التجارب. يمكنك حذف هذا والحصول على بعض النتائج والإبلاغ عن المزيد حول هذا الموضوع.
الممارسة التالية، الموجودة أيضًا والمهمة أيضًا، ولكن يستخدمها عدد قليل من الأشخاص، هي مراقبة أداء التطبيق.
أردت أن أقول شيئًا واحدًا فقط عن مراقبة أداء التطبيق. ما هو الأهم في هذه الممارسة؟ هذا هو ما تعنيه مراقبة أداء التطبيق تقريبًا مثل إصلاح الشقة. هذه ليست الحالة النهائية، بل هي عملية. عليك أن تفعل ذلك بانتظام.
بطريقة جيدة، سيكون من الجيد إجراء مراقبة أداء التطبيق على كل إصدار تقريبًا، على الرغم من أنه كما تفهم، فإن هذا ليس ممكنًا دائمًا. ولكن، على الأقل، يجب تنفيذ ذلك لكل إصدار.
لماذا هو مهم؟ لأنه إذا واجهت فجأة انخفاضًا في الأداء، فأنت بحاجة إلى فهم السبب بوضوح. إذا كان لدى فريقك، على سبيل المثال، سباقات سريعة لمدة أسبوعين، فيجب عليك مرة واحدة على الأقل كل أسبوعين نشر تطبيقك على خادم منفصل، حيث يكون لديك معالج ثابت بشكل واضح، وذاكرة الوصول العشوائي، والأقراص، وما إلى ذلك. وقم بإجراء نفس اختبارات الأداء . تحصل على النتيجة. انظر كيف تغيرت عن السباق السابق.
وإذا اكتشفت أن التراجع قد انخفض بشكل حاد في مكان ما، فهذا يعني أن ذلك كان فقط بسبب التغييرات التي حدثت خلال الأسبوعين الماضيين. سيسمح لك ذلك بتحديد المشكلة وحلها بشكل أسرع. ومرة أخرى، هذه تقريبًا نفس المقاييس التي يمكنك من خلالها قياس مدى نجاحك في القيام بذلك.
الممارسة التالية لدينا هي ممارسة إدارة التكوين. هناك عدد قليل جدا من الذين يأخذون هذا على محمل الجد. لكن صدقوني، هذا في الواقع أمر خطير للغاية.
كانت هناك قصة مضحكة في الآونة الأخيرة. جاء إليّ الرجال وقالوا: "ساعدنا في إجراء تدقيق أمني لتطبيقنا". لقد نظرنا إلى الكود معًا لفترة طويلة، وأخبروني عن التطبيق، ورسموا المخططات. وكان كل شيء زائدًا أو ناقصًا منطقيًا ومفهومًا وآمنًا، ولكن كان هناك شيء واحد ولكن! كان لديهم ملفات تكوين في التحكم بالمصادر الخاصة بهم، بما في ذلك تلك الموجودة في الإنتاج باستخدام قاعدة بيانات IP، مع تسجيلات الدخول وكلمات المرور للاتصال بقواعد البيانات هذه، وما إلى ذلك.
وأنا أقول: "يا رفاق، حسنًا، لقد أغلقتم بيئة الإنتاج الخاصة بكم بجدار الحماية، ولكن حقيقة أن لديك تسجيل الدخول وكلمة المرور لقاعدة بيانات الإنتاج مباشرة في التحكم بالمصدر ويمكن لأي مطور قراءتها يمثل بالفعل خطرًا أمنيًا كبيرًا . وبغض النظر عن مدى أمان تطبيقك من وجهة نظر التعليمات البرمجية، إذا تركته تحت التحكم بالمصادر، فلن تتمكن أبدًا من اجتياز أي تدقيق في أي مكان. هذا ما أتحدث عنه.
إدارة التكوين. قد يكون لدينا تكوينات مختلفة في بيئات مختلفة. على سبيل المثال، قد يكون لدينا تسجيلات دخول وكلمات مرور مختلفة لقواعد بيانات ضمان الجودة والعرض التوضيحي وبيئة الإنتاج وما إلى ذلك.
يمكن أيضًا أتمتة هذا التكوين. يجب أن يكون دائمًا منفصلاً عن التطبيق نفسه. لماذا؟ نظرًا لأنك أنشأت التطبيق مرة واحدة، ثم لا يهتم التطبيق بما إذا كنت تتصل بخادم SQL عبر عنوان IP كذا وكذا أو عنوان IP كذا وكذا، فيجب أن يعمل بنفس الطريقة. لذلك، إذا كان أحدكم فجأة لا يزال يقوم بترميز سلسلة الاتصال في الكود، فتذكر أنني سأجدك وأعاقبك إذا وجدت نفسك في نفس المشروع معي. يتم وضع هذا دائمًا في تكوين منفصل، على سبيل المثال، في web.config.
ويتم بالفعل إدارة هذا التكوين بشكل منفصل، أي هذه هي اللحظة التي يمكن فيها للمطور والمسؤول الحضور والجلوس في نفس الغرفة. ويمكن للمطور أن يقول: "انظر، هذه هي ثنائيات تطبيقي. هم يعملون. التطبيق يحتاج إلى قاعدة بيانات للعمل. يوجد هنا ملف بجانب الثنائيات. في هذا الملف، هذا الحقل هو المسؤول عن تسجيل الدخول، وهذا عن كلمة المرور، وهذا عن IP. انشرها في أي مكان." وهي بسيطة وواضحة للمسؤول. يمكنه نشره حقًا في أي مكان من خلال إدارة هذا التكوين.
والممارسة الأخيرة التي أود أن أتحدث عنها هي ممارسة مرتبطة جدًا بالسحب. ويحقق أقصى قدر من التأثير إذا كنت تعمل في السحابة. هذه هي الإزالة التلقائية لبيئتك.
أعلم أن هناك العديد من الأشخاص في هذا المؤتمر من الفرق التي أعمل معها. ومع جميع الفرق التي أعمل معها، نستخدم هذه الممارسة.
لماذا؟ بالطبع، سيكون أمرًا رائعًا لو كان لدى كل مطور جهاز افتراضي يعمل على مدار الساعة طوال أيام الأسبوع. لكن ربما هذا خبر لك، ربما لم تنتبه، لكن المطور نفسه لا يعمل 24/7. يعمل المطور عادةً 24 ساعات يوميًا. حتى لو جاء للعمل مبكرًا، فإنه يتناول وجبة غداء كبيرة يذهب خلالها إلى صالة الألعاب الرياضية. فليكن 7 ساعة يوميًا عندما يستخدم المطور هذه الموارد فعليًا. وفقًا لتشريعاتنا، لدينا 8 أيام من أصل 12 أيام في الأسبوع تعتبر أيام عمل.
وعليه، في أيام الأسبوع، يجب ألا تعمل هذه الآلة 24 ساعة، بل 12 ساعة فقط، وفي عطلات نهاية الأسبوع يجب ألا تعمل هذه الآلة على الإطلاق. يبدو أن كل شيء بسيط للغاية، ولكن ما هو المهم أن نقول هنا؟ من خلال تنفيذ هذه الممارسة البسيطة وفقًا لهذا الجدول الأساسي، فإنها تسمح لك بتقليل تكلفة صيانة هذه البيئات بنسبة 70%، أي أنك أخذت سعر التطوير وضمان الجودة والعرض التوضيحي والبيئة وقسمته على 3.
والسؤال هو ماذا تفعل ببقية الأموال؟ على سبيل المثال، يجب على المطورين شراء ReSharper إذا لم يفعلوا ذلك بالفعل. أو لديك حفل كوكتيل. إذا كان لديك سابقًا بيئة واحدة يرعى فيها كل من المطورين وضمان الجودة، وهذا كل شيء، يمكنك الآن إنشاء 3 بيئات مختلفة سيتم عزلها، ولن يتداخل الأشخاص مع بعضهم البعض.
فيما يتعلق بشريحة قياس الأداء المستمر، كيف يمكننا مقارنة الأداء إذا كان لدينا 1 سجل في قاعدة البيانات في المشروع، وبعد شهرين هناك مليون؟ كيف نفهم لماذا وما هو الهدف من قياس الأداء؟
هذا سؤال جيد، لأنه يجب عليك دائمًا قياس الأداء على نفس الموارد. وهذا يعني أنك تقوم بطرح كود جديد، وتقيس الأداء على الكود الجديد. على سبيل المثال، تحتاج إلى اختبار سيناريوهات أداء مختلفة، لنفترض أنك تريد اختبار كيفية أداء التطبيق عند التحميل الخفيف، حيث يوجد 1 مستخدم وحجم قاعدة البيانات 000 غيغابايت. لقد قمت بقياسه وحصلت على الأرقام. بعد ذلك نأخذ سيناريو آخر. على سبيل المثال، 5 مستخدم، حجم قاعدة البيانات 5 تيرابايت. لقد تلقينا النتائج وتذكرناها.
ما هو المهم هنا؟ الشيء المهم هنا هو أنه اعتمادًا على السيناريو وحجم البيانات وعدد المستخدمين المتزامنين وما إلى ذلك، قد تصل إلى حدود معينة. على سبيل المثال، إلى حد بطاقة الشبكة، أو إلى حد القرص الصلب، أو إلى حد قدرات المعالج. وهذا هو المهم بالنسبة لك أن تفهم. في سيناريوهات مختلفة، تواجه حدودًا معينة. وتحتاج إلى فهم الأرقام عندما تضربها.
هل نتحدث عن قياس الأداء في بيئة اختبار خاصة؟ وهذا هو، هذا ليس الإنتاج؟
نعم، هذا ليس إنتاجًا، هذه بيئة اختبار، وهي نفسها دائمًا بحيث يمكنك مقارنتها بالقياسات السابقة.
فهم، وذلك بفضل!
إذا لم تكن هناك أسئلة، أعتقد أننا يمكن أن ننتهي. شكرًا لك!
المصدر: www.habr.com