یازده شاخص کلیدی عملکرد دواپس | 11 DevOps KPI

یازده شاخص عملکرد کلیدی دواپس

شاخص های کلیدی عملکردی دواپس یا DevOps KPI که قبلا به چهار دسته سرعت، کیفیت، بهره وری و امنیت تقسیم کردیم را چطور ارزیابی می‌کنید؟ در این مطلب یازده شاخص کلیدی عملکرد، اصول و پایه های لازم برای ارزیابی موفقیت DevOps را معرفی و بررسی کرده ایم.

velocity iconشاخص های سرعت دواپس | DevOps Velocity KPI

در مطلب قبلی با عنوان “ارزیابی میزان موفقیت عملکرد دواپس با شاخص های عملکرد کلیدی” به دلیل اندازه گیری و ارزیابی سرعت اشاره کردیم. اما با چه سنجه و متریک هایی می توان سرعت را اندازه گیری کرد؟ در اینجا قصد داریم چهار شاخص عملکرد کلیدی سرعت دواپس را معرفی و شرح دهیم.

1. فرکانس استقرار | Frequency of deployment

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

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

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

  • طراحی بهتر معماری در فازهای ابتدایی‌تر DevOps: ماژولار کردن، امکان استقرار مکرر و پی در پی را فراهم می کند.
  • پوشش بهتر تست: اگر تولیدات بیشتری را مورد استفاده قرار دهید، عوامل مربوطه حس می کنند که می توانند محصولات را با فرکانس بالاتری مستقر کنند.

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

2. سرعت استقرار | Speed of deployment

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

دلیل اهمیت: در روش های سنتی، سیستم های شرکتی اتصال تنگاتنگی دارند(tightly coupled هستند)؛ هر زمان چیزی مستقر می شود، ممکن است در نهایت نیاز به استقرار مجدد کل اپلیکیشن باشد. یک دهه پیش، این امر قابل قبول بود – می توانستید از کار افتادگی پنج ساعته‌ی ویندوز را برای نیمه شب زمانبندی کنید، بدون این که این از کار افتادگی تاثیر منفی برای بیزینس داشته باشد. اما مشاغل امروزه جهانی هستند – مثلاً وقتی در امریکا نیمه شب است، در آسیا روز است – و اکثر شرکت ها در همه اوقات مشتریانی دارند که بیدار هستند. بنابراین سریع بودن استقرار امری حیاتی است.

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

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

3. سرعت تایید بیلد ها | Speed of build verification (QA)

مفهوم: کل زمان حرکت یک محصول در چرخه QA

دلیل اهمیت: اکثر اوقات QA تبدیل به یک تنگنا می شود. ارزیابی زمان سپری شده برای یک محصول تولیدی در QA اطلاعات کلیدی درباره اینکه با چه سرعت و فرکانسی می توانید یک محصول یا سرویس ارائه دهید، در اختیارتان قرار می دهد. وقتی مقدار این سنجه بالا باشد، متوجه می شوید که می توانید فرکانس را بدون اینکه QA تبدیل به تنگنا شود، افزایش دهید. اگر این مقدار پایین باشد، نشان می دهد که نیاز به پیاده سازی تکنیک هایی مثل اتوماسیون تست در خط لوله‌ی انتشار محصول دارید (release pipeline).

4. فرکانس تایید بیلد ها | Frequency of build verification (QA)

مفهوم: تعداد تولیداتی که یک تیم QA می تواند در یک دوره خاص به مصرف برساند.

دلیل اهمیت: افزایش تعداد تولیداتی که QA می تواند به صورت مثبت مورد مصرف قرار دهد تاثیر مثبتی بر زمانبندی انتشار دارد. ممکن است سرعت استقرار بالا باشد، اما بدون ادغام مستمر (Continuous Integration) باید تولیدات را به صورت دستی مدیریت کنید که این کار باعث کند شدن خط لوله انتشار (DevOps Pipeline) می شود. به طور مشابه، بدون Continuous Testing، حین فرایند تست زمان هدر می رود. نتیجه این است که تیم QA نمی تواند حداکثر تعداد تولیدات را در هر چرخه به مصرف برساند و پوشش تست – همچنین اطمینان از حرکت به مرحله بعد – دچار مشکل است.

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


