CI/CD چیست؟

در حوزهٔ دوآپس CI/CD دو سرواژه‌ای هستند به کرات استفاده می‌شوند و در این مقاله قصد داریم تا به بررسی تفاوت‌های آن‌ها بپردازیم. Continuous Integration یا به اختصار CI به طور خلاصه به پروسه‌ای اشاره دارد که از آن طریق فیچرهای جدید به صورت خودکار با ریپازیتوری اصلی ادغام می‌شوند اما CD هم مخفف واژگان Continuous Delivery است و هم به Continuous Deployment اشاره دارد به طوری که اصطلاح اول به فرآیندی اشاره می‌کند که از آن طریق نرم‌افزار دائماً آماده دیپلوی است اما اصطلاح دوم سازوکاری است که به صورت خودکار کدهای آماده را روی سرور/سرورهای اصلی منتشر می‌کند (به طور کلی، این مفاهیم ارتباط تنگاتنگی با فرهنگ اجایل دارند که در آن تمرکز روی بهبود مستمر و انتشار قابلیت‌های جدید در بازه‌های زمانی بسیار کوتاه است.)

Continuous Integration چیست؟

Continuous Integration به تیم‌های مهندسی اجایل و دوآپس کمک می‌کند تا تغییرات اِعمال‌شده برر روی سورس‌کد روی تک‌تک سیستم‌های دولوپرها دائماً با سورس‌کد (ریپازیتوری) اصلی ادغام شوند که این کار ابتدا به ساکن با پیاده‌سازی یکسری تست به منظور اطمینان حاصل کردن از عدم ناسازگاری مابین کامپوننت‌ها/کدهای جدید با کامپوننت‌ها/کدهای قدیمی صورت می‌گیرد و نیاز به توضیح نیست که این استراتژی اساساً بروز کانفیلیکت (تداخل) مابین فیچرهای جدیدی که توسط برنامه‌نویسان مختلف افزوده می‌شوند را به حداقل می‌رساند و این تضمین را می‌دهد که ایشان همواره به آخرین نسخه از تغییرات دسترسی دارند (در همین راستا، توصیه می‌کنیم به مقالهٔ معرفی برخی از ابزارهای اپن‌سورس Continuous Integration مراجعه نمایید.)

Continuous Delivery چیست؟

Continuous Delivery که گام بعدی پس از مرحلهٔ فوق است این تضمین را ایجاد می‌کند که تیم‌های توسعهٔ نرم‌افزار می‌توانند با خیال راحت هر موقع که مشتری تمایل داشته باشد کدهای جدید را روی سرور دیپلوی کنند چرا که قبلاً تست‌های مختلفی روی سورس‌کد اِعمال شده و هیچ‌گونه مشکلی در ارتباط با انتشار نسخهٔ جدید نرم‌افزار وجود نخواهد داشت. در این فرآیند، اقداماتی همچون بلید، پَکجینگ و دیگر کارهایی که باید برای کارا بودن یک نرم‌افزار صورت گیرند نیز تکمیل شده به طوری که CD این امکان را به توسعه‌دهندگان می‌دهد تا به صورت روزانه،‌ هفتگی و یا ماهانه نسخهٔ جدید نرم‌افزار خود را در دسترس کاربران واقعی‌اش قرار دهند.

Continuous Deployment چیست؟

Continuous Deployment پس از مرحلهٔ‌ قبل صورت می‌گیرد بدین شکل که هر تغییری که در سورس‌کد اِعمال می‌شود و با موفقیت تست‌های مختلف را پشت سر بگذارد به صورت خودکار توسط سیستم روی سرور دیپلوی می‌شود و هرگز برای این کار نیازی به دخالت عاملِ انسانی نخواهد بود و تنها در صورتی این کار متوقف می‌گردد که سورس‌کد نتواند از پسِ تست‌ها به صورت موفقیت‌آمیزی برآید. روی هم رفته می‌توان گفت که از مزایای CD این است که توسعه‌دهندگان می‌توانند تمرکز خود را روی کدنویسی گذاشته و انتشار خلاقیت‌هایی که به خرج می‌دهند را به سیستم‌های کامپیوتری واگذار کنند و نیاز به توضیح نیست که این کار منجر بدان خواهد شد که سریع‌تر هم بتوانند فیدبک‌های مرتبط با تغییرات مد نظر خود را از کاربران بگیرند.

