[ad_1]
قدیمترها، برای توسعه و انتشار هر نسخۀ جدید نرمافزار، نیاز بود که چندین نفر، ساعتهای زیادی زمان صرف کنند؛ از توسعهدهندهها گرفته تا افرادی که نرمافزار را تست، بررسی و باگهای آن را گزارش میکردند!
قسمت دوم کار که به آن Operation هم میگویند، گاهی حتی بیشتر از توسعه (Development) نرمافزار زمان میگرفت.
بالاخره در سال ۲۰۰۱، ۱۷ نفر از مهندسان نرمافزار دور هم جمع شدند و مانیفستی ۱۲ بندی را، برای توسعۀ نرمافزار به روش چابک (Agile) ارائه کردند.
شیوۀ اجایل، مشکلات قدیمی مثل انعطافپذیر نبودن پروژه، دخالت کم مشتری و نبودن قابلیت تغییر را از سر راه برداشت و میشود گفت که انقلابی در شیوههای مدیریت پروژه ایجاد کرد. اما …
همچنان درگیری بین تیم توسعهدهندهها و تیم عملیات زیاد بود. چون هنوز تیم توسعه باید کدها را برای استقرار و پشتیبانی، در اختیار تیم عملیات میگذاشتند.
در سال ۲۰۰۸، آقای اندرو کلی شافر، به همراه پاتریک دبویز، رویدادی به اسم DevOpsDays را در بلژیک راهاندازی کرده و از شیوۀ جدیدی به نام DevOps برای مدیریت هرچه بهتر و چابکتر پروژههای نرمافزاری، صحبت کردند.
حالا اینکه DevOps چیست، چه تاثیری در روند توسعۀ نرمافزار دارد و اصلاً کار DevOps را به دست چه کسانی باید سپرد، سوالیهایی هستند که در این مقاله پاسخ خواهیم داد.
فعلاً بیایید از تعریف DevOps شروع کنیم.
DevOps یعنی چه؟
کلمه دواپس از دو بخش تشکیل شده: Dev + Ops
Dev مخفف Development (به معنی توسعه) و Ops مخفف Operation (به معنی عملیات) است.
پس DevOps چیست؟ دواپس، پلی است بین تیم توسعه و تیم عملیات (یا IT) که با روشهای جدید و اتوماتسازی برخی عملیات، انجام کارها را سریعتر کرده و محصول را به نیاز مشتری نزدیکتر میکند.
در فرآیند DevOps کار تیم توسعه با تولید و انتشار نرمافزار تموم نمیشود؛ بلکه بعد از اجرای نرمافزار توسط مشتری و بهکار گرفته شدن، میشود گفت که کار تمام است.
DevOps تکاملیافتۀ همان روش اجایل (Agile) است و مزایای آن را دارد. پیشنهاد میکنم برای آشنایی بیشتر با این شیوه، مقالۀ مدیریت پروژه به روش چابک رو مطالعه کنید.
حالا چرا DevOps مهم شد؟
تغییر بر اساس نیاز مشتری و تحولات بازار، یک ویژگی حیاتی برای کسبوکارهای حوزۀ IT محسوب میشود. اگر در این حوزه فعالیت میکنید، حتماً میدانید که باید سریع همسو با تغییرات بهروز شوید و نسخههای جدید را رو کنید؛ وگرنه شانسی در این رقابت نخواهید داشت.
قبل از اینکه DevOps معرفی شود، ارتباط ضعیف بین تیمهای تضمین کیفیت، اجرا و تیمهای توسعه، باعث میشد که فرایندهای تست، انتشار و تحویل زمانبر شوند! بین خودمان بماند، ولی خیلی مواقع بود که تیمها تقصیر را گردن یکدیگر میانداختند و خب چون مرز کارها نزدیک به هم بود، نمیشد نظارت دقیقی کرد.
DevOps مرز بین این تیمها را برداشت و با اتومات کردن خیلی از روالهای تکراری، تحویل ارزش به مشتری را سریعتر و چابکتر کرد.
دقیقاً چه بخشهایی بعد از DevOps با هم ادغام شدند؟
همانطور که گفتیم، دو فرآیند توسعه (Dev) و عملیات (Ops) و بعد از رویداد DevOps، با هم ترکیب شدند. اما این دقیقاً یعنی چه؟ این فرآیندها، شامل چه بخشهایی بودند؟
در اینفوگرافیک زیر میتوانید راحت متوجه جواب این سوال شوید.
در مجموع، تیم توسعه (Development) مسئول بررسی عملکرد برنامه، آنالیز رفتار کاربران، کیفیت کدها و خطاهایی موجود در سطح کدنویسی است. در مقابل، تیم عملیات، مسئول در دسترس و قابل اجرا بودن برنامه، مناسب بودن زیرساختها و تنظیم آنها، رفع خطاها قبل از ارائه به مشتری و آنالیز عملکرد برنامه هستند.
با مدل CALMS آشنا شوید
خب، قبل از اینکه از DevOps استفاده کنید، بهتر است بدانید که با استفاده از این روش، از ۵ جنبه مختلف، تیمتان دچار تغییراتی خواهد شد. این ۵ جنبه را در یک مدل به اسم CALMS جمعبندی کردهاند، که در ادامه بهصورت خلاصه آن را مرور میکنیم.
CALMS چیست؟
CALM از سرواژه کلمات Culture، Automation، Lean، Measurement و Sharing گرفته شده است و در واقع یک چارچوب (Framework) کاربردی، برای مدیریت تمام جوانب DevOps است. بیایید این ۵ کلمه را بررسی کنیم و ببینیم که هر کدام چه معنی دارند.
Culture: فرهنگ
DevOps یک فرهنگ است. در این فرهنگ، بین افراد و تیمها دیواری وجود ندارد و همه چیز یکپارچه مدیریت میشود. در فرهنگ DevOps، هیچ هدفی با بقیه اهداف متضاد نیست؛ بلکه اهداف خُرد، در یک راستا به تحقق هدف اصلی کمک میکنند.
Automation: اتوماسیون
DevOps در برگیرنده دو مفهوم «یکپارچگی مستمر» و «تحویل مستمر» است. وقتی که فعالیتی مستمر است، بهترین کار این است که فرآیند را خودکار (اتومات) کنیم.
پس میشود گفت که اتوماسیون، بخش جدانشدنی DevOps است. با اتوماسیون، خطاهای انسانی کاهش پیدا کرده و سرعت انجام کارها چندین برابر میشود.
Lean: کاهش فعالیتهای غیرضروری
Lean در لغت به معنی ناب است؛ اما اگر بخواهیم در یک عبارت ملموستر آن را توصیف کنیم، میشود: هنر به حداقل رسیدن کارهای پیچیده و غیرضروری.
در DevOps باید بدون تعارف، با هر فرآیندی که به تولید ارزش منتهی نمیشود، خداحافظی کنیم. مسلماً انجام این کار، نیازمند آموزش و توانمندسازی تیم و همچنین یکپارچگی آنها است.
Measurement: اندازهگیری
همهچیز باید زیر نظر باشد. از سختافزارها و لایههای زیرساخت گرفته تا عمکلرد نرمافزارها. از نرخ تبدیل مشتریان گرفته تا تعداد باگهای هر نسخه. فقط با اندازهگیری مداوم است که میشود یک سیستم را چابک کرد. جمعآوری دادهها و تحلیل آنها، به تیمها کمک میکند که بهترین تصمیمها را بگیرند؛ مخصوصاً در مواقع حساس!
Sharing: اشتراکگذاری
DevOps برای این بهوجود آمد که شکاف بین تیم توسعه و عملیات را پر کند. تیمهای چابکی که از روش DevOps استفاده میکنند، باید تجربیات خود را به یکدیگر منتقل کنند تا تمام تیم باهم، رشد کنند و به هدف برسند.
DevOps، چه فرقی با CI/CD و Agile دارد؟
CI/CD مخفف Continuous Integration / Continuous Delivery است. حالا این یعنی چه؟
بخش اول این عبارت (یعنی Continuous Integration)، بهمعنی ادغام مستمر است.
برنامهنویسها، معمولاً کدهای خود را در یک مخزن، مثل GitHub، CodeCommit، Bitbucket و … بارگذاری میکنند. سپس این مخزن، کدها را تست کرده و Build میکند (Bulid کردن به معنی کم کردن حجم کدهاست). این کار برای این است که مطمپن شوند کد کار میکند؛ در صورتی که خطایی وجود داشته باشد، برنامهنویسها فیدبک گرفته و خیلی زود میتوانند کدها را بهتر یا باگها را رفع کنند.
به بخش دوم این عبارت، یعنی Continuous Delivery میرسیم. این عبارت به معنی استقرار مستمر است.
برنامهنویسها، بعد از مرحلۀ قبلی، نیاز دارند که بدانند برنامۀ Build شده قابل ارائه و انتشار رسمی هست یا نه؟ اصلاً عملیات استقرار (Deploy) با سرعت انجام میشود؟ مانعی در این مسیر نیست؟
اگر مانعی بر سر راه استقرار پروژه نباشد، برنامهنویسها می٬توانند بهجای ۳ تا Deploy در ماه، ۵ تا Deploy در روز انجام دهند. واضح است که چنین عملیاتی، بدون اتومات کردن فرآیند امکان ندارد. در روش CD برای این استقرار مداوم برنامه، از تکنولوژیهایی مثل CodeDeploy، Jenkins CD و Spinnaker استفاده میشود. تصویر زیر را ببینید.
همانطور که میبینید، در ادامۀ فرآیند CI/CD، برنامه بعد از Build به Deployment Server فرستاده شده و در نسخههای مختلف، Deploy میشود.
اگر دوست داشتید درباره CI/CD بیشتر بدانید، این ویدئو را در یوتیوب تماشا کنید؛ مفاهیم اصلی در این ویدئو، خیلی ساده توضیح داده شدهاند.
خب حالا که با CI/CD آشنا شدید، با نگاهی به جدول زیر میتوانید تفاوت آن را با DevOps و Agile ببینید.
توجه کنید که هر ۳ مورد بالا، ابزارها و روشهایی برای مدیریت پروژه هستند و زمانی بهترین کارایی را خواهند داشت که در کنار یکدیگر استفاده شوند.
اگر موافق باشید، دوباره برگردیم سراغ دواپس.
DevOps به درد چه کسانی میخورد؟
اگر دوست دارید که یک تیم قوی داشته باشید که خیلی سریع، بر اساس بازخورد کاربران و تغییرات بازار، خودش را بهروز میکند، DevOps به درد شما میخورد. برعکس، اگر همهچیز در تیم شما بهصورت دستی پیش میرود و سازمان اجازه اتومات کردن برخی فرآیندها را نمیدهد، DevOps به دردتان نمیخورد.
برای شروع DevOps چه کار کنیم؟
ببینید، همانطور که پیشتر هم گفتیم، دواپس یک شیوه و یک فرهنگ است که باید درون سازمان شما پیاده شود؛ پس فراموش نکنید که این کار نیاز به آموزش هم دارد! شما برای شروع میتوانید با کارشناسان DevOps صحبت کنید، از آنها راهنماییهای لازم را بگیرید و در صورت نیاز نیروی متخصص استخدام کنید.
ما هم یک کتاب خوب برای یادگیری بیشتر DevOps برایتان آماده کردهایم. نام کتاب DevOps به زبان آدمیزاد است و با لحنی روان و ساده (و البته به زبان انگلیسی) همهچیز را شرح داده است. برای دانلود کتاب کافی است روی آیکون زیر کلیک کنید.
حرف آخر
گفتنیهای اصلی را گفتیم. حالا دیگر میدانید که دواپس چیست و چه کمکی به بالا بردن بهرهوری تیمتان میکند. به عنوان آخرین نکته، بد نیست بدانید که استفاده از DevOps در هر سازمانی، تنها با فرهنگسازی و متعهد بودن اعضای تیم به آن، امکانپذیر است!
در صورتی که از دواپس در سازمانتان استفاده میکنید، خوشحال میشویم که تجربه خود را به ما بگویید. اگر هم سوالی داشتید، مثل همیشه آماده پاسخگویی هستیم.
[ad_2]