quality iconشاخص های کیفیت دواپس | DevOps Quality KPI

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

5. نرخ موفقیت استقرار | Deployment success rate

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

دلیل اهمیت: نرخ موفقیت بالا هنگام استقرار در سرورهای غیرتولیدی، دلالت بر کیفیت بالا در مراحل قبلی دارد. نرخ موفقیت پایین حاکی از ضعف کیفی کدنویسی است. در خیلی از شرکت ها، ممکن است System Integration Test و QA نرخ موفقیت بالایی داشته باشند ولی در عین حال در محیط پیش عملیات (Staging) موفق نباشند. این معیار می تواند به شما کمک کند تا مشکلات موجود در مرحله استقرار را هدف گرفته و از بین ببرید. نرخ موفقیت باید به مرور زمان افزایش پیدا کند.

در سازمان هایی که عملکرد خیلی خوبی دارند، مقدار این معیار باید به دلیل حذف مشکلات در پیش عملیات (Staging) – یا بهتر از آن، پیشگیری از این مشکلات – بالا باشد. اما خیلی از سازمان ها در این حوزه دچار چالش هستند و باید انتشارها (یا نسخه ها) را به عقب برگردانند. پایین بودن نرخ موفقیت بعد از یک فاز پیمایش موفق می تواند نشان دهنده چندین مشکل باشد:

  • فقدان سازگاری بین محیط های مختلف | Lack of consistency across environments
  • فقدان مدیریت مناسب داده های تست | Lack of good test data management
  • پوشش و کیفیت پایین تست | Low testing quality and coverage

6. میزان حوادث/نقایص | Incident/defect volumes

مفهوم: تعداد حوادث و نقایص گزارش شده در یک نسخه خاص از یک محصول یا سرویس در محیط عملیاتی

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

  • کیفیت نیازمندی ها | Quality of the requirements
  • کیفیت توسعه | Quality of development
  • کیفیت تست از جمله قابلیت مدیریت داده های تست | Quality of testing, including test data management capability
  • سطح همکاری بین استقرار، QA و عملیات (مثلاً اشتباه در درک نیازمندی ها) | Level of collaboration between development, QA, and operations

7. نرخ پوشش نیازمندی ها | Requirements coverage ratio

مفهوم: درصد قابلیت ردیابی (traceability) بین نیازمندی ها و تست ها (منظور امکان ارتباط دادن این دو به هم است).

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

وقتی که نیازمندی ها و test case ها با هم هماهنگی داشته باشند، تغییر در نیازمندی ها منجر به قابلیت مشاهده موارد متناظر در پوشش test case می شود. بروز رسانی هر یک از test case به نیازمندی ربط پیدا می کند. وجود ارتباط، تاثیر مثبت و مستقیمی بر کیفیت نرم افزار دارد. بالا بودن میزان این ارتباط نشان دهنده افزایش کیفیت نرم افزار؛ تناقض و ناسازگاری کمتر بین تحلیل گران، توسعه دهندگان و تیم QA؛ و بهره وری بالاتر است.


productivity iconشاخص های بهره وری دواپس | DevOps Productivity KPI

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

8. میزان استفاده از ویژگی‌ها | Feature usage

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

دلیل اهمیت: DevOps یک چرخه بازخوردی است (feedback loop) که شامل بیزنس، توسعه، تست، عملیات و کاربران می شود. پایین بودن میزان استفاده از ویژگی‌ها به این معناست که بخش فناوری اطلاعات (IT) مشغول توسعه ویژگی ها و امکاناتی است که یا مورد تقاضا نیستند (بازخورد ضعیف از سوی بیزنس به بخش توسعه)، یا مورد نیاز نیستند (بازخورد ضعیف از طرف کاربران به بیزنس) یا به صورت ضعیف ساخته شده اند (مشکل در بازخورد از سوی بخش IT). هزینه ویژگی ها و امکاناتی که مورد استفاده قرار نمی گیرند، می تواند بسیار زیاد باشد، بنابراین مهم است که علت این امر شناسایی شود. بالا بودن تعداد ویژگی هایی که در یک محصول خاص استفاده نشده اند نشان دهنده منفی بودن میزان اثربخشی مدیریت و توسعه نیازمندی ها است.

