أعد المقال كونستانتين بريوخانوف ، رئيس دورة "CI / CD" . في ذلك ، كشف كونستانتين عن عدد من النقاط الإشكالية المتعلقة بتسليم رمز منتج البرمجيات في شركات تكنولوجيا المعلومات ، وجمع التوصيات من بين أفضل الممارسات الدولية.
في عمليات تكنولوجيا المعلومات ، يكون الاتجاه الأكثر طلبًا هو الضبط الدقيق وتوفير التسليم والنشر المستمر. تتطور التقنيات والمنهجيات باستمرار ، ويتم تحسين الأدوات. ولذلك ، فإن أحدث متطلبات التسليم والنشر تشمل استعداد واستمرارية اختبار التغيير ، والتحضير وإعداد بيئة اختبار لفريق ضمان الجودة.
أدت الاختراقات التكنولوجية والبرمجيات الحرة إلى تغيير كبير في نهج تنظيم عمليات CI / CD. لقد أثر الانتقال إلى المبادئ الجديدة بشكل كبير على ثقافة الشركة ، ومهارات الموظفين المطلوبة ومبادئ العمل في المنظمات ، مما أدى إلى تغييرات واسعة النطاق في عالم تطوير البرمجيات.
أصبحت الحلول السحابية ذات أولوية متزايدة. يتطلب التسليم المستمر للبرامج تعاونًا فعالاً بين فرق التطوير والاختبار والعمليات ، وتعتبر السحابة رائعة لهذا التعاون.
ومع ذلك ، فإن مرحلة النشر ، التي يتم إجراؤها في هيكل موزع معقد ، عرضة للخطأ وتتطلب بشكل عام استكشاف الأخطاء وإصلاحها يدويًا. غالبًا ما تؤدي مرحلة نشر المنتج في عملية التسليم المستمر إلى اختناقات وتؤثر سلبًا على فعالية عملية DevOps.
يتيح لك التسليم المستمر تحقيق أتمتة اختبار التغييرات المتزايدة في البرامج والنشر السريع للتحديثات بأكثر الطرق كفاءة وأمانًا. يمنح هذا الأسلوب المستخدمين الثقة في أن أحدث إصدار من الكود يتم استخدامه في بيئة الإنتاج ، ويمكن أن تصل التغييرات التي أجراها المبرمجون إلى العملاء في غضون ساعات أو حتى دقائق.
لنفكر في السيناريو الأكثر شيوعًا لتنفيذ CI / CD في المشروع:
- يقوم فريق التطوير بإصدار إصدار جديد من المنتج (وظيفة جديدة أو إصلاحات للأخطاء من الإصدار السابق).
- تتحقق خدمة التكامل المستمر (CI) من صحة التعليمات البرمجية الجديدة من خلال سلسلة من الاختبارات التي تتضمن مستويات متعددة من الاختبارات ، مثل اختبارات بناء الجملة والوحدة والانحدار.
- , (CD).
- (, ) , (staging), , .
- stage- CI/CD , .
- .
هذا السيناريو هو الأكثر عمومية ويغطي معظم احتياجات فرق التطوير والعمليات ، ولكن لا يزال هناك بعض المشاكل ، على سبيل المثال:
- استبدال الملفات . غالبًا ما يكون من الضروري تحديث ملفات التكوين أو استبدالها أو إعادة إنشاء بعض المحتوى الثابت. في هذه الحالة ، قد يتلقى المستخدمون أخطاء حتى يتم تحويل حركة المرور من إصدار البرنامج القديم إلى الإصدار الجديد. في حالة فشل النشر ، هناك خطر عدم توافق الملف.
- . , , . . , - , - .
- . . , , .. . , - , , .. .
تجدر الإشارة إلى أن المشكلات المذكورة أعلاه يمكن أن تظهر حتى في بيئة شبه مثالية ، ولكن إحدى الصعوبات الرئيسية في تنفيذ منهجية DevOps هي عدم وجود صورة واحدة لما يجب أن تبدو عليه عملية التسليم المستمر ونشر المنتج. تعرف العديد من شركات تكنولوجيا المعلومات القليل جدًا عن DevOps ، وأحيانًا لا تفهم هذه المنهجية على الإطلاق ، في حين أن شركات أخرى لديها بالفعل حلول تاريخية يتعين عليها بناء عمليات جديدة على رأسها. مع الأخذ في الاعتبار المتطلبات العالية لمؤهلات اختصاصيي Devops ونقصهم في سوق العمل ، غالبًا ما يضطر صاحب العمل إلى استخدام الموارد الموجودة بالفعل تحت تصرفه وإعطاء مهام Devops للمهندسين المبتدئين. نتيجة لذلك ، هناك المزيد من نقاط الضعف في النظام.
عند استخدام CI / CD بدون فهم صحيح للمنهجية ، بدون اتباع نهج تحليلي لبناء البنية التحتية وطرق تقديم التعليمات البرمجية ، تظهر المشكلات التالية:
1. العامل البشري . يرتبط الخطر الأول والأكثر أهمية بالعوامل البشرية. دعنا نتخيل موقفًا عندما يكون من الضروري تكوين عدة خوادم أخرى مشابهة للخوادم الحالية. إذا كان الاختصاصي الذي أجرى عمليات التثبيت أو الإعدادات السابقة غير متوفر حاليًا لأي سبب (مريض ، توقف ، وما إلى ذلك) ولم يقم بإعداد تعليمات مفصلة ، يصبح الموقف أكثر تعقيدًا. في هذه الحالة ، يجب على كل متخصص جديد دراسة العملية الكاملة لإعداد الخادم بالكامل ، بينما لا يوجد لديه هامش للخطأ. وإلى جانب ذلك ، من المستحيل تقدير المدة التي سيستغرقها إعدادها وضمان نجاحها بدقة.
يتضمن هذا أيضًا المخاطر المرتبطة بحقيقة أن مؤلف الطريقة قد ارتكب خطأ ، أو نسي تغطية العمليات بالاختبارات ، أو ببساطة لم يأخذ في الاعتبار شيئًا ما ، ولم يلاحظه خليفته.
يجب أن نتذكر أيضًا أن الشركات غالبًا ما تقوم بتطوير العديد من المشاريع ، وعادةً ما يكون قسم عمليات تكنولوجيا المعلومات واحدًا ، ويخدم مهندس عمليات واحد العديد من المشاريع. إذا لم يكن هناك مخطط ومفهوم واحد ، فسيتم بناء العمليات في فرق مختلفة بطرق مختلفة ، مما سيعقد بشكل كبير التطوير اللاحق لـ Devops في الشركة وسيجعل عتبة عالية لدخول مهندس عمليات في مشروع آخر ، حيث يتم بالفعل استخدام عمليات مختلفة عن تلك التي عمل معها سابقا.
2. السيناريوهات غير العاطفة... Idempotency هي سمة مهمة للتسليم المستمر وسيناريوهات نشر الكود ، خاصة في عمليات نشر البنية التحتية. يجب أن يكون المهندس واثقًا من أنه في كل مرة يتم فيها تنفيذ البرامج النصية ، ستكون النتيجة مضمونة بشكل فريد ومتوقعة وغير متغيرة عند إعادة تشغيل نفس البرنامج النصي. في كثير من الأحيان ، عند تنفيذ Devops في شركة ما ، يحاول المهندسون تطوير حل تجاري وقد لا يأخذون في الاعتبار عدم القدرة على العمل أو ببساطة لا يعرفون عن هذا المطلب. في هذه الحالة ، تتلقى الشركة قنبلة موقوتة. هناك احتمال أن يتم تسليم رمز غير متوقع إلى منشآت الإنتاج. على سبيل المثال ، إذا قام شخص ما بتحديث وحدة CMS لمشروع واحد ، وبالتالي أثر على الآخرين ، حيث لا يكون ذلك متوقعًا.
3. تخزين البيانات الحساسة وتنظيم الوصول. واحدة من أهم النقاط في نهج Devops لتخزين البيانات السرية وتقييد الحقوق وتنظيم الوصول إلى الشبكة والمستخدم. حتى الآن ، لا توجد ممارسات وأدوات مقبولة موحدة لحل هذه المشكلة ، ويتعين على المهندسين إجراء بحث في كل مرة ، اعتمادًا على التنظيم الحالي للبنية التحتية والطرق المعتمدة لتقييد الوصول. لهذا السبب ، فإن تنفيذ منهجية Devops في مؤسسة ما معقد بسبب حقيقة أنه من المستحيل العثور بشكل قاطع على حل لحالتك الخاصة ، واستخدام ممارسات الآخرين لا يضمن دائمًا الأمان.
4. تحديد نموذج الميزانية ، أكثر ملاءمة لمنهجية الشلال.
5. متطلبات سلامة عالية.وبالتالي ، من المستحيل وضع البنية التحتية لمشاريع تكنولوجيا المعلومات الوطنية في نطاق مسؤولية الشركات التجارية والأجنبية ، مثل أمازون ومايكروسوفت.
6. كمية كبيرة من "التعليمات البرمجية القديمة" ، "البنية التحتية القديمة" التي تحتاج إلى صيانة. الحاجة إلى التكامل مع عدد كبير من الأنظمة القديمة.
وبالتالي ، يمكن أن تكون عملية بناء Devops في مؤسسة مصحوبة بعدد من المشكلات ولا تحل دائمًا المشكلات التي تم إنشاؤها من أجلها.
الخطوة الأولى المهمة هي التخلي عن العلاقة بالخوادم كعنصر فريد من نوعه في البنية التحتية يصعب تخصيصه.، الانتقال من تكوين الخادم اليدوي إلى إدارة البنية التحتية المركزية الآلية. يجب وصف عملية إعداد كل خادم في شكل تكوين يسهل قراءته ، وقابل للتغيير ، وجاهز لإعادة الاستخدام الآمن المتعدد ، مما يوفر نتيجة مضمونة لا لبس فيها. أمثلة على أنظمة المنسق الصناعي هي Chef أو Ansible. تتيح لك هذه الأنظمة إدارة عدد كبير من الخوادم بأقل تكلفة.
الخطوة المهمة التالية هي تطبيق الاختبار الآليلتغطية أكبر قدر ممكن من وظائف الشفرة التي يجري تطويرها (كل من البرامج والبنية التحتية). بمعنى آخر ، وجود بنية أساسية منتشرة ، ولكن بدون اختبار آلي ، فإن عنق الزجاجة في عملية التطوير سيكون التحقق في الوقت المناسب من الوظائف. يجب أن تبدأ أتمتة عملية الاختبار بالكتابة الفعلية لرمز البرنامج (اختبار الوحدة) ، وتطبيق الاختبارات الأولية على الخادم المسؤول عن بناء البرنامج ، واختبار تكوين الخادم. سيؤدي ذلك إلى تقليل عبء العمل على فريق ضمان جودة البرامج وتقليل وقت مرور البرنامج عبر خط الأنابيب بشكل كبير.
الخطوة المنطقية النهائية هي التجميع المركزي وتحليل ملفات السجل من جميع الخوادملإخطار جميع أصحاب المصلحة في الوقت المناسب والمراقبة الاستباقية لحالة البنية التحتية ككل.
ستساعدك الإرشادات المذكورة أعلاه على بناء بنية تحتية مرنة وقابلة للتطوير يمكنها التعامل مع عملية تطوير مكثفة. يتطلب تنفيذ DevOps مشاركة الجميع في العملية ، من الاختبار والتطوير إلى المديرين والعمليات. في كل مرحلة ، يلزم إجراء تحليل رجعي مستمر للعملية ، لأنه نتيجة للأخطاء العشوائية عند تغيير التكوين ، تتوقف الأنظمة تمامًا عن العمل. يحتاج القياس عن بُعد إلى التحسين لاكتشاف الأخطاء واستردادها بشكل أفضل ولحماية خط أنابيب النشر وتلبية أهداف تغيير الإدارة. سيسمح لك ذلك بتلقي أقصى قدر من الدعم من الإدارة في تنفيذ مبادرات DevOps ، وخلق بيئة عمل أكثر حيوية وودية ،حتى يتمكن أي مشارك من التعلم طوال الوقت - لن يساعد ذلك كل فنان على تحقيق الأهداف فحسب ، بل سيقود المنظمة أيضًا إلى النجاح.
في 3 أشهر على موقعنا على الانترنت بالطبع "CI / CD" التي ستعمل على تطوير فهم بنية مقدمي سحابة، وتعلم لأتمتة تحليل رمز والبحث عن نقاط الضعف، وتعلم كيفية تخصيص عمليات بناء واختبار وتثبيت التطبيق من أكبر ثلاثة مزودين . تم تصميم البرنامج للمتخصصين من ذوي الخبرة في الإدارة - سيساعدك اختبار الدخول الخاص على معرفة ما إذا كان لديك استعدادًا كافيًا للتدريب.