کیوان دمیرچی - Keivan Damirchi
کیوان دمیرچی - Keivan Damirchi
خواندن ۷ دقیقه·۴ سال پیش

CI/CD - قسمت 3 - مفاهیم مرتبط

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

داکر در طی فرایندهای CI/CD فواید بسیاری از جمله سرعت، اطمینان، ... را به توسعه دهندگان و سازمان می رساند
داکر در طی فرایندهای CI/CD فواید بسیاری از جمله سرعت، اطمینان، ... را به توسعه دهندگان و سازمان می رساند


داکر و داکرایز کردن سرویس ها

ابتدا در این پست تعریف ساده ای از داکر را با هم می خوانیم :

با استفاده از داکر به خوبی می‌توان مواردی که برای یک پروژه نیاز است را در کنار هم جمع‌آوری کرد و به صورت کامل آنها را در یک پکیج قرار داد. یعنی به اختصار هر آن چیزی که یک نرم‌افزار نیاز خواهد داشت اعم از پکیج‌های وابسته (Dependency Package) و کتابخانه‌ها (library) مورد نیاز در یک کانتینر آماده خواهد شد و همواره همراه نرم‌افزار در هر محیط که نیاز به راه‌اندازی دارد منتقل خواهد شد.

همانطور که مطالعه کردید، بطور کلی داکر یک تکنولوژی می باشد که یکی از مزایای آن امکان یکپارچه سازی وابستگی های یک سرویس یا نرم افزار است. برای درک عمیق تر داکر این پست را مطالعه کنید.

با توجه به وضعیت های مختلفی که در مراحل تولید و توسعه نرم افزارهای یک سازمان وجود دارد، ممکن است سازمان از تکنولوژی داکر در مراحل توسعه نرم افزار خود استفاده نکند، با در نظر گرفتن اینکه فرایند داکرایز کردن نرم افزارها برای انتشار و نگهداری نسخه های نرم افزاری بسیار با ارزش و سودمند می باشد، با داکرایز کردن نرم افزارهای و سرویس های سازمان، علاوه بر استفاده از فوایدی که داکرایز کردن به خودی خود دارد (از جمله سرعت لود بالاتر نسبت به ماشین مجازی و سیستم عامل ها، امکان تعیین میزان دلخواه سی پی یو و رم برای نرم افزار، قابل حمل بودن image ها، ...) از مزایای آن در انتشار نسخه های جدید نرم افزارها که یکی از اصلی ترین آن پیکربندی آسان تر و یکپارچه بودن با سیستم های رایج CI/CD است استفاده شود.


تست اتومات

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

در فرایند CI/CD می توان از انواع تست ها بهره برد و با سرعت بیشتری باگها و خطاهای سیستم را کشف کرد
در فرایند CI/CD می توان از انواع تست ها بهره برد و با سرعت بیشتری باگها و خطاهای سیستم را کشف کرد


از آنجا که وجود تست اتومات بعنوان یک مزیت برای CI/CD مطرح می شود، همانطور که ذکر شد توصیه می شود شروع اتوماسیون کردن تست ها بصورت ابتدایی و مرحله به مرحله به نرم افزارها و سرویس های موجود در سازمان اضافه شود. از جمله فوایدی که برای تست اتومات می توان برشمرد به شرح زیر می باشد :

  • دریافت بازخورد سریعتر و دقیق تر در هر فاز از پروژه به توسعه دهندگان و مدیران پروژه
  • بالا بردن کیفیت کدهای نوشته شده به جهت وجود خطاهای کمتر
  • مستندسازی کدها توسط برخی تست ها(تست های واحد)
  • پروداکتیو شدن هر چه سریعتر نرم افزار به جهت تست سریع تر
  • افزایش امنیت در حوزه قوانین تجاری و منطقی یک نرم افزار

