devops چیست ؟ راهنمای کامل DevOps

devops چیست ؟ راهنمای کامل DevOps

devops چیست ؟ راهنمای کامل DevOpsWhat is DevOps? The Ultimate Guide to DevOps

devops چیست ؟ راهنمای کامل DevOps

توسط : admin
آیا می خواهید اطلاعات بهتری راجع به DevOps کسب کنید؟ در این مقاله هشت مفهوم اساسی در مورد devops را که باید بدانید به شما معرفی میکنیم.

 

راهنمای کامل DevOps در 8 مفهوم اساسی

این روزها DevOps به یک کلمه کلیدی بزرگ در جستجوها تبدیل شده است که برای بسیاری از افراد ، معانی مختلفی دارد. وقتی می خواهید درک کنید که DevOps چیست یا DevOps را تعریف کنید با یک چالش روبرو هستید. ما به جای تلاش برای تعریف DevOps ، قصد داریم مفاهیم اساسی را که افراد مختلف در DevOps با آن در ارتباط هستند و همچنین تاریخچه تکامل یافتن DevOps  را برای کمک به شما در  این مقاله جامع توصیف کنیم.

 

۱−DevOps از کجا آمده است؟

DevOps یکی از فرزندان توسعه چابک است ، که  با افزایش سرعت تولید نرم افزار ها نیاز به داشتن آن کاملا ضروری شد. پیشرفت در فرهنگ و متدهای چابک در دهه گذشته ، نیاز به یک رویکرد جامع تر در چرخه تحویل نرم افزار end-to-end  را نشان می دهد.

 

توسعه نرم افزار چابک چیست؟

توسعه سریع یک اصطلاح برای متد های توسعه نرم افزاری تکراری و افزایشی است. محبوب ترین روش های چابک شامل Scrum ، Kanban   ، Scaled Agile Framework  ، توسعه لاغر و برنامه نویسی بی وقفه (XP) میباشد.

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

