من زمان زیادی را صرف بررسی چگونگی استفاده سازمانها از دواپس برای بهبود زمان چرخه تحویل نرم افزار ، توانایی نوآوری و توانایی بهبود کیفیت کرده ام. من شنیده ام که بعضی از مردم تا آنجا پیش می روند که می گویند دواپس جایگزین اجایل شده است ، اما فکر نمی کنم درست باشد. دواپس اجایل را تقویت و پشتیبانی می کند و اجایل همچنان در قلب دواپس است. ویژگی های اساسی اجایل – کار با مراحل کوچک (دسته ای) ، ارائه نرم افزار کارکننده به طور مرتب بر اساس اولویت های کاری ، کار در تیم های کوچک دارای عملکرد خودکار کوچک و اندازه گیری پیشرفت بر اساس نرم افزار کارکننده – برای کار دواپس ضروری است. به نظر من دواپس به صراحت آنچه که بسیاری از تیم های اجایل قبلاً آموخته بودند را بیان می کند اما ممکن است رسمیت نیافته باشد. دواپس همچنین اصول اجایل را به سایر قسمتهای سازمان بخصوص بخش عملیات (Ops) گسترش می دهد. در حقیقت ، اجایل و دواپس از نظر همزیستی و جدایی ناپذیری با هم ارتباط دارند.
بیانیه اجایل می گوید تیم های اجایل به نرم افزارهای که کار می کنند بیش از مستندات جامع اهمیت می دهند. این بدان معنی است که آنها نیاز به ساخت و تست نرم افزار دارند. زیاد. در واقع همه وقت. در حالت ایده آل ، آنها باید هر بار که تغییراتی در سورس کد منبع ایجاد می شود ، ساخته شوند. اما ساختارها فقط نقطه شروع هستند – آنها همچنین باید هر بار که تغییر ایجاد می کنند آزمایش شوند. نه فقط تست های واحد ، بلکه تست های عملیاتی ، تست رگرسیون ، عملکرد و مقیاس پذیری ، همه از API گرفته می شوند. و نه فقط در محیط های ساده ، بلکه در محیط هایی که تا حد امکان شبیه تولید هستند. وقتی این کار را انجام می دهند کد بهتری ارائه می دهند.
برای انجام این کار ، آنها باید توسعه مبتنی بر تنه اصلی (master) را تمرین کنند. آنها به اتوماسیون ادغام مداوم نیاز دارند که نه تنها روند ساخت ، بلکه یک فرآیند تست مبتنی بر API را هر بار کد تغییر می کند به عهده بگیرد. آنها همچنین باید محیط های تست قوی را در صورت تقاضا در دسترس داشته باشند ، این بدان معنی است که از زیرساخت ها به عنوان کد یا سایر اتوماسیون های تأمین کننده محیط استفاده می شود. و در برهه ای از زمان ، هنگامی که آنها کاملاً مسئول پشتیبانی از برنامه در تولید هستند ، برای استقرار قابل اعتماد کد ، به ابزارهای اتوماسیون انتشار نیاز دارند. برخی از افراد اظهارات بیانیه را مبنی بر اینکه تیم های اجایل برای افراد و تعاملات بیش از فرایندها و ابزارها به معنای مهم نبودن ابزارها ارزیابی می کنند. افراد از اهمیت بیشتری برخوردار هستند زیرا آنها کسانی هستند که در واقع نرم افزار را خلق می کنند ، اما از نظر عملی این افراد به ابزار نیاز دارند.
ارائه کد در حال کار در نسخه ی نمایشی در پایان هر اسپرینت بسیار ضروری است. با این وجود نسخه های نمایشی همانند دنیای واقعی نیستند. نسخه نمایشی ظرفیت کاری واقعی را در محیط های تهدید کننده زندگی تست نمی کند. نسخه نمایشی لازم نیست با برنامه های دیگر به خوبی اجرا شود. نسخه نمایشی نیازی به تحمل خطا یا خود درمانی ندارد. نسخه نمایشی در یک محیط تست لازم است اما کافی نیست. مقیاس پذیری ، امنیت ، قابلیت اطمینان و قابلیت نگهداری ضروری است. نسخه ی نمایشی می تواند بیش از حد بر روی ظاهر و احساس برنامه تمرکز کند و به اندازه کافی به ویژگی های دنیای واقعی آن نپردازد. تیم های اجایل که از برنامه های خود در محیط های واقعی پشتیبانی می کنند به سرعت این را می آموزند.
محیط های تستی که مشابه شرایط واقعی هستند اولین قدم خوب است. تکنیک های پیشرفته استقرار مانند استقرارهای سبز و آبی و استقرار قناری ها ، استقرار در زیرمجموعه های جامعه کاربران ، بینش هایی را ارائه می دهد که نسخه های نمایشی هرگز نمی توانند. تست فرآیندهای استقرار خود با استفاده مکرر در محیط های واقعی به رفع ناهماهنگی هایی که منابع قابل توجهی از حوادث تولید هستند ، کمک می کند. تیم های چابک باید تعریف خود را از “انجام شده” تنظیم کنند تا درنهایت ارسال به مشتریان واقعی را شامل شود – تا زمانی که این کار را انجام دهند ، ممکن است خودشان را در مورد کیفیت و ارزشی که فکر می کنند ارائه می دهند فریب دهند.
مالک محصول تنها مرجع در مورد آنچه باید ساخته شود و داور “انجام شده” است ، حداقل تا زمانی که مشتریان واقعی صحبت کنند. دارندگان محصولات ، حتی افراد عالی ، افرادی مانند بقیه ما هستند ، با تعصبات و نقاط کور خاص خود. افزودن سایر سهامداران به نسخه های نمایشی می تواند با گسترش دیدگاه ها کمک کند ، اما آنها نیز نقاط کور دارند. داور نهایی ارزش، مشتری است و هرچه تیم سریعتر بتواند به مشتریان واقعی ارائه دهد ، سریعتر نظریه های خود را درباره آنچه که واقعاً مشتری به آن نیاز دارند تأیید یا رد می کند. این انتقادی از نقش مالک محصول یا نظرات ذینفعان نیست ، صرفاً بازتاب واقعیت است.
عملکرد و مقیاس پذیری اهمیت دارد. مسائل امنیتی مهم است. خدمات ، ریز سرویس ها و API ها خصوصاً مهم هستند. هرچه برنامه با ساختار تکه های مستقل و یا کم وابسته باشد (loosely coupled) ، تغییر یک قسمت آسان تر است بدون اینکه این قسمت باعث تخریب بسیاری از قسمت های دیگر شود. API ها می توانند به عنوان بخشی از روند ادغام مداوم ، رگرسیون را تست کنند. به حداقل رساندن وابستگی به کد هنگام پرداختن به برنامه های بزرگتر سودآوری نیز دارد: هماهنگی کار با تیم های دیگر از طریق API های مشترک بسیار آسان تر از به اشتراک گذاری ساختارهای داده است. هنگامی که وابستگی تیم از طریق API واسطه است ، می توان از بسیاری از برنامه های پیچیده مدیریت برنامه و هماهنگی تیم جلوگیری کرد. تکنیک هایی مانند مجازی سازی خدمات (در غیر این صورت تمسخر و لجاجت شناخته می شوند) می توانند برای شبیه سازی تعهدات در حالی که تیم دیگر روی تحویل API جدید کار می کنند ، استفاده شوند.
یکی از دلایلی که انتشار کد برنامه قدیمی بسیار دشوار است این است که برنامه یکپارچه است ، ساختار داده ها و پایگاه داده را با برنامه های دیگر به اشتراک می گذارد. تغییر آنها سخت است زیرا هر تغییری عوارض جانبی ناشناخته ای دارد. کنترل مجدد این کد سال ها به طول می انجامد و بازنویسی آن ساده تر است. ولی اپلیکیشن های مدرن اینگونه نیستند و تیم های اجایل بایستی سخت کار کنند تا محصولات آنها بر اساس ساختار تکه های مستقل یا وابستگی کم باشند که مبادا روزی اپلیکیشن های قدیمی آینده شوند.
هرچه میزان انتشار کمتر باشد ، وابستگی ها نیز کمتر می شوند. هر چه وابستگی ها کمتر باشد ، موارد کمتری برای اشتباه وجود دارد. اگر می خواهید خطر انتشار را کاهش دهید ، اندازه را کاهش دهید ، فرآیندهای کنترل را که در واقع اندازه انتشار را افزایش می دهند ، با ایجاد یک فرآیند بسیار سخت ، دو برابر نکنید ، به طوری که افراد برای جلوگیری از آن هر کاری انجام می دهند ، مانند انتشار کمتر. انتشارهای کوچکتر هماهنگی را آسان می کند. آنها پذیرش کاربر را آسان می کنند زیرا تغییرات یا ویژگی های جدید کمتری برای یادگیری وجود خواهد داشت. انتشارهای هدفمند و کوچک تر ، ارزیابی تأثیر آنها را آسان تر می کند زیرا موارد کمتری برای اندازه گیری وجود دارد. این بازخورد را سریعتر می کند ، که باعث کاهش اتلاف شده و به تیم ها کمک می کند تا نسخه های بعدی را بهتر کنترل کنند. انتشارهای مکرر و کوچک تر ، خوب هستند.
آنها خوب هستند ، اما تنها در صورتی که تیمی به طور مداوم در حال ساخت و آزمایش نرم افزار خود باشد. آنها فقط درصورتی که فرآیندهای انتشار، ساده و قابل پیش بینی باشند ، خوب هستند. آنها فقط زمانی خوب هستند که اپلیکیشن ها بر اساس ساختار تکه های مستقل و یا کم وابسته باشند تا در صورت بروز یک مشکل، منجر به ایجاد سلسله ای از مشکلات دیگر نشوند.
شیوه های دواپس به تیم اجایل کمک می کند تا کارهای روزمره و معمولی را به صورت خودکار انجام دهد و به آنها اجازه می دهد تا روی نوشتن کد ماژولار با کیفیت بالا و به هم پیوسته متصل شوند که راه حل مناسب را ارائه دهد. دواپس به بک لاگ تجاری محور اجایل (از طریق مالک محصول) و قابلیت مدیریت خط جریان (pipeline) نیاز دارد. این برای ایجاد تیم های با عملکرد بالا به مدل تیم اجایل نیاز دارد. تیم های چابک باید مسئولیت مدیریت برنامه های کاربردی در تولید را به عهده بگیرند و مهارت های Ops و Security را به کارنامه خود اضافه کنند.
اجایل و دواپس در واقع چیزهای جداگانه ای نیستند. چابک همیشه از برتری در اصول مهندسی استقبال کرده است. نیاز به ارائه و پشتیبانی برنامه های کاربردی در تولید ، تمرکز را گسترش می دهد. انجام این کار در چرخه های سریعتر به این معنی است که اتوماسیون اکنون حتی بخش مهمی از آن اقدامات مهندسی است.
لینک مقاله اصلی:
https://www.scrum.org/resources/blog/what-devops-taught-me-about-agile
