بله
امیلی فریمن در کتاب DevOps برای همه به معرفی دواپس و چگونگی استفاده از آن برای همکاری بهینه‌ی تیم توسعه نرم‌افزار و عملیات در کنار یکدیگر پرداخته است. این کتاب از مجموعه‌ی دامیز می‌تواند اطلاعات مفیدی درباره‌ی دواپس به افراد کاملا مبتدی تا پیشرفته ارائه دهد.
درباره‌ی کتاب DevOps برای همه
امروزه با وجود پیشرفت سریع سخت‌افزارها و نرم‌افزارهای مختلف، دیگر لزومی ندارد که نگران کامپیوترهایمان باشیم. بلکه چیزی که در این میان اهمیت بیشتری پیدا می‌کند، انسان‌ها هستند. دواپس (DevOps) که از اصول مدیریت چابک (Agile project management) برگرفته شده است، به سیاست‌هایی اشاره دارد که بازدهی عملیاتی شرکت‌های فناوری اطلاعات را بالاتر می‌برد. امیلی فریمن (Emily Freeman) در کتاب DevOps برای همه (DevOps For Dummies) دواپس را به‌عنوان یک فلسفه در مهندسی به مخاطبان خودش می‌شناساند. مهم نیست که این واژه را برای اولین بار شنیده یا مهندسی باشید که سال‌ها با این فلسفه سر و کار داشته، در کتاب DevOps برای همه با ابزارها و روش‌های متداول برای پیاده‌سازی دواپس آشنا می‌شوید و همچنین می‌بینید که دواپس چگونه با فرهنگ سازمانی و پیوند میان تیم‌های توسعه نرم‌افزار و عملیات می‌تواند کیفیت خروجی را به‌شکلی قابل‌توجه بهبود بخشد.
کتاب DevOps برای همه نوشته‌ی امیلی فریمن را می‌توانید با ترجمه‌ی رامین مولانا پور و عفت عالی مراد خرم آباد در انتشارات آتی‌نگر بخوانید.
کتاب DevOps برای همه برای شما مناسب است اگر
- توسعه‌دهنده‌ی نرم‌افزار یا مدیر پروژه‌های نرم‌افزاری هستید.
- به مباحثی درباره‌ی رایانش ابری و اتوماسیون علاقه‌مندید.
- مشتاقید بدانید دواپس چطور باعث افزایش سرعت و کیفیت همکاری‌ها در تیم‌های نرم‌افزاری می‌شود.
در بخشی از کتاب DevOps برای همه می‌خوانیم
اصطلاح «انتقال به چپ» برای اولین بار در دهه 1990 ظاهر شد، زمانی که افراد متوجه شدند که روش توسعه آبشاری، نرم‌افزار ضعیف‌تر و محصولاتی را که اغلب نیاز به اصلاحات پرهزینه دارند به بازار روانه می‌کند. مشکل این بود که آزمون در چرخه حیات توسعه نرم‌افزار خیلی به سمت راست یا دیر انجام می‌شد. این درک دیگر فقط در مورد آزمون صدق نمی‌کند. مهم است که عملیات (و سایر تخصص‌ها) را به سمت چپ منتقل کنید.
اگر در ادبیات توسعه‌ی دیگر جست‌وجو کنید، گه‌گاه با عبارت «حرکت به چپ» در رابطه با تیم‌هایی مانند عملیات، امنیت و تضمین کیفیت مواجه می‌شوید. این ایده صرفاً به انتقال کارهای تکمیل‌شده توسط این تیم‌ها به سمت چپ در خط توسعه یا زودتر در فرایند اشاره دارد. به‌طور سنتی، کار عملیات آخرین چیزی بود که هر کسی به آن فکر می‌کرد. بیشتر سازمان‌هایی که من برای آن‌ها کار کرده‌ام، تنها پس از توسعه کد، مرحله عملیات را انجام می‌دهند. این وضعیت تأسف‌بار است؛ زیرا، توانایی مهندسان عملیات را برای برنامه‌ریزی و طراحی صحیح زیرساخت برای پشتیبانی از کد سلب می‌کند.
بسیاری از نقص‌هایی که در تولید مشاهده می‌شوند، پرهزینه هستند و معمولاً 5000 دلار در دقیقه هزینه دارند. هزینه قطعی تولید شما متفاوت است، اما مهم نیست که چگونه آن را قطع کنید؛ به‌هرحال پرهزینه است. اغلب علت قطعی، نبود ثبات در زیرساخت‌های ما و همچنین، فرایند توسعه است. وقتی عملیات را زودتر وارد خط توسعه نرم‌افزار می‌کنید، به آن‌ها این فرصت را می‌دهید تا از حوزه تخصصی خود استفاده کنند تا بقیه تیم را درباره مواردی که باید به آن‌ها توجه کنند و نحوه بهترین آمادگی برای استقرار موفق نرم‌افزار، مطلع کنند.
