تسليم مستمر

من أرابيكا، الموسوعة الحرة

هذه هي النسخة الحالية من هذه الصفحة، وقام بتعديلها عبد العزيز (نقاش | مساهمات) في 01:01، 9 فبراير 2023 (بوت: إصلاح التحويلات). العنوان الحالي (URL) هو وصلة دائمة لهذه النسخة.

(فرق) → نسخة أقدم | نسخة حالية (فرق) | نسخة أحدث ← (فرق)
اذهب إلى التنقل اذهب إلى البحث
جزء من سلسلة مقالات حول
عملية تطوير البرمجيات
نشاطات رئيسة
نماذج العمل
منهجيات التطوير وأُطُره
اختصاصات داعمة
تطبيقات بالممارسة
أدوات
منظَّمات ومعايير
شعار بوابة بوابة برمجيات

التسليم المستمر (بالإنجليزية: Continuous delivery)‏ اختصاراً CD، هو أحد نهج هندسة البرمجيات، تنتج الفرق باستخدامه البرمجيات خلال دورات قصيرة، ما يضمن إصدار البرمجيات بشكل موثوق في أي وقت، والقيام بذلك يدويًا. يهدف إلى إنشاء البرمجيات واختبارها وإصدارها بسرعة وتواتر أكبر. ويساعد هذا النهج على تقليل التكلفة والوقت ومخاطر إجراء التغييرات من خلال السماح بإجراء تحديثات تزايدية للتطبيقات في الإنتاج. وتعد عملية النشر المباشرة والقابلة للتكرار عملية مهمة للتسليم المستمر.[1][2]

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

العلاقة مع ديف أوبس

يتشابه التسليم المستمر وديف أوبس في معانيها وكثيرًا ما يخلط بينهما، ولكنهما مفهومان مختلفان. فنطاق ديف أوبس أوسع، ويتركز حول التغير الثقافي، وخاصةً تعاون مختلف الفرق المشاركة في تسليم البرمجيات (المطورين، العمليات، ضمان الجودة، الإدارة، إلخ)، بالإضافة إلى أتمتة عمليات تسليم البرمجيات. ومن ناحية أخرى، فإن التسليم المستمر هو نهج لأتمتة جانب التسليم، يركز على الجمع بين العمليات المختلفة وتنفيذها بسرعة وتواتر أكبر. وبالتالي، يمكن أن تكون ديف أوبس منتجاً للتسليم المستمر، ويتدفق التسليم المستمر مباشرةً  إلى ديف أوبس.[3][4][5]

العلاقة مع النشر المستمر

التسليم المستمر هو القدرة على تسليم البرمجيات التي يمكن نشرها في أي وقت من خلال الإصدارات اليدوية؛ ويتناقض هذا مع النشر المستمر الذي يستخدم النشر الآلي. ووفقا لمارتن فاولر، فإن النشر المستمر يتطلب التسليم المستمر. يميز الأدب الأكاديمي بين النهجين وفقًا لطريقة النشر؛ يدوية أم آلية.[6][7][8][2]

المبادئ

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

قد يحتاج المطورون الذين اعتادوا على الدورات الطويلة إلى تغيير طريقة تفكيرهم عند العمل في بيئة التسليم المستمر. من المهم أن نفهم أن أي تنفيذ للكود البرمجي يمكن إصداره إلى العملاء في أي وقت. قد تكون بعض الأنماط مثل تقنيات تبديل الميزات مفيدة جدًا في تنفيذ الكود البرمجي (الذي لم يجهز بعد لاستخدامه من قبل المستخدمين النهائيين) باكرًا. يمكن أن يؤدي استخدام نظام قواعد البيانات غير العلائقي إلى إزالة خطوة ترحيل البيانات وتغييرات المخطط، ويُنفذ غالباً خطوات اليدوية أو استثناءات لسير عمل التسليم المستمر.[11]

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

أنابيب تجزئة النشر

يُمكّن التسليم المستمر من خلال أنابيب تجزئة النشر. هناك ثلاث أهداف لأنابيب تجزئة النشر: الرؤية والتغذية الراجعة والنشر المستمر.[12]

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

