مقدمه: استرس ساعت ۲ شب و آپلود کردن

تصور کنید که در حال انجام یک تغییر خاص بوده اید و بالاخره یک باگ لعنتی را در پروژه مشتری پیدا کردید. الان باگ حل شده و با خوشحالی فقط باید تغییرات را آپلود کنید. خب طبیعتا نرم افزار ftp مثل  (FileZilla)  را باز می کنید و به سرور متصل می شوید و در محل مورد نظر فایل تغییر داده شده را آپلود می کنید. یک لحظه شک می کنید که آیا باید فایل های قبلی را پاک کنم یا نه؟ نکند تغییرات در جایی تاثیر گذاشته است و من حواسم نیست و آن را فراموش کرده ام. با ترس بر روی دکمه upload می زنید و بعد از این که سایت را refresh می کنید می بینید که سایت خطا می دهد. در این حالت قرار بود که آپلود بکنید و بعد بخوابید ولی انگار نقشه تغییر کرده و باید دنبال محل خطا و دلیل خطا بگردید و شب بیداری ادامه می یابد.
این حالت بین اکثر توسعه دهنده هایی که به صورت دستی آپلود می کنند پیش می آید و یکی از پر استرس ترین و خطرناک ترین و وقت گیرترین کارهای دنیاست. چون نمی دانید تا کی ادامه می یابد و کی درست خواهد شد.
اما بدانید که راهی برای حل این مشکل وجود دارد. تصور کنید راهی وجود داشته باشد که یک  دستور در ترمینال تایپ کنید و یک ربات هوشمند به صورت اتوماتیک کدهای شما را تست کند بعد بیلد کند و بدون این که خطایی پیش بیاید آنها روی سرور آپلود کند. این عمل امروزه به CI/CD معروف است. در این مطلب می خواهیم به زبان ساده توضیح بدهیم که CI/CD چیست و چرا آپلود کردن دستی کدها و فایل های پروژه کاری اعصاب خورد کن و وقت گیر است.

چرا نباید به صورت دستی (ftp) کدها را آپلود کنیم؟

شاید با خودتان بگویید که "من فقط قرار است که دوتا فایل php یا js ساده آپلود کنم. این دیگه این همه دنگ و فنگ نمی خواد" ولی بدانید که حتی برای پروژه های کوچک هم این کار اشتباه است. به دلایل زیر:

1.شما انسان هستید و انسان اشتباه می کند.

خیلی وقت ها پیش می آید که ما یک مسئله جزئی را فراموش می کنیم. کار توسعه نرم افزار کاری است که هم با جزئیات و هم با کلیات درگیر هستیم و شاید یک مسئله جزئی را فراموش کنیم و این باعث اشتباه خواهد شد. مثلا ما در پروژه فایل config را تغییر داده ایم ولی فراموش کرده ایم که وقتی آپلود می کنیم فایل config جدید را آپلود کنیم. یا فایل style.css را در پوشه اشتباه کپی می کنیم و یا ممکن است که هنگام آپلود اینترنت به مشکل بخورد و فایل به درستی آپلود نشده باشد یا پوشه یا فایل هایی که نباید آپلود شوند را آپلود کنیم مثل پوشه .env
هرکدام از این خطاهایی که گفتیم یک اشتباه کوچک است اما باعث به هم ریختن و خطا در سایت خواهد شد و باعث می شود مشتری و کارفرما از دست شما عصبانی باشد و مشکل پیش بیاید و شب ها نخوابید و اعصابتان خورد شود.

2.وقت شما با ارزش است.

فرض کنید که هر بار آپلود دستی برای شما چقدر طول می کشد؟ 5 دقیقه؟ 10 دقیقه؟ فرض کنید که اصلا به خطا هم برخورد نکنید اگر روزی مثلا 3 بار آپلود داشته باشید ماهی 15 ساعت شما در گیر آپلود و تست سایت بوده اید. تازه همانظور که گفتم اگر بدون خطا باشد. این زمان را می توانستید صرف کار دیگر یا استراحت بکنید ولی داشتید فایل جا به جا می کردید.

3.مشکل "روی سیستم من کار می کرد!"

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

4.امکان باگشت(Rollback) وجود ندارد.

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

حال CI/CD چیست؟

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

بخش اول (CI) یا continuous integration (یکپارچه سازی مداوم)

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

1.کد شما را با کد اصلی ادغام می کند.
2. به صورت اتوماتیک تمام تست ها را اجرا می کند. (همان تست هایی که قبلا نوشته شده است تا مطمئن شویم که برنامه به صورت کامل کار می کند.) 
اگر حتی یک تست هم با خطا مواجه شود CI جلوی شما را می گیرد و به شما اعلان می کند که باید کدتان را اصلاح کنید چون که باعث خرابی در جایی از برنامه شده است. 
نتیجه استفاده از CI این است که باگ ها در زمان افزودن کد شما به برنامه اصلی کشف می شوند. این خیلی بهتر از آن است که هنگام ارائه به مشتری و یا کارفرما باگ کشف شود و همه چیز خراب شود.

