إخلاء المسؤولية . Kostis Kapelonis - داعية المطور Codefresh ، أول منصة CI / CD لـ Kubernetes والحاويات ، للدفاع عن مبادئ تطوير البرمجيات ودعمها. مهمة Codefresh "أتمتة وتبسيط كل شيء من الكود إلى السحابة." يتمتع Kostis ، كمهندس برمجيات ، بسنوات عديدة من الخبرة في حاويات التطبيقات وإنشاء خطوط أنابيب CI / CD وتطوير تطبيقات Java. يعيش في اليونان ويحب التزلج على الجليد.
كما يقول المثل ، "إذا كان هناك شيء يسبب الألم ، فعل ذلك في كثير من الأحيان." التكامل المستمر هو ، في جوهره ، تكرار لخطوة التكامل مع التردد العالي من أجل تخفيف "الألم" الذي تسببه. هذا المقال يدور حول هذا - عن "ألم" التنمية وكيفية الحد منه.
هناك الكثير من المعلومات حول التكامل المستمر (CI) والتسليم المستمر (CD). تستخدم منشورات المدونة مصطلحات تقنية لتوضيح معنى منهجيات CI / CD وماذا تفعل وكيف يمكن أن تساعد شركتك. لسوء الحظ ، غالباً ما ترتبط كل من هذه المنهجيات بأدوات محددة أو حتى مقدمي البرامج. المحادثة النموذجية حول هذا الموضوع في الشركة هي:
- هل تستخدم التكامل المستمر في فريقك؟
- نعم ، بالطبع ، نستخدم الأداة X!
دعني أخبرك بسر صغير. التكامل المستمر والتسليم هما طريقتان لتطوير التعليمات البرمجية التي لا علاقة لها تماما بأداة معينة أو بائع معين. على الرغم من وجود أدوات وحلول يمكن أن تساعدك في كلتا الحالتين (على سبيل المثال ، Codefresh) ، في الواقع ، يمكن لشركة ممارسة CI / CD باستخدام البرامج النصية bash فقط والبرامج النصية أحادية الخط Perl. هذه ليست عملية جدا ، ولكن بالتأكيد ممكن جدا.
لذلك ، بدلاً من الوقوع في الفخ العام المتمثل في شرح جوهر CI / CD باستخدام الأدوات والمصطلحات الفنية ، سنشرح ما تستند هذه المنهجيات إلى أهم عامل في عملية التطوير - الأشخاص!
قصة الناس: هارد تايمز تكامل البرمجيات
تعرف على Alice و Bob و Charlie و David و Elizabeth - وكلهم يعملون لصالح شركة SoftwareCo Inc. عبر إنشاء تطبيق SuperBigProject. أليس ، بوب ، وتشارلي مطورين. ديفيد مهندس اختبار ، وإليزابيث هي مديرة مشروع فريق.
الطريقة التقليدية لتطوير التطبيق هي كما يلي: تعمل Alice و Bob و Charlie على ثلاث وظائف مختلفة على محطة العمل الخاصة بهم. كل مطور يكتب ويختبر الرمز بشكل فردي. يستخدمون فروع طويلة من الوظائف التي توجد لعدة أسابيع أو حتى أشهر قبل دمجها في منتج نهائي.
في مرحلة ما ، تقوم مديرة المشروع إليزابيث بتجميع الفريق بأكمله وتقول: "أيها الناس ، نحتاج بالفعل إلى إصدار إصدار ، لذلك تحاول!"
بعد ذلك ، تحاول أليس وبوب وتشارلي دمج وظائفهم الثلاثة في فرع واحد. هذا وقت مرهق للغاية لأن هذه الميزات لم يتم اختبارها معًا. تظهر العديد من الأخطاء والمشكلات في أي مكان ، بسبب الافتراضات أو المشكلات غير الصحيحة المتعلقة بالبيئة ، لأنه حتى لو كنت تتذكر ، فقد تم اختبار جميع الوظائف ببساطة حتى الآن على محطات عمل مختلفة ، معزولة عن بعضها البعض.
بمجرد انتهاء "حمى التكامل" ، يتم تمرير النتيجة المدمجة إلى David ، الذي سيقوم بإجراء اختبار يدوي وتلقائي إضافي. تستغرق هذه الفترة أيضًا الكثير من الوقت ، لأن ديفيد هو الذي يمكنه الموافقة على الإصدار أو حظره ، وذلك استنادًا إلى عدد الأخطاء الحرجة التي تم العثور عليها. يراقب الجميع عن كثب ديفيد أثناء قيامه بدوره ، حيث إن اختباره يمكن أن يكشف عن مشكلات خطيرة قد تؤدي إلى تأخير إصدار المنتج.
أخيرًا ، اكتمل الاختبار ، وأعلنت إليزابيث بسرور أن منتج البرنامج جاهز للتعبئة والشحن.
لذا ، كيف يشعر الناس في هذه القصة الخيالية ، ولكن واقعية للغاية؟
- المطورون Alice و Bob و Charlie غير راضين لأنهم يكتشفون دائمًا مشكلات التكامل قبل الإصدار. تشبه فترة التكامل إطلاق النار الذي تصل فيه الرصاصات في وقت واحد من جميع الجوانب.
- يشعر ديفيد بالتوتر المستمر بسبب طبيعة "ارتعاش" عمله - هناك فترات هادئة عندما ينتظر فقط حتى ينتهي المطورون من العمل ، وهناك مرحلة اختبار عندما يكون غارقًا في العمل ويتعين عليه التعامل مع نصوص اختبار غير متوقعة ، بالإضافة إلى ذلك ، في هذا الوقت ، يقف فريق التطوير خلفه حرفيًا.
- إليزابيث ، كمديرة للمشروع ، غير سعيدة أيضًا. مرحلة التكامل هي حلقة حرجة في المشروع. هذه فترة مزدحمة ، حيث إن أي مشكلة غير متوقعة تدفع إلى إطلاق المنتج. تحلم إليزابيث بإصدار برنامج دون أية مفاجآت ، ولكن هذا لا يحدث أبدًا في الممارسة. إن "نجاح" مرحلة التكامل في الجدول الزمني المخطط للمشروع هو دائمًا لعبة تخمين.
بشكل عام ، جميع أعضاء الفريق غير راضين. بالمناسبة ، إذا كانت شركتك لا تزال تعمل على تطوير مثل هذه البرامج ، فحاول أن تفهم أن عملية التطوير هذه ضارة بمعنويات فريقك.
لذلك ، المشكلة الوحيدة والرئيسية هي مرحلة التكامل ، والتي تحدث مع كل إصدار من منتج البرنامج. هذه نقطة ألم في سير العمل لا تسمح لفريق من المبرمجين بتحرير أنفسهم من الموقف المجهد المرتبط بإصدار البرنامج.
مضيفا الاستمرارية إلى التكامل
الآن وقد رأينا معنى "التكامل" ، من السهل جدًا فهم معنى "التكامل المستمر". كما يقول المثل ، "إذا كان هناك شيء يسبب الألم ، فعل ذلك في كثير من الأحيان." التكامل المستمر هو ، في جوهره ، تكرار لخطوة التكامل مع التردد العالي من أجل تخفيف "الألم" الذي تسببه.
تتمثل الطريقة الأكثر وضوحا لجعل العملية أقل إيلامًا في الاندماج في كثير من الأحيان بعد كل عملية دمج ، بدلاً من انتظار الإصدار الرسمي.
عندما يمارس فريق التكامل المستمر ، ثم:
- يتم دمج جميع الكائنات مباشرة في الفرع الرئيسي.
- المطورين العمل معا ، وليس في عزلة. تم تطوير جميع الوظائف من الخط الرئيسي.
- تعتبر الوظيفة مطورة إذا كان الخط الرئيسي يعمل بشكل كامل ويعمل على أي جهاز ، وليس فقط على محطة عمل منفصلة.
- يتم الاختبار تلقائيًا على مستوى العناصر الفردية أو كائنات التعليمات البرمجية ، وعلى مستوى الخط الرئيسي.
هذا هو جوهر التكامل المستمر. بالطبع ، هناك فروق دقيقة أخرى في هذه المنهجية ، وهناك كتاب كامل حول هذا الموضوع ، ولكن الشيء الرئيسي هو أنه بدلاً من فترة تكامل واحدة مرهقة ، عندما يتم دمج كل شيء واختباره في نفس الوقت ، يحدث التكامل في كل وقت بطريقة مستمرة.
التكامل المستمر في عملية تطوير البرمجيات متفوقة على التكامل التقليدي للأسباب التالية:
- يقلل من عدد المفاجآت التي تظهر عند دمج كائنات التعليمات البرمجية.
- يحل المشكلة "البرنامج يعمل فقط على الجهاز الخاص بي."
- يقسم فترة الاختبار إلى عدة فترات ، حيث يتم دمج كل كائن رمز تدريجيًا مع الخط الرئيسي ، بدلاً من دمج كل الكائنات مرة واحدة.
نتيجة لذلك ، فإن الفريق الذي يستخدم CI لا يشعر بأنه السفينة الدوارة عندما تتخلل فترات الهدوء من التطور إطلاقات مرهقة. بالإضافة إلى ذلك ، تتاح لها الفرصة لتقييم متقن مدى قرب المشروع من الانتهاء ، بدلاً من تخمين تواريخ الإصدار. يعد استخدام CI أحد أعمدة تطوير البرامج الحديثة. اليوم هذه الطريقة موثقة جيدًا ومعروفة جيدًا. لذلك ، لا يمكن أن يكون هناك مبرر لحقيقة أن شركتك لا تزال لا تمارس CI في تطوير مشاريع البرامج.
هارد تايمز تسليم البرمجيات
الآن وبعد أن نظرنا إلى تاريخ التكامل المنتظم وكيف يعمل التكامل المستمر ، يمكننا أن ننتقل إلى هذا المستوى التالي من عملية التطوير - التسليم المستمر. إذا عدنا إلى قصتنا الأصلية ، فسنرى صورة مشابهة لعملية التكامل الطبيعي:
كان إطلاق المنتج حدثًا أساسيًا يشبه الانفجار الكبير. بعد اعتبار البرنامج تم اختباره ، اضطر شخص ما إلى إكمال عملية تقليل البرامج ونشرها من الحاويات. كان نشر البرامج على الإنتاج أيضًا فترة مزدحمة جدًا وكان يتضمن تقليديًا العديد من الخطوات اليدوية وإجراءات المتابعة. كانت عمليات النشر نادرة جدًا ، وحتى اليوم لا توجد شركات تنفذ هذا الإجراء أكثر من مرة واحدة كل ستة أشهر. فقط في الحالات القصوى ، تم النشر في وقت واحد - عند استخدام نموذج التسلسل لتطوير البرمجيات (الشلال).
يؤدي تسليم البرنامج فقط بعد الوصول إلى الموعد النهائي إلى خلق نفس المشكلات التي تحدثها عمليات الدمج العادية والنادرة:
- تختلف بيئة الإنتاج عادة عن بيئة الاختبار ، والتي تتطلب تكوينًا إضافيًا في اللحظة الأخيرة.
- وظائف التي تعمل بشكل طبيعي في بيئة اختبار كسر في بيئة العمل.
- الوظائف التي لم تكن جاهزة في وقت الإصدار ، إما لا يتم توفيرها أبدًا للعملاء على الإطلاق ، أو يؤدي تحسينها إلى زيادة الإصدار.
- في هذا الصدد ، تخلق الإصدارات التوتر بين المطورين الذين يرغبون في إضافة ميزات جديدة لتوسيع وظائف البرنامج والمشغلين الذين يرغبون في الاستقرار ولا يرغبون في نشر الكثير من الوظائف الجديدة مرة واحدة.
الحل لهذه المشكلة هو نفس القالب كما في حالة التكامل. إذا تمكنا من تخفيف آلام عملية التكامل من خلال جعلها أكثر تواتراً ، فيمكننا فعل الشيء نفسه في عملية تسليم البرنامج.
إضافة الاستمرارية إلى التسليم
التسليم المستمر هو ممارسة التعبئة في الحاويات وإعداد البرامج كما لو كان يتم إرسالها إلى الإنتاج ، قدر الإمكان. وطريقة التسليم الأكثر تطرفا هي بعد كل دمج.
بهذه الطريقة ، يأخذ القرص المضغوط CI خطوة واحدة إلى الأمام. بعد دمج كل وظيفة مع فرع الخط الرئيسي ، لا يتم التحقق من التطبيق فقط للتأكد من صحته ، ولكن يتم أيضًا تعبئته ونشره في بيئة اختبار تتوافق تمامًا مع بيئة العمل. كل هذا يحدث في وضع تلقائي بالكامل - انتبه إلى غياب الرجال الصغار الذين يشيرون إلى الإجراءات اليدوية.
ضع في اعتبارك أيضًا أن كل ميزة جديدة هي مرشح محتمل لإطلاقها في الإنتاج. في الممارسة العملية ، لا يتم إرسال جميع المرشحين للإنتاج. اعتمادًا على تنظيم العملية ، يتطلب قرار النشر للإنتاج أحيانًا تدخل الشخص المسؤول الذي يقرر ما إذا كان سيتم إطلاق الإصدار في الإنتاج أم لا ، ولكنه لا يشارك شخصيًا في إعداد الإصدار. في هذه المرحلة ، يتم بالفعل إطلاق الإصدار وتعبئته ونشره في بيئة اختبار.
التسليم المستمر (CD) هو أكثر تعقيدًا بقليل من التكامل المستمر (CI). والسبب هو أنه بما أن كل مرشح للإصدار يمكنه تحقيق الإنتاج ، ينبغي أن تكون دورة الحياة الكاملة آلية:
- يجب أن تكون الجمعيات قابلة للتكرار والحتمية.
- يجب أن تكون جميع الخطوات مؤتمتة ، وهو أمر صعب التطبيق.
- يجب أن تكون كافة التكوينات والملفات ذات الصلة موجودة في نظام التحكم في الإصدار ، وليس فقط في التعليمات البرمجية المصدر.
- يجب اختبار كل ميزة / إصدار في بيئة اختبار تم إنشاؤها ديناميكيًا وتدميرها ديناميكيًا.
- يجب أن تكون جميع أجنحة الاختبار آلية وسريعة نسبيًا ، وهي ليست مهمة سهلة أيضًا.
على الرغم من أن "السحابة" يمكن أن تساعد بالتأكيد على تلبية جميع هذه المتطلبات ، يحتاج فريق من المبرمجين ، المطورين والمشغلين ، إلى مستوى معين من الانضباط يضمن حقًا عملية تسليم البرامج المستمر.
بعد إدخال إصدارات القرص المضغوط تصبح روتينًا ، كما لو كانت تُنفذ بنقرة زر بسيطة. كل عضو في الفريق ، وليس فقط مدير المشروع ، يمكنه رؤية مرشح الإصدار الحالي. قد لا يحتوي هذا المرشح على بعض الوظائف المطلوبة أو قد لا يلبي جميع المتطلبات بشكل كامل ، لكن هذا ليس مهمًا على الإطلاق حتى يؤثر على عملية الإصدار نفسها.
الحقيقة المهمة هي أن الإصدار تم اختباره بالكامل ، وتعبئته ، وجاهز للإرسال إلى الإنتاج إذا لزم الأمر. في الوقت نفسه ، يجب أن يكون أي مشارك في المشروع قادراً على إعطاء ضوء أخضر وإصدار برنامج فورًا للإنتاج.
إذا كنت تستخدم قرصًا مضغوطًا ، فيمكن تمثيل دورة حياة البرنامج على النحو التالي:
يتم إعداد كل مرشح إطلاق دائمًا مقدمًا. يقرر الشخص ما إذا كان مرشح الإصدار سيتم ترشيحه أيضًا للإنتاج أم لا. يستمر تخزين المرشحين المحررون الذين لا يصلون إلى الإنتاج كأدوات في حال احتاجوا إلى استخدامها في المستقبل.
لمعلوماتك ، حول التسليم المستمر ، وكذلك حول التكامل المستمر ، تم أيضًا كتاب كتاب كامل يمكنك من خلاله معرفة تفاصيل هذه المنهجية.
المكافأة: النشر المستمر
الحرف "D" في القرص المضغوط قد يعني نشر النشر ، وليس تسليم التسليم. ويستند هذا النهج لعملية التنمية على التسليم المستمر ويزيل أساسا تدخل الإنسان. أي مرشح للإصدار ، والذي سيجتاز جميع الاختبارات وفحص الجودة وسيتم الاعتراف به جاهزًا ، يتم إرساله على الفور إلى الإنتاج.
من المسلم به أن عددًا صغيرًا جدًا من الشركات قادر على العمل بهذه الطريقة. لا ينبغي الاستخفاف بالترويج للإنتاج دون تدخل بشري ، لأنه في وقت كتابة هذا التقرير ، لم تمارس العديد من الشركات حتى التسليم المستمر ، ناهيك عن النشر المستمر.
يجب أن تفهم أن كل نهج لاحق لعملية التطوير يعتمد على تنفيذ الطريقة السابقة.
قبل المضي قدماً في طريق التحسين ، يجب أن تتأكد شركتك من أن كل أسس العملية قوية حقًا. لقد رأينا في Codefresh الكثير من الشركات التي تهدف إلى التحول إلى التقنيات السحابية ، في محاولة لتحويل تقنياتها المُحسّنة للاستخدام في مراكز البيانات على خطوط أنابيب CI / CD ، دون إدراك أن بعض هذه التقنيات قد عفا عليها الزمن اليوم. محاولة نشر مستمر دون احتضان كامل التسليم المستمر محكوم عليه بالفشل.
يوضح الشكل التالي مراحل تطوير وتنفيذ البرامج بواسطة Alice و Bob و Charlie و David و Elizabeth cover CD و CI.
تأكد من الاقتراب من كل نموذج لتطوير البرمجيات بالترتيب الصحيح. نعتقد أن إدخال التسليم المستمر هو هدف واقعي للغاية ، حيث توجد جميع الأدوات اللازمة لتنفيذه.
قليلا من الإعلان :)
شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المواد المثيرة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية لأصدقائك ،
سحابة VPS للمطورين من 4.99 دولار ،
خصم 30 ٪ لمستخدمي Habr على تناظرية فريدة من الخوادم على مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2650 v4 (6 النوى) 10GB DDR4 240GB SSD 1Gbps من 20 دولار أو كيفية مشاركة خادم؟ (تتوفر خيارات مع RAID1 و RAID10 ، ما يصل إلى 24 مركزًا وما يصل إلى 40 جيجابايت من ذاكرة DDR4).
ديل R730xd 2 مرات أرخص؟ فقط لدينا
2 من Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6 جيجا هرتز 14 جيجا بايت 64 جيجا بايت DDR4 4 × 960 جيجا بايت SSD 1 جيجابت في الثانية 100 TV من 199 دولار في هولندا! Dell R420 - 2x E5-2430 سعة 2 جيجا هرتز 6 جيجا بايت 128 جيجا بايت ذاكرة DDR3 2x960GB SSD بسرعة 1 جيجابت في الثانية 100 تيرابايت - من 99 دولارًا! اقرأ عن
كيفية بناء البنية التحتية فئة باستخدام خوادم V4 R730xd E5-2650d تكلف 9000 يورو عن بنس واحد؟