مفهوم تحویل مستمر از جمله مفاهیمی در حوزه دوآپس و مهندسی نرم‌افزار است که مکررا شنیده می‌شود. البته تحویل مستمر بیشتر در کنار ادغام مستمر به صورت 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 در فین‌تک کار مجدد و زمان انتظار را حذف می‌کند. به لطف اتوماسیون فرآیندهای معمول، توسعه دهندگان نرم افزار می توانند روی سایر وظایف مهم تر، مانند اطمینان از کیفیت و امنیت کد، تمرکز کنند.
اگر کد تغییر کند، خط لوله تحویل پیوسته راه اندازی می شود و فرآیند آزمایش اجرا می شود. اینها فازهایی هستند که خط لوله تحویل مداوم از آن عبور می کند:
با بزرگ‌تر شدن تیم‌ها و انجام وظایف بلندپروازانه‌تر، پیاده‌سازی CD - تحویل واقعی در تحویل مداوم - می‌تواند یک چالش باشد. تأخیرها به دلایل متعددی اتفاق می‌افتد و تیم‌های DevOps پیوسته در حال مبارزه برای حفظ پروژه‌ها در مسیر هستند. از مقیاس‌بندی خیلی سریع تا سازمان‌دهی ضعیف، در اینجا فقط چند مورد از رایج‌ترین چالش‌هایی که تیم‌ها با آنها مواجه هستند، و همچنین تکنیک‌هایی که رهبران DevOps می‌توانند برای کاهش نقاط درد به کار ببرند، آورده شده است:
همانطور که تحویل مستمر به اجزای عملیاتی مختلف برای اطمینان از کد قابل اعتماد نیاز دارد، کسب و کار نیز برای موفقیت به همکاری بین تیم ها نیاز دارد. ارتباطات ضعیف بین تیم‌ها، چه محصول خاص و چه در کل کسب‌وکار، می‌تواند منجر به تجدید نظر و تأخیر قابل توجه در استقرار شود. تیم‌ها باید هم فرآیندهای عملیاتی و هم ابزارهای تولیدی خود را در سراسر سازمان خود ارزیابی کنند - و یک بار دیگر برنامه و نقشه راه مشترکی داشته باشند که قابل اعتماد و دقیق باشد. با ظهور مشکلات و تغییرات در پروژه، چه داخلی و چه در بازار، تیم های DevOps باید بتوانند به سرعت و شفاف در بخش های مربوطه پاسخ دهند.
توسعه دهندگان موفق باید ابزارهای لازم را داشته باشند تا نه تنها از محصولات کسب و کار پشتیبانی کنند، بلکه از تیم های داخلی خود نیز پشتیبانی کنند. تیم هایی که با DevOps مقیاس بندی می شوند باید بودجه لازم را برای ایجاد زیرساخت های مورد نیاز برای تیم ها برای ساخت محصولات جاه طلبانه تر و جمع آوری مقادیر بیشتری از داده ها داشته باشند. تیم هایی که سعی می کنند خیلی سریع مقیاس شوند، اغلب در این تنگنا گرفتار می شوند و کیفیت محصول یا زیرساخت داخلی خود را قربانی می کنند. این به جای استقرار به تاخیرهای مداوم منجر می شود و اگر عاقلانه برخورد نشود، این موضوع می تواند گلوله برفی داشته باشد. تیم‌ها باید قبل از اینکه تلاش‌های CD خود را افزایش دهند، این را در نظر بگیرند: «این موضوع چگونه بر زیرساخت‌ها و فرآیندهایی که امروز در اختیار دارم تأثیر می‌گذارد؟» قبل از اجرای یک فرآیند جدید، مطمئن شوید که چگونه فرآیندهای گردش کار فعلی شما می تواند تحت تأثیر قرار گیرد. صرف زمان برای ادغام جریان های کاری مناسب، انتقال را هموارتر می کند و از متورم شدن این تنگنا به تاخیر جدی جلوگیری می کند.
یک تیم اختصاصی تست اتوماسیون موتور محصول را روشن نگه می‌دارد، اما در طول چرخه عمر به نظم و انضباط قوی نیاز دارد. اولاً، این مستلزم این است که همه به توافق برسند. رهبران DevOps باید مطمئن شوند که همه تیم‌ها در مورد فرآیندی که انتخاب می‌کنید، خواه این فرآیند توسعه رفتار محور یا چابک باشد، موافق باشند. و از همه مهمتر، فرآیندهای سایه CI را در گذشته رها کنید تا اطمینان حاصل شود که تیم ها به یک نمای واحد از کد محصول شما دسترسی دارند. در کل فرآیند تست باید جدی گرفته‌شود و تست‌ها پوشش لازم را داشته باشند.
اتوماسیون ابزارهای DevOps می تواند ساعت های بی شماری را ذخیره کند و برنامه های CD را به موقع نگه دارد. با این حال، از آنجایی که مسئولیت‌های تیم شما تغییر می‌کند و وظایف جدید به وجود می‌آیند، خودکار کردن فرآیندها خیلی زود فقط به خاطر زمان آسان است. اتوماسیون یک فرآیند با طراحی ضعیف ممکن است در کوتاه مدت باعث صرفه جویی در زمان شود، اما دراز مدت می تواند به یک گلوگاه بزرگ تبدیل شود که رفع آن دشوار است. برای مبارزه با این، تیم‌ها باید قبل از خودکارسازی، گلوگاه‌های فرآیند را حل کنند. توسعه دهندگان باید به طور مداوم ممیزی پروتکل های خودکار خود را انجام دهند تا اطمینان حاصل کنند که آنها به طور مداوم دقیق هستند، در حالی که فرآیندهای فعلی را برای کارایی آزمایش می کنند.
