آشنایی با Continuous Delivery

1- مقدمه و کاربرد

تحویل مداوم یک روش توسعه نرم افزار است که در آن تغییرات کد به طور خودکار برای عرضه به تولید آماده می شود. یکی از ستون‌های توسعه برنامه‌های کاربردی مدرن، تحویل مستمر پس از یکپارچگی مداوم با استقرار همه تغییرات کد در یک محیط آزمایش و/یا یک محیط تولید پس از مرحله ساخت، گسترش می‌یابد. زمانی که توسعه دهندگان به درستی پیاده سازی شوند، همیشه یک مصنوع ساخت آماده برای استقرار خواهند داشت که از یک فرآیند تست استاندارد عبور کرده است.
تحویل مستمر به توسعه‌دهندگان امکان می‌دهد تست‌های فراتر از تست‌های واحد را به‌طور خودکار انجام دهند تا بتوانند به‌روزرسانی‌های برنامه را در ابعاد مختلف قبل از استقرار برای مشتریان تأیید کنند. این تست‌ها ممکن است شامل تست UI، تست بارگذاری، تست یکپارچه‌سازی، تست قابلیت اطمینان API و غیره باشد. این به توسعه‌دهندگان کمک می‌کند تا به‌روزرسانی‌ها را به‌طور کامل اعتبارسنجی کنند و پیشگیرانه مشکلات را کشف کنند. با استفاده از فضای ابری، خودکارسازی ایجاد و تکثیر چندین محیط برای آزمایش، که قبلاً انجام آن در محل دشوار بود، آسان و مقرون به صرفه است.
تحویل مستمر در مقابل استقرار مستمر
با تحویل مداوم، هر تغییر کد ساخته می‌شود، آزمایش می‌شود و سپس به یک محیط آزمایش یا مرحله‌بندی غیرتولیدی هدایت می‌شود. ممکن است چندین مرحله آزمایش موازی قبل از استقرار تولید وجود داشته باشد. تفاوت بین تحویل مداوم و استقرار مداوم وجود تأییدیه دستی برای به روز رسانی به تولید است. با استقرار مداوم، تولید به طور خودکار و بدون تأیید صریح اتفاق می افتد.

تحویل مداوم کل فرآیند انتشار نرم افزار را خودکار می کند. هر تجدیدنظری که انجام می شود یک جریان خودکار را راه اندازی می کند که به روز رسانی را ایجاد، آزمایش و سپس مرحله بندی می کند. تصمیم نهایی برای استقرار در یک محیط تولید زنده توسط توسعه دهنده انجام می شود.

مزایا

1- انتشار کم خطر: هدف اولیه از تحویل مداوم این است که پیاده‌سازی نرم‌افزار را بدون دردسر و رویدادهای کم خطری که می‌توان در هر زمان و بنا به درخواست انجام داد، انجام داد. با بکارگیری الگوهایی مانند استقرارهای سبز-آبی، دستیابی به استقرارهای زمان توقف صفر که برای کاربران غیرقابل شناسایی هستند، نسبتاً ساده است.

2- زمان سریعتر: برای بازاریابی غیرمعمول نیست که مرحله ادغام و آزمایش/تثبیت چرخه عمر مرحله ای سنتی تحویل نرم افزار هفته ها یا حتی ماه ها طول بکشد. هنگامی که تیم ها برای خودکارسازی ساخت و استقرار، تهیه محیط و فرآیندهای تست رگرسیون با هم کار می کنند، توسعه دهندگان می توانند تست یکپارچه سازی و رگرسیون را در کار روزانه خود بگنجانند و این مراحل را به طور کامل حذف کنند. ما همچنین از حجم زیاد دوباره کاری که رویکرد مرحله‌ای را آزار می‌دهد اجتناب می‌کنیم.

3- کیفیت بالاتر: وقتی توسعه‌دهندگان ابزارهای خودکاری دارند که در عرض چند دقیقه رگرسیون‌ها را کشف می‌کنند، تیم‌ها آزاد می‌شوند تا تلاش خود را بر روی تحقیقات کاربر و فعالیت‌های تست سطح بالاتر مانند تست اکتشافی، تست قابلیت استفاده، و تست عملکرد و امنیت متمرکز کنند. با ساخت یک خط لوله استقرار، این فعالیت ها می توانند به طور مداوم در طول فرآیند تحویل انجام شوند و اطمینان حاصل شود که از ابتدا کیفیت در محصولات و خدمات تعبیه شده است.