در ابتدا ، تیم های چابک در درجه اول از توسعه دهندگان تشکیل می شدند. از آنجا که تیم های چابک در تولید نرم افزار مؤثرتر و کارآمدتر شدند ، مشخص شد که جدا بودن تیم های تضمین کیفیت (QA: Quality Assurance) و (Dev (development and operations ، ناکارآمد است. چابک به منظور افزایش سرعت در ارائه نرم افزار ،  QA را در بر می گیرد و اکنون که چابک بار دیگر در حال بزرگتر شدن است قصد دارد اعضای تحویل دهنده و پشتیبان خود را برای گسترش سریع از ایده تا تحویل را افزایش دهد.

DevOps شیوه های توسعه چابک را با ساده تر کردن حرکت تغییر نرم افزار از طریق مراحل ساخت ، اعتبارسنجی و استقرار و تحویل ، گسترش می دهد ، ضمن اینکه از تیم های عملکردی با مالکیت کامل برنامه های نرم افزاری  ، از طراحی تا تولید ، پشتیبانی می کنند.

DevOps یک طرز فکر IT است که به منظور بهبود سرعت و کیفیت ارائه نرم افزار ، توسعه دهندگان نرم افزار و عملیات IT را ترغیب به ، ارتباط ، همکاری ، ادغام و اتوماسیون میکند.

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

 

۲−DevOps چه چالش هایی را حل می کند؟

قبل از توسعه DevOps ، تیم ها مسئول جمع آوری نیازهای تجاری برای یک برنامه نرم افزاری و نوشتن کد بودند. در صورت برآورده شدن شرایط ، تیم QA ، جداگانه این برنامه را در یک محیط توسعه ایزوله ، آزمایش و کد عملیات را برای نهایی سازی ارسال می کند. تیم های استقرار بیشتر در گروه های خاموش مانند شبکه و پایگاه داده قرار می گیرند. هربار که یک برنامه نرم افزاری  به یک تیم مستقل محول می شود ، مشکلات بروز می کنند. مشکل این الگو این است که وقتی تیم ها جداگانه کار می کنند:

  • Dev اغلب از مشکلات  QA و Ops که مانع از اجرای برنامه مطابق پیش بینی می شود بی اطلاع است .
  • QA و Ops معمولاً بر روی ویژگیها کار می کنند و اطلاعات کمی از هدف تجاری و ارزش نرم افزار دارند.
  • هر گروه اهداف متضاد دارد که می تواند منجر به ناکارآمدی شده و در هنگام اشتباه انگشت اتهام به سمت آنها باشد.

 

DevOps با ایجاد تیم های متقابل ، عملکردی مشترک که مسئولیت نگهداری از سیستمی که نرم افزار را اجرا می کند و تهیه نرم افزار برای اجرای آن سیستم با افزایش بازخورد کیفیت و مسائل اتوماسیون ، این چالش ها را برطرف می کند.

یک سناریوی مشترک پیش از DevOps

هدف تیم Dev این است که کشتی بزرگی از ویژگی ها را ایجاد کرده ،و یک نسخه جدید را به QA منتقل کند. سپس هدف آزمایش كننده این است كه حداكثر اشکالات را پیدا كند. هنگامی که آزمایش کنندگان یافته های خود را به Dev منتقل می کنند ، توسعه دهندگان حالت دفاعی گرفته و آزمایش کنندگانی که محیط را برای اشکالات آزمایش می کنند سرزنش می کنند. آزمایش کنندگان پاسخ می دهند که این اشکالات ناشی از محیط آزمایش آنها نیست بلکه کد های برنامه نویس است که باعث بروز مشکل شده است.

سرانجام این مسائل حل می شوند و QA پس از دیباگ ، نسخه جدید را  به Ops منتقل میکند. هدف تیم Ops ایجاد کمترین تغییرات در سیستم است ، اما آنها با نگرانی کد را منتشر می کنند و  سیستم خراب میشود .و باز هم اشاره گیری انگشت اتهام از سر گرفته می شود.

Ops می گوید که Dev به آنها محصول معیوب داده است. Dev می گوید همه چیز در محیط تست خوب کار کرده است. Ops جهت تولید یک سیستم پایدار شروع به اشکال زدایی در سیستم  می کنند. تولید بر عهده Dev و QA نیست ، بنابراین در حالی که Ops تمام شب را سپری می کند تا مشکلات تولید را برطرف سازد ،آنها دست از کار می کشند.

 

۳−هدف DevOps چیست؟

بهبود همکاری بین همه ذینفعان از طریق برنامه ریزی برای تحویل و اتوماسیون فرایند تحویل به منظور:

  • بهبود فرایند استقرار
  • زمان بیشتری را برای بازار بدست آورید
  • میزان شکست کمتر در نسخه های جدید
  • کوتاه شدن زمان رفع باگها
  • بهبود میانگین زمان ترمیم

مطابق گزارش وضعیت DevOps در سال 2015 ، "سازمانهای عالی کارآمد فناوری اطلاعات 30 برابر بیشتر و 200 برابر زمان هدر رفت کمتر دارند. آنها 60 برابر کمتر شکست میخورند و 168 برابر سریعتر ترمیم می یابند. "

یک سناریو مشترک Pre-DevOps : گروه نرم افزاری قبل از شروع یک پروژه نرم افزاری جدید ، با یکدیگر ملاقات می کنند. این تیم شامل توسعه دهندگان ، آزمایش کنندگان ، عملیات و متخصصان پشتیبانی است. این تیم قصد دارد بررسی کند که چگونه نرم افزاری بسازند که کار کند و آماده ارائه باشد.

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

 

۴−شما اکنون در کجای DevOps هستید؟

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

نمودار چرخ devops

 

محور عمودی سه سطح زنجیره تحویل DevOps را ترسیم می کند: ادغام مداوم ، تحویل مداوم و استقرار مداوم. انجمن DevOps به سازمانهایی که در بالا سمت راست DevOps قرار دارند به عنوان تک شاخهای صورتی یاد می کند زیرا در حال حاضر تعداد معدودی از آنها وجود دارد که شما آنها را اغلب در مناطق وحشی نمی بینید. نمونه های مشهور این تک شاخ ها شرکت هایی مانند Netflix ، Etsy ، Amazon ، Pinterest ، Flicker ، IMVU و Google هستند. در نظرسنجی اخیر ، شرکت کنندگان نشان دادند مکان سازمانهایشان در زنجیره DevOps به این شکل جای دارد:

  • 55٪ پایین سمت چپ
  • 26٪ پایین سمت راست
  • 14٪ بالا سمت چپ
  • 5٪ سمت راست

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

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

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

 

۵−مراحل بلوغ DevOps چیست؟

در بلوغ DevOps چندین مرحله وجود دارد. در اینجا چند مورد از مراحل اصلی که باید بدانید ارائه شده است.

 

توسعه آبشاری

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

 

ادغام مداوم

ادغام مداوم عبارت است از ادغام سریع کدی که جدیداً توسعه یافته با کد اصلی که قرار است منتشر شود. ادغام مداوم زمان زیادی را صرفه جویی می کند که تیم آماده انتشار کد باشد.

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

فرآیند ادغام مداوم از منظر DevOps شامل بررسی کد شما ، وارد کردن آن به کد قابل استفاده (اغلب باینری قابل اجرا) و اجرای برخی از تست های اعتبار سنجی اساسی است.

 

تحویل مداوم

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

 

استقرار مداوم

استقرار مداوم ، نباید با تحویل مداوم [DevOps نیروانا] اشتباه گرفته شود ، استقرار مداوم تکامل یافته تحویل مداوم است. این عمل به کارگیری تمام راه های تولید بدون هیچ گونه مداخله انسانی است.

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

در حالی که دستیابی به نیروانا در DevOps اغلب هدف نهایی اکثر شرکتها نیست ، آنها اغلب بر حرکت به سمت تحویل مداوم متمرکز می شوند.

 

۶−ارزش DevOps چیست؟

DevOps به شدت بر ایجاد فرهنگ مشترک و بهبود کارایی از طریق اتوماسیون با ابزارهای DevOps تمرکز دارد. در حالی که برخی از سازمان ها و مردم تمایل دارند که بیش از دیگری ارزش خود را نشان دهند ، واقعیت این است که ترکیبی از فرهنگ و ابزار برای موفقیت لازم است. آنچه در مورد این دو ارزش در DevOps باید بدانید در اینجا آورده شده است.

 

فرهنگ DevOps

فرهنگ DevOps با افزایش همکاری ، کاهش چالش ها ، مسئولیت مشترک ، تیم های مستقل ، بهبود کیفیت ، ارزیابی بازخورد و افزایش اتوماسیون مشخص می شود. بسیاری از ارزش های DevOps جزو ارزش های چابک هستند زیرا DevOps یک چابک گسترش یافته است.

روش های Agile یک راه جامع تر برای ارائه نرم افزار است. تیم های توسعه چابک ، پیشرفت  را از نظر کارکرد نرم افزار اندازه گیری می کنند. صاحبان محصولات ، توسعه دهندگان ، آزمایش کنندگان و طراحان UX با همان اهداف مشابه همکاری می کنند.

DevOps فقط ذهنیت عملیات را اضافه می کند و شاید یکی از اعضای تیم با برخی از آن مسئولیت ها را به تیم چابک وارد کند. در حالی که قبل از اینکه نرم افزار از نظر کارکرد اندازه گیری شود ، پیشرفت DevOps از نظر کارکرد نرم افزار در دست مشتری اندازه گیری می شود.

برای دستیابی به این هدف ، Dev و Ops باید چالش های مابین را کنار گذاشته و با یکدیگر همکاری کنند ، مسئولیت حفظ سیستمی که نرم افزار را اجرا می کند بپذیرند ، و نرم افزار را برای اجرای روی سیستم با افزایش بازخورد و اتوماسیون تحویل آماده کنند.

 

ابزارهای DevOps

ابزارهای DevOps شامل سیستم های مدیریت پیکربندی ، تست و ساخت ، استقرار برنامه ها ، کنترل نسخه و ابزارهای نظارتی هستند. ادغام مداوم ، تحویل مداوم و استقرار مداوم به ابزارهای مختلفی احتیاج دارد. در حالی که هر سه روش می توانند از همان ابزارها استفاده کنند ، در حالی که از طریق زنجیره تحویل پیشرفت می کنید ، به ابزارهای بیشتری نیاز خواهید داشت.

 

چه ابزاری در DevOps استفاده می شود؟

در ابتدا ما به طور خلاصه در مورد برخی از ابزارهای مورد استفاده در DevOps بحث کردیم. در اینجا برخی از ابزارها و روشهای اصلی که باید بدانید را معرفی میکنیم.

 

Source Code Repository

مخزن سورس کد مکانی است که توسعه دهندگان وارد آن می شوند و کد را تغییر می دهند. مخزن کد منبع نسخه های متنوعی از کد را که در آن وارد شده اید ، مدیریت می کند ، بنابراین توسعه دهندگان نمی توانند هر کاری خواستند بکنند.

کنترل منبع احتمالاً حدودا چهل ساله است ، اما یکی از مؤلفه های اصلی ادغام مداوم است. ابزارهای ذخیره سازی کد منبع محبوب Git ، Subversion ، Cloudforce ، Bitbucket و TFS هستند.

 

Build Server

Build Server ابزاری برای اتوماسیون است که کدهای موجود در مخزن کد منبع را در پایگاه کد اجرایی گردآوری می کند. ابزارهای رایج عبارتند از جنکینز ، SonarQube و Artifactory.

 

Configuration Management

مدیریت پیکربندی ، پیکربندی یک سرور یا یک محیط را تعریف می کند. ابزارهای مدیریت پیکربندی محبوب Puppet و Chef هستند.

 

Virtual Infrastructure

وب سرویس آمازون و Microsoft Azure نمونه هایی از زیرساخت های مجازی هستند. زیرساخت های مجازی توسط فروشندگان ابری که زیرساخت ها یا بسترهای نرم افزاری را به عنوان خدمات (PaaS) به فروش می رسانند ، فراهم شده اند. این زیرساخت ها دارای API هایی هستند که به شما امکان می دهند توسط برنامه نویسی ، ماشینهای جدیدی را با ابزارهای مدیریت پیکربندی مانند Puppet و Chef ایجاد کنید.

همچنین ابرهای خصوصی وجود دارد. به عنوان مثال ، VMware دارای vCloud است. زیرساخت های مجازی خصوصی شما را قادر می سازد ابرهایی با سخت افزارهای بالا را در مرکز داده خود اجرا کنید.

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

 

Test Automation

اتوماسیون تست  سابقه طولانی دارد. تست DevOps بر پایه آزمایش خودکار در خطوط ساخت شما متمرکز است تا اطمینان حاصل شود که تا زمانی که چیزی برای استقرار دارید ، آماده استقرار است. شما نمی توانید به نقط delivery تحویل مداوم برسید در حالی که کد شما بدون مداخله انسانی تست نشده باشد. ابزارهای رایج Selenium و Water هستند.

 

Pipeline Orchestration

خط لوله مانند یک خط مونتاژ تولید است که از زمانی که یک توسعه دهنده می گوید ، "فکر می کنم کار خود را انجام داده ام" اتفاق می افتد ، تا زمان استقرار کد در محیط تولید و یا در مرحله پیش تولید تا مرحله آخر.

 

یکی سازی تولید و تحویل نرم افزار

VersionOne  مدیریت چرخه کاربرد نرم افزار چابک و DevOps را متحد می کند ، و یک تصویر کامل از کل خط لوله تحویل نرم افزار خود، در یک پلتفرم واحد ارائه می دهد. VersionOne® Continuum ™ برای DevOps یک راه حل تحویل مداوم برای اتوماسیون ، سازماندهی و تجسم جریان تغییر در چرخه تحویل نرم افزار است.

 

تاریخچه DevOps چیست؟

2007

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

پاتریک برای یک مرکز بزرگ یکپارچه سازی داده کار مشاوره ای را انجام داده بود. او مسئول آزمایش بود و این بدان معنا بود که او زمان زیادی را با Dev و Ops می گذراند. پاتریک همیشه نگران اختلافات بین نحوه کار Dev و Ops بود ، اما او در مورد مدیریت چالش های این دو گروه نا امید شده بود.

ادغام مداوم در جامعه چابک محبوبیت بیشتری پیدا می کرد و Dev را به استقرار نزدیک می کرد ، اما هنوز چیزی در آنجا نبود که کاملاً از شکاف Dev و Ops عبور کند. پاتریک مطمئن بود که باید راهی بهتر باشد که این دو تیم با هم کار کنند.

 

2008

اندرو شفر ایده ای برای زیرساخت های چابک "پرندگان یک پر" در کنفرانس چابک 2008 ارائه داد. پاتریک دبوئیس پست را دید و به جلسه رفت. متأسفانه ، او تنها کسی بود که حاضر شد. این ایده چنان ضعیف پذیرفته شد که حتی اندرو  حاضر نشد جلسه را ادامه دهد.

خوشبختانه ، پاتریک آنقدر هیجان داشت که شخص دیگری که علاقه مند به حل چالش های Dev و Ops هست را پیدا کرده و آنها تصمیم به ایجاد یک گروه گوگلی به نام Agile System Administling گرفتند.

 

2009

جان آلسپاو ، معاون ارشد عملیات فنی فلیکر و پل هاموند مدیر مهندسی فلیکر در کنفرانس شتاب O'Reilly در سن خوزه با عنوان "10+ کار تولیددر روز: همکاری با Dev & Ops در Flickr" سخنرانی کردند. " در این ارائه مقدماتی برای چگونگی همکاری Dev و Ops به طور مؤثر برای بهبود استقرار نرم افزار بیان شد.

پاتریک دبوئیس از طریق پخش زنده در بلژیک به تماشای این همایش پرداخت و از آن الهام گرفت تا کنفرانس خود با نام DevOpsDays را در گنت بلژیک را آغاز کند. این کنفرانس یک گروه پرانرژی از مغزهای متفکر را در تلاش برای بهبود استقرار نرم افزار گرد هم آورد. آنچه ممکن است از این هم مهمتر باشد این است که این گروه از افراد با هشتگ #DevOpsDays گفتگو را در توییتر ادامه می دهند.توئیتر تلاش میکرد که در فضای کاراکترها صرفه جویی کند ،بنابراین خیلی زودمردم طول این نام را کوتاه کرده و هشتگ به #DevOps تغییر نام داد.

 

2010

سال بعد ، DevOpsDays در استرالیا و ایالات متحده برگزار شد با گذشت زمان تعداد بیشتری DevOpsDays وجود داشت که در کشورهای مختلف و شهرهای مختلف جهان میزبانی می شدند. جلسات رو در رو ، بیشتر و بیشتر مردم را به اشتیاق در مورد DevOps سوق می داد تا اینکه به یک جنبش مردمی کامل تبدیل شود.

 

2011

تا سال 2011 ، جنبش DevOps مورد توجه افراد و ابزارهای منبع آزاد و كمترین توجه تحلیلگران یا فروشندگان قرار گرفت. اما در سال 2011 ، این جنبش شروع به جریان اصلی کرد و توجه تحلیلگرانی چون کامرون هاییت از گارتنر و جی لیمن از 451 Research را به خود جلب کرد. فروشندگان بزرگ شروع به بازاریابی DevOps کردند.

 

2012

در سال 2012 ، DevOps به سرعت به کلمه کلیدی تبدیل شد و DevOpsDays به رشد خود ادامه داد.

 

2013

عطش عمومی به اطلاعات DevOps باعث شد چندین نویسنده به نوشتن کتاب در مورد این موضوع الهام بخش بنمایند. نمونه بارز این پروژه Phoenix توسط ژن کیم ، کوین بهر و جورج اسپافورد و اجرای نرم افزار توسعه ناب توسط مری و تام پوپندنیک است.

 

۲۰۱۴

سال 2014 شرکت های بزرگی مانند Target ، Nordstrom و LEGO به برخی از اولین شرکتهایی تبدیل شدند که DevOps را وارد این شرکت کردند.

نظرات :

در عرض چند دقیقه برای ایجاد حساب

کاربری خود اقدام کنید


اکنون حساب کاربری خود را ایجاد کنید!


ایجاد حساب کاربری

با ثبت نام در نیلوتک از آخرین بروز رسانی های آموزش ها و مقالات سایت مطلع شوید