استراتژی استقرار نرم افزار | Software Deployment Strategy

Software Deployment Strategy

در این مطلب به ابتدا به تعریف استراتژی (Strategy)، استقرار نرم افزار (Software Deployment) اشاره شده و در ادامه دو تا از استراتژی های پایه استقرار نرم افزار معرفی و بررسی شده است.

در این صفحه به مطالب زیر می پردازیم :

 

در مطلب بعدی موارد زیر معرفی و بررسی خواهند شد

  • استراتژی های پیشرفته استقرار نرم افزار
    • Canary Deployment Strategy
    • Blue-Green Deployment Strategy
    • Dark Launch Strategy
    • A/B Deployment Strategy

استراتژی چیست ؟ | What is Strategy ?

تعاریف مختلفی از استراتژی وجود دارد اما به نظرم سه تعریف زیر در کنار هم دید خوبی از مفهوم استراتژی به ما می دهد.

  1. استراتژی یعنی یک برنامه کلان برای رسیدن به یک یا چند هدف در شرایط غیر قطعی (ویکی پدیا)
  2. استراتژی داشتن یعنی اینکه وقتی مجموعه ی تصمیم هایمان دیده می شود، بتوان الگوی خاصی را در آن ها مشاهده کرد. (هنری مینتزبرگ)
  3. استراتژی یعنی کاری که دیگران انجام می دهند را با منابع کمتر (کاراتر) انجام دهیم و کارهایی انجام دهیم که هیچ کس غیر از ما انجام نمی دهد. (مایکل پورتر)

همانطور که از تعاریف مشخص است، استراتژی برنامه ای با جزئیات دقیق و کاملا قابل پیش بینی نیست. تاکید یک استراتژی خوب بر آن است که در برخی از توانایی های رقابتی خاص پیشرفت حاصل شود. برای دستیابی و رسیدن به اهداف یک استراتژی، نیاز است برنامه هایی (Plans) قابل پیش بینی و با جزئیات، تعریف و اجرا شود.

دیپلویمنت چیست ؟ | What is Deployment ?

دیپلویمنت یعنی گسترش دادن، استفاده، یا سازماندهی برای رسیدن آگاهانه به یک هدف. (Merrian Webster – Definition of Deploy)

استقرار نرم افزار چیست ؟ | What is Software Deployment ?

Software Deployment یا استقرار نرم افزار شامل تمام فعالیت هایی است که یک نرم افزار را برای استفاده ی کاربران نهایی آماده می کند. از آنجایی که هر سیستم نرم افزاری شرایط و ویژگی های منحصر به فردی دارد، فرایند ها و روش های استقرار آن باید به طور خاص و دقیق برای همان سیستم تعریف شود. بنابراین استقرار نرم افزار، یک فرایند کلی است که باید با توجه به شرایط و خصوصیات هر سیستم نرم افزاری به صورت دقیق تعریف شود. (ویکی پدیا)

(در ادامه ی این متن، از واژه ی “استقرار” به جای “Software Deployment” یا “استقرار نرم افزار” استفاده شده است.)

استراتژی استقرار نرم افزار چیست ؟ | What is Software Deployment Strategy ؟

Software Deployment Strategy یا استراتژی استقرار نرم افزار، یک استراتژی در جهت گسترش، استفاده، و یا سازماندهی، برای استقرار به صورت آگاهانه است. به عبارت ساده تر فرایندی است که نحوه ی استقرار و پیکربندی اپلیکیشن و سرورها را مشخص می کند. هر اپلیکیشن یا سرور برای استقرار، نیازمندی ها و ملاحظات متفاوتی دارد که برای انجام آن باید از یک استراتژی مناسب استفاده کرد. از جمله این نیازمندی ها می توان به دسترس پذیری اپلیکیشن، مدت زمان استقرار و بسیاری موارد دیگر اشاره کرد.

در گذشته های نه چندان دور، استقرار اپلیکیشن شامل انتقال فایل ها از طریق Ftp به سرور و اعمال یک سری تنظیمات و پیکربندی به صورت دستی و غیر اتوماتیک در آن بود. با گذشت زمان و تکامل اپلیکیشن ها و همچنین اپلیکیشن-سرورها، روش های استقرار و انتشار نرم افزار هم کامل تر و متنوع تر شدند. با این وجود هنوز بسیاری از تولید کنندگان نرم افزار، از روش های قدیمی و منسوخ شده برای استقرار استفاده می کنند که معایب زیادی به همراه دارد.

