بخش ۱: تعریف
هدف این است که استقرارها را - خواه یک سیستم توزیع شده در مقیاس بزرگ، یک محیط تولید پیچیده، یک سیستم تعبیه شده یا یک برنامه - انجام شود- امور معمول و قابل پیش بینی که می توانند در صورت تقاضا انجام شوند.
همه اینها را با اطمینان از اینکه کد مان همیشه در وضعیت قابل استقرار است، حتی در مواجهه با تیم‌هایی متشکل از هزاران توسعه‌دهنده که روزانه تغییراتی ایجاد می‌کنند، باید به دست آورد. بنابراین، فازهای ادغام، آزمایش و سخت شدن را که به طور سنتی به دنبال «dev full» دنبال می‌کردند، و همچنین فریز کردن کد باید کاملاً حذف شوند.
اغلب فرض بر این است که اگر می‌خواهیم نرم‌افزار را به دفعات بیشتری مستقر کنیم، باید سطوح پایین‌تری از ثبات و قابلیت اطمینان را در سیستم‌های خود بپذیریم. در واقع، تحقیقات بررسی شده نشان می دهد که اینطور نیست - تیم های با عملکرد بالا به طور مداوم خدمات را سریعتر و قابل اطمینان تر از رقبای کم عملکرد خود ارائه می دهند. این امر حتی در حوزه های بسیار تحت نظارت مانند خدمات مالی و دولتی نیز صادق است. این قابلیت، مزیت رقابتی باورنکردنی را برای سازمان هایی که مایل به سرمایه گذاری برای پیگیری آن هستند، فراهم می کند.
- اقداماتی که در قلب تحویل مستمر وجود دارد به ما کمک می کند تا به چندین مزیت مهم دست یابیم:
۱) انتشار کم خطر هدف اولیه از تحویل مداوم، این است که استقرار نرم‌افزار را بدون دردسر و رویدادهای کم خطری که می‌توان در هر زمان و بنا به درخواست انجام داد، انجام داد. با استفاده از الگوهایی مانند استقرارهای سبز-آبی، دستیابی به استقرارهای زمان توقف صفر که برای کاربران غیرقابل شناسایی هستند، نسبتاً ساده است.
۲) زمان سریعتر، برای بازاریابی غیرمعمول نیست که مرحله ادغام و آزمایش/تثبیت چرخه عمر تحویل نرم افزار مرحله ای سنتی هفته ها یا حتی ماه ها طول بکشد. هنگامی که تیم ها برای خودکارسازی ساخت و استقرار، تهیه محیط و فرآیندهای تست رگرسیون با هم کار می کنند، توسعه دهندگان می توانند تست یکپارچه سازی و رگرسیون را در کار روزانه خود بگنجانند و این مراحل را به طور کامل حذف کنند. ما همچنین از حجم زیاد دوباره کاری که رویکرد مرحله‌ای را آزار می‌دهد اجتناب می‌کنیم.
۳) کیفیت بالاتر، وقتی توسعه‌دهندگان ابزارهای خودکاری دارند که در عرض چند دقیقه رگرسیون‌ها را کشف می‌کنند، تیم‌ها آزاد می‌شوند تا تلاش خود را بر روی تحقیقات کاربر و فعالیت‌های تست سطح بالاتر مانند آزمایش اکتشافی، تست قابلیت استفاده، و تست عملکرد و امنیت متمرکز کنند. با ایجاد یک خط لوله استقرار، این فعالیت ها می توانند به طور مداوم در طول فرآیند تحویل انجام شوند و اطمینان حاصل شود که از ابتدا کیفیت در محصولات و خدمات تعبیه شده است.
۴) هزینه های پایین تر، هر محصول یا خدمات نرم افزاری موفقی در طول عمر خود به طور قابل توجهی تکامل می یابد. با سرمایه‌گذاری در ساخت، آزمایش، استقرار و اتوماسیون محیط، با حذف بسیاری از هزینه‌های ثابت مرتبط با فرآیند انتشار، هزینه ایجاد و ارائه تغییرات تدریجی در نرم‌افزار را به‌طور قابل‌توجهی کاهش می‌دهیم.
۵) محصولات بهتر تحویل مداوم کار را در دسته های کوچک اقتصادی می کند. این بدان معنی است که ما می توانیم در طول چرخه عمر تحویل بر اساس نرم افزار کار از کاربران بازخورد دریافت کنیم. تکنیک‌هایی مانند تست A/B ما را قادر می‌سازد تا رویکردی مبتنی بر فرضیه را برای توسعه محصول در پیش بگیریم که به موجب آن می‌توانیم ایده‌ها را با کاربران قبل از ایجاد ویژگی‌های کامل آزمایش کنیم. این بدان معناست که می‌توانیم از 2/3 ویژگی‌هایی که می‌سازیم که ارزش صفر یا منفی را به کسب‌وکارمان ارائه می‌کنند، اجتناب کنیم.
۶) تیم های شادتر تحقیقات بررسی شده نشان داده است که تحویل مداوم باعث کاهش درد و کاهش فرسودگی تیم می شود. علاوه بر این، زمانی که ما بیشتر منتشر می‌کنیم، تیم‌های تحویل نرم‌افزار می‌توانند فعال‌تر با کاربران درگیر شوند، بیاموزند که کدام ایده‌ها کار می‌کنند و کدام نه، و از نزدیک نتایج کاری را که انجام داده‌اند ببینند. با حذف فعالیت‌های دردناک کم‌ارزش مرتبط با تحویل نرم‌افزار، می‌توانیم روی چیزی که بیش از همه به آن اهمیت می‌دهیم تمرکز کنیم - به طور مداوم کاربران خود را خوشحال کنیم.
۷) اگر این خیلی خوب به نظر می رسد که درست نباشد، به خاطر داشته باشید: تحویل مداوم جادو نیست. این در مورد بهبود مستمر و روزانه است - نظم و انضباط ثابت برای دنبال کردن عملکرد بالاتر با پیروی از اکتشافی "اگر دردناک است، آن را بیشتر انجام دهید و درد را به جلو ببرید."
تحویل مداوم و DevOps از نظر معانی مشابه هستند و اغلب با هم ترکیب می شوند، اما آنها دو مفهوم متفاوت هستند. DevOps دامنه وسیع تری دارد، و حول محور تغییرات فرهنگی، به ویژه همکاری تیم های مختلف درگیر در تحویل نرم افزار (توسعه دهندگان، عملیات، تضمین کیفیت، مدیریت، و غیره)، و همچنین خودکارسازی فرآیندها در تحویل نرم افزار متمرکز است. از سوی دیگر، تحویل مستمر رویکردی برای خودکارسازی جنبه تحویل است و بر گردآوری فرآیندهای مختلف و اجرای سریعتر و مکرر آنها تمرکز دارد. بنابراین، DevOps می تواند محصول تحویل مداوم باشد و CD مستقیماً به DevOps جریان می یابد.
تحویل مستمر توانایی ارائه نرم افزاری است که می تواند در هر زمان از طریق انتشار دستی مستقر شود. این برخلاف استقرار مداوم است که از استقرار خودکار استفاده می کند. به گفته مارتین فاولر، استقرار مداوم مستلزم تحویل مداوم است. دستی در مقابل خودکار تحویل مستمر.
مفهوم رایج خط لوله استقرار را به عنوان یک Poka-Yoke ناب تلقی می‌کند: مجموعه‌ای از تأییدیه‌ها که از طریق آن یک نرم‌افزار باید در مسیر انتشار قرار گیرد. کد در صورت لزوم کامپایل می شود و سپس هر بار که تغییری به یک مخزن کنترل منبع متعهد می شود توسط یک سرور ساخت بسته بندی می شود، سپس توسط تعدادی تکنیک مختلف (احتمالاً از جمله آزمایش دستی) آزمایش می شود تا بتوان آن را به عنوان قابل انتشار علامت گذاری کرد.
توسعه دهندگانی که به چرخه زمانی طولانی عادت دارند ممکن است نیاز داشته باشند که طرز فکر خود را هنگام کار در یک محیط CD تغییر دهند. درک این نکته مهم است که هر تعهد کد ممکن است در هر نقطه ای برای مشتریان منتشر شود. الگوهایی مانند جابجایی ویژگی‌ها می‌تواند برای ارسال زودهنگام کد که هنوز برای استفاده توسط کاربران نهایی آماده نیست بسیار مفید باشد. استفاده از NoSQL می تواند مرحله مهاجرت داده ها و تغییرات طرحواره را حذف کند، اغلب مراحل دستی یا استثنائات یک گردش کار تحویل مداوم. سایر تکنیک‌های مفید برای توسعه کد به صورت مجزا مانند شاخه‌بندی کد در دنیای CD منسوخ نشده‌اند، اما باید با اصول CD سازگار شوند - برای مثال، اجرای چندین شاخه کد با عمر طولانی می‌تواند غیرعملی باشد، زیرا یک مصنوع قابل انتشار باید اگر قرار است از تمام مراحل خط لوله عبور کند، در اوایل فرآیند CD از یک شاخه کد واحد ساخته شود.
تحویل مداوم از طریق خط لوله استقرار فعال می شود. هدف خط لوله استقرار دارای سه جزء است: دید، بازخورد و استقرار مداوم.
قابلیت مشاهده - تمام جنبه های سیستم تحویل از جمله ساخت، استقرار، آزمایش و انتشار برای همه اعضای تیم برای ارتقای همکاری قابل مشاهده است.
بازخورد - اعضای تیم در صورت بروز مشکلات در اسرع وقت از آنها مطلع می شوند تا بتوانند در اسرع وقت آنها را برطرف کنند.
استقرار مداوم - از طریق یک فرآیند کاملاً خودکار، می توانید هر نسخه از نرم افزار را در هر محیطی استقرار و منتشر کنید.
ابزار/انواع ابزار:
تحویل مداوم، اتوماسیون را از کنترل منبع تا پایان تولید می‌گیرد. ابزارهای مختلفی وجود دارد که به انجام تمام یا بخشی از این فرآیند کمک می کند. این ابزارها بخشی از خط لوله استقرار هستند که شامل تحویل مداوم است. انواع ابزارهایی که بخش های مختلف فرآیند را اجرا می کنند عبارتند از: یکپارچه سازی مداوم، اتوماسیون انتشار برنامه، اتوماسیون ساخت، مدیریت چرخه عمر برنامه.
معماری برای تحویل مداوم:
برای تمرین موثر تحویل مداوم، برنامه‌های نرم‌افزاری باید مجموعه‌ای از الزامات مهم معماری (ASR) مانند قابلیت استقرار، تغییرپذیری و آزمایش‌پذیری را برآورده کنند.
میکروسرویس ها اغلب هنگام معماری برای تحویل مداوم استفاده می شوند. استفاده از میکروسرویس ها می تواند قابلیت استقرار و تغییرپذیری یک سیستم نرم افزاری را افزایش دهد. پیشرفت‌های قابل استقرار مشاهده‌شده عبارتند از: استقلال استقرار، زمان استقرار کوتاه‌تر، روش‌های استقرار ساده‌تر، و استقرار زمان توقف صفر. پیشرفت‌های قابل تغییر مشاهده‌شده عبارتند از: زمان چرخه کوتاه‌تر برای تغییرات عملکردی افزایشی کوچک، تغییرات آسان‌تر در انتخاب فناوری، تغییرات ویژگی کیفیت افزایشی، و ارتقای زبان و کتابخانه آسان‌تر.
اجرا و استفاده:
کتاب سی دی نوشته شده توسط Jez Humble و David Farley (2010) این اصطلاح را رایج کرد، اما از زمان ایجاد آن، این تعریف به پیشرفت خود ادامه داده است و اکنون معنای توسعه یافته تری دارد. امروزه شرکت ها این اصول و بهترین شیوه های تحویل مستمر را اجرا می کنند. تفاوت در دامنه ها، به عنوان مثال. پزشکی در مقابل وب، هنوز قابل توجه هستند و بر اجرا و استفاده تأثیر می گذارند. شرکت های معروفی که این رویکرد را دارند عبارتند از یاهو، آمازون، فیس بوک، گوگل، پدی پاور و ولز فارگو.
مزایا و موانع:
چندین مزیت تحویل مداوم گزارش شده است.
زمان تسریع به بازار: CD به سازمان اجازه می دهد ارزش تجاری ذاتی در نسخه های نرم افزار جدید را سریعتر به مشتریان ارائه دهد. این قابلیت به شرکت کمک می کند تا یک قدم جلوتر از رقبا باقی بماند.
ساخت محصول مناسب: انتشارات مکرر به تیم های توسعه برنامه اجازه می دهد بازخورد کاربر را سریعتر دریافت کنند. این به آنها امکان می دهد فقط روی ویژگی های مفید کار کنند. اگر متوجه شوند که یک ویژگی مفید نیست، تلاش بیشتری برای آن نمی کنند. این به آنها کمک می کند محصول مناسبی بسازند.
بهره وری و کارایی بهبود یافته: صرفه جویی قابل توجهی در زمان برای توسعه دهندگان، آزمایش کنندگان، مهندسان عملیات و غیره از طریق اتوماسیون.
انتشار قابل اعتماد: خطرات مرتبط با انتشار به طور قابل توجهی کاهش یافته است و روند انتشار قابل اعتمادتر شده است. با CD، فرآیند استقرار و اسکریپت ها قبل از استقرار تا تولید به طور مکرر آزمایش می شوند. بنابراین، بیشتر خطاها در فرآیند استقرار و اسکریپت ها قبلاً کشف شده اند. با انتشار بیشتر، تعداد تغییرات کد در هر نسخه کاهش می یابد. این امر یافتن و رفع هر گونه مشکلی را که رخ می دهد آسان تر می کند و زمان تأثیر آنها را کاهش می دهد.
بهبود کیفیت محصول: تعداد اشکالات باز و حوادث تولید به طور قابل توجهی کاهش یافته است.
بهبود رضایت مشتری: سطح بالاتری از رضایت مشتری به دست می آید.
موانع نیز بررسی شده است.
ترجیحات مشتری: برخی از مشتریان به روز رسانی مداوم سیستم های خود را نمی خواهند. این امر به ویژه در مراحل بحرانی عملیات آنها صادق است.
محدودیت‌های دامنه: در برخی حوزه‌ها، مانند مخابرات و پزشکی، مقررات نیاز به آزمایش گسترده قبل از ورود نسخه‌های جدید به فاز عملیاتی دارند.
عدم اتوماسیون تست: عدم اتوماسیون تست منجر به عدم اطمینان توسعه دهنده می شود و می تواند از استفاده مداوم از تحویل جلوگیری کند.
تفاوت در محیط ها: محیط های مختلف مورد استفاده در توسعه، آزمایش و تولید می تواند منجر به لغزش مسائل ناشناخته به محیط تولید شود.
آزمایش‌هایی که به اوراکل انسانی نیاز دارند: همه ویژگی‌های کیفیت را نمی‌توان با اتوماسیون تأیید کرد. این ویژگی‌ها به انسان‌ها در حلقه نیاز دارند و خط لوله تحویل را کاهش می‌دهند.
بخش ۲: معرفی چند ابزار:
- ابزار Argo CD: یک ابزار CI/CD برای توسعه Kubernetes است. این یک پروژه منبع باز است که در حال حاضر در وضعیت نهفتگی در بنیاد محاسبات بومی ابری (CNCF) قرار دارد. از مخازن Git برای ذخیره وضعیت برنامه‌های Kubernetes استفاده می‌کند، برنامه‌ها را نظارت می‌کند و می‌تواند خوشه‌ها را به حالت دلخواه مجدداً همگام‌سازی کند، همانطور که در پیکربندی git نشان داده شده است.
این رویکرد نوآورانه همچنین به شما امکان می‌دهد چندین حالت دلخواه یک برنامه Kubernetes را با استفاده از شاخه‌ها، برچسب‌ها یا با پین کردن نسخه‌های مانیفست با استفاده از یک Git commit ذخیره کنید. این یک محیط انعطاف پذیر برای مدیریت پیکربندی های Kubernetes در طول فرآیند توسعه فراهم می کند.
- ابزار CircleCI: یک ابزار منبع باز CI/CD است. این شامل ویژگی هایی برای هماهنگی کار، پیکربندی منابع، ذخیره سازی، اشکال زدایی، امنیت و گزارش های داشبورد است. CircleCI با ابزارهای مختلفی از جمله GitHub، Heroku، Slack و Docker ادغام می شود. CircleCI در سه سطح موجود است که یکی از آنها رایگان است. می‌توانید آن را در فضای ابری یا در محل با ماشین‌های لینوکس، مک یا ویندوز استفاده کنید.
- ابزار GitHub Actions: یک ویژگی ابزار منبع باز است که اخیراً منتشر شده است که می توانید از آن برای خودکارسازی گردش کار استفاده کنید. این به شما امکان می‌دهد تا کد را مستقیماً از GitHub بسازید، آزمایش کنید و اجرا کنید. شما می توانید اتوماسیون خود را بر اساس هر رویداد GitHub، از جمله ایجاد فشار یا مشکل، قرار دهید. GitHub Actions شامل ویژگی‌هایی برای جریان‌های کاری ماتریس، اجراهای میزبانی شده برای همه سیستم‌عامل‌های اصلی، ذخیره‌سازی اسرار داخلی و بررسی گزارش‌های زنده است. از تمامی زبان های برنامه نویسی رایج پشتیبانی می کند.
اکشن‌های GitHub شامل محیط‌های زمان اجرا میزبانی شده است که برای 2000 دقیقه اول استفاده در ماه رایگان هستند. اگر به زمان بیشتری برای آزمایش نیاز دارید، می توانید زمان را به صورت دقیقه ای یا عمده خریداری کنید. می‌توانید با قرار دادن اکشن‌های GitHub در فایل‌های YAML خود، از آنها استفاده کنید.
- ابزار GoCD: یک ابزار ساخت متن باز است که به شما امکان می دهد خطوط لوله توسعه CI/CD بسازید. در هسته خود، یک سرور یکپارچه سازی پیوسته (CI) است که به شما امکان می دهد با جریان های کاری انتشار پیچیده کار کنید. این فراتر از CI کلاسیک است که به شما امکان می‌دهد یک خط لوله تحویل کامل (CD) از استقرار خودکار و ایمن تا تولید بسازید. GoCD خطوط لوله را با استفاده از کد بررسی شده در کنترل منبع تعریف می کند - این رویکرد زیرساخت به عنوان کد (IaC) به شما امکان می دهد خطوط لوله را در چندین پروژه آزمایش، مدیریت و استفاده مجدد کنید. خطوط لوله را می توان با قالب های JSON یا YAML نشان داد.
یکی دیگر از ویژگی های GoCD توانایی اجرای خطوط لوله به صورت متوالی و موازی با وابستگی های قابل تنظیم است. می‌توانید کل گردش‌های کاری را از توسعه تا تولید مشاهده کنید و با استفاده از نگاشت جریان ارزش، یک ویژگی را از تعهد اولیه تا استقرار تولید ردیابی کنید. همچنین، GoCD بسیار منعطف است و اکوسیستمی از پلاگین ها را ارائه می دهد و این ابزار همچنین به شما امکان می دهد خودتان را توسعه دهید و مشارکت دهید.
بخش ۳: معرفی چند شرکت ارائه دهنده ی این سرویس در ایران:
خدماتی که ارائه می دهد، علاوه بر راه اندازی و مشاوره، کمک به جلوگیری از ضرر مالی و زمان
[1] Chen, Lianping (2015). "Continuous Delivery: Huge Benefits, but Challenges Too". IEEE Software. 32 (2): 50–54. doi:10.1109/MS.2015.27. S2CID 1241241.
[2] Shahin, Mojtaba; Ali Babara, Muhammad; Zhu, Liming (2017). "Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices". IEEE Access. 5: 3909–3943. arXiv:1703.07019. Bibcode:2017arXiv170307019S. doi:10.1109/ACCESS.2017.2685629. S2CID 11638909.
[3] Hammond, Jeffrey (9 September 2011). "The Relationship between DevOps and Continuous Delivery". Forrester Research. Forester.
[4] 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.
[5] Swartout, Paul (2012). Continuous Delivery and DevOps: A Quickstart guide. Packt Publishing. ISBN 978-1849693684.
[6] Chen, Lianping (2017). "Continuous Delivery: Overcoming adoption challenges". Journal of Systems and Software. 128: 72–86. doi:10.1016/j.jss.2017.02.013.
[7] "bliki: ContinuousDelivery". martinfowler.com. Retrieved 2015-10-29.
[8] https://continuousdelivery.com/
[9] https://devops.com/7-popular-open-source-ci-cd-tools/
«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»