9. میانگین زمان لازم برای بازیابی سرویس | Mean time to restore service (MTTRS)

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

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

بعلاوه، MTTRS می تواند مشخص کننده مشکلاتی در سازمان باشد از جمله:

  • وضعیت سلامت چرخه بازخورد بین بیزنس، بخش های توسعه، QA، عملیات و کاربران نهایی.
  • سطح چابکی شرکت و این که شرکت با چه سرعتی می تواند به تغییرات ایجاد شده توسط یک فرد، فرایند و تکنولوژی‌های آینده واکنش نشان دهد.
  • بهره وری و اثربخشی کلی
  • The health of the feedback loop between the business, development, QA, operations, and end users
  • The level of enterprise agility and how quickly the enterprise can react to changes from a people, process, and technology perspective
  • Overall productivity and effectiveness

security iconشاخص های امنیت دواپس | DevOps Security KPI

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

10. میزان قبول شدن تست امنیت | Security test pass rate

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

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

11. نرخ تشخیص اسکن کدها | Code scanning detection rate

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

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


موفقیت دواپس توسط DevOps KPI

تحلیل مناسب اعداد و ارقام

DevOps این قابلیت را دارد که زنجیره ارائه نرم افزار را به ماشینی با تفکر ناب، سریع و به شدت موثر تبدیل کند تا آنچه کاربران تقاضا دارند را عرضه کند. این تبدیل اهمیت بسیار زیادی دارد. طبق یکی از نظر سنجی های شرکت Forrester Consulting که در سال 2015 انجام شده، 64 درصد از پاسخ دهندگان بر این باورند که نرم افزار یکی از عوامل کلیدی توانمندساز مشاغل است و موفقیت مشاغل بستگی به اپلیکیشن هایی با کیفیت بالا دارد که مناسب با مدل های بیزنسی مدرن باشد.

DevOps has the potential to transform the software delivery chain into a lean, fast, highly effective machine that delivers what users want.

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

مسیرهای آتی برای شاخص های کلیدی عملکرد DevOps

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

یکی از شاخص های کلیدی عملکرد که در حال حاضر مشاغل علاقه زیادی به آن دارند، میزان استفاده از ویژگی ها است اما می توانید در کنار آن، زمان چرخه را هم نظارت کنید که نشان می دهد تولید یک ویژگی خواسته شده و استقرار آن در یک محصول چقدر زمان می برد. البته شاخص های کلیدی عملکرد از نوعِ اقتصادی نیز همیشه برای مشاغل متناسب و مهم هستند – که یکی دیگر از راه های گسترش داشبورد را تشکیل می دهند.

بعلاوه می توانید داشبورد DevOps را به سمت پایین هم گسترش دهید تا فعالیت های روزمره‌ی افراد را تحت پوشش قرار دهد.

استفاده از معیارها برای ادامه مسیر حرکت DevOps

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


“تشکیلات IT باید این امر را به رسمیت بشناسند که DevOps  قابلیت تحول و تغییر را دارد و بر این اساس باید در جنبه های فردی و فرایندی تلاش هایشان سرمایه گذاری زمانی و پولی کنند. مدیران IT نباید بیش از حد بر فناوری تاکید کنند و در نتیجه حوزه های دیگر را تحت تاثیرات منفی قرار دهند.”

 

منبع : “Hewlett Packard Enterprise, “Measuring DevOps success

Share Button

چارچوب CALMS در DevOps چیست و چه کمکی می کند؟

Keep CALMS and do DevOps

پایه و اساس DevOps ، تغییر است. Keep CALMS !

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

کافی است تا عبارت “DevOps” را در google جستجو کنید تا دیاگرام ها و متدولوژی های بسیاری را پیدا کنید که هر کدام از آن ها جنبه ی متفاوتی را برجسته کرده اند. اما می توان گفت که همه ی آن ها در موارد زیر با هم مشترک اند:

  1. فرهنگ سازی | Culture
  2. خودکارسازی Automation
  3. تفکر ناب | Lean thinking
  4. اندازه گیری همه چیز Measurement
  5. اشتراک گذاریSharing

به این چهار مورد اصول یا چارچوب CALMS در DevOps می گویند.

چارچوب CALMS در DevOps چیست ؟

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