اهداف استراتژی های استقرار نرم افزار کدامند ؟

از جمله اهدافی که استراتژی های استقرار به دنبال دستیابی به آن ها هستند، می توان به این موارد اشاره کرد:

  1. به حداقل رساندن DownTime یا به صفر رساندن آن
  2. کاهش ریسک ناشی از استقرار
  3. کاهش ریسک عملیاتی کردن نسخه ی جدید
  4. شناسایی سریع مشکلات نسخه ی جدید بعد از عملیاتی شدن
  5. سرعت بخشیدن به امکان Rollback به نسخه ی قبلی

معایب استقرار به روش های قدیمی چیست ؟

استفاده از روش های استقرار قدیمی و غیر اتوماتیک در نگهداری سرور ها و استفاده از آن ها برای مدت زمان طولانی (چندین ماه یا چند سال) باعث مشکلات زیادی می شود. حتی اگر شما تمامی patch ها و update ها را به درستی روی سرور و اپلیکیشن نصب کرده باشید، بعد از مدتی با یک سرور حساس و شکننده با پیکربندی منحصر به فرد مواجه خواهید شد که نمی توانید آن را تعویض کنید یا سروری مشابه آن ایجاد کنید. (به چنین سروهایی در اصطلاح “Snowflake Servers” می گویند). دلایل مختلفی وجود دارد که نیاز می شود یک سرور جدید راه اندازی کنید، از جمله تغییر دیتاسنتر، اضافه کردن سرورهای fail-over، اضافه کردن سرور برای مقیاس پذیری بیشتر، مشکلات امنیتی و … که در چنین شرایطی امکان آن وجود نخواهد داشت یا با ریسک بسیار بالا و صرف زمان زیادی همراه خواهد بود.

رانش پیکربندی چیست ؟ | What is Configuratoin Drift ؟

از اصطلاح Configuration Drift یا “رانش پیکربندی” مواقعی استفاده می شود که تغییرات پیکربندی به صورت موردی، با توجه کم و بدون مستند سازی روی سرورها اعمال می شود عملا سرور را به یک سرور منحصر به فرد تبدیل می کند که محدودیت ها و مشکلاتی را به همراه خود دارد.

برخی از این مشکلات که در بالا اشاره شد، با به کار گیری ابزارهای مدیریت پیکربندی نظیر Chef و Puppet و Ansible برطرف می شوند. اگر پیکربندی ها با استفاده از این ابزارها انجام شود، از پدیده ی Configuration Drift جلوگیری می شود. اما نکته ی مهم این است که در این روش تنها پیکربندی هایی که صراحتا از طریق ابزار اعمال شده انجام خواهد شد و اگر مواردی خارج از آن به محیط یا سرور اعمال شود، ابزار مطلع نمی شود.

Immutable Server چیست ؟

استراتژی ای وجود دارد که در آن به صورت دوره ای سرورها را حذف مب کنند و یک سرور جدید به جای آن ایجاد می کنند و با استفاده از ابزارهایی که در بالا معرفی شد، به صورت اتوماتیک، پیکربندی می کنند. این کار باعث جلوگیری از Configuration Drift می شود. با این روش، با هر تغییر در پیکربندی، بلافاصله قادر به راه اندازی یک سرور جدید خواهیم بود. این استراتژی با نام Immutable Server شناخته می شود از رانش پیکربندی و Snowflake Server ها جلوگیری می کند. از این استراتژی می توان در کنار  Recreate Deployment Strategy که در ادامه توضیح خواهم داد استفاده کرد.

انواع استراتژی استقرار نرم افزار | Deployment Strategies

در ادامه به معرفی استراتژی های پایه استقرار نرم افزار می پردازیم. در مطلب بعدی “استراتژی های پیشرفته استقرار نرم افزار” را بررسی خواهم کرد. لازم به ذکر است که این استراتژی ها را می توان با هم ترکیب کرد و استراتژی جدیدی ایجاد کرد. در ادامه مطالب زیر بررسی خواهد شد :

Recreate Strategy | Recreate Deployment

استراتژی Recreate Deployment یکی از استراتژی های پایه استقرار نرم افزار می باشد. روش انجام این استراتژی دقیقا شبیه به زمانی است که یک اپلیکیشن برای اولین بار نصب و راه اندازی می شود. همه چیز مرحله به مرحله و از ابتدا باید انجام شود. همچنین نیازی نیست که کدهای جدید و قدیم در کنار هم کار کنند.

