مفاهیم CI/CD و Pipeline، از ابتدا تا پیشرفته

به جمله زیر دقت کنید:

پایپ لاین CI/CD یکی از بهترین شیوه های پیاده سازی در تیم های devops به منظور دریافت تغییرات ایجاد شده در کد، بصورت مداوم و مطمئن است.

در ابتدا، باید قادر باشیم تا مفاهیم اصطلاحات بکار رفته در جمله کلیدی بالا را بطور کامل درک کنیم. بصورت خلاصه برای هر یک از آنها شرح کوتاهی خواهم آورد:

1- پایپ لاین (Pipeline)

در معنی لغوی و غیر اصطلاحانه، پایپ لاین به لوله های بلندی که معمولا در زیر زمین قرار داشته و برای جابجایی نفت و یا گاز استفاده شده و در متراژ طولانی تعبیه می شوند، گفته می شود. حال به دنیای مهندسی باز می گردیم. پایپ لاین را به توالی خطی ای از ماژول های مشخص می گویند که در جهتی مشخص در حال حرکت هستند.

مثلا در دنیای CPU ها، پایپ لاین، به وسیله ای درون CPU گفته می شود که CPU را قادر می سازد دستورات را قبل از اجرا بخواند، و در صورت تایید و به محض تکمیل و بعد از تحویل آن، دستور بعدی را بخواند.

2- معنی CI (Continuous Integration)

به معنی ادغام مداوم است. یک فلسفه در کدنویسی و مجموعه ای از اقدامات است که تیم های توسعه را به سمت پیاده سازی تغییرات کوچک و بررسی کدها در ریپازیتوری، آنهم بطور مداوم می برد. از آنجایی که اپ های پیشرفته کنونی در چندین پلتفرم و ابزار های مختلف اقدام به توسعه می کنند، لذا نیاز به مکانیزمی برای ادغام (integrate) و تایید (validate) تغییرات مختلف، اهمیت بالاتری پیدا می کند.

3- معنی (Continuous Delivery)

معنی لغوی آن تحویل مداوم میشود. CD زمانی ظاهر میشود که کار CI به اتمام می رسد. CD عملیات رساندن اپلیکیشن ها به محیط های زیرساختی را بطور اتوماتیک انجام می دهد.

4- وظیفه DevOps

وظایف DevOps ترکیبی از عملکردهای توسعه نرم افزار (Dev) و عملیات IT یا(Ops) است که هدف آن کوتاه کردن چرخه عمر سیستم ها و تحویل مداوم (CD) و باکیفیت نرم افزار است.

--------------------------

اکنون که با اصلاحات مورد نیاز، آشنا تر شدیم و درک بهتری از جمله کلیدی خودمان بدست آوردیم، به شرح بیشتر این موضوع می پردازیم.

مفاهیم CI و CD، تجسم یک فرهنگ است. مجموعه ای از قواعد و اقداماتی که تیم های توسعه اپلیکیشن را قادر می سازد تغییرات ایجاد شده در کدها را سریع تر و مطمئن تر بدست مخاطب برساند. پیاده سازی این قواعد و اقدامات را اصطلاحا CI/CD pipeline می گویند.

استفاده از CI/CD یکی از بهترین اقداماتی است که تیم های DevOps می توانند انجام دهند. همچنین اقدامی عالی در جهت روش های agile است که تیم های توسعه را قادر میسازد بر روی نیازهای منطقی پروژه، کیفیت کد و همچنین امنیت پروژه تمرکز کنند، چرا که مراحل توزیع پروژه بصورت اتوماتیک انجام می شود.

هدف بنیادی CI، دستیابی به راهی اتوماتیک و استوار برای ساخت (Build) ، پکیج (Package) و تست اپلیکیشن ها است. زمانی که فرایند ادغام باثباتی انجام شود، تیم ها راحت تر و با سرعت بالاتری می توانند تغییراتشان را اعمال کنند و باعث بوجود آمدن همکاری بهتر و کیفیت بالاتر نرم افزار می شود.

بسیاری از تیم ها از چندین محیط توسعه بجای استفاده تنها از محیط production استفاده می کنند. مانند محیط های development و محیط های testing. و CD اطمینان حاصل می کند که راهی اتوماتیک برای رساندن تغییرات کدها به این محیط ها وجود داشته باشد.

ابزارهای CI/CD پارامترهای مختص به هر محیط را ذخیره کرده و سپس هر سرویس مورد نیازی که باید در وب سرور ها، دیتابیس ها و ... استفاده شود را در زمان تحویل، صدا می زند.

ادغام مداوم (CI) و تحویل مداوم (CD) نیازمند آزمایش مداوم (continuous testing) است. چرا که هدف، رساندن اپلیکیشن های با کیفیت و کدهای جدید به کاربران است. آزمایش مداوم معمولا بعنوان مجموعه ای از رگرسیون ها و عملکردهای اتوماتیک در پایپ لاین CI/CD انجام می شود.

