چگونه تیم های DevOps اتوماسیون را پس می گیرند


آیا اتوماسیون فرآیندهای شما را تسریع می کند یا خود را با یک سیستم شکننده پیدا خواهید کرد که نیاز به توجه مداوم و تنظیمات مکرر و زمان بر دارد؟

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

تصویر: mantinov – stock.adobe.com

یک مثال برجسته از گردش کار CI / CD است. قدرت تبدیل CI / CD روشن است: اجرای خودکار روی خط لوله رهاسازی در زمان زیادی صرفه جویی می کند ، که به شما این امکان را می دهد تا صرفه جویی در هزینه های کلان را انجام دهید و خیلی سریعتر در بازار عرضه کنید.

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

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

بایگانی و اقدامات احتیاطی خودکار

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

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

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

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

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

مت دیکنز مدیر ارشد محصولات و شرکت – بنیانگذار شرکت انتقال.

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

ما از نظرات شما در مورد این موضوع در کانال های رسانه های اجتماعی خود استقبال می کنیم [contact us directly] با س questionsال در مورد سایت.

مقالات بیشتر




منبع: tasiveh-news.ir

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>