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

 

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

بدون  DevOps

به طور سنتی، یا ۱۰ سال پیش می گویم، تیم توسعه می تواند تقریبا به توسعه دهندگان تقسیم شود – افرادی که می دانستند چگونه کد و عملیات را بنویسند. برای کسانی که هنوز هم تعجب می کنند – کسانی که بر روی زمین این عملیات هستند:
آنها مدیران – sysadmins، مدیران شبکه، مدیران پایگاه داده، و همه افراد دیگر که زیرساخت را می دانند.
بنابراین … عملیات علاقه مند به نگه داشتن چیزهای پایدار برای به حداقل رساندن احتمال درگیری های نرم افزاری بود. در حالی که توسعه دهندگان عموما در مورد ویژگی های جدید، نسخه های جدید، و همچنین رفع اشکالات بله مراقبت می کنند. مشکل اصلی با همه موارد عدم همکاری و ارتباط بود. به عنوان یک نتیجه، نرم افزار را نمی توان با سرعت مورد نظر تحویل داده شد.

 

با DevOps

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

 

مزایا:

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

 

دیگه چی

به جز روش های فرهنگی، روش DevOps به لطف روش های زیر امکان پذیر بود:

 

• زیرساخت به عنوان کد – رویکردی است که سرورها می توانند به طور خودکار پیکربندی شوند. ایده در اینجا این است که تصور کنید زیرساخت های سرور بیشتر شبیه یک مفهوم انتزاعی است. به اندازه کافی آسان است زیرا بسیاری از سرورهای امروز مبتنی بر ابر هستند. گام بعدی این است که به راحتی پیکربندی سرورهای خود را در یک فایل پیکربندی توصیف کنید. مزایای این موارد زیر است: شما می توانید هر تعداد سرور ها را بسیار سریع پیکربندی کنید، تمام تنظیمات با همان کد ثبت می شوند.
• معماری Microservice – یک رویکرد در توسعه نرم افزار زمانی که نرم افزار به قطعات به آسانی متصل شده است تقسیم شده است. تصور کنید یک برنامه پیامرسانی رسانه های اجتماعی مدرن با چت، داستان، تماس صوتی، ربات و غیره داشته باشید. همه اینها را می توان به عنوان برنامه های کوچک مستقل توسعه داد. این روش باعث می شود بخش هایی از برنامه را حفظ، آزمایش و استفاده مجدد کند. از سوی دیگر، فرآیند توسعه پیچیده تر می شود، زیرا کد شامل بخش های بیشتری است. توسعه دهندگان باید ارتباط بین خدمات درون برنامه ها را در نظر بگیرند.
• DevOps را دوست دارد اتوماتیک – اتوماسیون مورد نیاز توسط مدرن و مدرن توسعه سریع صنعت نرم افزار عامل. ده ها تن از مجتمع های به طور مداوم یکپارچه شده اند برای راه اندازی …. روزانه. هیچ راهی وجود ندارد که بتوانید همه آنها را به صورت دستی آزمایش کنید. همین امر برای پیکربندی سرور استفاده می شود.
• DevOps از زرادخانه ابزار استفاده می کنند – بسیاری از جنبه های DevOps بدون ابزار مانند Jenkins، Ansible، Docker یا Puppet امکان پذیر نخواهد بود. با این حال، ابزار تنها روند را تسهیل و اجازه می دهد برای رسیدن به هدف. دانستن چگونگی ایجاد ظرف Docker لازم نیست به این معنی باشد که شما در باشگاه DevOps هستید.

 

 

 

چرا شما نیاز به DevOps دارید؟

این همه در مقیاس پروژه بستگی دارد. اگر هدف شما این است که یک محصول حداقل ماندگاری (MVP) را برای آزمایش ایده خود بگذارید، به احتمال زیاد شما می توانید بدون شیوه های DevOps زندگی کنید. اگر نرم افزار شما چندین بار منتشر شده است. زمان بیشتری برای راه اندازی محیط DevOps از ابتدا لازم است. در مراحل اولیه مردم گیج می شوند چرا باید زمان و پول بیشتری برای راه اندازی Docker و Ansible بگیریم. پاسخ ساده است – اکنون زمان کمی بیشتر خواهد بود، و در نتیجه، آن را در یک چشم انداز دراز مدت ذخیره کنید.

 

چگونه ما DevOps را اجرا می کنیم

در ستون های جانگا، اجرای بسیار به مشتری بستگی دارد. در اینجا فهرستی از “انواع” ترین درخواستها را مشاهده می کنید:

 

• مشتریانی که می خواهند یک MVP را بسازند

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

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

 

• مشتریانی که قبلا بخشی از پروژه را توسط فرد دیگری ساخته اند.

اغلب زمان سخت ترین مورد است. ما دوست داریم از پروژه هایی که توسط شخص دیگری آغاز شده اند جلوگیری کنیم و به دلایلی رها شده ایم. با این وجود، برخی از موارد استثنایی نادر زمانی وجود دارد که پروژه ها به اندازه کافی امیدوار باشند تا خطر را برطرف کنند. موارد به طور انحصاری به مشتری بستگی دارد. گاهی اوقات ما یک برنامه را با در نظر گرفتن بهترین شیوه های DevOps توسعه می دهیم، با درخواست این است که برنامه را از Python 2 به Python 3 ارتقا دهیم. در حالیکه یکی دیگر نیاز به بازنویسی کاملی از سطح زمین را دارد.

• مشتریان و شرکای بلند مدت با برنامه های بالغ

این مورد مربوط به یک “دنیای کامل DevOps” است. مهندسین نرم افزار ما با همکاری نزدیک با عملیات مشتری یا مهندسان DevOps کار می کنند.

هر زمان که ما یک درخواست برای پیاده سازی یک ویژگی جدید دریافت کنیم، توسعه دهندگان ما اطلاعات زیر را به تیم های ops مشتری ارائه می دهند:

• وابستگی های احتمالی
• قابلیت بارگذاری احتمالی می تواند اداره شود
• خدمات تحت تأثیر ویژگی های آینده

تیم ops سرورها را بر اساس نیازهای برنامه نویسان راه اندازی می کند. این، به نوبه خود، زندگی طولانی تر توسعه دهندگان ما را آسان تر می کند.

Toolchain  ما

در اینجا ابزارهایی هستند که ما هر روزه از آن استفاده می کنیم مهم نیست که کدام پروژه با ما در ارتباط است:

 

• بندر برای کانتینر
• جنکینز و دایره CI برای ادغام و تحویل مداوم
• برای ردیابی خطا در زمان واقعی ارسال کنید
• ELK برای سنجش و ورود به سیستم
• Terraform و غیر ممکن برای تهیه سرور و زیرساخت
• Nagios و جدید Relic برای نظارت

شما می توانید مقایسه CI ما و آموزش Docker در وبلاگ ما را بررسی کنید

نتیجه

DevOps یک رویکرد است که توسعه دهندگان و عملیات را برای توسعه و ارائه نرم افزار کارآمد تر از رویکرد سنتی سنتی است. تیم ها تنها به توسعه دهندگان و عملیات IT و طراحی سایت محدود نمی شوند. در اغلب موارد، رویکرد نیز در مورد QAs، PMs و کارشناسان امنیتی گسترش می یابد. شرکت هایی که DevOps را در مراحل اولیه اجرا می کنند، زمینه رشد رشد را ایجاد می کنند.