این استراتژی به دلیل اینکه در یک بازه زمانی هیچ نمونه ای از اپلیکیشن در حال اجرا و سرویس دهی نیست، منجر به DownTime خواهد شد. درنتیجه برای محیط های عملیاتی مناسب نیست.

چه موقع از Recreate Deployment استفاده کنیم ؟

  • زمانی که قبل از راه اندازی نسخه ی جدید، نیاز است یک مهاجرت ( Migration ) در سطح دیتا یا سرور انجام شود
  • زمانی که نیازی نیست تا نسخه های جدید و قدیم اپلیکیشن به طور همزمان با هم کار کنند
  • زمانی که از یک RWO volume ای استفاده می کنید که قابلیت به اشتراک گذاری بین چند نسخه را ندارد [openshift.org]

مثال: در شکل زیر مراحل انجام این روش برای محیطی با سه نود نمایش داده شده است.

مرحله اول: قبل از شروع کار، ترافیک به سرور که نسخه ی قدیمی اپلیکیشن را دارد، هدایت می شود.

مرحله دوم: تمامی نود ها از مدار خارج می شود و دیگر ترافیک عملیاتی به سمت آن هدایت نمی شود و سپس به روزرسانی می شوند. در این زمان DownTime خواهیم داشت.

مرحله سوم: همه ی نودها به روزرسانی شده اند و به مدار باز میگردند.

 

Recreate Deployment Strategy

 


Rolling Strategy | Rolling Deployment

Rolling Deployment یکی دیگر از استراتژی های پایه استقرار نرم افزار است و هدف آن به حداقل رساندن یا حذف DownTime و کم کردن ریسک های وابسته به استقرار می باشد. Rolling Deployment برای محیط هایی عملیاتی که نیاز است به روزرسانی در آن ها بدون DownTime انجام شود، مناسب است. این استراتژی معمولا در محیط هایی با تعداد نود(سرور)های زیاد به کار گرفته می شود و برخلاف برخی دیگر از استراتژی ها نیاز به منابع اضافه ندارد و با استفاده از سرورها و منابع جاری قابل اجرا است.

روش انجام Rolling Deployment : در این روش یکی از (یک گروه از) نودها از دسترس خارج شده و نسخه ی جدید اپلیکیشن با نسخه ی قبلی جایگزین می شود، سپس ترافیک عملیات به آن هدایت می شود و نوبت به نود بعدی می رسد. این کار تا به روزرسانی همه ی نود ها ادامه می یابد.

مثال: در شکل زیر مراحل انجام این استراتژی برای محیطی با سه نود (سرور) نشان داده شده است. این مثال یک محیطی با عملیاتی است که ترافیک ورودی توسط یک Router یا Load-Balancer به سرورهای مشابه هدایت می شوند.

مرحله صفر : قبل از شروع کار، ترافیک به هر سه سرور که نسخه ی قدیمی اپلیکیشن را هاست کرده اند، هدایت می شود.

rolling deployment strategy 0

مرحله اول: یکی از نود ها از مدار خارج می شود و از آن پس ترافیک عملیاتی به سمت آن هدایت نمی شود. در همین حین نودی که از مدار خارج شده، به روزرسانی می شود.
rolling deployment strategy 1

مرحله دوم: نودی که به روزرسانی شده به مدار باز میگردد و نود دیگری از مدار خارج و به روزرسانی می شود.
rolling deployment strategy 2

مرحله سوم: مرحله دوم برای تمامی نودهای باقیمانده (در اینجا یک نود) تکرار می شود.

rolling deployment strategy 3

مرحله چهارم: در این مرحله تمامی نودها به مدار بازگشته و ترافیک به آن ها هدایت می شود.

rolling deployment strategy 4

چه موقع از Rolling Deployment استفاده کنیم ؟

  • زمانی که میخواهیم در حین استقرار یا به روزرسانی اپلیکیشن، DownTime نداشته باشیم
  • زمانی که اپلیکیشن می تواند به طور همزمان با نسخه ی جدید و قدیم کار کند