تصميم التسليم المستمر

لتطبيق التسليم المستمر بفعالية، يجب أن تلبي التطبيقات البرمجية مجموعة من المتطلبات البنيوية المهمة (ايه إس آر) مثل إمكانية النشر وقابلية التعديل وقابلية الاختبار. تتطلب هذه المتطلبات البنيوية المهمة أولوية عليا ولا يمكن استبدالها بسهولة.[13]

كثيرًا ما تُستخدم الخدمات الصغيرة لتصميم التسليم المستمر. يمكن أن يزيد استخدام الخدمات الصغيرة قابلية نشر النظام وتعديله. تتضمن تحسينات قابلية النشر الملحوظة: استقلالية النشر، ووقت نشر أقصر، وإجراءات نشر أبسط، وعدم تعطل النشر. تشمل تحسينات قابلية التعديل الملحوظة: فترات زمنية أقصر للتغيرات الوظيفية التزايدية الصغيرة، تغييرات أسهل في اختيار التكنولوجيا، تغييرات سمات الجودة التزايدية، وتحديثات أسهل للغة والمكتبة.[14]

التطبيق والاستخدام

نشر كتاب التسليم المستمر الذي كتبه جيهز همبل وديفيد فارلي مصطلح النشر المستمر، ولكن منذ إنشائه، استمر التعريف في التقدم ويملك الآن معنى أكثر تطوراً. تطبق الشركات اليوم مبادئ التسليم المستمر هذه وأفضل الممارسات. ما تزال الاختلافات بين المجالات، مثل الطب مقابل الويب، كبيرة وتؤثر على التنفيذ والاستخدام. وفيما يلي بعض الشركات المعروفة التي تعتمد هذا النهج: ياهو!،[15] وأمازون،[16] وفيسبوك،[17] وغوغل،[18] وبادي باور[1] وويلز فارغو.[19]

الفوائد والعوائق

أُبلغ عن العديد من فوائد التسليم المستمر:[20][1]

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

وجرى التحقيق  في العقبات أيضًا.[20]

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

طرح تشن ثمانية تحديات اعتماد أخرى وصاغها. تتمثل هذه التحديات في مجالات البنية التنظيمية والعمليات والأدوات والبنية التحتية والنظم القديمة وتصميم التسليم المستمر، والاختبار المستمر للمتطلبات غير الوظيفية، وتحسين تنفيذ الاختبار.[6]

انظر أيضًا