بخش دوم CD یا Continuous Deployment/Delivery به معنی تحویل یا استقرار مداوم

اگر بخواهیم این بخش را به زبان ساده بگوییم می شود: «اگر کد شما از تست ها سالم بیرون آمد آن را برای ارائه به مشتری روی سرور آپلود کن»
این بخش ادامه کار CI است. وقتی CI تایید کرد که کدتان تمیز است و تست ها هم پاس شده اند نوبت به CD می رسد. عملی که در بخش CD انجام می شود عبارتند از:

1.کد شما را بیلد (Build) می کند. یعنی برنامه شما را به نسخه قابل اجرا روی سرور تبدیل می کند. (مثلا فایل های سی شارپ یا جاوا را کامپایل می کند یا فایل های react را فشرده می کند و یا ایمیل داکر را می سازد.)
2.نسخه بیلد شده را روی سرور دیپلوی (deploy) می کند. یعنی همان کاری که قبلا به صورت دستی با ftp انجام می دادیم به صورت اتوماتیک و امن انجام می شود و فایل های مورد نظر آپلود می شوند.

نکته: در Continuous Delivery ربات همه چیز را آماده می کند و منتظر اجازه شما می ماند تا روی سرور اصلی آپلود کند ولی در Continuous Deployment اگر تست ها پاس شوند بدون اجازه مستقیم نسخه بیلد شده را روی سرور اصلی قرار می دهد.

به صورت ساده یک پایپلاین(Pipeline) ساده CI/CD چطور کار می کند؟

مراحل اتوماتیک CI/CD که در مورد آنها صحبت کردیم را چون مرحله به مرحله اجرا می شوند را پایپلاین یا خط لوله می نامیم. حال در این بخش می خواهیم یک سناریو ساده برای این مراحل را پیش ببریم.
1.قدم اول: شما به عنوان توسعه دهنده یک قابلیت جدید مثل دکمه لایک را برنامه نویسی می کنید و آن را در گیت پوش می کنید.
2.قدم دوم شروع پایپلاین: ابزار CI/CD که استفاده می کنید مثل Github actions , Gitlab CI یا Jenkins متوجه پوش کردن شما می شود و اتوماتیک شروع به اجرا می کند.
3.قدم سوم: مرحله تست (Test): در این مرحله تست هایی که برای این ویژگی لایک کردن نوشته اید اجرا می شود ببیند این قابلیت درست کار می کند یا خیر و همچنین تست های قبلی هم که برای بقیه قسمت های برنامه نوشته شده است هم اجرا می شوند تا مشخص شود که این قابلیت جدید بقیه قسمت های برنامه را خراب نکرده باشد. اگر تست خطا داشته باشد و پاس نشود پایپلاین متوقف می شود و به شما خطا اعلان می شود. اما اگر تست ها پاس شوند به مرحله بعد می رویم.
4.قدم چهارم: بیلد (Build): در این مرحله برنامه شما بیلد و کامپایل و بسته بندی می شود و فایل های نهایی آماده می شوند.
5.قدم پنجم: استقرار (deploy): با یک روش امن (ftp نه) به سرور متصل شده و نسخه جدید و بسته بندی شده جایگزین نسخه قبلی خواهد شد.

با این روش  ها شما فقط عمل پوش را انجام داده اید ولی بقیه کار ها را پایپلاین انجام داده و تغییرات روی سرور قرار گرفته اند.

چطور می توانم یک پایپلاین CI/CD داشته باشم؟

ابزارهای مدرنی مثل Github actionsو Gitlab CI/CD این کار را راحت کرده اند. شما فقط یک فایل متنی ساده بافرمت yaml می نویسید و مراحل گفته شده را در آن تعریف می کنید و این ابزار ها پایپلاین را برای شما راه اندازی می کنند و مراحلی که شما از آنها خواسته اید را مرحله به مرحله اجرا می کنند.

نکته مهم
در مراحلی که گفته شده علاوه بر برنامه نویسی که یک مرحله خیلی مهم در پایپلاین وجود دارد و بدون آن CI/CD عملا مشکل دار و بی معنی است. و آن مرحله تست است. برنامه شما باید روی بخش های مختلف تست داشته باشد و جزء به جزء‌ برای آن تست نوشته باشید. کاری که خیلی از توسعه دهندگان برای انجام آن بهانه می آورند و یا آن را پشت گوش می آندازند ولی وقتی گیر می افتید تست ها شما را نجات خواهند داد. امروزه هم که با استفاده از هوش مصنوعی می توانید سریع تر برای بخش های مختلف برنامه تست بنویسید. پس تست نوشتن و مهارت تست نویسی را هرگز فراموش نکنید.
می توانید همین الان یک پروژه تعریف کنید و آن را در گیت هاب پوش کنید و برای آن یک پایپلاین راه اندازی کنید و مراحل آن را متوجه شوید.