نگاه
دِوآپس؛ حالمان هنوز خوب نیست!
ضرب‌المثلی در زبان ما و بسیاری از کشورهای دیگر با این عنوان وجود دارد: «چون که صد آمد، نود هم پیش ما است.» اگرچه معنای این ضرب‌المثل بسیار واضح است، اما فارغ از حوزه استفاده، گاهی در تفسیر آن اشتباهاتی ایجاد می‌شود. در دنیای نرم‌افزار نیز تا دلتان بخواهد این تفاسیر اشتباه وجود داشته است. به ‌عبارت بهتر، هرچه جامعه نرم‌افزار در تشخیص 90 ماجرا ـ توسعه کدهای با کیفیت، با خطای نزدیک به صفر و در کم‌ترین زمان ممکن ـ موفق بوده، در تشخیص 100 آن که روش رسیدن به این خواسته است، دچار اشکال و نقصان بوده‌اند.

در نتیجه این دشواری هر از چند گاهی روش‌های توسعه جدیدی معرفی شده‌اند تا بلکه این مشکل برطرف شود. ساختار و مدل «دوآپس» (DevOps) نوین‌ترین این رویکردهای توسعه است که به ‌دلیل وارد شدن بخش‌های دیگر سازمان مانند مدیریت، گروه‌های اجرایی، کنترل کیفیت و مانند آن در کنار گروه توسعه نرم‌افزار، بسیار امیدبخش‌تر از روش‌های پیشین به ‌نظر می‌آید. شاید مناسب باشد تا اندکی درباره فسلفه به‌ وجود آمدن این رویکرد جدید صحبت کنیم. ارائه سرویس یا نرم‌افزاری با کیفیت توسعه بالا، خطای نزدیک به صفر و در چهارچوب زمان‌بندی شده، همواره غایت آمال یک شرکت نرم‌افزاری بوده و است. دست‌یابی به این شاخص‌ها زمانی به چالش تبدیل می‌شوند که به‌ دلیل توسعه زیرساخت‌های آماده ـ مانند کامپوننت‌ها یا سرویس‌های ابری آماده ـ سرعت اجرا بالا رود و به‌ همان نسبت انتظار جامعه مخاطبان از این شرکت‌ها نیز افزایش یابد. این افزایش انتظار از شرکت‌های ارائه‌کننده سرویس، به فشاری مداوم بر گروه‌های توسعه تبدیل شده است و به‌طور مداوم از ایشان می‌خواهد تا در کم‌ترین زمان ممکن نیازهای مخاطبان را برطرف کنند.
بدیهی است هرچه سرعت توسعه افزایش یابد، پارامترهای کیفی بیش‌تری قربانی خواهند شد و سیستم یا سرویس نهایی با اشکالات بیش‌تری مواجه خواهند بود. برای حل این مشکلات، راه‌کار «دوآپس» توسط اندرو کلی شافر و پاتریک دبوس در کنفرانس سالانه Agile در سال 2008 مطرح شد و پس از آن و از سال 2009 این راه‌کار ذیل همین نام مورد بحث قرار گرفت و از آن سال کنفرانس‌هایی با همین نام در سراسر دنیا برگزار می‌شوند. این متدولوژی که به حل مشکلات از طریق همکاری گروه‌های توسعه با گروه‌های عملیاتی تأکید دارد، از گروه‌های برنامه‌نویسی می‌خواهد تا از ابتدای چرخه توسعه با استقرار کدها، آزمون‌های مناسب و بررسی کارایی و عملکرد سیستم در فشار کاری زیاد، گروه اجرایی را پشتیبانی کند. این گروه نیز با فراهم آوردن دانش مورد نیاز و بازخوردهای مشتریان پیش از استقرار، در حین آن و پس از استقرار گروه توسعه را پشتیبانی کند.
برای کسانی که در گروه‌های بزرگ مشغول به کار هستند یا سرویس‌های با تعداد مخاطب بالا را توسعه داده‌اند، مفاهیم و دشواری‌های فوق بسیار ملموس و راه‌کار ارائه شده بسیار امیدبخش است. ساختار «دوآپس» مسیری است که در حال حاضر شرکت‌های بسیاری در آن قدم گذاشته و با وجود مشکلات فرهنگی موجود که به‌طور خاص گروه‌های توسعه آن را به وجود خواهند آورد، در حال حرکت در مسیر آن هستند. در شرایط پرفشار کنونی و در حالی که برنامه‌های زمان‌بندی تا حد امکان فشرده شده‌اند، دیوارهای موجود بین گروه‌های توسعه، تضمین کیفیت و محیط اجرا مانعی بر سر چابکی سازمان هستند و «دوآپس» سعی در شکستن این مرزها دارد و مهارت‌های مدیریت گروه را به اندازه مهارت‌های فنی ارزشمند می‌داند. همچنین، تمرکز این رویکرد تنها بر تجربه کاربر از محصول ارائه شده و نحوه اثرگذاری این تجربه بر سازمان است. بنابراین، می‌توان گفت «دوآپس» تنها ابزار جدیدی برای انجام همان کارهای قدیمی به گونه‌ای بهتر نیست و معرف یک فرهنگ و فرآیند جدید است. فرهنگی که از همکاری و تعامل گروه توسعه، تضمین کیفیت و محیط عملیاتی برآمده و قرار است تا ضامن خروج سیستمی کارا باشد.
همانند همیشه، سخت‌ترین مسیر در یک سازمان تغییر فرهنگ آن است و تنها روش برای آن‌که همه اعضا به شکلی خودخواسته به این تغییر فرهنگ متمایل شوند، ارائه دلایل مبرهن برای آن است. در بحث «دوآپس» نیز ماجرا یکسان است و دست بر قضا این ‌بار باید فرهنگ کسانی تغییر داده شود که اغلب چندان اعتقادی به فرهنگ‌های بشری ندارند و فرهنگ غالب آن‌ها همان زبان کامپیوتر است؛ یعنی گروه‌های توسعه! اگرچه مدیران سازمان راهی سخت برای قانع‌ کردن ایشان به تغییر خواهند داشت، اما شاید سه نکته ذیل بتواند به آن‌ها کمک شایانی کند.
- ارتقای کیفیت زندگی اعضای گروه توسعه: از آن‌جا که در این رویکرد برنامه‌نویس‌ها خطاها را پیش از آن‌که به یک بحران شبانگاهی تبدیل شوند از سوی گروه‌های عملیاتی دریافت می‌کنند؛ بنابراین، فشار و استرس آن‌ها تا حد بسیار زیادی کاسته خواهد شد. 
- تطابق سیستم توسعه داده شده با محصول دریافت شده از مشتری: در مدل «دوآپس»، هرچه توسعه داده می‌شود پس از رفتن به گروه‌های تضمین کیفیت و همچنین گروه عملیاتی محیط، همچنان توسط گروه توسعه نیز قابل مشاهده و ارزیابی بوده و می‌توانند نسبت به تغییرات ایجاد شده روی آن اظهار نظر کنند و در نتیجه سیستم نهایی همان سیستم توسعه داده شده اولیه باشد. در نتیجه، حس خوب مالکیت محصول همچنان برای توسعه‌دهنده باقی خواهد بود. 
- افزایش کار مرتبط: در این ساختار برنامه‌نویسان و اعضای گروه توسعه با داده‌ها و مشکلات واقعی به وجود آمده روبه‌رو هستند و مانند روش‌های سنتی در محیطی ایزوله درگیر سناریوهای خودساخته روی داده‌های فرضی و نامرتبط نخواهند بود.
در شماره آینده، به بررسی میزان حرکت یک سازمان در مسیر «دوآپس»، کنار گذاشتن عادت‌های قدیمی و نحوه برخورد میان همکاران در این مدل صحبت خواهیم کرد.

 

ماهنامه شبکه را از کجا تهیه کنیم؟
ماهنامه شبکه را می‌توانید از کتابخانه‌های عمومی سراسر کشور و نیز از دکه‌های روزنامه‌فروشی تهیه نمائید.

ثبت اشتراک نسخه کاغذی ماهنامه شبکه     
ثبت اشتراک نسخه آنلاین

 

کتاب الکترونیک +Network راهنمای شبکه‌ها

  • برای دانلود تنها کتاب کامل ترجمه فارسی +Network  اینجا  کلیک کنید.

کتاب الکترونیک دوره مقدماتی آموزش پایتون

  • اگر قصد یادگیری برنامه‌نویسی را دارید ولی هیچ پیش‌زمینه‌ای ندارید اینجا کلیک کنید.

ایسوس

نظر شما چیست؟