Continous Integration
متاسفانه نمی تونم کامل و با ترتیب درستی به مطالب بپردازم اما خب سعی می کنم ساده ترین شکل هم شده این مطالب رو ادامه بدم. شاید این کار به این مطلب هم بی ربط نباشه. بهتره تغییرات رو کم کم انجام داد و خروجی های کوچک و تغییرات رو اضافه کرد و سریع تر Feedback گرفت و در صورت اشکال مسیر رو تصحیح کرد، گاهی ساده گرفتن بهتر از انتظار برای کامل بودنه.
- CI در لغت به معنای یکپارچه سازی مداوم هست. می شه CI رو یکی از مهم ترین و پایه ای ترین تمرین های DevOps نام برد. تمرینی که با عنوان Start of DevOps awesomeness هم معرفی شده. واطلاعات و فایل های مورد نیاز رو برای مراحل بعدی Pipeline تولید و آماده می کنه.
CI مثل تمام مفاهیم DevOps صرفا یک تمرینه نه یک ابزار. تمرینی که کمک می کنه اعضای یک تیم (دراین مورد خاص صرفا تیم Develop) با پیاده کردن یک فرهنگ درست تر بتونن با سرعت، مسئولیت و از همه مهم تر همکاری بیشتر محصول باکیفیت تری رو برای ارائه به مشتری تولید کنند.
این تغییرات در تیم ها با آموزش فرهنگ و پیاده سازی Automation قابل دستیابی است. طبق شکل زیر مهم ترین فرایند هایی که در DevOps Pipeline باید Automate باشند رو معرفی می کنه.
برای پیاده سازی CI لزوما Automated Build باید راه اندازی بشه و Automated Test در عمل می تونه پیاده سازی نشه اما در صورت پیاده سازی نشدن مزایای Automated Test از دست رفته و نمی شه گفت CI درستی راه اندازی شده.
مزایای Automated Build:
Works on my box
اگر در تیم تولید نرم افزار کار کرده باشید قطعا جمله "روی سیستم من درست کار می کنه " رو بعد از پیدا شدن خطا در نرم افزاری که به محیط تست یا محیط عملیات رفته باشه رو از developer شنیدین. این مورد با یکی از شرایط زیر اتفاق می افته:
· نادرست بودن Configuration:
این مورد در صورت متفاوت بودن محیط Deploy شده با محیط Develop به وجود می آد. مثل متفاوت بودن آدرس پایگاه داده ها و یا سرویس های مورد استفاده.
· خطا در Integration
ممکنه کدی که یکی از اعضای تیم به محصول اضافه کرده باعث بروز خطا در کد دیگران شده باشه و درسیستم توسعه دهنده ای که Publish رو ارائه داده دریافت نشده باشه.
· نادرست بودن Deployment
ممکنه در فرایند عملیاتی کردن محصول یکی از موارد درست انجام نشده باشه. دسترسی ها لحاظ نشده باش و یا اطلاعات پایه مورد نیاز در پایگاه داده وارد نشده باش.
تمام این موارد با Automated Build قابل بررسی و تصحیح هستند.اگر شما Automated Build رو راه اندازی کرده باشید بعد از هر بار که توسعه دهنده کدی رو به Version Control اضافه می کنه که Push یا Checkin نامیده می شه یک Event برای Build پروژه صدا زده می شه. فرایند Build در این قسمت صرفا به تولید فایل های Binary پروژه اطلاق نمی شه بلکه یک اصطلاحه که به فرایندی گفته می شه که عملیات مختلفی رو شامل می شه. عملیاتی مثل دریافت آخرین نسخه از کد نرم افزار روی Version Control، Build پروژه و ساخت فایل های باینری که ضروری هستند و مراحل دیگری مانند Configuration ، Testing و غیره که توسط طراح Build Definition معمولا به این فرایند اضافه می شه و با هر بار اضافه شدن کد به Version Control عملیات تعریف شده در Build اجرا می شن.
فواید Automated Build:
· کد ها روی سیستم Developer اجرا نمی شوند و خطای Works on my box در کمترین زمان قابل شناسایی است.
· امکان قضاوت بی طرفانه رو به سیستم اضافه می کنه. )این اصطلاح ترجمه Unbiased Judge هست اما بیشتر معنای بررسی در فارسی رو در بر داره، در DevOps سعی می شه که مشکلات پیدا رو رفع بشن و پیدا کردن مقصر هدف و ملاک نیست(
· اگر هر یک از مراحل Build یا Test ناموفق باشند عملیات Rollback می شود و به اعضای تیم اطلاع رسانی می شود.
· نیاز مستقیم به انسان ها برای این فرایند از بین می رود و منابع تیم آزاد تر هستند.
Automated Test:
وجود باگ یکی از نگران کننده ترین موارد برای برنامه نویسان و کل تیم ارائه دهنده محصول است. چرا که باگ ها می تونن اعتبار محصول رو خدشه دار کنن و مسئولیت زیادی رو برای اعضای تیم بوجود میاره. نسبت سرعت کشف باگ و خدشه ای که به محصول وارد می شه رو می شه بصورت زیر در نظر گرفت.
1. اگر باگ پیش از checkin توسط developer کشف شود و رفع بشه باسرعت بالا و کم ترین هزینه خطا از بین می ره.
2. اگر باگ توسط تیم QA پیدا شود، مستند شود و برای developer ارسال شود تا رفع شود زمان و هزینه بیشتری به تیم تحمیل می کند.
3. اگر باگ توسط EndUser کشف شود و در صورت اطلاع رسانی به تیم Support و عدم انصراف مشتری از استفاده از نرم افزار تا رفع نهایی آن بیشترین هزینه و اتلاف وقت و خسارت به اعتبار تیم بوجود می آید.
استفاده از Automated Test کمک می کنه از شماره 3 موارد بالا به شماره 1 حرکت کنیم. مهم نیست Automated Test با چه ابزاری پیاده سازی می شود. مهم اینه که چطور از اون استفاده می کنید. مهم ترین اتفاق جا افتادن این فرهنگ است که بعد از هر بار وقوع خطا از وقوع مجدد آن جلوگیری و نحوه رفع آن به باقی تیم آموزش داده بشه.
با تشکر فراوان از دوستانی که در مورد مطلب قبل من رو راهنمایی کردن.
مطلبی دیگر از این انتشارات
راهنمای سریع کتابخانهی mPDF (ساختن PDF در php)
مطلبی دیگر از این انتشارات
Rewrite Mapping
مطلبی دیگر از این انتشارات
آموزش زبان برنامهنویسی Rust-قسمت3:معرفی آرایه, تاپل, کاراکتر و مقادیر بولی