Culture | فرهنگ

همه میدانیم فرهنگ چیزی نیست که یک نفر بتواند آن را پیاده سازی کند. فرهنگ در یک محیط طبیعی که شامل سرتاسر تیم تولید نرم افزار می شود وجود دارد. منظور از سرتاسر همه ی افراد است از جمله توسعه دهندگان (Development)، تضمین کنندگان کیفیت (QA) و تیم های عملیات (Operation) و … . در چنین اکوسیستمی که متشکل از مجموعه ای از افراد و ابزارها است، برای رفع موانع و تسهیل همکاری برای دستیابی به اهداف نهایی، یک کار فرهنگی لازم است.

هیچ چیز زشت درباره فرهنگ وجود ندارد.

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

Automation | خودکارسازی :

هنگامی که فرهنگ سازی در سازمان انجام شد، می توانید بر خودکارسازی یا اتوماسیون تمرکز کنید. اتوماسیون تنها به نوشتن Script ها و استفاده از Unit Test ها یا Functional Test ها محدود نمی شود. خودکارسازی شامل همه قسمت ها از جمله Continuous-Integration ، Continuous-Delivery/Deployment، Infrastructure-Automation و هر جای دیگری می شود.

با راه اندازی Automation می توانید برای همه چیز برنامه ریزی کنید.

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

Lean | ناب:

بعد از راه اندازی اتوماسیون، به یاد داشته باشید که همچنان ناب بمانید و اصول تولید ناب نرم افزار را رعایت کنید.

اجرای Lean به معنی نگه داشتن همه چیز در حداقل است.

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

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

باید تیم را در اندازه ای نگه داشت که بیشترین کارایی را داشته باشد. یک آشپزخانه با آشپزهای بیش از حد، بازده کمی خواهد داشت. اگر پیچیدگی اپلیکیشن به گونه ای باشد که نیاز به تیم های بزرگ باشد، تیم را به زیرگروه های کوچکتر تقسیم کنید، همانطور که سازمان های بزرگ این کار را می کنند. (spotify یکی از موفق ترین مثال ها در این زمینه است)

Measurement | اندازه گیری :

اندازه گیری مانند چسبی است که همه چیز را در کنار هم قرار می دهد. زمانی شما یک سازمان چابک و ناب هستید که همه چیز را اتوماتیک می کنید، ممکن است که توانایی به خاطر سپردن و مستند سازی را از دست بدهید.

اگر تیمی در همه موارد شفافیت لازم را نداشته باشد و کارها اندازه گیری نشوند، در نهایت اشتباهات بزرگی رخ خواهد داد.

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

با این وجود نمی توانید با یک excel ساده این کار را انجام داد. در یک سازمان ناب، شما فرصت ندارید که همه چیز را به صورت دستی و غیر اتوماتیک ثبت کنید. این کار بسیار زمان گیر و مستعد خطای انسانی است.

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

Sharing | به اشتراک گذاری :

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

ایجاد جریان اطلاعات دوطرفه یکی از مزیت های شکستن دیوار بین تیم ها می باشد و باعث جلوگیری از انداختن توپ در زمین تیم دیگر می شود. با این وجود اگر اطلاعات به صورت proactive و فعالانه به اشتراک گذاشته نشوند، ارزشی نخواهند داشت.

Sharing و Reporting کاملا با هم متفاوت هستند، Sharing تنها گزارش واقعیات نیست، بلکه مبادله ی ایده ها در سر تا سر تیم ها و به طور دائمی است. Reporting معمولا به صورت انفعالی (reactive) اتفاق می افتد در حالی که Sharing به صورت فعالانه و proactive می باشد.

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

چارچوب CALMS در DevOps برای آزادسازی خلاقیت ها است نه ردیابی عملکرد افراد

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

چیزی که در توصیف CALMS از DevOps منحصر به فرد است، تاکید بر بعد فرهنگی DevOps است.

از CALMS برای رها سازی جهت بروز خلاقیت ها استفاده کنید، نه برای ردیابی عملکرد افراد

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

CALMS یک نقشه راه است، نه تعریف تمامی گام ها و جزئیات لازم برای رسیدن به هدف، پس به یاد داشته باشید که به تنهایی کافی نیست.