به همان ترتیبی که به توضیح این مفاهیم پرداختیم، آن‌ها یکی پس از دیگری می‌آیند و ارتباط‌شان از بالا به پایین است بدین شکل که CI بخش زیربنایی CD است و Continuous Deployment نیز فرآیندی همچون Continuous Delivery است با این تفاوت که اجرای آن به صورت خودکار صورت می‌گیرد به طوری که تصویر زیر این ارتباط را به خوبی ترسیم کرده است:

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

آشنایی با مزایای Continuous Integration

پیش از آنکه به مزایای CI بپردازیم لازم به یادآوری است که برای این کار دولوپرها باید برای هر فیچر جدیدی که به نرم‌افزار یا اپلیکیشن اضافه می‌کنند و یا باگی را فیکس می‌کنند یک تست جداگانه بنویسند مضاف بر اینکه نیاز به یک سرور مجزا برای اجرای این فرآیند خواهیم داشت تا بتوان از آن طریق به محض کامیت کردن فیچرهای جدید، تست‌ها را به صورت خودکار اجرا کرده و همچنین ریپازیتوری اصلی را مانیتور کرد (در این فرآیند توصیه می‌شود که تمامی اعضای تیم مهندسی تغییراتی که روی محیط لوکال خود اِعمال کرده‌اند را حداقل روزی یک بار با ریپازیتوری اصلی ادغام نمایند.)

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

- Unit Test: در این نوع تست یکسری فانکشن‌هایی وجود دارند که این وظیفه را دارند تا عملکرد سایر فانکشن‌ها را تست کنند.
- Integration Test: این تست اطمینان حاصل می‌کند که کامپوننت‌های مختلف به خوبی با یکدیگر سازگار هستند.
- Acceptance Test: این تست همچون مورد قبل است با این تفاوت که بیشتر از بُعد تجاری نرم‌افزار را محک می‌زند.
- UI Test: این تست تضمین می‌دهد که وقتی رابط کاربری در اختیار کاربران قرار گیرد، همان‌طور که از آن انتظار می‌رود کار خواهد کرد.

آشنایی با مزایای Continuous Delivery

همان‌طور که پیش از این اشاره کردیم، این فرآیند پس از CI صورت می‌گیرد بدین صورت که در هر زمانی که مشتری و یا تیم مهندسی تمایل داشته باشد، می‌توان نسخهٔ‌ جدید نرم‌افزار را روی سرور اصلی منتشر کرد مضاف بر اینکه با سرعت بیشتری می‌توان فیچرهای جدید را در معرض دید کاربران نهایی نرم‌افزار قرار داده و بالتبع از ایشان برای اِعمال تغییرات یا بهبود بیشتر فیدبک گرفت.

همچنین نکته‌ای که در ارتباط با این فرآیند باید همواره مد نظر قرار داده شود آن است که کیفیت نرم‌افزار تحت هیچ عنوان نباید فدای سرعت انتشار آن گردد! به عبارت دیگر، گرچه CD این امکان را در اختیار تیم‌های مهندسی نرم‌افزار می‌گذارد تا همواره آمادهٔ عرضهٔ آخرین نسخه از نرم‌افزار خود باشند، اما در عین حال داشتن اطمینان کامل از کارکرد صحیح بیلد یک باید است.

آشنایی با مزایای Continuous Deployment

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

وقتی Continuous Deployment به فرآیند توسعهٔ نرم‌افزار ورود پیدا می‌کند، تیم توسعه با خیال راحت می‌تواند بر کدنویسی خود متمرکز باشد زیرا کدهایی که ایشان می‌نویسند قرار است ابتدا به صورت کامل توسط سیستم تست شده سپس به صورت خودکار روی سرور اصلی و بدون نیاز به دخالت ایشان دیپلوی شوند مضاف بر اینکه از دید کاربران نهایی نیز این مزیت شکل می‌گیرد که دائماً بهبودهایی را به صورت روزانه یا هفتگی در نرم‌افزار مورد استفادهٔ‌ خود شاهد هستند و دیگر نیازی نیست تا روزها، هفته‌ها و یا ماه‌ها برای انتشار نسخهٔ جدید نرم‌افزار یا اپلیکیشن صبر نمایند.

نکته‌ای که در ارتباط با این فرآیند وجود دارد آن است که همواره باید به سازوکاری اندیشید تا بتوان به صورت Real-time (بلادرنگ) رفتار سیستم را مانیتور کرد چرا که در این پروسه همه چیز به صورت خودکار صورت می‌گیرد و بدیهی است که نیاز به ابزارهایی داریم تا چنانچه به هر دلیلی مشکل روی سرور ایجاد شد،‌ از طریق نوتیفیکیشن‌های مختلف از آن مطلع گردیم.

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