4- هزینه های پایین تر: هر محصول یا خدمات نرم افزاری موفقی در طول عمر خود به طور قابل توجهی تکامل می یابد. با سرمایه‌گذاری در ساخت، آزمایش، استقرار و اتوماسیون محیطی، ما با حذف بسیاری از هزینه‌های ثابت مرتبط با فرآیند انتشار، هزینه ایجاد و ارائه تغییرات تدریجی در نرم‌افزار را به‌طور قابل ملاحظه‌ای کاهش می‌دهیم.

5- محصولات بهتر: تحویل مداوم کار را در دسته های کوچک اقتصادی می کند. این بدان معنی است که ما می توانیم در طول چرخه عمر تحویل بر اساس نرم افزار کار از کاربران بازخورد دریافت کنیم. تکنیک‌هایی مانند تست A/B ما را قادر می‌سازد تا رویکردی مبتنی بر فرضیه برای توسعه محصول داشته باشیم که به موجب آن می‌توانیم ایده‌ها را با کاربران قبل از ایجاد ویژگی‌های کامل آزمایش کنیم. این بدان معناست که می‌توانیم از 2/3 ویژگی‌هایی که می‌سازیم که ارزش صفر یا منفی را به کسب‌وکارمان ارائه می‌کنند، اجتناب کنیم.

6- تیم های شادتر: تحقیقات بررسی شده نشان داده است که تحویل مداوم باعث کاهش درد و کاهش فرسودگی تیم می شود. علاوه بر این، هنگامی که ما به دفعات بیشتری منتشر می کنیم، تیم های تحویل نرم افزار می توانند فعالانه تر با کاربران درگیر شوند، یاد بگیرند که کدام ایده ها کار می کنند و کدام نه، و نتایج کاری را که انجام داده اند، از نزدیک ببینند. با حذف فعالیت‌های دردناک کم‌ارزش مرتبط با تحویل نرم‌افزار، می‌توانیم روی چیزی که بیشتر به آن اهمیت می‌دهیم تمرکز کنیم - به طور مداوم کاربران خود را خوشحال کنیم.

ارتباط با DevOps
تحویل مداوم و DevOps از نظر معانی مشابه هستند و اغلب با هم ترکیب می شوند، اما آنها دو مفهوم متفاوت هستند. DevOps دامنه وسیع تری دارد و حول محور تغییرات فرهنگی، به ویژه همکاری تیم های مختلف درگیر در تحویل نرم افزار (توسعه دهندگان، عملیات، تضمین کیفیت، مدیریت، و غیره)، و همچنین خودکارسازی فرآیندها در تحویل نرم افزار متمرکز است. از سوی دیگر، تحویل مستمر رویکردی برای خودکارسازی جنبه تحویل است و بر گردآوری فرآیندهای مختلف و اجرای سریعتر و مکرر آنها تمرکز دارد. بنابراین، DevOps می تواند محصول تحویل مداوم باشد و CD مستقیماً به DevOps جریان می یابد.

