https://virgool.io/feed/@SaadatmandAmirH fa 2026-04-15 03:29:53 https://files.virgool.io/upload/users/5358/avatar/UE68Tp.png?height=120&width=120 https://virgool.io/@SaadatmandAmirH https://virgool.io/Software/continous-integration-yn62nmgwk9tr متاسفانه نمی تونم کامل و با ترتیب درستی به مطالب بپردازم اما خب سعی می کنم ساده ترین شکل هم شده این مطالب رو ادامه بدم. شاید این کار به این مطلب هم بی ربط نباشه. بهتره تغییرات رو کم کم انجام داد و خروجی های کوچک و تغییرات رو اضافه کرد و سریع تر 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 با چه ابزاری پیاده سازی می شود. مهم اینه که چطور از اون استفاده می کنید. مهم ترین اتفاق جا افتادن این فرهنگ است که بعد از هر بار وقوع خطا از وقوع مجدد آن جلوگیری و نحوه رفع آن به باقی تیم آموزش داده بشه.با تشکر فراوان از دوستانی که در مورد مطلب قبل من رو راهنمایی کردن. Amir Hosein saadatmand Amir Hosein saadatmand Thu, 12 Jul 2018 16:47:20 +0430 https://virgool.io/coderlife/devops-%DA%86%DB%8C%D8%B3%D8%AA-fssxro5ahhkq سلام من امیرحسینم و سعی می کنم در مجموعه نوشته هایی که قصد دارم تکمیلشون کنم در مورد DevOps و بطور خاص در مورد WinOps (که تو این حیطه کار می کنم) به زبان ساده بنویسم.چند سالی می شه که همه کم و بیش اصطلاح DevOps به گوشمون خورده و در موردش شنیدیم. خود من تقریبن یکسال پیش بود که این اصطلاح رو شنیدم و چند ماهی می شه که در موردش می خونم. اوایل با تعریف های مختلفی در موردش مواجه شدم. یکی می گفت DevOps همون اسکرامه. یکی می گفت DevOps زیر مجموعه ITIL هست. یکی می گفت DevOps حذف تیم های Test و Deploy از تیم های بزرگ نرم افزاریه و فقط تیم های Develop و Operation باقی می مونه و خیلی خیلی تعریف های دیگه که خیلی هاش از اساس غلط بود و خیلی های دیگه شبیه همون داستان فیل و اتاق تاریک مولانا بود که هر کسی یه قسمت از فیل رو لمس کرده بود و فکر می کرد فیل فقط همونه.امیدوارم چیز هایی که می گم اینطوری نباشه و اگر اشتباهی هم داشتم خواننده هایی باشن که تصحیحش کنن.DevOps در لغت به معنی Develop + Operation هست. و این مفهوم رو می رسونه که تیم های Develop و Operation باید به هم نزدیک تر باشن و تیم هایی با ساز و کار جداگانه و غیر همسو نباشند. اما اگر بخواهیم دقیق تر در موردش صحبت کنیم DevOps یک مفهوم یا یک تفکره که تمام مراحل تولید نرم افزار از لحظه ای که ایده (Idea) در تیم و یا خارج از تیم نرم افزاری بوجود میاد و در جریان تولید قرار می گیره تا لحظه ای محصول به دست مشتری نهایی (EndUser) می رسه و حتی بعد تر یعنی استمرار و پایایی محصول در ارائه خدمت به مشتریان رو شامل می شه. در واقع یک تفکر موفق در تولید نرم افزاره که حاصل تجربیات فراوان آزمون و خطا ها در چرخه تولید نرم افزار و حتی قبل تر از اون در چرخه تولید غول های صنعت (به طور بخصوص چند تا از اصطلاح های DevOps اصطلاحاتی هستند که در شرکت Toyota ابداع و استفاده شدند. اصطلاحاتی مثل Andon و Lead Time) آزمایش و استفاده شدند و با دیدن نتیجه این تفکرات بر روی تولید بعد ها توسط دیگران هم مورد استفاده قرار گرفتند.شکل زیر می تونه نمونه خوبی در توضیح DevOps و نحوه کار اون باشه. تصویر سمت چپ می تونه ناقص ترین درک ما و تصویر سمت راست درک جامع تری نسبت به این مفهوم باشه.هدف غایی DevOps رو می تونیم سریع تر شدن چرخه تولید و ارائه محصول به مشتری نام ببریم اما واقعا این مفهوم جامع تر از این حرف هاست.. اما یکی از مواردی که با پیاده سازی تفکر DevOPs در سازمان های ما خیلی می تونه مفید باشه همکاری و تعهد بین تمام تیم های یک سازمان در جهت تولید سریع تر و صحیح تر و ارزان تر محصول و رسوندن اون به دست مشتریه. تقریبن چیزی شبه به حرکت از تصویر شماره 1به تصویر شماره 2 هست.12در انتها اگر بخوام دقیق ترین تعریفی که از DevOps شنیدم رو انتخاب کنم باید بگم من تعریف زیر رو می پسندم.DevOps is a mindset plus a set of practices that focuses on automation, Deliver faster & more often with less work.در واقع Automation یکی از مهم ترین مواردیه که DevOps بر اون تاکید داره. برای توضیح Automation و فواید اون بطور ساده ترجیح می دم با شکل زیر شروع کنم. شکل زیر برای توضیح System Thinking مفهومی که در سال 1992 توسط جرالد وینبرگ ابداع شد و در کتاب Quality Software Management ارائه شد استفاده شده.در این شکل نشون داده می شه که اگر یک برنامه نویس یک Task برای انجام داده باشه 100% تمرکزش رو می تونه صرف این تسک بکنه اما اگر دو Task همزمان داشته باشه ناخودآگاه 20% تمرکزش وبازدهی ش رو از دست می ده و این روند تا جایی ادامه داره که اگر 5 Task همزمان داشته باشه 75% تمرکز و بازدهی مفیدش رو از دست می ده.این مساله چه تاثیری روی کسب و کار اون نهاد می ذاره. می شه گفت اگر اعضای یک تیم 5 Task همزمان داشته باشند و 75% بازدهی شون رو از دست بدن در طول یک هفته شنبه، یکشنبه، دوشنبه و نیمی از سه شنبه رو ازدست دادن و فقط روز چهارشنبه تولید موفقی خواهند داشت. MultiTasking فقط با اختصاص دادن چند Task همزمان به یک فرد بوجود نمیاد. در دنیای نرم افزار MultiTasking بصورت ناخودآگاه وارد کار می شه. فرض کنید یک برنامه نویس مشغول انجام یکی از Task هاش باشه. همزمان چند تا bug از Task های قبلیش بهش ارجاع داده می شه یا مجبوره یه مشکلی رو برای تیم QA حل کنه یا باید یه Patch جدید تولید کنه یا مشکل خاصی در سیستم های واحد Operation رو حل کنه و یا Release جدیدی رو ارائه بده. همینطوری MultiTasking وارد کارهای برنامه نویس می شوند بازدهی ش رو کاهش می دن. این اتفاق برای اعضای تیم های دیگه هم می افته . Automation اینجا کاربرد پیدا می کنه. اگر بشه موارد اینچنیین رو پیگیری Track کرد و کارهای تکراری رو به عهده ماشین ها گذاشت. بخش اعظمی ار اتلاف وقت ها از بین می ره و همینطور تمرکز افراد روی کارشون هم بیشتر می شه. باید بگم قطعن هیچوقت در دنیای واقعی کسی Single Task نمی شه اما اگر این عدد از 75 به 30 یا 40 هم برسه برای یک تیم تولید در عرصه رقابت موفقیت محسوب می شه.با کم شدن Multitasking و بالاتر رفتن تمرکز افراد تولید محصول سریع تر و همینطور فضای کار مطبوع تر خواهد شد.امیدوارم تونسته باشم این مفهوم رو برسونم که DevOps یک تعریف ساده و یا یک فعالیت خاص نیست.در مطالب بعدی سعی می کنم مجموعه ای از تعاریف و تمرین های های مختلف رو توضیح بدم و خیلی خوشحال می شم نظرات خواننده ها به من در نوشتن بهترشون کمک کنه و یا بتونم با دیگران در این کار شریک بشم. Amir Hosein saadatmand Amir Hosein saadatmand Tue, 03 Jul 2018 20:55:16 +0430