برخی از موارد که در چارچوب CALMS به آن اشاره نشده است

داشتن iteration و ضرب آهنگ منظم و همچنین نتیجه گرا بودن، از موارد مهمی هستند که در CALMS به آن ها اشاره نشده است و می تواند مکمل CALMS باشند. از موارد دیگری که در CALMS به آن اشاره نشده، Security و امنیت محصول است، اما قطعا DevOps امنیت محصول را بهبود می دهد. تمامی موارد اشاره شده شامل بعد فرهنگی و فناوری می باشند.

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

این تمرین مهم است نه به این دلیل که CALMS باید به یک استاندارد تبدیل شود یا نه، به این دلیل که زمانی که جنبش های جدیدی به وجود می آیند (مانند جنبش DevOps)، باید مسیری از عادت به عملکرد فعالانه وجود داشته باشد. CALMS به کسانی که با Operations زندگی کرده اند و همچنین کسانی که حتی نمی دانند Operations چیست کمک می کند.

تفاوت CALMS و ITSM

کسانی است که با ITSM آشنایی دارند ممکن است دچار این چالش ذهنی بشوند که تفاوت DevOps و ITSM چیست؟ آیا DevOps یک راهکار جایگزین برای ITSM است؟

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

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

 

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) است اما تنها به این موارد محدود نمی شود. در نتیجه دوآپس شامل تمام کسانی می شود که به نحوی در تحویل یک محصول یا سرویس مشارکت دارند. به همین منظور اسامی مشابهی مانند DevSecOps, DevOpSec, SecOps, SecureDevOps یا BizDevSecOps مطرح می شود اما رویکرد و طرز تفکری دوآپس شامل همه ی این موارد هست، درگیر عناوین نشوید.

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

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

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

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

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

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

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

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

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





Share Button

Continuous Delivery چیست ؟

Continuous Delivery چیست

Continuous Delivery یا (CD)، رویکردی در مهندسی نرم افزار است که تیم ها را قادر می سازد نرم افزار تولید شده را به روشی سریع و مطمئن برای انتشار و تحویل آماده کنند. این فرایند از لحظه اضافه شدن یا تغییر کد در source control شروع می شود و شامل بیلد، تست، پیکربندی و انتشار در محیط های مختلف تست و محیط عملیات می شود. این مفهوم در فارسی به “تحویل مداوم” یا “تحویل مستمر” ترجمه شده است.

به عبارت دیگر: Continuous Delivery توانایی اعمال تغییرات در محیط عملیات در هر لحظه با روشی سریع و مطمئن و به طور کاملا پایدار می باشد. این تغییرات شامل همه انواع آن از جمله تغییرات پیکربندی در نرم افزار، زیرساخت و پلتفرم، افرودن ویژگی های جدید، رفع باگ و خطا ها می شود.

به وسیله محیط های تست مختلف، می توان یک Release Pipeline ایجاد کرد تا بتوان یک زیرساخت جدید را به طور اتوماتیک ایجاد کرد و نرم افزار را روی آن منتشر کرد. منظور از زیرساخت، سرور، سیستم عامل، سرویس دهنده ی وب، virtualization، شبکه و پیکربندی و تنظیمات آنها می باشد. به کمک این محیط های متوالی می توان فعالیت های طولانی Integration، تست عملکرد و تست های پذیرش نهایی را به تدریج انجام داد. فرایند Continuous Delivery در Release Pipeline با Continuous Integration شروع میشود و با انتشار و پایان تست در هر محیط، انتشار و تست در مرحله بعدی شروع می شود. مجموع این کارها به صورت حلقه های یک زنجیر در پشت سر هم قرار گرفته و فرایند Continuous Delivery را تشکیل می دهند.

ContinuousDelivery Process چیست

هدف Continuous Delivery چیست ؟