خط لوله استقرار
تحویل مداوم از طریق خط لوله استقرار فعال می شود. هدف خط لوله استقرار دارای سه جزء است: دید، بازخورد، و استقرار مداوم.
قابلیت مشاهده - تمام جنبه های سیستم تحویل از جمله ساخت، استقرار، آزمایش و انتشار برای همه اعضای تیم برای ارتقای همکاری قابل مشاهده است.
بازخورد - اعضای تیم در صورت بروز مشکلات در اسرع وقت از آنها مطلع می شوند تا بتوانند در اسرع وقت آنها را برطرف کنند.
استقرار مداوم - از طریق یک فرآیند کاملاً خودکار، می توانید هر نسخه از نرم افزار را در هر محیطی استقرار و منتشر کنید.
ابزار/انواع ابزار
تحویل مداوم، اتوماسیون را از کنترل منبع تا پایان تولید می‌گیرد. ابزارهای مختلفی وجود دارد که به انجام تمام یا بخشی از این فرآیند کمک می کند. این ابزارها بخشی از خط لوله استقرار هستند که شامل تحویل مداوم است. انواع ابزارهایی که بخش‌های مختلف فرآیند را اجرا می‌کنند عبارتند از: یکپارچه‌سازی مداوم، اتوماسیون انتشار برنامه، اتوماسیون ساخت، مدیریت چرخه عمر برنامه.
معماری برای تحویل مداوم
برای اجرای مؤثر تحویل مستمر، برنامه‌های نرم‌افزاری باید مجموعه‌ای از الزامات مهم معماری (ASR) مانند قابلیت استقرار، تغییرپذیری و آزمایش‌پذیری را برآورده کنند. این ASR ها نیاز به اولویت بالایی دارند و نمی توان آنها را به راحتی معامله کرد.
میکروسرویس ها اغلب هنگام معماری برای تحویل مداوم استفاده می شوند. استفاده از Microservices می تواند قابلیت استقرار و تغییرپذیری یک سیستم نرم افزاری را افزایش دهد. پیشرفت‌های قابل استقرار مشاهده‌شده عبارتند از: استقلال استقرار، زمان استقرار کوتاه‌تر، روش‌های استقرار ساده‌تر، و استقرار زمان توقف صفر. پیشرفت‌های قابل تغییر مشاهده‌شده عبارتند از: زمان چرخه کوتاه‌تر برای تغییرات عملکردی افزایشی کوچک، تغییرات آسان‌تر در انتخاب فناوری، تغییرات ویژگی کیفیت افزایشی، و ارتقای زبان و کتابخانه آسان‌تر.

محدودیت‌ها

1- ترجیحات مشتری: برخی از مشتریان به روز رسانی مداوم سیستم های خود را نمی خواهند. این امر به ویژه در مراحل بحرانی عملیات آنها صادق است.
2- محدودیت‌های دامنه: در برخی حوزه‌ها، مانند مخابرات و پزشکی، مقررات نیاز به آزمایش گسترده قبل از ورود نسخه‌های جدید به فاز عملیاتی دارند.
3- عدم اتوماسیون تست: عدم اتوماسیون تست منجر به عدم اطمینان توسعه دهنده می شود و می تواند از استفاده مداوم از تحویل جلوگیری کند.
4- تفاوت در محیط ها: محیط های مختلف مورد استفاده در توسعه، آزمایش و تولید می تواند منجر به لغزش مسائل ناشناخته به محیط تولید شود.
5- آزمایش‌هایی که به اوراکل انسانی نیاز دارند: همه ویژگی‌های کیفیت را نمی‌توان با اتوماسیون تأیید کرد. این ویژگی‌ها به انسان‌ها در حلقه نیاز دارند و خط لوله تحویل را کاهش می‌دهند.

تضمین تحویل مستمر
از همان ابزارهایی که CI/CD را خودکار می کنند، می توان برای خودکارسازی امنیت نیز استفاده کرد. کالین کمپبل، مدیر الگوها و شیوه‌ها در Chef، این داستان را نقل می‌کند: «یک سازمان مالی بزرگ بلافاصله مزایای استفاده از پلتفرم اتوماسیون سرآشپز را زمانی که Shellshock در سال 2014 وارد شد، دید. این شرکت 2200 سرور را به Chef منتقل کرده بود و آن 2200 سرور را برد. 10 دقیقه برای گزارش آسیب‌پذیری و خود پچ کردن. 66000 سرور این شرکت که به آشپز منتقل نکرده بودند؟ هشت ساعت برای شناسایی آسیب‌پذیری، پنج روز برای وصله تمام سرورها و یک تیم ۱۸ نفره برای حل این مشکل طول کشید.»

خط لوله CI/CD
خط لوله CI/CD مجموعه ای از مراحل است که به منظور ارائه نسخه جدیدی از نرم افزار انجام می شود. وقتی CI/CD را در عمل پیاده کردید، یک خط لوله CI/CD ایجاد کرده اید.
خط لوله CI/CD، نظارت و اتوماسیون را برای بهبود گردش کار توسعه برنامه، به ویژه در مراحل یکپارچه سازی و آزمایش، و همچنین در حین تحویل و استقرار معرفی می کند.
اگرچه امکان اجرای دستی هر یک از مراحل یک خط لوله CI/CD وجود دارد، اما ارزش واقعی خطوط لوله CI/CD از طریق اتوماسیون چرخه عمر برنامه محقق می شود.

2- ابزارهای مرتبط

1- ابزار Buddy