استفاده از این روش به این معنی است که اپلیکیشن  باید بتواند با نسخه ی قدیم و جدید به طور همزمان کار کند. در این روش ممکن است دیتایی توسط نسخه ی جدید ذخیره شود و توسط نسخه ی قدیمی خوانده شود (و بالعکس). در نتیجه اپلیکیشن باید به گونه ای طراحی شده باشد تا بدون اینکه مشکلی پیش بیاید این کار را انجام دهد. این موضوع در جاهای مختلفی باید رعایت شود، از جمله برای دیتاهایی که در فایل ذخیره می شوند، دیتاهایی که در پایگاه داده ذخیره می شوند، دیتاهایی که به طور موقت در cache ذخیره می شوند، یا دیتاهایی که سمت کلاینت و در مرورگر کاربران ذخیره می شوند. نکته ای بسیار مهم که در به کارگیری این روش وجود دارد این است که اپلیکیشن برای این کار تست باید طراحی و تست شده باشد.


جمع بندی

در این مطلب راجع به مفهوم استراتژی و استراتژی های استقرار نرم افزار صحبت کردیم، در ادامه به برخی از اهداف و چالش ها در این زمینه اشاره کردیم و دو تا از استراتژی های پایه استقرار نرم افزار به نام های Recreate و Rolling را با ذکر مثال شرح دادیم. همچنین مواقعی که می توان از این استراتژی ها استفاده کرد را شمردیم.

امیدوارم این مطب مورد استفاده شما دوستان واقع شده باشه. در مطلب بعدی که سعی میکنم کمتر از یک هفته دیگه منتشر کنم، استراتژی های پیشرفته ی استقرار نرم افزار که در Continuous Deployment و DevOps کاربرد دارند را بررسی خواهم کرد.

Share Button

دوآپس و تصورات اشتباه درباره DevOps

دوآپس و تصورات اشتباه درباره آن | DevOps Misundrestandings

تصورات اشتباه و کج فهمی ها درباره دوآپس ( DevOps )

دنیای فناوری اطلاعات با سرعت و شتاب زیادی در حال تغییر است و هر روز واژه های جدیدی در حال شکل گرفتن است، با این وجود شاید عجیب نباشد که درک های نادرست و کج فهمی هایی از این واژه ها ایجاد شود. واژه DevOps / دوآپس  (که اولین بار در کنفرانس Agile 2008 مطرح شد) هم از این قاعده مستثنی نبوده. از این رو سوالات زیادی درباره اینکه واقعا دوآپس چیست مطرح می شود. در این مطلب سعی کردم به طور خلاصه به برخی از تصورات اشتباه درباره DevOps بپردازم. در پست های آینده، به طور مفصل تری به “انواع روش های اشتباه اجرا و استقرار دوآپس در سازمان ها” خواهم پرداخت.

DevOps چیست ؟

بیشتر از آنکه روی پاسخ سوال “DevOps چیست ؟” توافق وجود داشته باشد، روی سوال “DevOps چه نیست ؟” وجود دارد. در ادامه بیشتر به این مطلب خواهم پرداخت
در ادامه مطالب زیر را خواهید خواند:


دوآپس فقط Automation و Continuous Delivery نیست

اشتباه بزرگ و رایجی که وجود دارد این است که تصور شود جنبش دوآپس کلا درباره ی خودکارسازی همه چیز با یک سری ابزار و تکنولوژی است. (مثل Docker, Ansible, Kubernetes, Team Foundation ). بسیاری بیان می کنند که ما در سازمان خودمان، دوآپس داریم آن را اجرا کردیم. وقتی که می پرسیم چطور آن را اجرا کردید، متوجه می شویم که از واقعیت دور هستند و فقط بخش کوچکی از آن را اجرا کرده اند. (معمولا پاسخ ها به مسائلی بیش از Automation و Continuous Delivery ختم نمی شود).

DevOps CD CI Agile چیست

دوآپس به معنی حذف عملیات نیست

برخی تصور میکننند که دوآپس یعنی اینکه توسعه دهندگان، کارهای عملیاتی را هم به دوش بگیرند و انجام دهند. قسمتی از این جمله درست است و قسمتی نادرست. این تصوری اشتباه است که دوآپس از سوی توسعه دهندگان بوجود آمده تا تیم عملیات را حذف کنند. کارشناسان عملیات متوجه شدند که اصول، فرایندها و روش های قدیمی برای استمرار موفقیت ها کافی نیستند. برای آنکه تیم های کسب و کار و توسعه به چابکی بیشتری برسند نیاز بود تا گام های مستحکم تری برداشته شود. اما برای آنکه قادر باشیم زیرساخت های سیستم را به روش موثری فراهم کنیم نیاز به یک تغییر جهت بنیادی داشتیم.

