تحویل پیوسته
تحویل پیوسته یا (CD)،(به انگلیسی: Continuous delivery) رویکردی در مهندسی نرم‌افزار است که تیم‌ها را قادر می‌سازد نرم‌افزار تولید شده را به روشی سریع و مطمئن برای انتشار و تحویل آماده کنند. این فرایند از لحظه اضافه شدن یا تغییر کد در source control شروع می‌شود و شامل ساخت (build)، تست، پیکربندی و انتشار در محیط‌های مختلف تست و محیط عملیات می‌شود. این مفهوم در فارسی به «تحویل مداوم» یا «تحویل مستمر» ترجمه شده‌است.
به عبارت دیگر: تحویل مستمر توانایی اعمال تغییرات در محیط عملیات در هرلحظه با روشی سریع و مطمئن و بطور کاملاً پایدار می‌باشد. این تغییرات شامل همه انواع آن از جمله تغییرات پیکربندی در نرم‌افزار، زیرساخت و پلتفرم، افزودن ویژگی‌های جدید، رفع باگ و خطاها می‌شود.
به وسیله محیط‌های تست مختلف، میتوان یک Deployment pipeline ایجاد کرد تا بتوان یک زیرساخت جدید را به‌طور اتوماتیک ایجاد کرد و نرم‌افزار را روی آن منتشر کرد. منظور از زیرساخت سرور، سیستم عامل، سرویس دهندهٔ وب، virtualization، شبکه ، پیکربندی و تنظیمات آنها می‌باشد. به کمک این محیط‌های متوالی میتوان فعالیت‌های طولانی یکپارچه‌سازی، تست عملکرد و تست‌های پذیرش نهایی را به تدریج انجام داد. فرایند تحویل پیوسته در Deployment pipeline با یکپارچه‌سازی مداوم شروع و با انتشار و پایان تست در هر محیط، انتشار و تست در مرحله بعدی شروع می‌شود. مجموع این کارها به صورت حلقه‌های یک زنجیر در پشت سرهم قرار گرفته و فرایند تحویل پیوسته را تشکیل می‌دهند.[۱]
ارتباط با دواپس
[ویرایش]تحویل پیوسته و دواپس از نظر معنایی به هم مشابه هستند و عموما با هم ترکیب می‌شوند، اما به طور کلی این دو مفهوم با یکدیگر متفاوت هستند.[۲] دواپس دامنه تعریف گسترده‌تری دارد و حیطه اصلی کار آن تغییر فرهنگ‌های سازمانی به‌ویژه در مفهوم همکاری تیم‌ها مختلف درگیر در تحویل نرم‌افزار (تیم اجرایی، تیم توسعه، مدیریت و غیره) می‌باشد.[۳] از دیگر مسئولیت‌های دواپس خودکار سازی فرآیند‌های تحویل نرم‌افزار می‌باشد. در سوی دیگر اما تحویل پیوسته، رویکردی برای خودکار کردن تحویل، گرد‌آوری پروسه‌های مختلف و اجرای سریعتر و مکرر آنها می‌باشد. بنابر آنچه بیان شد: دواپس محصور تحویل پیوسته است و تحویل پیوسته (CD) مستقیم به دواپس منتقل می‌شود.[۴]
ارتباط با استقرار پیوسته
[ویرایش]تحویل مداوم ، توانایی ارائه نرم افزاری است که می تواند در هر زمان از طریق انتشار دستی به کار گرفته شود. این در تضاد با استقرار پیوسته است که از گسترش خودکار استفاده می کند.[۵] به گفته مارتین فاولر ، استقرار مداوم به تحویل مداوم نیاز دارد.[۶] ادبیات دانشگاهی بین دو روش با توجه به روش استقرار تفاوت قائل می شود. دستی در مقابل خودکار.[۷]
خط لوله استقرار
[ویرایش]تحویل پیوسته به وسیله خط لوله‌ها فعال و پیاده می‌شود. خط لوله‌ها سه هدف دارند: قابل مشاهده بودن، بازخورد، استقرار پیوسته.[۸]
قابل مشاهده بودن: تمام مراحل استقرار از جمله ساخت، استقرار، تست و انتشار به منظور همکاری، برای اعضای تیم قابل مشاهده است.
بازخورد: اعضای تیم به محض اتفاق افتادن خطا آنها را مطالعه می‌کنند و تلاش می‌کنند که هرچه سریعتر مشکل را حل کنند.
استقرار پیوسته: با استفاده از یک فرايند کاملا خودکار، هر نسخه از محصول در هر محیط به صورت خودکار نصب شود.
انواع ابزارها
[ویرایش]در تحویل پیوسته، انتقال کد و استقرار آن در محیط عملیاتی به صورت خودکار انجام می‌شود. [۹]به وسیله این ابزارها میتوان خط لوله مناسب برای استقرار را ایجاد کرد. انواع ابزار‌هایی که قسمت‌های مختلف این عملیات را انجام می‌دهند عبارت‌اند از: یکپارچه‌سازی مداوم، خودکارسازی انتشار برنامه، مدیریت چرخه عملکرد برنامه.[۱۰]
جنکینز یکی از ابزار‌های پرکاربرد برای ایجاد خط لوله‌های تحویل پیوسته است.
اصول
[ویرایش]
تحویل مداوم ، مفهوم رایج خط لوله استقرار را به عنوان پیشگیری از خطای سهوی و ناب در نظر می گیرد:[۱۱] مجموعه‌ای از اعتبارسنجی‌ها که یک نرم‌افزار در مسیر عرضه‌اش باید سپری کند. کد درصورت نیاز باید کامپایل شود و پس از آن هر دفعه که تغییری در مخزن ثبت ثبت می‌شود توسط سرور ساخت (build) بسته‌بندی شود. در مرحله آخر نیز این کد باید توسط تکنیک‌های متنوع تست شود تا از آمادگی آن برای عرضه اطمینان حاصل شود.
توسعه دهندگان که به یک دوره چرخه طولانی عادت کرده اند ممکن است هنگام کار در محیط CD نیاز به تغییر طرز فکر خود داشته باشند. در این راهکار مهم است که بدانیم هر قطعه کدی که در مخزن ثبت می‌شود ممکن است هر لحظه به کاربران عرضه شود. الگوهایی مانند ضامن ویژگی ها می توانند برای انجام زودهنگام کد که هنوز برای استفاده توسط کاربران نهایی آماده نیست ، بسیار مفید باشند.
مزایا و موانع
[ویرایش]برخی از مزایای تحویل پیوسته:
- شتاب بیشتر در زمان ورود به بازار: تحویل پیوسته به شما این امکان را می دهد که ارزش تجاری ذاتی نسخه های نرم افزاری جدید را با سرعت بیشتری به مشتریان تحویل بدهید. این قابلیت به شرکت کمک می کند تا یک گام جلوتر از رقابت باقی بمانید.
- ساخت محصول مناسب: انتشارهای مکرر باعث می شود تیم‌های توسعه‌دهنده برنامه با سرعت بیشتری نظرات کاربران را بدست آورند. این به آنها اجازه می‌دهد فقط روی ویژگی‌های مفید کار کنند. اگر آنها دریابند که یک ویژگی مفید نیست، دیگر هیچ تلاشی برای آن نمی کنند. این به آنها کمک می کند تا محصول مناسب‌تری را بسازند.
- بهبود در بهره‌وری و کارایی: صرفه‌جویی قابل توجهی در زمان برای توسعه دهندگان، آزمایشگران، مهندسان عملیات و غیره از طریق اتوماسیون به همراه دارد.
- انتشارهای مطمئن: خطرات مرتبط با انتشار به‌اندازه قابل‌توجهی کاهش یافته و روند انتشار قابل اعتمادتر می‌شود. با استفاده از تحویل پیوسته، مراحل استقرار و اسکریپت‌ها قبل از استقرار در هنگام تولید به طور مکرر آزمایش می‌شوند. بنابراین، بیشتر خطاها در روند استقرار و اسکریپت‌ها قبلاً کشف شده است. با انتشارهای بیشتر، تعداد تغییرات کد در هر نسخه کاهش می‌یابد. با این کار یافتن و برطرف کردن هر مشکلی که رخ دهد آسان تر می‌شود و از زمان تأثیر آنها می کاهد.
- بهبود کیفیت محصول: تعداد اشکالات باز و حوادث در محیط عملیاتی به طور قابل توجهی کاهش می‌یابد.
- بهبود رضایت مشتری: سطح بالاتری از رضایت مشتری حاصل می شود.
برخی از موانع تحویل پیوسته:
- خواسته‌های مشتری: برخی از مشتریان نمی خواهند سیستم هایشان به طور مداوم به روز شود. این امر به ویژه در مراحل حساس عملیات آنها بیشتر صدق می کند.
- محدودیت دامنه: در برخی از حوزه ها، مانند مخابرات و پزشکی، مقررات آزمایش‌های گسترده قبل از اجازه ورود به فاز عملیات نصب نسخه‌های جدید وجود دارد.
- عدم وجود تست خودکار: عدم خودکارسازی آزمون منجر به عدم اعتماد به نفس توسعه دهنده می‌شود و می تواند از تحویل پیوسته جلوگیری کند.
- تفاوت در محیط‌ها: محیط‌های مختلفی که در توسعه، آزمایش و تولید مورد استفاده قرار می‌گیرند که می‌توانند منجر به رخداد مسائل شناسایی نشده در محیط عملیاتی شوند.
- تست‌هایی که نیاز عملیات انسانی دارند: همه‌ی ویژگی‌های کیفیت به صورت خودکار قابل تأیید نیستند. این ویژگی‌ها نیاز به انسان دارند و باعث کند شدن خط لوله انتقال می شوند.
هشت چالش بیشتر برای تطابق توسط چن مطرح و شرح داده شد.[۱۲] این چالش ها در زمینه ساختار سازمانی، فرایندها، ابزارها، زیرساخت‌ها، سیستم‌های قدیمی، معماری تحویل پیوسته، آزمایش مداوم نیازمندی‌های غیر عملکردی و بهینه سازی اجرای آزمون است.
جستارهای وابسته
[ویرایش]منابع
[ویرایش]- ↑ امید شریعتی. «Continuous Delivery چیست». http://hidevops.com. پیوند خارجی در
|وبگاه=وجود دارد (کمک) - ↑ Hammond, Jeffrey (9 September 2011). "The Relationship between DevOps and Continuous Delivery". Forrester Research. Forester.
- ↑ 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.
- ↑ Swartout, Paul (2012). Continuous Delivery and DevOps: A Quickstart guide. Packt Publishing. ISBN 978-1849693684.
- ↑ 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. Retrieved 2015-10-29.
- ↑ 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). pp. 111–120. doi:10.1109/ESEM.2017.18. ISBN 978-1-5090-4039-1.
- ↑ Felden, Timm (2015-03). "Improving lava flow based software development". 2015 IEEE 2nd International Workshop on Patterns Promotion and Anti-patterns Prevention (PPAP). IEEE. doi:10.1109/ppap.2015.7076849. ISBN 978-1-4673-6920-6.
{{cite journal}}: Check date values in:|date=(help) - ↑ Soni, Mitesh (2015-11). "End to End Automation on Cloud with Build Pipeline: The Case for DevOps in Insurance Industry, Continuous Integration, Continuous Testing, and Continuous Delivery". 2015 IEEE International Conference on Cloud Computing in Emerging Markets (CCEM). IEEE. doi:10.1109/ccem.2015.29. ISBN 978-1-4673-8566-4.
{{cite journal}}: Check date values in:|date=(help) - ↑ Binstock, Andrew (16 September 2014). "Continuous Delivery: The Agile SUccessor". Dr. Dobb's the World of Software Development. San Francisco: UBM.
- ↑ Humble, J.; Read, C.; North, D. (2006). "The Deployment Production Line". Agile 2006 (Agile'06). pp. 113–118. doi:10.1109/AGILE.2006.53. ISBN 0-7695-2562-8.
- ↑ Chen, Lianping (2017-06). "Continuous Delivery: Overcoming adoption challenges". Journal of Systems and Software (به انگلیسی). 128: 72–86. doi:10.1016/j.jss.2017.02.013.
{{cite journal}}: Check date values in:|date=(help)