آشنایی با مفهوم تحویل مداوم (Continuous Delivery)

مفهوم تحویل مستمر از جمله مفاهیمی در حوزه دوآپس و مهندسی نرم‌افزار است که مکررا شنیده می‌شود. البته تحویل مستمر بیشتر در کنار ادغام مستمر به صورت CI/CD به کار برده می‌شود. در این مقاله قصد داریم به بررسی مفهوم تحویل مداوم بپردازیم، مزایای آن را ذکر کنیم و بگوییم چرا در سازمان یا شرکتمان به آن نیاز داریم. تحویل مداوم چیست؟ اگرچه تعاریف متعددی برای CD در اینترنت موجود است، اما این تعاریف تقریبا بیان مشترکی دارند. یکی از این تعاریف چنین است.تحویل مداوم (CD) به عنوان توانایی ارائه به‌روزرسانی‌های محصول به مشتریان در سریع‌ترین زمان ممکن و مکرر تعریف می‌شود. چه این به‌روزرسانی‌ها شامل رفع اشکال ساده، عملکرد بهبودیافته یا یک رابط جدید طراحی شده باشد، CD فرآیند و پروتکل‌هایی را برای ارسال سریع کد در کوتاه‌ترین زمان ممکن تعریف می‌کند.تحویل مستمر چه هنگامی به وجود آمد؟ هنگامی که توسعه نرم افزار برای اولین بار به عنوان یک زمینه ظهور کرد، بسیاری از تیم ها برای چرخه عمر توسعه نرم افزار خود (SDLC) به روش آبشاری تکیه کردند. توسعه‌ی آبشاری به مرور زمان و توسعه صنعت نرم‌افزار دیگر پاسخگو نبود و در دهه 90 به لطف شیوه‌های توسعه چابک نرم‌افزار تغییر کرد، که به تیم‌ها قدرت می‌داد تا به جای توسعه یک محصول کامل، محصول را کم کم توسعه بدهند و به تکامل برسانند :))با داشتن توانایی ایجاد تغییرات در سطوح مختلف، چارچوب های جدید مبتنی بر اصول چابک به سرعت برای بسیاری از تیم ها عادی شد. این چارچوب‌ها شامل رویکردهایی مانند تحویل مداوم، DevOps و استقرار مستمر بودند که از آن زمان بسیار مورد استفاده قرار گرفته‌اند. بنابراین استارت بحث تحویل مداوم را می‌توانیم از دهه 90 میلادی و توسعه‌ی روش‌های چابک بدانیم. تحویل مستمر چه ارتباطی با دواپس دارد؟ برای اینکه بفهمیم دوآپس چیست بگذارید اشاره‌ای به تعریف آن داشته باشیم. دواپس ترکیبی از فلسفه‌ها، شیوه‌ها و ابزارهای فرهنگی است که توانایی سازمان را برای ارائه برنامه‌ها و خدمات با سرعت بالا افزایش می‌دهد. توسعه و بهبود محصولات با سرعتی سریع‌تر از سازمان‌هایی که از فرآیندهای توسعه نرم‌افزار سنتی و مدیریت زیرساخت استفاده می‌کنند، با فرهنگ دواپس انجام می‌شود. این سرعت سازمان ها را قادر می سازد تا به مشتریان خود خدمات بهتری ارائه دهند و به طور موثرتری در بازار رقابت کنند.اگر DevOps فرهنگی است به دنبال تسریع در ارائه خدمات جدید و با کیفیت است، مطمئناً تحویل مداوم همان چیز است، اینطور نیست؟ اگر به توسعه‌ی نرم‌افزار به عنوان یک خط تولید تولید نگاه کنیم، DevOps ماشینی است که محصول را ایجاد می کند، در حالی که تحویل مداوم تسمه نقاله‌ای است که محصول را از خط تولید خارج می کند.گارتنر تمایز بین DevOps و تحویل مستمر را با بیان می‌کند: "DevOps یک بازار و شیوه تجاری نیست، بلکه یک فلسفه ابزار محور است که از زنجیره تحویل مداوم پشتیبانی می کند." این تحلیلگر استدلال می کند که استراتژی های کسب و کار دیجیتال تقاضا برای بهبود سرعت و اثربخشی تحویل نرم‌افزار را تحریک می کند.بنابراین می‌توان تحویل مداوم را بخشی از فرهنگ دواپس نامید. تحویل مداوم و DevOps ویژگی‌های مشترکی دارند. هدف هر دو روش تفکر چابک و ناب است: هر کدام تغییرات کوچک و سریعی را ارائه می دهند. با این حال، هدف DevOps ادغام نقش های توسعه دهنده و عملیاتی با یکدیگر - و فرآیندهایی که آنها مدیریت می کنند - برای دستیابی به اهداف تجاری است. همه چیز در مورد یک فرهنگ مشترک، مشترک و همکاری پیشرفته است. در مورد فرآیندهای تجاری به وضوح تعریف شده است.ارتباط تحویل مداوم با ادغام مداوم و استقرار مداوموقت آن رسیده تا مفهوم CI/CD را بیان کنیم :)) CI و CD دو نام اختصاری هستند که اغلب در شیوه های توسعه مدرن و DevOps استفاده می شوند. CI مخفف یکپارچه‌سازی مداوم است، یکی از best practiceهای اساسی DevOps که در آن توسعه دهندگان اغلب تغییرات کد را در یک ریپازیتوری اصلی که در آن ساخت و آزمایش های خودکار اجرا می شود، ادغام می کنند. اما CD می تواند به معنای تحویل مداوم یا استقرار مداوم باشد. ابتدا بهتر است هر مفهموم را تعریف کنیم و سپس مقایسه را انجام دهیم. ادغام مداوم:‌در توسعه اپلیکیشن‌های مدرن، هدف این است که چندین توسعه‌دهنده به طور همزمان روی ویژگی‌های مختلف یک برنامه کار کنند. با این حال، اگر بخواهیم همه‌ی شاخه‌ها را در یک روز باهم ادغام کنیم این کار هم زمانبر می‌تواند باشد و هم خطرناک. این به این دلیل است که وقتی توسعه‌دهنده‌ای که به صورت مجزا کار می‌کند، تغییری در یک برنامه ایجاد می‌کند، این احتمال وجود دارد که با تغییرات مختلفی که به‌طور همزمان توسط توسعه‌دهندگان دیگر ایجاد می‌شوند، تضاد داشته باشد. اگر هر توسعه دهنده محیط توسعه یکپارچه محلی (IDE) خود را سفارشی کرده باشد، این مشکل می تواند بیشتر شود، به جای اینکه تیم بر روی یک IDE مبتنی بر ابر توافق کند.یکپارچه‌سازی پیوسته (CI) به توسعه‌دهندگان کمک می‌کند تا تغییرات کد خود را به یک "Trunk" بیشتر ادغام کنند - گاهی اوقات حتی روزانه. هنگامی که تغییرات یک برنامه‌نویس در یک برنامه ادغام می‌شوند، این تغییرات با ساخت خودکار برنامه و اجرای سطوح مختلف آزمایش خودکار، معمولاً تست‌های واحد و یکپارچه‌سازی، تأیید می‌شوند تا اطمینان حاصل شود که تغییرات برنامه را خراب نکرده است. این به معنای آزمایش همه چیز از کلاس ها و عملکردها گرفته تا ماژول های مختلف است که کل برنامه را تشکیل می دهند. اگر آزمایش خودکار مشکلی بین کد جدید و کد موجود را کشف کند، CI رفع سریع و مکرر آن اشکالات را آسان‌تر می‌کند.استقرار مستمراستقرار مستمر یک گام فراتر از تحویل مداوم (CI) است. با این عمل، هر تغییری که تمام مراحل خط لوله تولید شما را پشت سر بگذارد برای مشتریان شما منتشر می شود. هیچ دخالت انسانی وجود ندارد، و تنها یک آزمایش ناموفق مانع از اعمال تغییرات جدید در تولید می شود. استقرار مستمر یک راه برای تسریع حلقه بازخورد با مشتریان و کاهش فشار از تیم است زیرا دیگر روز انتشار وجود ندارد. توسعه‌دهندگان می‌توانند بر روی ساختن نرم‌افزار تمرکز کنند و چند دقیقه پس از پایان کار بر روی آن، کار خود را زنده می‌بینند.تصویر زیر مقایسه تحویل مداوم و استقرار مداوم را نشان می‌دهد. مقایسه تحویل مداوم با استقرار مداومبه بیان ساده، ادغام مداوم بخشی از تحویل مداوم و استقرار مداوم است. و استقرار مداوم مانند تحویل مداوم است، با این تفاوت که انتشار در استقرار مداوم به طور خودکار اتفاق می افتد. تحویل مداوم برای ما چه مزایایی دارد؟ بسیاری از مقالات مزایای CD را در کنار CIبررسی کرده‌اند تا مزایای آن برای همگان بسیار ملموس شود. برای راحتی در کار نیز ما هم همین کار را می‌کنیم :))زمان سریعتر برای بازارمزیت مهم تجاری یکپارچه سازی مداوم و تحویل مستمر، سرعت بخشیدن به کل فرآیند توسعه با توسعه دهندگان فین‌تک است. اگر مجبور به راه اندازی یک برنامه فین‌تک در مدت زمان کوتاهی هستید، CI/CD مناسب خواهد بود. به گفته مک کینزی، با CI/CD، شرکت ها می توانند کد را به جای 89 روز به طور متوسط ​​در 15 روز به انتشار برسانند.انعطاف پذیری و پاسخگوییواقعیت این است که CI/CD نه تنها به صورت هفتگی، بلکه حتی روزانه اجازه انتشار نرم افزار را می دهد. تحویل مداوم در فین‌تک به‌روزرسانی برنامه‌ها را سریع‌تر می‌کند. و این باعث می شود که معرفی ویژگی‌های جدید آسان‌تر شود. مهمتر از آن، با CI/CD، توسعه دهندگان می توانند مشکلات را به سرعت برطرف کنند. در صورت عدم موفقیت برنامه، توسعه دستی سنتی گزینه ای برای یک شرکت فین‌تک نیست. واضح است که وقتی یک برنامه نیاز به یک اصلاح اساسی دارد، تاخیر در صنعت مالی قابل قبول نیست. راه حل در پیاده سازی خط لوله CI/CD نهفته است که امکان تحویل سریع نرم افزار را فراهم می کند. این عمل به شرکت‌های فین‌تک کمک می‌کند تا انعطاف‌پذیر و پاسخ‌گو باشند، یعنی مشتریان راضی‌تر.بهره‌وری بیشترپیاده سازی CI/CD به تیم توسعه اجازه می دهد تا بهره‌وری بیشتری داشته باشند. CI/CD در فین‌تک کار مجدد و زمان انتظار را حذف می‌کند. به لطف اتوماسیون فرآیندهای معمول، توسعه دهندگان نرم افزار می توانند روی سایر وظایف مهم تر، مانند اطمینان از کیفیت و امنیت کد، تمرکز کنند.تلاش کمتری برای رساندن محصول به پروداکشن لازم است: همه چیز قبلا automate شده است :))فشار کمتر بر توسعه دهنده: زیرا تغییرات کوچکتر هست و پس از اعمال تغییرات سریع مشکلات و منبع مشکلات شناسایی می‌شود. فاز‌های یک پایپلاین تحویل مداوماگر کد تغییر کند، خط لوله تحویل پیوسته راه اندازی می شود و فرآیند آزمایش اجرا می شود. اینها فازهایی هستند که خط لوله تحویل مداوم از آن عبور می کند:خط لوله تحویل مستمرمرحله کامیت: در این مرحله آزمایش اول، نسخه نرم افزار بررسی می شود، اجزای نرم افزار ساخته یا کامپایل می‌شوند و یونیت تست‌های لازم انجام می‌شود. پس از آزمایش موفقیت آمیز، مرحله تکمیل می شود. نتایج کامپایل که معمولا مخزن ذخیره می شوند. این بسته سپس عملکرد خط لوله را تعیین می کند زیرا وضعیت نرم افزار را تعیین می کند. در نهایت، بسته شامل مقدار داده ای است که بعداً روی سیستم هدف نصب می‌شود. مرحله آزمون قبولی (Acceptance Test): در مرحله آزمون دوم، آزمون‌های قبولی انجام می‌شود. این شامل تست های یکپارچه‌سازی (آیا تعامل اجزا کار می کند؟) و همچنین تست های سیستم لازم (آیا نرم افزار در سمت کاربر کار می کند؟). برخی از آزمون‌های اختیاری نیز وجود دارد که در مرحله آزمون پذیرش ادغام می‌شوند، مانند آزمون‌های عملکرد و سایر آزمون‌هایی که الزامات غیر کاربردی نرم‌افزار را بررسی می‌کنند. برای مرحله آزمون پذیرش، باندل ایجاد شده در مرحله قبل مجددا مورد استفاده قرار می گیرد و در محیط آزمون مناسب نصب می شود.هر گونه خطا یا عوارض در این مراحل مستند شده و در صورت لزوم به عنوان بازخورد برای توسعه دهنده ارسال می‌شود. از آنجا که خط لوله با هر تغییر کد فعال می شود، پیام های خطا یا رگرسیون همیشه به آخرین تغییر در اینجا اشاره می کنند. این به توسعه‌دهنده اجازه می‌دهد تا سریع و کارآمد واکنش نشان دهد و هر گونه باگ یا کد باگی را برطرف کند.در فاز بعدی آزمایشات دستی در صورت نیاز انجام می شود. برای این تست‌ها نیز خط لوله از فاز اول باندل استفاده می کند و آن را در محیط آزمایشی مناسب نصب می کند.اگر تمام تست ها با بازخورد مثبت کامل شوند، بسته را می توان به صورت دستی بر روی سیستم هدف نصب کرد. این معمولاً فقط به "فشردن یک دکمه" نیاز دارد. اگر این مرحله خودکار باشد، به آن استقرار پیوسته می گویند.چالش‌های موجود در تحویل مداومبا بزرگ‌تر شدن تیم‌ها و انجام وظایف بلندپروازانه‌تر، پیاده‌سازی CD - تحویل واقعی در تحویل مداوم - می‌تواند یک چالش باشد. تأخیرها به دلایل متعددی اتفاق می‌افتد و تیم‌های DevOps پیوسته در حال مبارزه برای حفظ پروژه‌ها در مسیر هستند. از مقیاس‌بندی خیلی سریع تا سازمان‌دهی ضعیف، در اینجا فقط چند مورد از رایج‌ترین چالش‌هایی که تیم‌ها با آن‌ها مواجه هستند، و همچنین تکنیک‌هایی که رهبران DevOps می‌توانند برای کاهش نقاط درد به کار ببرند، آورده شده است:ارتباط ضعیف بین تیم ها همانطور که تحویل مستمر به اجزای عملیاتی مختلف برای اطمینان از کد قابل اعتماد نیاز دارد، کسب و کار نیز برای موفقیت به همکاری بین تیم ها نیاز دارد. ارتباطات ضعیف بین تیم‌ها، چه محصول خاص و چه در کل کسب‌وکار، می‌تواند منجر به تجدید نظر و تأخیر قابل توجه در استقرار شود. تیم‌ها باید هم فرآیندهای عملیاتی و هم ابزارهای تولیدی خود را در سراسر سازمان خود ارزیابی کنند - و یک بار دیگر برنامه و نقشه راه مشترکی داشته باشند که قابل اعتماد و دقیق باشد. با ظهور مشکلات و تغییرات در پروژه، چه داخلی و چه در بازار، تیم های DevOps باید بتوانند به سرعت و شفاف در بخش های مربوطه پاسخ دهند.هزینه های زیرساختیتوسعه دهندگان موفق باید ابزارهای لازم را داشته باشند تا نه تنها از محصولات کسب و کار پشتیبانی کنند، بلکه از تیم های داخلی خود نیز پشتیبانی کنند. تیم هایی که با DevOps مقیاس بندی می شوند باید بودجه لازم را برای ایجاد زیرساخت های مورد نیاز برای تیم ها برای ساخت محصولات جاه طلبانه تر و جمع آوری مقادیر بیشتری از داده ها داشته باشند. تیم هایی که سعی می کنند خیلی سریع مقیاس شوند، اغلب در این تنگنا گرفتار می شوند و کیفیت محصول یا زیرساخت داخلی خود را قربانی می کنند. این به جای استقرار به تاخیرهای مداوم منجر می شود و اگر عاقلانه برخورد نشود، این موضوع می تواند گلوله برفی داشته باشد. تیم‌ها باید قبل از اینکه تلاش‌های CD خود را افزایش دهند، این را در نظر بگیرند: «این موضوع چگونه بر زیرساخت‌ها و فرآیندهایی که امروز در اختیار دارم تأثیر می‌گذارد؟» قبل از اجرای یک فرآیند جدید، مطمئن شوید که چگونه فرآیندهای گردش کار فعلی شما می تواند تحت تأثیر قرار گیرد. صرف زمان برای ادغام جریان های کاری مناسب، انتقال را هموارتر می کند و از متورم شدن این تنگنا به تاخیر جدی جلوگیری می کند.تست ضعیفیک تیم اختصاصی تست اتوماسیون موتور محصول را روشن نگه می‌دارد، اما در طول چرخه عمر به نظم و انضباط قوی نیاز دارد. اولاً، این مستلزم این است که همه به توافق برسند. رهبران DevOps باید مطمئن شوند که همه تیم‌ها در مورد فرآیندی که انتخاب می‌کنید، خواه این فرآیند توسعه رفتار محور یا چابک باشد، موافق باشند. و از همه مهمتر، فرآیندهای سایه CI را در گذشته رها کنید تا اطمینان حاصل شود که تیم ها به یک نمای واحد از کد محصول شما دسترسی دارند. در کل فرآیند تست باید جدی گرفته‌شود و تست‌ها پوشش لازم را داشته باشند. اتکای بیش از حد به اتوماسیوناتوماسیون ابزارهای DevOps می تواند ساعت های بی شماری را ذخیره کند و برنامه های CD را به موقع نگه دارد. با این حال، از آنجایی که مسئولیت‌های تیم شما تغییر می‌کند و وظایف جدید به وجود می‌آیند، خودکار کردن فرآیندها خیلی زود فقط به خاطر زمان آسان است. اتوماسیون یک فرآیند با طراحی ضعیف ممکن است در کوتاه مدت باعث صرفه جویی در زمان شود، اما دراز مدت می تواند به یک گلوگاه بزرگ تبدیل شود که رفع آن دشوار است. برای مبارزه با این، تیم‌ها باید قبل از خودکارسازی، گلوگاه‌های فرآیند را حل کنند. توسعه دهندگان باید به طور مداوم ممیزی پروتکل های خودکار خود را انجام دهند تا اطمینان حاصل کنند که آنها به طور مداوم دقیق هستند، در حالی که فرآیندهای فعلی را برای کارایی آزمایش می کنند.ابزار‌ها و تکنولوژی‌های متن‌بازابزار Jenkins: این ابزار یکی از معروف‌ترین (یا شاید بهتر باشد بگوییم معروف‌ترین) ابزار تحویل مدام است که با هر تغییر در متن برنامه، مراحل متعدد ساخت و ارزیابی کیفیت نرم‌افزار را اجرا می‌کند. به عبارت دیگر، Jenkins یک ابزار ایده‌آل برای ادغام و تحویل مداوم در فرآیند DevOps است. پنل جنکینزابزار fluxcd: Flux CD یک ابزار تحویل مداوم است که به سرعت در حال محبوبیت است. Weaveworks در ابتدا این پروژه را توسعه داد و آن را به صورت منبع باز در اختیار بنیاد Cloud Native Computing قرار داد. دلایل موفقیت آن این است که بسیار با کوبرنتیز ادغام شده است و راه اندازی آن ساده است. امیدوار کننده ترین ویژگی ارائه شده این است که به تیم ها اجازه می دهد تا استقرارهای Kubernetes خود را به صورت اعلامی مدیریت کنند. Flux CD مانیفست‌های Kubernetes ذخیره‌شده در مخزن کد منبع را با خوشه Kubernetes از طریق نظرسنجی دوره‌ای مخزن همگام‌سازی می‌کند، بنابراین تیم‌ها نیازی به نگرانی در مورد اجرای دستورات kubectl و نظارت بر محیط ندارند تا ببینند آیا بارهای کاری مناسب را مستقر کرده‌اند یا خیر. در عوض، Flux CD تضمین می کند که خوشه Kubernetes همیشه با پیکربندی تعریف شده در مخزن کد منبع همگام است.FluxCDابزار ArgoCD: ابزار Argo نیز دیگر ابزار مشهوری است که پیکربندی محیط ما را (نوشته شده به عنوان نمودار فرمان، شخصی سازی فایل ها، فایل های jsonnet یا یاml ساده) از مخزن git می خواند و آن را در فضای نام Kubernetes شما اعمال می کند. این ابزار بسیار با کوبرنتیز ادغام یافته و برای استقرار برنامه‌های cloud native مناسب است. ArgoCDابر آروان: ابر آروان نیز یکی از مشهورترین ارائه‌دهندگان خدمات ابری در ایران است که قابلیت تحویل مداوم را در سطح PaaS برای محصولات خود فعال کرده است. تحویل مداوم در سناریو فروشگاه ساده با مدل CD ابرآروانمنابع WhatIsContinuousDelivery(CD)?Definition,HistoryandBenefits(airfocus.com) DevOpsandContinuousDelivery:NottheSame-DevOps.com https://virgool.io/d/pvqltinyed0c/WhatisDevOps?-AmazonWebServices(AWS) Continuousintegrationvs.continuousdeliveryvs.continuousdeployment(atlassian.com) WhatisCI/CD?(redhat.com) https://virgool.io/d/pvqltinyed0c/6CommonChallengesSlowingDownContinuousDelivery%E2%80%93Stackify Flux(fluxcd.io)