همانطور که متوجه شدیم قسمت هایی از عملیات نیاز به خودکارسازی دارند. این کار به چند روش قابل انجام است، یکی اینکه اعضای تیم عملیات، خودکارسازی را توسعه دهند، یا توسعه دهندگان برای “operation” کدنویسی کنند، یا هر دوی آن. پذیرش این موضوع برای برخی سخت است و در مقابل آن مقاومت می کنند، اما این بخشی از ارزشی است که با همکاری مشترک بین تیمی بوجود می آورد. تمامی تیم هایی که در این زمینه موفق شده اند شامل هر دو گروه از افراد بودند (متخصصان حرفه ای توسعه و متخصصان حرفه ای عملیات) و با یک همکاری مشترک در کنار هم، یک محصول بهتر ایجاد کردند.

دوآپس فقط ابزار نیست

دوآپس به سادگی اجرا و به کارگیری چند ابزار ساده نیست. یکی از مسائل نگران کننده که در تعاریف موجود وجود دارد، مفاهیم گیج کننده و با ساختاری ضعیف در آن ها است که باعث می شود افراد بعد از یادگیری این تئوری شروع کنند به اجرای فرایند ها و یا به کارگیری ابزارها بدون اینکه اصول دوآپس را در ذهن خود داشته باشند، که این قطعا یک ضد الگو است. همانقدر که خودکارسازی هوشمندانه می تواند سودمند باشد، خودکارسازی غیر هوشمندانه باعث آسیب هایی می شود. (در آینده مطالبی راجع به اصول و انواع ضد الگوهای دوآپس خواهم نوشت)

معمولا در چابک سازی تیم ها هم مشابه این اتفاق می افتد، اعضای گروه کار کردن در قالب iteration و اجرای سایر تمرین های چابک (Agile) را شروع می کنند بدون آنکه همکاری معناداری با هم داشته باشند. من تیم های زیادی را می شناسم که از برخی از روش ها و ابزارهای چابک استفاده می کنند بدون آنکه به اصول چابک توجه کافی داشته باشند. مشخص است که نتیجه ایده آل نمی شود. مطمئنا ابزارهای چابک (یا به طور مشابه ابزارهای دوآپس) می توانند مفید باشند، اما اگر ندانید که چطور از آن ها درست استفاه کنید، شبیه چاقوی جراحی ای است که با آن هندوانه قاچ کنید!

در آخر به این موضوع هم اشاره کنم این جمله هم اشتباه است که بگوییم “هیچ ابزاری نباید به نام ابزار دوآپس معرفی شود”. آیا poker planning در Agile به این معنی است که انجام آن باعث چابک شدن شما می شود ؟ خیر. اما این یک ابزار مشترک در بسیاری از روش های چابک است، پس می توانیم از آن به عنوان یک “ابزار چابک” نام ببریم. به طور مشابه به این دلیل که نمی توان دوآپس را فقط مجموعه ای از ابزار دانست، نمی توان گفت که ابزارهایی که برای اجرای آن ساخته می شوند، “ابزار دوآپس” نیستند.

دوآپس فقط یک فرهنگ نیست

بسیاری از افراد اسرار دارند که بگویند “دوآپس فقط یک فرهنگ است” و شما نمی توانید آن را با یک سری اصول و تمرین ها اعمال کنید، اما این جمله هم درست نیست. Agile فقط به واسطه بعد فرهنگی اش نیست که به هزاران تیم کمک کرده است، اعضای تیم های چابک در کنار هم بهروش هایی (Best Practice) را جهت اجرای آن شناسایی کردند و ابزارهایی را به کار گرفتند و آن ها را به اشتراک گذاشتند. دوآپس از بهروش ها، ابزارها و به طور کلی آیتم هایی در سطوح مختلف تشکیل شده است (و همچنان در حال کامل تر شدن است) ، و عمدتا بدون اجرای تمریناتی که حول آن بوجود آمده، بی فایده است.

دوآپس فقط توسعه و عملیات نیست

