تسليم مستمر
عودة للموسوعةالتسليم المستمر (سي دي أوسي دي إي) هوأحد نهج هندسة البرمجيات، تنتج الفرق باستخدامه البرمجيات خلال دورات قصيرة، ما يضمن إصدار البرمجيات بشكل موثوق في أي وقت، والقيام بذلك يدويًا. يهدف إلى إنشاء البرمجيات واختبارها وإصدارها بسرعة وتواتر أكبر. ويساعد هذا النهج على تقليل التكلفة والوقت ومخاطر إجراء التغييرات من خلال السماح بإجراء تحديثات تزايدية للتطبيقات في الإنتاج. وتعد عملية النشر المباشرة والقابلة للتكرار عملية مهمة للتسليم المستمر.
يتناقض التسليم المستمر مع النشر المستمر، وهونهج مماثل تُنتج فيه البرمجيات أيضًا في دورات قصيرة ولكن من خلال عمليات النشر الآلية بدلاً من اليدوية.
العلاقة مع ديف أوبس
يتشابه التسليم المستمر وديف أوبس في معانيها وكثيرًا ما يخلط بينهما، ولكنهما مفهومان مختلفان. فنطاق ديف أوبس أوسع، ويهجرز حول التغير الثقافي، وخاصةً تعاون مختلف الفرق المشاركة في تسليم البرمجيات (المطورين، العمليات، ضمان الجودة، الإدارة، إلخ)، بالإضافة إلى أتمتة عمليات تسليم البرمجيات. ومن ناحية أخرى، فإن التسليم المستمر هونهج لأتمتة جانب التسليم، يركز على الجمع بين العمليات المتنوعة وتطبيقها بسرعة وتواتر أكبر. وبالتالي، يمكن حتى تكون ديف أوبس منتجاً للتسليم المستمر، ويتدفق التسليم المستمر مباشرةً إلى ديف أوبس.
العلاقة مع النشر المستمر
التسليم المستمر هوالقدرة على تسليم البرمجيات التي يمكن نشرها في أي وقت من خلال الإصدارات اليدوية؛ ويتناقض هذا مع النشر المستمر الذي يستخدم النشر الآلي. ووفقا لمارتن فاولر، فإن النشر المستمر يحتاج التسليم المستمر. يميز الأدب الأكاديمي بين النهجين وفقًا لطريقة النشر؛ يدوية أم آلية.
المبادئ
يعامل التسليم المستمر المفهوم الشائع لأنابيب تجزئة التوزيع مثل بوكا يوكي الخالي من الهدر على أنه مجموعة من عمليات التحقق التي يجب حتى تخضع لها البرمجية في طريقها إلى الإصدار. يترجم الكود البرمجي إذا لزم الأمر ثم يجمع بواسطة خادم بناء في جميع مرة يجرى فيها تغيير على مستودع التحكم بالمصدر، ثم يختبر باستخدام تقنيات عديدة مختلفة (تتضمن الاختبار اليدوي على الأغلب) قبل حتى يحدد أنه قابل للإصدار.
قد يحتاج المطورون الذين اعتادوا على الدورات الطويلة إلى تغيير كيفية تفكيرهم عند العمل في بيئة التسليم المستمر. من المهم حتى نفهم حتى أي تطبيق للكود البرمجي يمكن إصداره إلى العملاء في أي وقت. قد تكون بعض الأنماط مثل تقنيات تبديل الميزات مفيدة جدًا في تطبيق الكود البرمجي (الذي لم يجهز بعد لاستخدامه من قبل المستخدمين النهائيين) باكرًا. يمكن حتى يؤدي استخدام نظام قواعد البيانات غير العلائقي إلى إزالة خطوة ترحيل البيانات وتغييرات المخطط، ويُنفذ غالباً خطوات اليدوية أواستثناءات لسير عمل التسليم المستمر.
هناك تقنيات مفيدة أخرى لتطوير الكود بشكل منفصل مثل تفريع الكود، وهي تقنيات حديثة في التسليم المستمر، ولكن يجب تكييفها لتتناسب مع مبادئ التسليم المستمر - مثلًا، يمكن حتىقد يكون تشغيل عدة فروع الكود طويلة الأجل غير عملي، لأنه يجب بناء منتج قابل للإصدار في وقت مبكر من عملية التسليم المستمر من فرع واحد من فروع الكود إذا فُرض عليه المرور عبر جميع مراحل أنابيب التجزئة.
أنابيب تجزئة النشر
يُمكّن التسليم المستمر من خلال أنابيب تجزئة النشر. هناك ثلاث أهداف لأنابيب تجزئة النشر: الرؤية والتغذية الراجعة والنشر المستمر.
- الرؤية - تكون جميع جوانب نظام التسليم، بما في ذلك البناء، والنشر، والاختبار، والإصدار، مرئية لجميع أعضاء الفريق ما يؤيد التعاون.
- التغذية الراجعة: يتعهد أعضاء الفريق على المشاكل بمجرد حدوثها ليتمكنوا من إصلاحها في أسرع وقت ممكن.
- النشر المستمر: يمكن نشر أي إصدار من البرنامج وإصداره لأي بيئة، من خلال عملية آلية بالكامل.
تصميم التسليم المستمر
لتطبيق التسليم المستمر بفعالية، يجب حتى تلبي التطبيقات البرمجية مجموعة من المتطلبات البنيوية المهمة (ايه إس آر) مثل إمكانية النشر وقابلية التعديل وقابلية الاختبار. تتطلب هذه المتطلبات البنيوية المهمة أولوية عليا ولا يمكن استبدالها بسهولة.
كثيرًا ما تُستخدم الخدمات الصغيرة لتصميم التسليم المستمر. يمكن حتى يزيد استخدام الخدمات الصغيرة قابلية نشر النظام وتعديله. تتضمن تحسينات قابلية النشر الإشارة: استقلالية النشر، ووقت نشر أقصر، وإجراءات نشر أبسط، وعدم تعطل النشر. تضم تحسينات قابلية التعديل الإشارة: فترات زمنية أقصر للتغيرات الوظيفية التزايدية الصغيرة، تغييرات أسهل في اختيار التكنولوجيا، تغييرات سمات الجودة التزايدية، وتحديثات أسهل للغة والمخطة.
التطبيق والاستخدام
نشر كتاب التسليم المستمر الذي خطه جيهز همبل وديفيد فارلي مصطلح النشر المستمر، ولكن منذ إنشائه، استمر التعريف في التقدم ويملك الآن معنى أكثر تطوراً. تطبق الشركات اليوم مبادئ التسليم المستمر هذه وأفضل الممارسات. ما تزال الاختلافات بين المجالات، مثل الطب لقاء الويب، كبيرة وتؤثر على التطبيق والاستخدام. وفيما يلي بعض الشركات المعروفة التي تعتمد هذا النهج: ياهو!،وأمازون،وفيسبوك،وغوغل، وبادي باور وويلز فارغو.
الفوائد والعوائق
أُبلغ عن الكثير من فوائد التسليم المستمر:
- وقت سريع في الوصول إلى السوق: يتيح التسليم المستمر للمؤسسة تقديم قيمة العمل المتأصلة في الإصدارات البرمجيات الجديدة للعملاء بسرعة أكبر. تساعد هذه القدرة الشركة على البقاء في صدارة المنافسة.
- بناء المنتج المناسب: تسمح الإصدارات المتكررة لفرق تطوير التطبيقات بالحصول على تعليقات المستخدمين بسرعة أكبر. ما يتيح لهم العمل على الميزات المفيدة فقط. إذا تبين لهم حتى إحدى الميزات غير مفيدة، فلا يبذلوا أي جهد إضافي عليها. يساعدهم ذلك على بناء المنتج المناسب.
- تحسين الإنتاجية والكفاءة: توفر الأتمتة وقت كبير للمطورين والمختبرين ومهندسي العمليات وغيرهم.
- الإصدارات الموثوقة: تقلصت المخاطر المرتبطة بالإصدار بشكل كبير، وأصبحت عملية الإصدار أكثر موثوقية. تُختبر عملية النشر وبرامجها النصية بشكل متكرر باستخدام التسليم المستمر قبل النشر للإنتاج. لذا، تُكتشف معظم الأخطاء في عملية النشر وبرامجها النصية. يتناقص عدد تغييرات الكود البرمجي في جميع إصدار مع الإصدارات الأكثر تكرارًا. يُسهل هذا العثور على المشاكل وإصلاحها ما يقلل وقت تأثيرها.
- تحسين جودة المنتج: انخفض عدد الأخطاء المفتوحة ومشاكل الإنتاج بشكل كبير.
- تحسين رضا العملاء: حُقق مستوى أعلى من رضا العملاء.
وجرى التحقيق في العقبات أيضًا.
- تفضيلات العملاء: لا يريد بعض العملاء تحديثات مستمرة لأنظمتهم. وخاصّةً في المراحل الحرجة من عملياتها.
- قيود المجال: في بعض المجالات، مثل الاتصالات عن بعد والطب، تتطلب اللوائح إجراء اختبارات شاملة قبل السماح للإصدارات الجديدة بالدخول في فترة العمليات.
- نقص أتمتة الاختبار: يؤدي نقص أتمتة الاختبار إلى نقص ثقة المطور ويمكن حتى يمنع هذا استخدام التسليم المستمر.
- الاختلافات في البيئات: قد يؤدي استخدام بيئات مختلفة في التطوير والاختبار والإنتاج إلى مشاكل خفية في بيئة الإنتاج.
- الاختبارات التي بحاجة إلى أوراكل بشري: لا يمكن التحقق من جميع سمات الجودة باستخدام الأتمتة. وتتطلب هذه السمات الإطلاع البشري، ما يؤدي إلى إبطاء أنابيب تجزئة التسليم.
طرح تشن ثمانية تحديات اعتماد أخرى وصاغها. تتمثل هذه التحديات في مجالات البنية التنظيمية والعمليات والأدوات والبنية التحتية والنظم القديمة وتصميم التسليم المستمر، والاختبار المستمر للمتطلبات غير الوظيفية، وتحسين تطبيق الاختبار.
انظر أيضًا
- إدارة التغيير
- هجريب متواصل
- ديف أوبس
- ضبط النسخ (الحاسوب)
مراجع
- ↑ Chen, Lianping (2015). "Continuous Delivery: Huge Benefits, but Challenges Too". IEEE Software. 32 (2): 50–54. doi:10.1109/MS.2015.27.
- ↑ 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.
- ^ Hammond, Jeffrey (9 September 2011). "The Relationship between DevOps and Continuous Delivery". Forrester Research. Forester. مؤرشف من الأصل فيعشرة فبراير 2017.
- ^ Humble, Jez; Farley, David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc. ISBN .
- ^ Swartout, Paul (2012). Continuous Delivery and DevOps: A Quickstart guide. Packt Publishing. ISBN .
- ↑ Chen, Lianping (2017). "Continuous Delivery: Overcoming adoption challenges". Journal of Systems and Software. 128: 72–86. doi:10.1016/j.jss.2017.02.013.
- ^ "bliki: ContinuousDelivery". martinfowler.com. مؤرشف من الأصل في أربعة نوفمبر 2019. اطلع عليه بتاريخ 29 أكتوبر 2015.
- ^ 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 .
- ^ Humble, J.; Read, C.; North, D. (2006). "The Deployment Production Line". Agile 2006 (Agile'06). صفحات 113–118. doi:10.1109/AGILE.2006.53. ISBN .
- ^ Fitzgerald, Brian (2014-06-03). (PDF). 1st International Workshop on Rapid Continuous Software Engineering. New York, NY: Association for Computing Machinery. صفحات 1–9. doi:10.1145/2593812.2593813. ISBN . مؤرشف من الأصل (PDF) في 25 أكتوبر 2014. اطلع عليه بتاريخ 24 أكتوبر 2014.
- ^ Kluge, Lars (12 September 2013). "Continuous Deployment with MongoDB at Kitchensurfing". slideshare.net. مؤرشف من الأصل في 11 فبراير 2017. اطلع عليه بتاريخ 03 يناير 2014.
- ^ Duvall, Paul (2012). "Continuous Delivery: Patterns and Anti-Patterns in Software Lifecycle" (PDF). Refcardz. مؤرشف من الأصل (PDF) في 19 يونيو2018. اطلع عليه بتاريخ October 9, 2015.
- ^ 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.
- ^ Chen, Lianping (2018). . The IEEE International Conference on Software Architecture (ICSA 2018). IEEE. مؤرشف من الأصل في 08 ديسمبر 2019.
- ^ "Implementing Continuous Delivery at Yahoo!". confreaks.tv. 23 October 2013. مؤرشف من الأصل في أربعة يناير 2018.
- ^ ". youtube.com. 20 June 2011. مؤرشف من الأصل في 30 سبتمبر 2019.
- ^ "Rapid Release At Massive Scale". 2017-08-31. مؤرشف من الأصل في 18 ديسمبر 2017.
- ^ Humble, Jez (13 February 2014). "The Case for Continuous Delivery". thoughtworks.com. مؤرشف من الأصل في 23 سبتمبر 2019. اطلع عليه بتاريخ 16 يوليو2014.
- ^ jFrog (December 2014). "2014-year-continuous-integration-revolution". مؤرشف من الأصل فيسبعة مايو2015.
- ↑ 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.
التصنيفات: تصميم البرمجيات, عملية تطوير البرمجيات, مقالات يتيمة منذ ديسمبر 2019, جميع المقالات اليتيمة, جميع المقالات التي بحاجة لصيانة, بوابة علم الحاسوب/مقالات متعلقة, بوابة برمجة الحاسوب/مقالات متعلقة, بوابة تقنية المعلومات/مقالات متعلقة, بوابة برمجيات/مقالات متعلقة, جميع المقالات التي تستخدم شريط بوابات