هدف CD این است که که انتشار و تحویل نرم افزار را به خصوص برای سیستم های توزیع شده در مقیاس بسیار بزرگ و محیط های عملیاتی پیچیده به یک فرایند روتین، ساده و قابل پیش بینی تبدیل کند. رسیدن به این هدف تنها در صورتی امکان پذیر است که کدهای نرم افزار همیشه در وضعیت آماده برای انتشار باشند، حتی در شرایطی که یک تیم با هزاران توسعه دهنده به طور روزانه در حال تغییر و به روزرسانی کد ها و نرم افزار هستند. به این ترتیب روش سنتی فازهای ادغام (Integration)، تست، پیکربندی و Hardening جای خود را به روش های اتوماتیک می دهد. همچنین زمان آماده شدن برای انتشار، زمان مهاجرت به محیطهای دیگر (Time to Remediate) و زمان برطرف کردن رخداد در محیط عملیات را کاهش (Time To Mitigate or time to remediate production incidents) می دهد.

تفاوت Continuous Delivery و Continuous Deployment چیست ؟

بسیاری از مواقع دو مفهوم Continuous Delivery و Continuous Deployment به اشتباه به جای هم استفاده می شوند اما تقاوت این دو چیست ؟ Continuous Deployment به این معنی است که هر تغییر در نرم افزار به طور اتوماتیک (یا بر طبق یک زمان بندی مشخص) در محیط عملیات منتشر شود. اما Continuous Delivery به این معنی است که هر تغییر در نرم افزار، آماده انتشار در هر محیطی باشد اما ممکن است تصمیم این باشد که منتشر نشود (معمولا به دلایل کسب و کاری). این محیط ها شامل محیط تست تیم توسعه، محیط تست تیم کنترل کیفیت و محیط عملیات و هر محیط دیگری می شود.

تفاوت Continuous Delivery و دواپس چیست ؟

این دو مفهوم از جهاتی به هم نزدیک هستند و اما تفاوت های بنیادی با هم دارند. دامنه ی DevOps بسیار گسترده تر از CD است و علاوه بر خودکارسازی فرایند تحویل نرم افزار، شامل تغییرات فرهنگی به خصوص ارتباط بین تیم های مختلفی که در جریان آماده سازی و تحویل محصول نرم افزاری (Software Delivery) هستند هم می شود. (از جمله تیم های توسعه، عملیات، تضمین کیفیت، مدیریت و … ) اما Continuous Delivery روشی است برای اتوماتیک سازی زنجیره تحویل محصول و بر این موضوع تمرکز دارد که فرایند های مرتبط در کنار هم طوری اجرا شود که منجر شود محصول نرم افزاری، سریعتر، امن تر و با تکرار بیشتری به دست مشتری برسد.

DevOps CD CI Agile چیست

در نبود Continuous Delivery …

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

حداقل الزامات اجرای Continuous Delivery

برای راه اندازی و اجرای Continuous Delivery الزاماتی وجود دارد که در کمترین حالت می توان از دو مورد زیر نام برد

  • زیربنایی از تست ها که تا حد قابل قبولی خیال شما را از اینکه نرم افزار به درستی کار می کند، راحت کند و به شما اعتماد به نفس لازم را برای شروع استقرار بدهد
  • ابزارهای خودکارسازی (automation) و اسکریپت های لازم که به شما اطمینان دهد استقرار با موفقیت انجام خواهد شد و در صورت نیاز امکان Rollback وجود خواهد داشت

سخن آخر

در آخر باید این این نکته را اضافه کنم که فرایند Continuous Delivery و Infrastructure as Code و Monitoring به طور قابل ملاحظه ای مکمل یکدیگر هستند. Continuous Delivery برای کنترل تاثیر تغییرات در محیط عملیاتی از استراتژی های استقرار از جمله Blue-Green Deployment و همچنین تکنیک Feature Flags (یا Feature Toggles) نیز پشتیبانی می کند. (در آینده راجع به استراتژی های انتشار مطلبی خواهم نوشت)
امروزه ارزش هایی که CD برای سازمان ها ایجاد می کند، آن را به یک نیاز ضروری تبدیل کرده است. برای رساندن ارزش به مشتریان نهایی، باید محصول را به طور پیوسته و بدون خطا منتشر کرد. Release Pipeline های پیشرفته به توسعه دهندگان اجازه می دهد که feature های جدید را سریع و مطمئن منتشر کنند. با کمک CD، رفع خطاها در محیط عملیات و اضافه کردن ویژگی های جدید بسیار سریع تر و با اطمینان بالا انجام خواهد شد و به دست مشتری خواهد رسید.

Share Button

Continuous Integration چیست ؟

Continuous Integration

به زبان ساده

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