دوآپس محدود به توسعه (Development) و عملیات (Operation) نیست. برخی شاکی هستند و می گویند پس اعضای تیم امنیت چه ؟ یا مدیران شبکه چه ؟ چرا دوآپس به آن ها توجه نکرده ؟ اما نکته ی مهم این است که دوآپس برای همه ی کسانی است که به نحوی در تولید و تحویل یک محصول یا یک سیستم مشارکت دارند، از افراد کسب و کار گرفته، تا تحلیل گران، توسعه دهندگان، اعضای تیم های زیرساخت، شبکه، امنیت و سایر افراد مرتبط. همانطور که در توسعه چابک، تمرکز بر ارتباط و همکاری بین کسب و کار (Business) و تیم توسعه (Development) است (Biz + Dev)، در دوآپس تمرکز بر ارتباط و همکاری بین توسعه (Development) و عملیات (IT Operation) است اما تنها به این موارد محدود نمی شود. در نتیجه دوآپس شامل تمام کسانی می شود که به نحوی در تحویل یک محصول یا سرویس مشارکت دارند.

دوآپس فقط یک عنوان شغلی نیست

به سادگی و با تغییر نام تیم عملیات (IT Operation) به تیم دوآپس، هیچ چیز عوض نمی شود. با تعویض عنوان شغلی به مهندس دوآپس (DevOps Engineer) هم چیزی عوض نمی شود. اگر شما ارزش ها و اصول دوآپس را قبول نکنید (که نیازمند تغییرات در سطح کلی سازمان است نه فقط تغییرات در یک بخش یا تیم)، نمی توانید از تمام مزایای آن بهره مند شوید.

البته من مخالف این موضوع نیستم که کسی نباید از واژه ی دوآپس در عناوین شغلی استفاده کند. معمولا استفاده از این واژه برای تمایز بین دو تفکر است، یکی “تفکر به روش دوآپس، تاکید بر خودکارسازی، همکاری توسعه و عملیات، اجرای CI و …” و دیگری  “تفکر کسانی که در اتاق خودشان نشسته اند و اهمیتی نمی دهند که در بیرون از اتاق چه اتفاقی می افتد و منافع سازمان در چیست”.

دوآپس یک تیم نیست

اصولا هدف دوآپس حذف دیوار بین تیم ها و  سیلو ها است و اگر خودش به یک تیم جداگانه تبدیل شود، هدف اصلی نقض شده است. تشکیل یک تیم موقت به این نام، در بهترین حالت شاید بتواند یک راهی برای رسیدن به آن باشد اما احتمالا روش کارامدی نیست. تشکیل تیم جداگانه با نام تیم دوآپس یکی از ضدالگو هایی است که در مطلبی جداگانه به آن خواهیم پرداخت.

دوآپس راجع به همه چیز و همه جا نیست

برخی از افراد با طرح یک ادعای بزرگ به اشتباه مدعی می شوند که دوآپس درباره “همه چیز و همه جا !” است. دوآپس با تفکر های چابک (Agile) و ناب (Lean) اجین می شود و از آن به عنوان فرصتی برای همکاری درون سازمانی استفاده می شود، اما واقعا همه چیز به خاطر وجود آن نیست. این بخشی از یک فرهنگ کلی، امیدوار به همکاری و فرهنگ سازمانی چابک است در حالی که دوآپس به طور خاص در مورد این است که چطور محصولات و سرویس ها، عملیاتی و تحویل داده می شوند.

برخی افراد به اشتباه دوآپس را به یک نسخه ی کوچک از Agile و Lean یا فقط به عنوان یک علاقه مندی تبدیل می کنند (البته به عنوان یک چشم انداز خوب است) اما با دنبال کردن سلسله مراتب پیچیدگی ها، بیشتر به یکپارچکی عملیاتی (Operational Integration) می رسند و تلاش در سایر بخش ها امیدوار کننده نیست. اما همچنان مشکلات حل نشده ای در تحویل نرم افزار، نگهداری سرویس و سریعتر، قابل اعتمادتر و امن تر کردن آن باقی مانده است. اگر کسی بخواهد با استفاده از آموخته هایش در دوآپس در محدوده ی (scope) بزرگتری از سازمان به مشاوره بپردازد، که خیلی هم عالی است، اما معمولا افرادی فنی درگیر دوآپس هستند که می خواهند کار خودشان را بهبود بخشند نه کار دیگران را !

به گفته ی ارنست مولر، دوآپس را می توان “تحویل و عملیات چابک نرم افزار” (“Agile Software Delivery and Operations”) دانست که در آن افراد با همکاری یکدیگر بر روی ابتکارات سازمانی بزرگتر کار می کنند بدون اینکه ارزش پیشنهادی اصلی خود را فراموش کنند.





Share Button