شروع DevOps با تست پیوسته
مقدمه
به وسیله ارتباط قوی تست با توسعه و عملیات و همچنین خودکارسازی طراحی، توسعه، تضمین کیفیت و استقرار برنامه‌های کاربردی و سیستم‌های جدید، سازمان‌های فناوری اطلاعات می‌توانند به طور موثرتری همکاری نموده و نرم‌افزار را با چابکی عملیاتی و سرعت عرضه دو برابر به بازار تحویل دهند.
خلاصه اجرایی
سازمان‌های فناوری اطلاعات، از نمونه‌های کاربردی هستند که DevOps را اتخاذ کرده‌اند تا نسخه‌های نرم‌افزاری بیشتری را، هم برای سرعت بخشیدن به زمان عرضه به بازار و هم بهبود کلی تجربه مشتری، تولید کنند. اما نمونه‌های کاربردی که DevOps را اتخاذ کرده‌اند، نیازمند تغییر مردم از نظر فرهنگی، فرایندها و فن‌آوری‌های درگیر در توسعه، تست و عملیات است. بسیاری از سازمان‌ها هنگام پذیرش DevOps با چالش‌های قابل توجهی، مخصوصا در هنگام اجرای آن در بخشهای موروثی (legacy) روبرو می‌شوند. ثابت شده است که رفع چنین موانعی در مقایسه با موانعی که شرکت‌های دیجیتال بومی با آن مواجه می‌شوند، خیلی سخت‌تر می‌باشد.
باور عمومی بر این است که DevOps نیازمند آن است که هر چیزی که توسط سازمان ساخته شده است باید دور ریخته شود و مجددا از ابتدا شروع شود. اما، این درست نیست.
نیاز به بهبود ارتباط و همکاری بین دیسیپلین‌های تیمIT ، بخش حیاتی DevOps در سازمان‌های بزرگ می‌باشد. فراهم نمودن چنین رفتاری می‌تواند بسیار دشوار باشد، به ویژه هنگامی که انطباق با قوانین، مستلزم حفظ ساختارهای سازمانی موجود باشد.
در سازمان‌های سنتی فناوری اطلاعات، توسعه‌دهندگان، تست‌کنندگان و مهندسین عملیات معمولا نقش‌های مختلفی بازی می‌کنند و مسئولیت‌ها، تعاریف و فرهنگ‌های کاری متفاوتی دارند و در حوزه‌های عملیاتی متمایز به عنوان موجودیت‌های مجزا کار می‌کنند.
سوال این است که آیا QA می‌تواند گروه‌های مختلف را تحت پرچم DevOps متحد کند. این مقاله تلاش می‌کند که به این سوال پاسخ داده و در مورد این رویکرد توضیح دهد.
نقش تست در DevOps
واژه DevOps از ترکیب توسعه و وظایف عملیاتی ساخته شده است. DevOps تکنولوژی نیست، یک فرایند یا استاندارد نیست؛ بلکه یک فرهنگ یا جنبش فناوری اطلاعات است که بر روش‌هایی تاکید می‌کند که در آنها توسعه، تست و عملیات می‌توانند به طور موثرتری همکاری کنند. DevOps بیشتر در مورد اطمینان، افراد و کار گروهی می‌باشد تا در مورد فرایند، و ایجاد نرم افزار به عنوان یک سرویس در حال توسعه، نه یک محصول ایستا.
در حالی که تفسیرهای مختلفی از تعریف DevOps وجود دارد، برداشت همه از کاری که انجام می‌دهد یکسان است. به عنوان مثال Gartner، DevOps را بدین صورت تعریف می‌کند: "... تغییر در فرهنگ فناوری اطلاعات، با تمرکز بر ارائه سریع خدمات فناوری اطلاعات از طریق پذیرش شیوه‌های چابک در چارچوب یک رویکرد مبتنی بر سیستم. DevOps بر مردم (و فرهنگ) تأکید دارد و به دنبال بهبود همکاری میان عملیات و تیم‌های توسعه است. پیاده‌سازی‌های DevOps از تکنولوژی بهره می‌برند - به ویژه ابزارهای خودکارسازی که می‌توانند از زیرساخت قابل برنامه‌ریزی و پویا از دید چرخه حیات به میزان چشمگیری بهره گیرند."
DevOps به دلایل زیر پدید آمده است:
وجود ساختارهای تیمی سنتی که برای پاسخگویی به نیازهای متنوع شرکت‌های مدرن مناسب نیستند.
قطع ارتباط واقعی میان تیم‌های توسعه، تست و عملیاتی، که منجر به ارتباطات، همکاری و یکپارچهسازی ضعیف می‌شود.
پیشرفت سریع فن‌آوری‌های دیجیتال، که سریع‌تر از فرایندهای اساسی مورد استفاده برای استقرار، گسترش و مدیریت آنها، رشد می‌کند.
چهار فعالیت کلیدی زیر، DevOps را تعریف می‌کنند.
| تست در DevOps | تست در Agile |
|---|---|
| تست به طور پیوسته انجام می‌گیرد | تست اغلب و در صورت امکان در مراحل اولیه انجام می‌گیرد |
| تقریبا همه چیز را خودکار می‌کند | تست خودکار را تا حد ممکن انجام می‌دهد |
| یکپارچهسازی پیوسته و تست الزامی است | یکپارچهسازی پیوسته و تست یک گام رو به جلو است |
| به طور بالقوه کد قابل حمل پس از هر یکپارچهسازی تولید می‌شود. | به طور بالقوه کد قابل حمل در پایان یک sprint تولید می‌شود |
DevOps از دید صنعت
بر اساس یک گزارش صنعتی اخیر که توسط تامین‌کننده‌ِ منابع آموزشی آنلاین DevOps.com منتشر شده است، بیش از 70٪ از سازمان‌های فناوری اطلاعات DevOps را در برخی از فرم‌ها پذیرفته‌اند.DevOps به سرعت در حال پیشرفت است و در برخی موارد این سفر آغاز شده است.
همانطور که در شکل بالا نشان داده شده است، سه نقطه تمرکز اصلی سازما‌ن‌هایی کهDevOps را اتخاذ کرده‌اند، ساخت و تست خودکار، مدیریت پیکربندی، و یکپارچهسازی پیوسته/استقرار پیوسته می‌باشد. در نتیجه، بر اساس Forrester Research (شکل بعدی)، یک چرخه حیات توسعه نرم افزار جدید (SDLC) در حال ظهور است. بر اساس بررسی Forrester، ویژگی‌های SDLC جدید عبارتند از:
چرخه‌های انتشار سریع‌تر: بیش از 24 درصد از شرکت‌ها، به طور روزانه و هفتگی نرم‌افزار منتشر می‌کنند.
تغییر نیازمندی‌ها و عدم هماهنگی میان گروه‌ها: تقریبا 47٪ معتقدند که این عدم ارتباطات، نقاط اصلی شکست در طی یک بررسی انتشار بود.
ظهور DevOps:تقریبا 66 درصد از CIO ها، DevOps را در دستور کار IT خود قرار داده‌اند.
یک چرخه حیات توسعه نرم‌افزار جدید در حال ظهور است
| SDLC جدید | SDLC قدیمی |
|---|---|
| توافقی | دستوری |
| هدف‌گرا | وظیفه‌گرا |
| تیم‌های توانمند | نقش‌های تخصصی |
| پاسخگویی بهینه | مقاومت در برابر تغییر |
| خودکار | برون سپاری |
| بهینه‌سازی سهام | بهینه‌سازی پروژه |
چالش‌های پذیرش
سازمان‌های تاسیس شده در دوران پیدایش تکنولوژی ابر، DevOpsرا از روز اول پذیرفته‌اند. DevOps توسط سازمان‌های موروثی نیز درنظر گرفته شده است اما به علت چالش‌های مختلف، به کندی گام برمی‌دارد. جنبش چابک، نحوه ساخت و استقرار برنامه‌های کاربردی را با نزدیک‌تر ساختن فناوری اطلاعات به کسب و کار به طور اساسی تغییر داده است، در حالی که عملیات و تضمین کیفیت بدون تغییر باقی مانده‌اند.
چالش‌های معمول در سازمان‌های فناوری اطلاعات که به دنبال پذیرش DevOps هستند عبارتند از:
تیم عملیات سنتی: این گروه بیشتر زمان خود را صرف کاهش زمان تولید می‌کنند، با شکست‌‌های تکراری مقابله کرده و فورا درصدد رفع آنها برمی‌آیند.
سربار محیط تست: هر محيطی (تست، توسعه، پیش تولید/ اجرا و تولید) منحصر به فرد است. عملیات باید بر مشکلات مربوط به محیط تولید تمرکز کنند و بدین ترتیب زمان را فقط صرف بهبود زیرساخت نکنند.
تست سنتی: چندین هزار مورد آزمون بازگشتی (رگرسیون) وابسته به یکدیگر، از طریق رابط کاربری برنامه کاربردی، در طی چندین روز اجرا می‌شوند، که باعث چرخه‌های تست طولانی‌تر می‌گردند، و در نتیجه منجر به بازخورد بسیار کندتر می‌شوند. استراتژی مدیریت داده تست که به درستی تعریف نشده و وابستگی‌های جریان پایین به بالا / جریان بالا به پایین، بدون تکنولوژی‌های مجازی‌سازی سرویس، باعث به تاخیر افتادن تست می‌شود.
توسعه سنتی: به تاخیر افتادن یکپارچهسازی کد منجر به مشکلات یکپارچهسازی و به تاخیر افتادن رفع شکست‌ها منجر به چرخه‌های حیات طولانی‌تر می‌شود. تاخیر‌های زمانبندی اغلب به علت فقدان روش‌های بررسی و استقرار ساخت خودکار رخ می‌دهد.
قصور فنی عظیمی در این دیسیپلین‌های فناوری اطلاعات تجمع می‌یابند و اغلب همکاری میان تیم‌های فناوری اطلاعات کم می‌شود. راه حل این است که نمونه‌های کاربردی DevOps را به طور افزایشی، و به صورت یک گام در هر زمان، بسازید.
تست پیوسته: گامی در مسیر درست
از نظر ما در هنگام شروع سفرDevOps، تست پیوسته (CT) اولین گام در مسیر درست است. CT یک اسم مستعار برای مکانیزم بازخورد پیوسته است که تحویل نرم‌افزار را از طریق تونل SDLC هدایت می‌کند. بازخورد خودکار در هر نقطه بازرسی (check point) یک راه‌انداز برای فرایند بعدی در زنجیره تحویل است در صورتی که این بازخورد برای حرکت رو به جلو باشد. اگر بازخورد برای حرکت رو به جلو نباشد، این فرایند فورا متوقف شده و اقدامات اصلاحی انجام می‌گیرد.
سازمان‌های فناوری اطلاعات سنتی می‌توانند مسیر پیاده سازی CT را با استفاده مجدد و اصلاح قابلیت‌های خودکار موجود تست (همانطور که در تصویر بعدی نشان داده شده است) کوتاه کنند.
ایجاد یک اکوسیستم CT در سطح بالا شامل مراحل زیر می‌باشد:
مانند پایه کد برنامه کاربردی، باید در یک مخزن کنترل نسخه، قرار گیرد.تغییر اسکریپت‌های تست خودکار به یک ابزار کنترل نسخه سازمانی، برای ایجاد یک منبع اطمینان منفرد. سازمان‌های تست معمولا اسکریپت‌های خودکار را در ابزارهای مدیریت تست ذخیره نموده یا در یک ساختار پوشه‌ای به اشتراک می‌گذارند. با این حال، پایه کد خودکار، درست
یکپارچهسازی مجموعه خودکار با یک ابزار استقرار ساخت برای فعال‌سازی اجرا و گزارش‌دهی متمرکز.
دسته‌بندی مجموعه خودکار در چند لایه تستبرای فعال‌سازی بازخورد سریع‌تر در هر نقطه بازرسی. تست‌های معمول عبارتند از:
بررسی درستی: بررسی خودکار، سرویس‌های پس از استقرار را تایید می‌کند. به طور معمول، بررسیهای صحت سیستم تنها ظرف چند دقیقه اجرا می‌شود.
تست‌های دود: این مجموعه حیاتی از تست‌های خودکار تضمین می‌کند که ویژگی‌های کلیدی سیستم، عملیاتی هستند و هیچ نقص مسدود کننده‌ای اتفاق نمی‌افتد. تست‌های دود معمولا در کمتر از 15 دقیقه اجرا می‌شوند و برای تکمیل فرایند CT، زمان پاسخ باید بهینه‌تر شود.
رگرسیون هوشمند: اگر زمان اجرای رگرسیون کامل به میزان قابل توجهی بالا باشد، تنظیم CT به دلیل چرخه‌های بازخورد طولانی، کمتر موثر است. در چنین سناریویی، زیر مجموعه‌ای از رگرسیون که در زمان اجرا بر اساس نواحی بحرانی و آسیب دیده متوقف شده، تنها می‌تواند برای فراهم نمودن بازخورد در یک چارچوب زمانی معقول اجرا شود. اجرای رگرسیون کامل می‌تواند، بسته به هماهنگی آن با تکرار دفعات ساخت به شب یا آخر هفته موکول شود.
رگرسیون کامل: بازخورد نهایی اکوسیستم CT است. هدف به حداقل رساندن زمان بازخورد با اجرای موازی تست‌های خودکار با استفاده از thread ها یا ماشین‌های چندگانه است.
تمامی تست‌های فوق، به عنوان بخشی از فرآیند استقرار ساخت انجام می‌شوند. در صورتی که هر یک از آنها با شکست مواجه شود، فرآیند استقرار متوقف می‌شود، و به هر کسی که در تحویل نرم‌افزار درگیر است – توسعه‌دهندگان، تست‌کنندگان و پرسنل عملیاتی - بلافاصله اعلام می‌شود تا اقدام اصلاحی را انجام دهد. حلقه‌های بازخورد کوتاه‌تر، تیم را قادر می‌سازند تا به سرعت شکست را کشف نموده و سریعا آن را رفع نمایند.
خودکارسازی هوشمند تست، یک راه‌حل است
خودکارسازی تست در رقابت با فرایندهای دستی در سازمان‌های DevOps برنده است. اما تست‌های خودکار معمولا با چالش‌های زیر مواجه می‌شوند:
اغلب به علت محدودیت‌های لایسنس، سرعت تست‌های ساخته شده در ابزارهای تجاری در طی زمان کاهش می‌یابد و با چالش‌های مقیاس‌پذیری مواجه می‌شوند.
اغلب، خودکارسازی با استفاده از ابزارهای مختلف برای پوشش UI، API ها، موبایل و غیره انجام می‌گیرد.
تاثیر کسب و کار بر روی تعریف رگرسیون، اغلب تیم‌های تست را وادار به ساخت تست‌های قابل اجرا در مدت زمان طولانی می‌کند.
هوشمندسازی تست‌های خودکار موجود و انتقال تست‌ها به ابزارهای متن باز مانند سلنیوم اثربخشی تنظیمات DevOps را بیشتر افزایش می‌دهد.
همانطور که شکل زیر نشان می‌دهد، ایجاد مدل‌های رگرسیون هوشمند مانند مدل Monday-to-Friday weekend برای فراهم نمودن بازخورد تست اولیه در فرایند CT مهم است.
برای تسریع اجرای تست‌ها در طی هفته، باید زیر مجموعه‌هایی از کل مجموعه رگرسیون (تست‌های دود، بررسیهای صحت سیستم و مجموعه‌های رگرسیون هوشمند) با استفاده از اصول زیر برجسته شوند:
یک دامنه رگرسیون پویا برای هر ساخت بر اساس نوع تغییر کد؛ release note های تولید شده به طور خودکار، به کار رگرسیون اضافه می‌شود.
یک چارچوب خودکار تست هوشمند قادر به فعال‌سازی و غیرفعال‌سازی سناریوهای تست بر اساس تغییرات برنامه کاربردی می‌باشد.
موارد آزمون قابل ردیابی با فایل‌های کد.
یک مخزن متمرکز از کد برای موارد آزمون قابل ردیابی.
یک رویکرد مبتنی بر ریسک با ریسک تقریبا صفر.
یکپارچهسازی تست‌های غیرکارکردی به کمک CT
منطق اصلی فرایندهای CT، این است که هر تغییر ایجاد شده در برنامه کاربردی در صورت امکان در مراحل اولیه تست شود. با این حال، اگر تست‌های غیرکارکردی مانند کارایی و امنیت، در فرایند کلی CT قرار نگیرند، تنها بخشی از معما حل می‌شود. مشکلاتی که بعدا شناسایی می‌شوند می‌توانند همه بهره‌وری‌های CT را که از یک نقطه ثابت عملکردی بدست آمده‌اند و هنوز زمانبندی انتشار را به خطر می‌اندازند، از بین ببرد.
چنانچه فعالیت‌های CT رشد نموده و کامل گردد، توانایی یکپارچهسازی تست غیرکارکردی در outlier باقی می‌ماند اما به عنوان یک فعالیت اصلی دیده می‌شود. با این حال، چالش‌های شناخته‌شده‌ای برای یکپارچهسازی تست‌های غیرکارکردی با فرایندهای CT، خصوصا در تست بار وجود دارد که عبارتند از:
عدم دسترس‌پذیری سرورهای اختصاصی برای تولید بار مورد نظر کاربر.
محدودیت‌های ظرفیتی تاثیرگذار برروی قابلیت مقیاس‌پذیری محیط CT و حفظ اندازه تست‌های بار.
در صورت تقاضا، بهره‌وری از ابزارهای مانیتورینگ برای شناسایی گلوگاه‌ها.
سازمان‌ها باید به منظور استفاده موثر از منابع موجود و توانایی اجرای تست‌های بار در صورت تقاضا، بدون اتلاف زمان و منابع، ساخت یک زیرساخت ابری را مدنظر قرار دهند. ابزارهایی مانندApache JMeter ، به عنوان ابزارِ انتخاب تست کارایی در سازمان‌های DevOps، به سرعت در حال ظهور هستند.
شرکت مهندس پیشگان آزمون افزار یاس، خدمات زیر را در حوزه تست چابک و DevOps ارائه می دهد:
ارائه مشاوره در حوزه تست چابک و DevOps
تهیه و آموزش ابزارهای تست چابک و DevOps
ارائه راهکارهای مبتنی بر DevOps برای بهبود کیفیت نرم افزار
مراجع
[1] “Testing in the DevOps World of Continuous Delivery”, Manoj Narayanan, 2012
[2] “Leading the Transformation: Applying Agile and DevOps Principles at Scale”, Gruver, Gary; Mouser, Tommy , 2015
[3] “DevOps- Not a Market, but a Tool-Centric Philosophy That Supports a Continuous Delivery Value Chain”, Laurie F. Wurster, Ronni J. Colville, Jim Duggan , 2015
[4] “Practices for DevOps and Continuous Delivery”, Ben Linders, 2015
[5] “Reducing wasted development time via continuous testing. 14th International Symposium on Software Reliability Engineering”, Saff, D.; Ernst, M.D. , 2003
[6] “ Testing in a Continuous Delivery World”, Rob Marvin, 2003