الرئيسيةعريقبحث

تسليم مستمر

☰ جدول المحتويات

التسليم المستمر (سي دي أو سي دي إي) هو أحد نهج هندسة البرمجيات، تنتج الفرق باستخدامه البرمجيات خلال دورات قصيرة، ما يضمن إصدار البرمجيات بشكل موثوق في أي وقت، والقيام بذلك يدويًا. يهدف إلى إنشاء البرمجيات واختبارها وإصدارها بسرعة وتواتر أكبر. ويساعد هذا النهج على تقليل التكلفة والوقت ومخاطر إجراء التغييرات من خلال السماح بإجراء تحديثات تزايدية للتطبيقات في الإنتاج. وتعد عملية النشر المباشرة والقابلة للتكرار عملية مهمة للتسليم المستمر.[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:. Bibcode:2017arXiv170307019S. doi:10.1109/ACCESS.2017.2685629.
  3. Hammond, Jeffrey (9 September 2011). "The Relationship between DevOps and Continuous Delivery". Forrester Research. Forester. مؤرشف من الأصل في 10 فبراير 2017.
  4. Humble, Jez; Farley, David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc.  .
  5. Swartout, Paul (2012). Continuous Delivery and DevOps: A Quickstart guide. Packt Publishing.  .
  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. مؤرشف من الأصل في 4 نوفمبر 201929 أكتوبر 2015.
  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.  .
  9. Humble, J.; Read, C.; North, D. (2006). "The Deployment Production Line". Agile 2006 (Agile'06). صفحات 113–118. doi:10.1109/AGILE.2006.53.  .
  10. Fitzgerald, Brian (2014-06-03). Continuous Software Engineering and Beyond: Trends and Challenges ( كتاب إلكتروني PDF ). 1st International Workshop on Rapid Continuous Software Engineering. New York, NY: Association for Computing Machinery. صفحات 1–9. doi:10.1145/2593812.2593813.  . مؤرشف من الأصل ( كتاب إلكتروني PDF ) في 25 أكتوبر 201424 أكتوبر 2014.
  11. Kluge, Lars (12 September 2013). "Continuous Deployment with MongoDB at Kitchensurfing". slideshare.net. مؤرشف من الأصل في 11 فبراير 201703 يناير 2014.
  12. Duvall, Paul (2012). "Continuous Delivery: Patterns and Anti-Patterns in Software Lifecycle" ( كتاب إلكتروني PDF ). Refcardz. مؤرشف من الأصل ( كتاب إلكتروني PDF ) في 19 يونيو 2018October 9, 2015.
  13. Chen, Lianping (2015). Towards Architecting for Continuous Delivery. The 12th Working IEEE/IFIP Conference on Software Architecture(WICSA 2015). 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). IEEE. مؤرشف من الأصل في 08 ديسمبر 2019.
  15. "Implementing Continuous Delivery at Yahoo!". confreaks.tv. 23 October 2013. مؤرشف من الأصل في 4 يناير 2018.
  16. "Velocity 2011: Jon Jenkins, "Velocity Culture". youtube.com. 20 June 2011. مؤرشف من الأصل في 30 سبتمبر 2019.
  17. "Rapid Release At Massive Scale". 2017-08-31. مؤرشف من الأصل في 18 ديسمبر 2017.
  18. Humble, Jez (13 February 2014). "The Case for Continuous Delivery". thoughtworks.com. مؤرشف من الأصل في 23 سبتمبر 201916 يوليو 2014.
  19. jFrog (December 2014). "2014-year-continuous-integration-revolution". مؤرشف من الأصل في 7 مايو 2015.
  20. Leppänen, M.; Mäkinen, S.; Pagels, M.; Eloranta, V. P.; Itkonen, J.; Mäntylä, M. V.; Männistö, T. (2015-03-01). "The Highways and Country Roads to Continuous Deployment". IEEE Software. 32 (2): 64–72. doi:10.1109/MS.2015.50. ISSN 0740-7459.

موسوعات ذات صلة :