یک CI/CD بالغ و کامل، شامل گزینه پیاده سازی توزیع مداوم است، که تغییرات اپلیکیشن از طریق پایپ لاین CI/CD اجرا شده و build های تایید شده مستقیما در محیط های production توزیع می شوند. تیم هایی که با توزیع مداوم کار می کنند، انتخاب می کنند که با برنامه زمانی روزانه یا حتی ساعتی، به production اپلیکیشن را توزیع کنند، و حتی در برخی از تیم ها، توزیع دائمی، اختیاری نیست و حتما باید بصورت مرتب انجام شود.

ادغام مداوم (CI) چگونه کیفیت و کار تیمی را بهبود می بخشد؟

زمانی که CI در حال اجراست، توسعه دهندگان بطور مداوم کدهایشان را به ریپوزیتوری ورژن کنترل commit می کنند و اکثر تیم ها این استاندارد را دارند که کدها حداقل روزی یک بار باید commit شوند. بنیاد و پایه پشت این کار این است که شناسایی عیوب و سایر مشکلات کیفی نرم افزار در کدهایی که کمتر تغییر یافته اند، آسان تر است. علاوه بر این، زمانی که توسعه دهندگان روی چرخه عمر کمتری از commit ها کار می کنند، احتمال اینکه یک قطعه کد توسط چندین برنامه نویس بصورت همزمان ویرایش شود، کاهش یافته و نیاز به merge در زمان commit کاهش میابد.

تیم هایی که ادغام مداوم را اجرا می کنند، اغلب کارشان را با پیکربندی ورژن کنترل و تعاریف عملیات آغاز می کنند. اگرچه بررسی کدها مداوما و در فواصل زمانی کوتاه انجام می شود، feature ها و رفع عیب ها می توانند در فریم های زمانی کوتاه و بلند پیاده سازی شوند. تیم های توسعه از تکنیک های مختلفی برای کنترل feature ها و کدهایی که آماده برای production هستند، استفاده می کنند.

بسیاری از تیم ها از feature flag ها استفاده می کنند. که مکانیزم پیکربندی ای برای فعال سازی feature ها و کد ها در زمان اجرای اپ است. feature هایی که هنوز در حال توسعه هستند، با feature flag در کد مشخص شده و همراه با برنچ master راهی production می شوند. ولی تا زمانی که آماده برای استفاده نباشند، فعال و یا روشن نمی شوند. بر اساس آخرین نظرسنجی، 63 درصد تیم هایی که از feature flag ها استفاده می کنند، testing و کیفیت بالاتر و بهتری از نرم افزار را گزارش داده اند. ابزار feature flagging مانند CloudBees Rollout، Optimizely Rollouts و LaunchDarkly با ابزارهای CI/CD ادغام شده و پیکر بندی های بر پایه feature را ممکن می سازند.

یکی دیگر از راههای مدیریت feature ها، استفاده از برنچینگ در ورژن کنترل است. یک استراتژی برنچینگ مانند GitFlow برای تعریف پروتکل هایی است که مثلا در آن مشخص می شود کدهای جدید چگونه باید با برنچ های استاندارد ادغام شده و برای محیط های development یا testing یا production آماده شوند.

برنچ های feature دیگری برای آنهایی که زمان توسعه بیشتری نیاز دارند، ایجاد شده و زمانی که feature تکمیل شد، توسعه دهندگان می توانند تغییرات را از این برنچ ها به برنچ ابتدایی برده و ادغام کنند. این رویکرد نیز خوب است، اما مدیریت آنها می تواند مشکل ساز شود، اگر feature های زیادی بطور همزمان در حال توسعه باشند.

سپس فرایند build می تواند بوسیله جمع آوری نرم افزار، دیتابیس و اجزای دیگر بطور اتوماتیک انجام شود. فرض کنید اگر در حال توسعه یک اپ جاوا هستید، CI تمامی فایل های استاتیک وب سرور مانند HTML و CSS و جاوا اسکریپت را همراه با اپ جاوا و تمام اسکریپت های دیتابیس جمع آوری می کند.

نه تنها CI تمام اجزای نرم افزار و دیتابیس را جمع آوری می کند، بلکه این اتوماسیون می تواند unit test ها و سایر تست ها را بر روی آن انجام دهد. این فرایند تست می تواند به توسعه دهندگان آن کد بازخورد دهد که کدهای جدیدی که نوشته اند، نباید در هیچ unit test شکست بخورد.

بسیاری از ابزارهای CI/CD به توسعه دهندگان اجازه می دهد که build ها را بر اساس تقاضا شروع کرده، و آنها را با کدهای commit شده در ورژن کنترل درگیر کند یا می تواند این build در فواصل زمانی مشخصی انجام شود.