تغریف دقیق تر از Continuous Integration

به فرایند ادغام یکپارچه کد ها و بیلد کردن پروژه ها و اجرای unit test ها به صورت اتوماتیک، Continuous Integration یا CI می گویند. با اجرای CI، با اعمال یک تغییر در سورس کد و اضافه شدن آن به source control، یک بیلد اتوماتیک را به راه می افتد تا بوسیله آن، آخرین نسخه کدها از مخزن کد استخراج و بیلد شود و unit test های آن اجرا شود، در واقع با این کار یک ارزیابی کلی از سلامت کدها انجام شود. این کار معمولا چندین بار در یک روز انجام می شود.

در نبود Continuous Integration چه اتفاقی می افتد ؟

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

Continuous Integration چه کمکی به ما می کند ؟

با اجرای CI، توسعه دهندگان در فواصل کوتاه و با هر بار check-in (یا commit) در source control قادر خواهند بود که تغییرات خود را با سایر تغییرات ادغام کنند و یک ارزیابی سریع از آن داشته باشند. با کمک CI می توان شاخه اصلی کد را تمیز و پایدار نگه داشت. در چنین شرایطی توسعه دهندگان ترقیب می شوند تا تغییرات خود را به صورت قطعه های کوچکتر و با تکرار بیشتری در Source Control اعمال کنند.تیم ها از بیلد های اتوماتیک استفاده می کنند تا اطمینان پیدا کنند که باگ ها خیلی زود و در چرخه توسعه شناسایی می شوند که منجر می شود برای رفع آن ها هزینه ی کمتری بپردازیم. اجرای تست ها به صورت اتوماتیک در هر بار تغییر در source control منجر به کیفیت پایدار در آن خواهد شد.

تیم ها به وسیله version control های جدید مانند GIT، می توانند برای هر feature، یک شاخه ی کوتاه مدت از کد در سیستم خودشان بسازند و بعد از تایید یک pull request، تغییراتشان با شاخه اصلی کد ها ادغام شود و سپس آن شاخه را حذف کنند. این کار می تواند بارها تکرار شود. تیم ها می توانند برای branch ها سیاست گزاری کنند تا همیشه مطمئن باشند که معیارهای کیفی لازم در آن رعایت شده است.

امروزه CI به عنوان یک Best Practice در توسعه نرم افزار شناخته می شود، تا جاییکه جزئی جدا ناپذیر از روش های چابک تولید نرم افزار شده است. همچنین یکی از ملزومات دواپس (DevOps)  و Continuous Delivery نیز می باشد.

10 دلیل که نیاز است تکنیک Continuous Integration را فرا بگیریم؟

  1. در بازه های زمانی کوتاه و چند بار در روز قادر خواهید بود که تغییرات اعمال شده توسط توسعه دهندگان با هم ادغام شوند و یک ارزیابی سریع از آن داشته باشید.
  2. با کمک CI همیشه می توان شاخه اصلی کد را تمیز و پایدار نگه داشت.
  3. توسعه دهندگان ترغیب می شوند که تغییرات خود را در قطعات کوچکتر و در دفعات بیشتری در سورس کنترل اعمال کنند.
  4. خطاها خیلی زودتر و در مراحل ابتدایی چرخه حیات نرم افزار شناسایی می شوند.
  5. شناسایی زودتر خطاها باعث می شود هزینه رفع آن ها بسیار اندک باشد.
  6. منجر به افزایش شفافیت و ارتباط بهتر با ذینفعان می شود.
  7. از آشوب و به هم ریختگی در روز انتشار جلوگیری می کند.
  8. کمک می کند محصول سریعتر و با کیفیت بهتری به دست مشتری نهایی برسد.
  9. اجرای خودکار تست ها و بررسی نتایج آن ها منجر به کیفیت پایدارتری خواهد شد و به پروسه تضمین کیفیت کمک می کند.
  10. پیش نیاز Continuous Delivery است.
Share Button

دواپس چیست و چرا آن را اجرا کنیم ؟ | What is DevOps, Why should imp it ?

فرایند دواپس

دواپس به زبان ساده

این مطلب با پست دیگری “دواپس به زبان ساده چیست ؟” ادغام شد.

Share Button
Show Buttons
Hide Buttons