Rollback کردن نسخه های منتشر شده

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

  • بازگردانی تغییرات با استفاه از انتشار نسخه قبلی(بازنشر نسخه قبل)، یکی از ساده ترین راه های پیش روی تیم توسعه این است که با استفاده از آخرین نسخه منتشر شده قبل از نسخه فعلی، وضعیت نرم افزار را به حالت قبل از انتشار شکست خورده ببرند. نحوه انجام آن نیز بدین صورت می باشد که با مراجعه به لیست Release های قبلی و انتخاب Release مورد نظر، به سادگی اقدام به بازگردانی به نسخه دلخواه نمایند. البته این روش در هر شرایطی پاسخگوی نیاز تیم توسعه نمی باشد، چرا که ممکن است نرم افزار به همراه سرویس های خارجی منتشر شده باشد و یا تغییرات مربوط به دیتابیس از قبیل تغییر نام جدول و .. اتفاق افتاده باشد. همانطور که ذکر شد، در صورت وجود تغییرات روی دیتابیس همراه با نسخه جدید، استفاده از این روش بطور کاملا روال بازگردانی را پوشش نمی دهد و قسمتی از فرایند بازگردانی در این روش نیازمند برگرداندن دستی تغییرات مربوط به دیتابیس می باشد.
  • برطرف کردن مشکل و انتشار مجدد نسخه، روشی عمدتا دستی اما منعطف تر می باشد که تیم توسعه قادر است بصورت دستی تغییرات اعمال شده را به حالت قبل از انتشار شکست خورده برگرداند و تغییرات مربوط به سرویس های خارجی و اسکریپت های دیتایس و ... اعمال نماید. گرچه ممکن است شرایط بازم هم مطمئن نباشد اما بصورت حداقلی می توان کارکرد نرم افزار را تا بعد از برطرف کردن مشکل تضمین کرد. این روش زمانی سودمند می باشد که تیم توسعه وقت کافی برای اصلاح خطای موجود داشته باشد و یا ابعاد خطای بوجود آمده آنقدر کوچک باشد که با صرف زمان اندک نسبت به رفع آن اقدام شود.
  • ترکیبی از دو روش قبل، بدین صورت که با فرض پیش بینی وجود خطا در انتشار نسخه، اقدام به تهیه اسکریپت های مرتبط با تغییرات جاری کرده و در صورت وجود خطا و با اجرای اسکریپت های اصطلاحا Rollback وضعیت را به حالت قبل از بروز خطا برگردانیم و بعد از برطرف کردن مشکل اقدام به بازنشر نسخه جدید کنیم. در کنار تهیه اسکریپت های Rollback، می توان اقدام به تعریف وظایف Rollback نیز نمود تا اسکریپت ها نیز به صورت خودکار برگردانده شوند. برای ایجاد اسکریپت های مربوط به Rollback می توان از نرم افزارهای موجود در زمینه کار با دیتابیس استفاده نمود. بطور مثال نرم افزار ApexSQL یک نرم افزار قدرتمند در زمینه رهگیری تغییرات دیتابیس و ... می باشد که به سادگی قابلیت بررسی تغییرات انواع مختلف نسخه های دیتابیس را می دهد. با توجه به استفاده تیم توسعه از CI/CD برای انتشار نسخه های نرم افزاری، می توان این پیشفرض را پذیرفت که میزان تغییرات مربوط به یک نسخه با نسخه قبل، به دلیل انتشار سریع نسخه ها، به اندازه ای کم است که زمان و انرژی چندانی از تیم های برای ایجاد اسکریپت های Rollback نمی گیرد.

مانیتورینگ عملیات های CI/CD

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

امکان ارسال اعلان در صورت وجود خطا در فرایندهای CI/CD یکی از مزیتهایی مورد علاقه راهبران سیستم می باشد.
امکان ارسال اعلان در صورت وجود خطا در فرایندهای CI/CD یکی از مزیتهایی مورد علاقه راهبران سیستم می باشد.


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

در قسمت بعد بصورت عملی و با استفاده از Microsoft Azure Devops اقدام به اعمال CI/CD بر روی یک نرم افزار خواهیم کرد.

cicddockermonitoringdevops
توسعه دهنده نرم افزار
شاید از این پست‌ها خوشتان بیاید