اگر تا به حال در تیم نرم‌افزاری یا در تیم DevOps یک شرکت مشغول به کار بوده باشید یا اینکه حتی یک فرد علاقه‌مند به حوزه‌های مرتبط با نرم‌افزار باشید حتماً عباراتی مانند CI و CD به گوش شما خورده است. در این نوشته می‌خواهیم به بررسی بخش CD یا همان Continuous Delivery بپردازیم.
برای پاسخ به این سوال ابتدا باید یک مرحله به عقب برگردیم و بدانیم CI/CD چیست. ابتدا تعریف CI را مرور می‌کنیم. CI یا Continuous integration در واقع ادغام تغییرات کد نرم‌افزار به صورت مستمر در یک ریپازیتوری است. این عمل معمولاً سعی می‌شود که به صورت خودکار انجام شود. در عملیات CI معمولاً build شدن کد و اجرای تست‌ها و ادغام کد صورت می‌پذیرد. در واقع CI یک مکانیزم برای سازگاری مستمر میان تغییرات گوناگونی که توسط برنامه نویسان مختلف یک سیستم نرم‌افزاری انجام می‌شود است. هم‌چنین در این فرایند با استفاده از تست‌های مختلف طراحی شده مشکلات پیش آمده در ادغام کدها شناسایی می‌شود.
حال می‌توانیم به تعریف CD یا همان Continuous Delivery یا همان تحویل مستمر بپردازیم. تحویل مستمر یعنی به صورت مستمر کدها و سامانه نرم‌افزاری بتواند منتشر شود. این انتشار ممکن است که صرفاً در دسترس تیم فنی یا تیم‌های دیگر مرتبط با محصول باشد. فرایند تحویل مستمر پس از CI صورت می‌گیرد.
اکنون بیایید با مفهوم Continuous Deployment آشنا شویم. Continuous Deployment پس از Continuous Delivery یا همراه با آن انجام می‌شود. Continuous Deployment به معنی استقرار مستمر است یعنی پس از اینکه CI انجام شد و پس از آن در ریپازیتوری اصلی انتشار آن نسخه از برنامه که بیلد و تست شده صورت گرفت، این نرم‌افزار منتشر شده در سمت مشتریان اصلی استقرار یابد و این مشتریان بتوانند از نرم‌افزار منتشر شده استفاده کنند.
معمولاً فرایندهای Continuous Delivery و Continuous Deployment آن قدر به‌هم‌تنیده و دارای مشترکات زیاد و مکمل هم هستند که خیلی اوقات یک فرایند در نظر گرفته می‌شوند. در تصویر ۱ فرایندهای CI/CD به خوبی به تصویر کشیده شده‌اند.
خط لوله یا pipeline در CI/CD مجموعه‌ای از قدم‌ها است که باید برای انتشار و رسیدن نسخه جدید نرم‌افزار انجام شود. در واقع این pipeline به تیم نرم‌افزاری کمک می‌کند که فرایند انتشار و استقرار یافتن نرم‌افزار را پایش کنند و هم‌چنین بتوانند این فرایند را به طور خودکار انجام دهند. امروزه تقریباً اکثر شرکت‌های نرم‌افزاری این فرایندها را با استفاده از pipeline به صورت خودکار انجام می‌دهند.
در مراحل مختلف تحویل مستمر در pipeline ابتدا در مرحله CI نرم‌افزار build و test می‌شود. سپس در مرحله Continuous Delivery نرم‌افزار داخل ریپازیتوری منتظر می‌شود و در نهایت با Continuous Deployment این نرم‌افزار منتشر شده deploy شده و به دست مشتری می‌رسد. البته ممکن است مراحلی مانند ارزیابی (Validation) های مختلف نیز در هر یک از این مراحل یا پس از این مراحل انجام شود.
معمولاً فرایندهای مربوط به CI و CD که شامل تحویل مستمر هم می‌شود در تیم DevOps یک شرکت انجام می‌شود. کلمه DevOps از دو بخش Dev یعنی توسعه و Ops یعنی عملیات تشکیل شده است. همان طور که از این واژه پیداست، وظیفه تیم DevOps به طور کلی این است که با استفاده از فرایندها، متدها و ابزارهایی که برای یکپارچگی میان تیم توسعه، تیم عملیات و بررسی کیفیت و مشتری استفاده می‌شود، به طور مستمر محصول را به مشتریان عرضه کند. به صورت سنتی قبلاً تیم‌های توسعه و عملیات جدا بودند که امروزه لغت DevOps به ما این منظور را می‌رساند که تیم‌ها به تیم‌هایی دارای چندین تخصص و با مهارت‌های متفاوت تبدیل شده‌اند. امروزه در بسیاری از تیم‌ها دیگر تیم DevOps به صورت جدا وجود ندارد بلکی مختصصان DevOps در تیم اصلی توسعه نرم‌افزار نیز حضور دارند. فرایند تحویل مستمر به عنوان یکی از فرایندهایی که متخصصان DevOps انجام می‌دهند معمولاً توسط این تیم خودکارسازی می‌شود. این تیم هم‌چنین وظیفه دارد که اپلیکیشن به طور مداوم، سریع و مطمئن build و سپس منتشر شود و پس از آن استقرار یابد.
البته ممکن است تیم DevOps در انجام فرایند نصب و تحویل مستمر دچار چالش‌هایی مانند سرعت پایین نصب و استقرار، کانفلیکت‌های زیاد، وابستگی به یک پلتفرم خاص جهت انجام فرایندها، عدم خودکار بودن بخشی از فرایند و مواردی از این دست شود که نسبت به مزایایی که استفاده از آن دارد قابل چشم‌پوشی است و میتواند با رعایت برخی نکات، این مشکلات را نیز برطرف کرد.
اکنون که فهمیدیم Continuous Delivery به چه معناست باید به این فکر کنیم که این فرایند چرا انجام می‌شود و چه مزایایی برای یک تیم نرم‌افزاری دارد. در ادامه چند مورد از این مزایا را با هم مرور می‌کنیم.
در فصل ۱۴ از کتاب Clean Architecture، آقای Robert C. Martin که معروف به عمو باب یا Uncle Bob است در مورد سندرومی صحبت می‌کند که در فرایند انتشار و استفاده مشتری از نسخه جدید نرم‌افزار صورت می‌گرفت. به گفته او همه اعضای یک تیم باید دور هم آخر هفته یا آخر ماه یا هر چند ماه یکبار جمع می‌شدند و طی یک یا چند روز فرایند انتشار نسخه جدید را به صورت کاملاً دستی انجام می‌دادند. این توسعه‌دهنده‌ها و افراد مرتبط با نرم‌افزار، نه تنها باید کارهای مربوط به توسعه خود را متوقف می‌کردند بلکه حتی مجبور می‌شدند بیش از یک روز در شرکت خود بمانند تا نسخه جدید منتشر شود و باگ‌های بزرگ آن یا مشکلات مشتریان با نسخه جدید برطرف شود.
همان‌طور که دیدیم فرایند انتشار نرم‌افزار و تحویل آن قبلاً کار آسانی نبوده و پر از مخاطرات مختلف برای یک تیم نرم‌افزاری بوده است. فرایند تحویل مستمر این مشکل را تا حد خوبی کم می‌کند تا حدی که امروزه در هر روز یا هر هفته ممکن است نسخه‌های مختلف برنامه منتشر شوند و به دست مشتری برسند و همزمان تیم توسعه نیز در حال توسعه امکانات برنامه است و مشکلی برای او پیش نمی‌آید و فرایند توسعه متوقف نمی‌شود. هم‌چنین وقت زیاد و بی‌استفاده‌ای از تیم مرتبط با انتشار نسخه جدید محصول گرفته نمی‌شود و در زمان آن‌ها صرفه‌جویی شده و در بهره‌وری‌شان بهبود قابل توجهی رخ می‌دهد. هم‌چنین ریسک انتشار محصول بسیار کاهش می‌یابد چون فرایند به صورت اتوماتیک انجام شده و احتمال خطای دستی در آن وجود ندارد.
نکته مهم در فرایند تحویل مستمر این است که این فرایند امروزه خودکارسازی (Automate) می‌شود. بدون اینکه نرم‌افزار به صورت سنتی منتشر شده و پس از آن به صورت دستی نسخه جدید نرم‌افزار در production مستقر شود تا مشتری‌ها بتوانند استفاده کنند، به طور خودکار فرایند انجام می‌شود و خطاهای احتمالی در این پروسه به مقدار قابل توجهی کاهش پیدا می‌کند.
از جمله مواردی که در تحویل مستمر کمک می‌کند بازخورد راحت‌تر و بیشتر مشتری و کاربر نرم‌افزار است. چون به صورت مستمر و مداوم فرایند تحویل و انتشار انجام می‌شود، کاربر راحت‌تر و سریع‌تر تغییرات خواسته‌شده را مشاهده می‌کند و در صورتی که باگی وجود داشته باشد، امکان جدیدی در برنامه بخواهد یا اینکه منتظر یک امکان جدید باشد بسیار سریع می‌توان به نیازش پاسخ داد و از او بازخورد گرفت. البته همیشه لازم نیست به همه کاربران یک نسخه جدید را انتشار داد. گاهی اوقات نیاز است که اگر امکان و فیچر جدیدی در برنامه داریم، به بخشی از کاربران آن را ارائه دهیم تا نتیجه و بازخورد آن را از سوی آنان ببینیم و تحلیل کنیم و پس از آن در مورد ارائه آن امکان به تمام مشتریان تصمیم‌گیری کنیم.
هر نرم‌افزاری که فرایند تحویل مستمر را به صورت خودکار انجام‌دهد میتواند حتی در تیم‌های کوچک نرم‌افزاری بدون دغدغه و هزینه‌های بیهوده جهت انتشار نسخه جدید به کار خود ادامه دهد. هم‌چنین این نرم‌افزار در پروسه انتشار تست شده و پس از آن انتشار یافته پس قسمتی از باگ‌های آن در زمان تست و قبل از انتشار مشخص می‌شود. هزینه تیم نرم‌افزار نیز کاهش می‌یابد چون وقت کمتری از تیم نسبت به زمانی که دستی این فرایند را انجام می‌دادند گرفته می‌شود و تیم مرتبط با نرم‌افزار و انتشار آن می‌توانند به موارد مهم‌تر رسیدگی کنند و توسعه را ادامه دهند.
با استفاده از تحویل مستمر، به تیم‌های چابک (Agile) کمک می‌شود که به صورت سریع‌تر، چابک‌تر، کم‌خطاتر و کم‌هزینه‌تر نرم‌افزار را منتشر کنند. بخش‌های مختلف یک تیم نرم‌افزاری چابک، دیگر نباید دغدغه انتشار یک نسخه جدید را به صورت سنتی داشته باشد و باید بداند ممکن است یک فیچر بسیار سریع توسعه و سپس به مشتری عرضه شود.
در این بخش به معرفی چند ابزار متن‌باز پرکاربرد در حوزه تحویل مستمر می‌پردازیم. معمولاً ابزارهای حوزه CI و CD جدا نیستند و هر دو فرایند CI و CD در ابزاری مشترک انجام می‌شود. در ادامه برخی از این ابزارها را مرور می‌کنیم.
این ابزار متن‌باز با زبان جاوا نوشته شده است. این ابزار یکی از بهترین و اولین ابزارهایی بود که فرایند build و تحویل مستمر را ساده‌تر کرد. این ابزار میتواند به صورت real time تست‌ها را انجام دهد و سپس خطاها را گزارش کند تا توسعه‌دهندگان مشکلات کد و برنامه خود را هر چه سریع‌تر متوجه شوند. Jenkins در سیستم‌عامل‌های ویندوز، مک‌او‌اس و سیستم‌های دیگر مبتنی بر Unix مانند لینوکس قابل استفاده است. یکی از مزایای Jenkins پشتیبانی آن از پلاگین‌های مختلف است که کار انتشار نسخه جدید برنامه را آسان‌تر می‌کنند. مزایای Jenkins را می‌توان در موارد زیر خلاصه کرد:
این ابزار یکی دیگر از ابزارهای مورد استفاده در حوزه CI و CD است که میتواند در محیط‌های مختلف اجرا شود. توسعه‌دهندگان با استفاده از این ابزار قدرتمند و API ای که خود CircleCI می‌دهد به قابلیت‌های این ابزار میتواند بیفزایند. برخی قابلیت‌های ابزار CircleCI را به صورت مختصر در زیر می‌آوریم:
امروزه در بسیاری از شرکت‌ها از ابزار Gitlab CI استفاده می‌شود چرا که سورس‌کد بعضی سامانه‌ها در ریپازیتوری خصوصی در گیت‌لب است و به منظور یکپارچه بودن ابزار مورد استفاده در بخش ادغام و نصب و تحویل مستمر (CI/CD) هم از ابزار مخصوص گیت‌لب استفاده می‌شود. این ابزار دارای محیط‌ها، pipeline ها و امکان اجرای تست‌ها و داشتن Variable در بخش CI/CD است و هم‌چنین بسیاری امکانات دیگر نیز دارد. یکی از مهم‌ترین ویژگی‌های آن استفاده از Gitlab Runner است که با آن می‌شود یک Runner مثلاً روی سرور شخصی راه‌اندازی و استفاده کرد و آن را با ابزار Gitlab CI یکپارچه نمود.
در این بخش سه شرکت فعال در حوزه تحویل مستمر در ایران را معرفی می‌کنیم.
سرویس ابری لیارا
این سرویس با پشتیبانی کامل از سیستم‌عامل‌های مختلف و توانایی ادغام با Gitlab یا Github و استفاده از تمامی امکانات آن‌ها یکی از سرویس‌هایی است که کسب و کارهای ایرانی می‌توانند برای فرایند نصب و تحویل مستمر از آن استفاده کنند. طبق گفته این شرکت در سایت خود، تمامی سرویس‌ها و قابلیت‌های این سرویس ابری، به صورت آنی قابل راه‌اندازی است و استقرار نرم‌افزار بدون هر گونه اخلال به دلایلی مانند تحریم اتفاق می‌افتد. هم‌چنین این سرویس امکان بازگشت آسان به نسخه‌های قبلی شما را به راحتی می‌دهد و با پشتیبانی از خط فرمان و گزارشات و لاگ‌های مختلف به مدیریت فرایند CI و CD نیز کمک زیادی می‌کند.
سرویس کانتینر ابری ابرآروان با استفاده از سرویس ابری ابرآروان، تمام نیازمندی‌های زیرساختی مانند کنترل مداوم فرایند نصب و تحویل و استقرار در دسترس کاربر خواهد بود و نرم‌افزار مطابق با پیکربندی توسعه‌دهندگان build و مستقر می‌شود. هم‌چنین امکان افزایش منابع سخت‌افزاری به سادگی در این پلتفرم وجود دارد تا فرایند CI/CD سریع‌تر شود. با استفاده از سرویس ابری ابرآروان، مراحل build و deploy توسط خود ابرآروان و با استفاده از container ها میتواند انجام شود و تیم نرم‌افزاری فقط به دغدغه کد خود بپردازد نه دغدغه نصب و تحویل مستمر نرم‌افزار.
این سرویس نیز با ابزارهایی مانند Gitlab CI به طور کامل قابل استفاده است.
می‌توانید جهت مشاهده مستندات هر یک از سرویس‌های بالا به سایت آن‌ها مراجعه کنید.
این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.