ابزار Buddy یک ابزار هوشمند CI/CD برای توسعه دهندگان وب است که برای کاهش آستانه ورود به DevOps طراحی شده است. از خطوط لوله تحویل برای ساخت، آزمایش و استقرار نرم افزار استفاده می کند. خطوط لوله با بیش از 100 اقدام آماده برای استفاده ایجاد شده اند که می توان آنها را به هر شکلی مرتب کرد - درست مانند ساختن خانه ای از آجر.
پیکربندی 15 دقیقه‌ای در UI/UX واضح و گویا
استقرار سریع رعد و برق بر اساس تغییرات
بیلدها در کانتینرهای ایزوله با وابستگی های کش اجرا می شوند
از همه زبان‌ها، فریم‌ورک‌ها و مدیران وظیفه پشتیبانی می‌کند
فهرست اختصاصی اقدامات Docker/Kubernetes
با AWS، Google، DigitalOcean، Azure، Shopify، WordPress و موارد دیگر ادغام می شود
از موازی سازی و پیکربندی YAML پشتیبانی می کند

2- ابزار JBoss

ابزار JBOSS متعلق به Red Hat یک سرور برنامه وب است که به طور کامل به منظور میزبانی برنامه های مبتنی بر JAVA (برنامه های توسعه یافته با استفاده از پلت فرم Java EE) یکپارچه شده است.
این شامل سرور HTTP آپاچی، موتورهای سرولت، متعادل کننده بار و کتابخانه بومی آپاچی تامکت است. JBOSS قابلیت اجرا بر روی چندین پلتفرم را دارد.

3- ابزار TOMCAT

آپاچی TOMCAT که به آن سرور تامکت نیز گفته می شود توسط ASF (بنیاد نرم افزار آپاچی) توسعه یافته است. این شامل ادغام مشخصات مختلف جاوا مانند Java Servlet، Java EE، Java EL، سوکت وب، صفحات سرور، عبارات جاوا و غیره است که یک محیط خالص برای اجرای کد جاوا ایجاد می کند.
وب سرور Tomcat از برنامه های متعدد در چندین پلتفرم پشتیبانی می کند و تحت مجوز Apache 2.0 منتشر شده است.

3- شرکت‌های فعال در این زمینه

1- ابراروان

مسئله‌ی Delivery & Deployment مستمر

با اتصال Source Code Managementهایی چون Git Lab به سکوی ابری آروان، با هر تغییر در کد اصلی به‌شکل خودکار تغییرات در خروجی نهایی محصول اعمال می‌شود.

2- لیارا

همه ما با دغدغه‌ها و مسائل مربوط به مدیریت سرور آشنا هستیم، هدف لیارا با ارائه خدمات ابری PaaS یا Platform as a Service و DBaaS یا DataBase as a Service ایجاد زیرساختی مناسب است تا توسعه‌دهندگان و استارتاپ‌های ایرانی به راحتی و در کمترین زمان، بتوانند محصول خود را به بازار عرضه کنند.

جمع‌بندی

ادغام مستمر و تحویل مستمر یک سناریوی ایده آل برای تیم های برنامه سازمان شما فراهم می کند. توسعه دهندگان شما به سادگی کد را به یک مخزن فشار می دهند. این کد یکپارچه می شود، آزمایش می شود، مستقر می شود، دوباره آزمایش می شود، با زیرساخت ادغام می شود، بررسی های امنیتی و کیفیت را طی می کند و با اطمینان بسیار بالا آماده استقرار می شود.
وقتی از CI/CD استفاده می‌شود، کیفیت کد بهبود می‌یابد و به‌روزرسانی‌های نرم‌افزار به سرعت و با اطمینان بالا ارائه می‌شوند که هیچ تغییری ایجاد نمی‌کند. تأثیر هر انتشار می تواند با داده های تولید و عملیات مرتبط باشد. می‌توان از آن برای برنامه‌ریزی چرخه بعدی نیز استفاده کرد - یک تمرین حیاتی DevOps در تحول ابری سازمان شما.

منابع

1- https://aws.amazon.com/devops/continuous-delivery/

2- https://en.wikipedia.org/wiki/Continuous_delivery

3- https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment

4- https://www.synopsys.com/glossary/what-is-continuous-delivery.html

5- https://www.redhat.com/en/topics/devops/what-is-continuous-delivery

6-https://www.softwaretestinghelp.com/best-continuous-delivery-tools/

7- https://www.arvancloud.com/fa/products/paas

8- https://liara.ir/

«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»