نرم‌افزار سازمانی شما باید از چه محیط هایی استفاده کند؟
بسیاری از شرکت ها با محیط هایی همچون محیط محصول نهایی، تضمین کیفیت و توسعه محصول آشنا هستند اما یا از مزیت های واقعی آنها درست خبر ندارند یا سایر محیط های در سطح حرفه ای(enterprise level) مانند محیط آزمایش بار و آزمایش خودکار را نمی شناسند. در این مقاله ما محیط هایی را به دقت بررسی می کنیم که نرم افزار شما باید از آنها استفاده کند و در ادامه شرح می دهیم که چگونه می توانید از چنین محیط هایی بهره ببرید.
محیط محصول نهایی Production Environment
محیط محصول نهایی یا همان محیطی که اپلیکیشن قابل انتشار (Deployed application) در آن حضور دارد باید کارایی بالایی داشته باشد و از مناطق مختلف جهان نیز در دسترس باشد. برای این که بتوانید اپلیکیشنی با کارایی بالا و انعطاف پذیر بسازید می توانید از توصیه های زیر استفاده کنید:
- هر نمونه از محیط محصول نهایی شما، باید از پس دو برابر ترافیک مورد انتظارتان بر بیاید. در این حالت هنگام رشد محصول زمان بیشتری در اختیار خواهید داشت.
- هر کدام از نمونه ها به دو دلیل باید از نوعی توزیع کننده ترافیک بهره ببرند: نخست این که شما می توانید ترافیک را بین نمونه های مختلف هدایت و تقسیم کنید و این گونه سرعت را افزایش دهید. دوم این که هنگامی که اپلیکیشن شما باید به روزرسانی شود می توانید ترافیک را به سمت نمونه هایی که می خواهید کاربر به آن دسترسی داشته باشد هدایت کنید به جای آن که کل اپلیکیشن را از دسترس خارج کنید.
محیط تضمین کیفیت QA Environment
محیط تضمین کیفیت محیطی مهم و حیاتی است زیرا فرصتی در اختیار تیم تضمین کیفیت می گذارد تا پیش از ورود اپلکیشن به مراحل بالاتر، آن را آزمایش کنند. لازم نیست این محیط مانند محیط محصول نهایی کارایی بالایی داشته باشد اما کیفیت محیط باید به گونه ای باشد که اعضای تیم تضمین بتوانند از آن استفاده کنند.
همچنین دسترسی جهانی به این محیط نیز ضروری نیست، مگر این که اپلیکیشن شما الزاماتی جهانی داشته باشد که باید آزمایش شوند؛ مانند انتشارهای نرم افزار بر اساس موقعیت زمانی یا محتواهایی که فقط در یک منطقه خاص جغرافیایی در دسترس هستند. در ادامه توصیه هایی برای فراهم ساختن یک محیط تضمین کیفیت مناسب را مشاهده می نمایید:
- شما تنها همان تعداد نمونه از محیط تضمین می خواهید که پاسخگوی سناریوهای آزمایشتان باشد. به عنوان نمونه اگر در یکی از محیط هایی که محصول را در آن پیاده سازی میکنید محتوایی داشته باشید که باید تنها در منطقه خاصی در دسترس باشد، در این حالت باید دو محیط تضمین کیفیت داشته باشید: یکی برای دسترسی به آن محتوا در آن منطقه و دیگری برای تضمین عدم دسترسی به آن محتوا در مناطق دیگر. اگر نیاز به آزمایش هایی بر مبنای منطقه زمانی یا محتوای قابل دسترسی نداشته باشید یک محیط تضمین نیز برایتان کافی است.
- اگر شما دائم و پیوسته در محیط تضمین آزمایش انجام نمی دهید پس لازم نیست این محیط همیشه آنلاین باشد. در این صورت در هزینه ها صرفه جویی می کنید به خصوص اگر از زیرساخت های ابری استفاده می کنید.
محیط توسعه (Development Environment)
هنگامی که تیم توسعه محصول دارید، محیط توسعه ضروریترین محیط برای شماست. اما نحوه استفاده شما از آن به نوع نیاز تیم توسعه و سناریوهای مختلفی که این تیم با آن روبرو میشود بستگی دارد. مثلا شما معمولا از محیط توسعه برای آزمایش کارهایی استفاده میکنید که در حال انجام آن هستید. به هر حال اگر بخواهید تغییراتی را که در نسخه فعلی و منتشرشده نرم افزار وجود دارد به حال اول برگردانید و مجبور باشید این تغییرات را آزمایش کنید، در این حالت شاید به محیط دومی نیاز پیدا کنید که در آن محیط موارد تغییر نیافته و بدون عملکردهای جدید را آزمایش کنید. این محیط باید به کارآمدی محیط تضمین کیفیت باشد و با پارامترهایی مانند پارامترهای محیط تضمین کار کند، پارمترهایی مانند: مشخصات سرور، سیستم عامل سرور و وصله های سرور. در ادامه توصیه هایی برای مدیریت بهتر محیط توسعه را مشاهده میکنید:
- محیط توسعه، بنیان و سنگ بنای تیم توسعه شماست. این محیط باید به سادگی از طریق فرایندهای DevOps در دسترس قرار گیرد و یا داده ها را به صورت فقط خواندنی (read only) ارائه دهد. در این حالت اعضای تیم توسعه به اکثر داده هایی که می خواهند دسترسی پیدا می کنند.
- به کمک این محیط تمامی تغییرات تیم های توسعه را یکجا گردآوری کنید تا نوع ارتباط این تغییرات را دریابید. توسعه دهندگان باید تغییرات را نخست در محیطی محلی و اختصاصی آزمایش کنند و سپس آنها را به سوی محیط توسعه بفرستند تا از ایجاد خطا و درهم ریختن محیط توسعه جلوگیری کنند.
محیط آزمایش تایید کاربران User Acceptance Testing Environment
محیط های آزمایش تایید کاربران یا UAT که محیط های مرحله بندی(Staging) نیز نامیده می شوند محیط هایی هستند که به کاربران اصلی اپلیکیشن اجازه می دهند تا قابلیت های جدید را پیش از ارسال آنها به محیط محصول نهایی آزمایش کنند. چنین محیط هایی به کاربران امکان می دهند که بازخوردهای ارزشمندی را درباره موارد واقعی و نحوه استفاده از ویژگی های جدید به تیم توسعه ارائه دهند. در ادامه توصیه هایی برای بهینه سازی این محیط را مشاهده می کنید:
- محیط های UAT همانند آزمایش محدود و بسته نسخه بتای یک اپلیکیشن هستند چرا که در این محیط ها، گروه کوچکی می توانند از اپلیکیشن استفاده کنند و قابلیت های آن را امتحان کنند. تعداد افراد این گروه به نظر شما بستگی دارد اما بهتر است حدود 5 درصد تعداد کاربران محصول نهایی به شما بازخوردهای مفصل بدهند البته بدون آن که تیم توسعه شما را به زحمت بیندازند.
- محیط های UAT باید تا جای ممکن محیط هایی بسته و جدا از محیط محصول نهایی باشند، تا به طور مثال کاربر مشکل کند بودن عملکرد را با کند بودن سرعت سرورها اشتباه نگیرد.
دیگر محیطهای ویژه
علاوه بر محیط های قبلی دو محیط ویژه دیگر نیز وجود دارند که می توانند به فرایند توسعه محصول شما کمک کنند. البته می توان هر کدام از آنها را در صورت عدم نیاز کنار گذاشت و در هزینه ها صرفه جویی کرد:
آزمایش بارLoad Testing: معمولا تیم های تضمین کیفیت، محصول نهایی، توسعه و UAT در مجموع حتی بخش کوچکی از کاربران محصول نهایی را تشکیل نمی دهند. در چنین شرایطی آزمایش بارگذاری بسیار مفید است: محیطی ایجاد میکند که شما در آن می توانید همزمان صدها و حتی هزاران کاربر را شبیه سازی کنید و بهتر دریابید که وقتی اپلیکیشنی به عنوان محصول نهایی منتشر میشود چگونه کار خواهد کرد.
آزمایش خودکارAutomated Testing: بسیاری از شرکتها از تیم های تضمین کیفیت برای آزمایش قابلیت های جدید و همچنین بازگشت به برخی از ویژگی های موجود نرم افزار استفاده می کنند اما در چنین حالتی ممکن است متحمل خساراتی شوند. وقتی از یک تیم آزمایش خودکار محصول استفاده می کنید می توانید مجموعه ای از برنامه های آزمایش اتومات و خودکار بسازید و آنها را مطابق برنامه ریزی انتشار محصول اجرا کنید و بنابراین از صرف شب های طولانی برای انجام آزمایش بازگشت به شرایط اولیه پرهیز می کنید.