مراجع

  1. ^ أ ب ت Chen، Lianping (2015). "Continuous Delivery: Huge Benefits, but Challenges Too". IEEE Software. ج. 32 ع. 2: 50–54. DOI:10.1109/MS.2015.27.
  2. ^ أ ب Shahin، Mojtaba؛ Ali Babara، Muhammad؛ Zhu، Liming (2017). "Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices". IEEE Access. ج. 5: 3909–3943. arXiv:1703.07019. Bibcode:2017arXiv170307019S. DOI:10.1109/ACCESS.2017.2685629.
  3. ^ Hammond، Jeffrey (9 سبتمبر 2011). "The Relationship between DevOps and Continuous Delivery". Forrester Research. Forester. مؤرشف من الأصل في 2017-02-10.
  4. ^ Humble، Jez؛ Farley، David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc. ISBN:978-0-321-60191-9.
  5. ^ Swartout، Paul (2012). Continuous Delivery and DevOps: A Quickstart guide. Packt Publishing. ISBN:978-1849693684.
  6. ^ أ ب Chen، Lianping (2017). "Continuous Delivery: Overcoming adoption challenges". Journal of Systems and Software. ج. 128: 72–86. DOI:10.1016/j.jss.2017.02.013.
  7. ^ "bliki: ContinuousDelivery". martinfowler.com. مؤرشف من الأصل في 2019-11-04. اطلع عليه بتاريخ 2015-10-29.
  8. ^ Shahin، Mojtaba؛ Babar، Muhammad Ali؛ Zahedi، Mansooreh؛ Zhu، Liming (2017). "Beyond Continuous Delivery: An Empirical Investigation of Continuous Deployment Challenges". 2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM). ص. 111–120. DOI:10.1109/ESEM.2017.18. ISBN:978-1-5090-4039-1.
  9. ^ Humble، J.؛ Read، C.؛ North، D. (2006). "The Deployment Production Line". Agile 2006 (Agile'06). ص. 113–118. DOI:10.1109/AGILE.2006.53. ISBN:0-7695-2562-8.
  10. ^ Fitzgerald، Brian (3 يونيو 2014). "Continuous Software Engineering and Beyond: Trends and Challenges" (PDF). 1st International Workshop on Rapid Continuous Software Engineering. http://continuous-se.org/. New York, NY: Association for Computing Machinery. ص. 1–9. DOI:10.1145/2593812.2593813. ISBN:978-1-4503-2856-2. مؤرشف من الأصل (PDF) في 2014-10-25. اطلع عليه بتاريخ 2014-10-24. {{استشهاد بمنشورات مؤتمر}}: |مسار المؤتمر= بحاجة لعنوان (مساعدة)
  11. ^ Kluge، Lars (12 سبتمبر 2013). "Continuous Deployment with MongoDB at Kitchensurfing". slideshare.net. مؤرشف من الأصل في 2017-02-11. اطلع عليه بتاريخ 2014-01-03.
  12. ^ Duvall، Paul (2012). "Continuous Delivery: Patterns and Anti-Patterns in Software Lifecycle" (PDF). Refcardz. مؤرشف من الأصل (PDF) في 2018-06-19. اطلع عليه بتاريخ 2015-10-09.
  13. ^ Chen، Lianping (2015). "Towards Architecting for Continuous Delivery". The 12th Working IEEE/IFIP Conference on Software Architecture(WICSA 2015). http://wicsa2015.org/. Montréal, Canada: IEEE. DOI:10.1109/WICSA.2015.23. {{استشهاد بمنشورات مؤتمر}}: |مسار المؤتمر= بحاجة لعنوان (مساعدة)، الوسيط |تاريخ الوصول بحاجة لـ |مسار= (مساعدة)، والوسيط |مسار أرشيف= بحاجة لـ |مسار= (مساعدة)
  14. ^ Chen، Lianping (2018). "Microservices: Architecting for Continuous Delivery and DevOps". The IEEE International Conference on Software Architecture (ICSA 2018). http://icsa-conferences.org/2018/. IEEE. مؤرشف من الأصل في 2019-12-08. {{استشهاد بمنشورات مؤتمر}}: |مسار المؤتمر= بحاجة لعنوان (مساعدة)
  15. ^ "Implementing Continuous Delivery at Yahoo!". confreaks.tv. 23 أكتوبر 2013. مؤرشف من الأصل في 2018-01-04.
  16. ^ "Velocity 2011: Jon Jenkins, "Velocity Culture"". youtube.com. 20 يونيو 2011. مؤرشف من الأصل في 2019-09-30.
  17. ^ "Rapid Release At Massive Scale". 31 أغسطس 2017. مؤرشف من الأصل في 2017-12-18.
  18. ^ Humble، Jez (13 فبراير 2014). "The Case for Continuous Delivery". thoughtworks.com. مؤرشف من الأصل في 2019-09-23. اطلع عليه بتاريخ 2014-07-16.
  19. ^ jFrog (ديسمبر 2014). "2014-year-continuous-integration-revolution". مؤرشف من الأصل في 2015-05-07.
  20. ^ أ ب Leppänen، M.؛ Mäkinen، S.؛ Pagels، M.؛ Eloranta، V. P.؛ Itkonen، J.؛ Mäntylä، M. V.؛ Männistö، T. (1 مارس 2015). "The Highways and Country Roads to Continuous Deployment". IEEE Software. ج. 32 ع. 2: 64–72. DOI:10.1109/MS.2015.50. ISSN:0740-7459.
مجلوبة من «https://3rabica.org/index.php?title=تسليم_مستمر&oldid=3194449»