تست های مداوم، فراتر از تست اتوماتیک

فریمورک های تست اتوماتیک، به مهندسان کنترل کیفی کمک می کند که انواع مختلف تست ها را تعریف کرده، اجرا کنند و این کارها را به صورت اتوماتیک انجام دهند که به تیم های توسعه کمک می کند متوجه شوند که آیا build نرم افزار با موفقیت انجام شده است یا خیر؟ اینها شامل تست های عملکردی هستند که در پایان هر Sprint ،توسعه یافته و در تمامی اپ تست می شوند. این تست های رگرسیون، بررسی می کنند که تغییرات کد ایجاد شده توسط تیم در بخشی از نرم افزار شکست خورده یا خیر و آن را در تمام اپلیکیشن که تحت پوشش این تست است، بررسی می کنند.

بهترین اقدام، قادرسازی توسعه دهندگان برای اجرای تمام یا بخشی از تست های رگرسیون در محیط توسعه محلی خودشان است. با این کار، این اطمینان حاصل می شود که توسعه دهنده تنها زمانی کدهای خود را commit می کند که تست ها در برابر تغییر کدها، موفقیت آمیز بوده باشند.

آزمون regression تنها شروع کار است. تست های عملکردی، تست های API، آنالیز کدهای استاتیک، تست امنیت و سایر اشکال تست نیز می تواند اتوماتیک وار انجام شود. نکته کلیدی، توانایی اجرای این تست ها از طریق command line یا webhook یا وب سرویس ها است و این ها هستند که باید پاسخ مناسب موفقیت آمیز بودن یا عدم موفقیت را به تست کننده برگردانند.

به محض اینکه عملیات تست، اتوماتیک شد، تست مداوم دلالت بر این دارد که این اتوماسیون با پایپ لاین CI/CD ادغام می شود. برخی از تست های unit و عملیاتی می توانند با CI در حالی که issue flag دارند؛ ادغام شود. تست هایی که نیاز دارند در محیط نرم افزار کامل انجام شوند، مانند تست های عملکردی یا امنیتی، معمولا باید با CD ادغام شده و بعد از این که build ها به محیط توسعه هدف رسیدند، اجرا شوند.

-------------------------

پس CI/CD روشی برای تحویل مداوم اپ ها به مشتریان از طریق تعریف اتوماسیون در هر یک از stage های توسعه اپ است. مفاهیم اصلی موجود در CI/CD، ادغام مداوم، تحویل مداوم و توزیع مداوم است. CI/CD راه حل برای مشکلاتی است که در زمان ادغام کدهای جدید برای توسعه دهندگان یا تیم ها بوجود می آید.

تفاوت بین CI و CD چیست؟

همانطور که گفته شد، CI به ادغام مداوم اشاره دارد که فرایندی اتوماتیک برای توسعه دهندگان است. یک CI موفق، باعث خواهد شد تغییرات جدید در کدها، به صورت منظم Build شده، test شده و با یک ریپازیتوری مشترک merge شود. پس CI می تواند بعنوان راه حلی در برابر وجود تعداد زیاد برنچ ها بصورت همزمان باشد، که این امر امکان تداخل برنچ ها با یکدیگر را کاهش می دهد.

اما CD، به تحویل مداوم (continuous delivery) و توزیع مداوم (continuous deployment) اشاره دارد که مفاهیم مرتبط با یکدیگری هستند و برخی اوقات بجای هم استفاده می شوند. اما هر دوی آنها در مورد اتوماتیک سازی stage های پایپ لاین است.

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

توزیع مداوم، اشاره به انتشار خودکار تغییرات برنامه نویس از ریپازیتوری به production دارد، یعنی به جایی که برای مشتریان قابل استفاده است. پس تیم های اجرایی زمان کمتری نسبت به فرایندهای دستی توزیع محصول به کاربران مصرف می کنند.

درک اهمیت CI با یک مثال

در دنیای توسعه نرم افزار امروز، هدف، کار همزمان چندین برنامه نویس بر روی feature های مختلف اپ است. حالا فرض کنید سازمان تصمیم گرفته تا تمامی برنچ های ایجاد شده را در یک روز مشخص merge کند. نتیجه این کار، امری طاقت فرسا، دستی و زمانبر خواهد بود. و دلیل آنهم مشخصا این است که برنامه نویس برای توسعه feature تغییراتی را در کد اعمال خواهد کرد که احتمال تداخل با کدهای سایر برنامه نویسان دارد. این مشکل مخصوصا زمانی که هر توسعه دهنده IDE محلی خودش را استفاده کند، بجای اینکه از IDE های کلود استفاده کند، عمیق تر خواهد بود.

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