اگر شرکت شما بهتازگی ابزارهای DevOps یا CI/CD را معرفی میکند، ممکن است برای شما مفید باشد که با رایجترین اشتباهات آشنا شوید تا آنها را تکرار نکنید و روی چنگک دیگران قدم نگذارید.
تیم
عدم آمادگی برای تغییر فرهنگ و فرآیندها
اگر به نمودار چرخه ای نگاه کنید
نمودار چرخه نامحدود DevOps
تست و تضمین کیفیت در طول توسعه و تحویل بخشی ضروری از هر کاری است که توسعه دهندگان انجام می دهند. این امر مستلزم تغییر ذهنیت برای گنجاندن آزمایش در هر کار است.
تست بخشی از کار روزانه هر عضو تیم می شود. انتقال به آزمایش مداوم آسان نیست، شما باید برای آن آماده باشید.
عدم بازخورد
اثربخشی DevOps به بازخورد ثابت بستگی دارد. اگر جایی برای همکاری و ارتباط وجود نداشته باشد، بهبود مستمر غیرممکن است.
شرکتهایی که جلسات گذشتهنگر را سازماندهی نمیکنند، اجرای فرهنگ بازخورد مستمر در CI/CD دشوار است. جلسات گذشته نگر در پایان هر تکرار برگزار می شود که طی آن اعضای تیم در مورد اینکه چه چیزی خوب و چه چیزی ضعیف بوده است بحث می کنند. جلسات گذشته نگر اساس Scrum/Agile هستند، اما برای DevOps نیز ضروری هستند.
این به این دلیل است که جلسات گذشته نگر عادت به تبادل بازخورد و نظرات را القا می کند. یکی از مهمترین نکات در شروع، سازماندهی جلسات تکرارشونده یکپارچهسازی با سیستمعامل است به طوری که برای کل تیم قابل درک و آشنا باشد.
وقتی صحبت از کیفیت نرم افزار می شود، همه اعضای تیم مسئول حفظ آن هستند. به عنوان مثال، توسعه دهندگان می توانند تست های واحد بنویسند و همچنین کدی را با در نظر گرفتن قابلیت تست بنویسند که از همان ابتدا به کاهش ریسک کمک می کند.
یک راه ساده برای انعکاس تغییر تفکر در مورد آزمایش این است که تسترها را نه QA، بلکه تستر نرم افزار یا مهندس کیفیت فراخوانی کنید. این تغییر ممکن است خیلی ساده یا حتی احمقانه به نظر برسد. اما نامیدن شخصی به عنوان "فرد تضمین کیفیت نرم افزار" تصور اشتباهی را در مورد اینکه چه کسی مسئول کیفیت محصول است به دست می دهد. در روش های Agile، CI/CD و DevOps، همه مسئول کیفیت نرم افزار هستند.
نکته مهم دیگر این است که بفهمیم کیفیت برای کل تیم و هر یک از اعضای آن، سازمان و ذینفعان به چه معناست.
سوء تفاهم از اتمام مرحله
اگر کیفیت یک فرآیند مستمر و کلی است، درک مشترک از اتمام مرحله مورد نیاز است. چگونه متوجه می شوید که یک مرحله تمام شده است؟ چه اتفاقی میافتد وقتی مرحلهای بهعنوان تکمیلشده در Trello یا سایر تابلوهای Kanban علامتگذاری شود؟
Definition of Done (DoD) یک ابزار قدرتمند در زمینه CD DevOps/CI است. این به درک بهتر استانداردهای کیفی در مورد آنچه و چگونه تیم می سازد کمک می کند.
تیم توسعه باید تصمیم بگیرد که «انجام شد» به چه معناست. آنها باید بنشینند و فهرستی از ویژگی هایی که باید در هر مرحله رعایت شود تا کامل تلقی شود تهیه کنند.
وزارت دفاع فرآیند را شفافتر میکند و اجرای CI/CD را در صورتی که توسط همه اعضای تیم درک شده و مورد توافق دوجانبه باشد، آسانتر میکند.
فقدان اهداف واقع بینانه و مشخص
این یکی از توصیههایی است که اغلب نقل میشود، اما باید تکرار شود. برای موفقیت در هر تلاش مهمی، از جمله CI/CD یا DevOps، باید اهداف واقع بینانه تعیین کنید و عملکرد را در مقابل آنها اندازه گیری کنید. سعی دارید با CI/CD به چه چیزی برسید؟ آیا این امکان انتشار سریعتر با کیفیت بهتر را فراهم می کند؟
هر هدف تعیین شده نه تنها باید شفاف و واقع بینانه باشد، بلکه باید با فعالیت های جاری شرکت همخوانی داشته باشد. به عنوان مثال، مشتریان شما هر چند وقت یک بار به وصله ها یا نسخه های جدید نیاز دارند؟ در صورت عدم وجود مزیت اضافی برای کاربران، نیازی به بارگذاری بیش از حد فرآیندها و انتشار سریعتر نیست.
علاوه بر این، شما همیشه نیازی به پیاده سازی CD و CI ندارید. به عنوان مثال، شرکت های بسیار تحت نظارت مانند بانک ها و کلینیک های پزشکی ممکن است فقط با CI کار کنند.
CI نقطه شروع خوبی برای هر شرکتی است که DevOps را اجرا می کند. هنگامی که اجرا می شود، رویکرد شرکت ها به ارائه نرم افزار به طور قابل توجهی تغییر می کند. پس از تسلط بر CI، می توانید به بهبود کل فرآیند، افزایش سرعت عرضه و سایر تغییرات فکر کنید.
برای بسیاری از سازمان ها، CI به تنهایی کافی است و CD تنها در صورتی باید پیاده سازی شود که ارزش افزوده داشته باشد.
عدم وجود داشبورد و معیارهای مناسب
هنگامی که اهداف خود را تعیین کردید، تیم توسعه می تواند داشبوردی برای اندازه گیری KPI ایجاد کند. قبل از توسعه آن، ارزش ارزیابی پارامترهایی را دارد که نظارت می شود.
گزارش ها و برنامه های مختلف برای اعضای مختلف تیم مفید است. اسکرام مستر بیشتر به وضعیت و دسترسی علاقه مند است. در حالی که ممکن است مدیریت ارشد به نرخ فرسودگی متخصصان علاقه مند باشد.
برخی از تیم ها همچنین از داشبوردهایی با نشانگرهای قرمز، زرد و سبز برای ارزیابی وضعیت CI/CD استفاده می کنند تا بفهمند که آیا همه کارها را درست انجام می دهند یا خطایی وجود دارد یا خیر. قرمز به این معنی است که باید به آنچه در حال رخ دادن است توجه کنید.
با این حال، اگر داشبوردها استاندارد نباشند، ممکن است گمراه کننده باشند. تجزیه و تحلیل داده هایی که همه به آن نیاز دارند، و سپس یک توصیف استاندارد از معنای آن ایجاد کنید. پیدا کنید چه چیزی برای ذینفعان منطقی تر است: گرافیک، متن یا اعداد.
بدون تست دستی
اتوماسیون آزمایشی پایه و اساس یک خط لوله خوب CI/CD را می گذارد. اما تست خودکار در تمام مراحل به این معنی نیست که نباید آزمایش دستی انجام دهید.
برای ایجاد یک خط لوله موثر CI/CD، به تست های دستی نیز نیاز دارید. همیشه جنبه هایی از آزمایش وجود خواهد داشت که نیاز به تجزیه و تحلیل انسانی دارد.
ارزش آن را دارد که تلاشهای آزمایش دستی را در خط لوله خود ادغام کنید. پس از اتمام تست دستی برخی از موارد تست، می توانید به مرحله استقرار بروید.
برای بهبود تست ها تلاش نکنید
یک خط لوله موثر CI/CD نیاز به دسترسی به ابزارهای مناسب دارد، خواه مدیریت آزمایش باشد یا یکپارچه سازی و نظارت مداوم.
هدف ایجاد یک فرهنگ قوی و کیفیت محور است
در اینجا چند نکته کاربردی وجود دارد که می توانید به راحتی آنها را اجرا کنید:
- اطمینان حاصل کنید که تستهای شما به راحتی نوشته میشوند و به اندازه کافی انعطافپذیر هستند که وقتی کد را تغییر میدهید شکسته نشوند.
- تیمهای توسعه باید در فرآیند آزمایش گنجانده شوند - فهرستی از مسائل و درخواستهای کاربر که برای آزمایش در طول خطوط لوله CI مهم هستند را ببینید.
- ممکن است پوشش کامل تست نداشته باشید، اما همیشه مطمئن شوید که جریانهایی که برای تجربه کاربری و تجربه مشتری مهم هستند، آزمایش میشوند.
آخرین اما نه کم اهمیت ترین نکته
انتقال به CI/CD معمولاً از پایین به بالا انجام میشود، اما در نهایت تحولی است که نیاز به خرید رهبری، زمان و منابع از سوی شرکت دارد. به هر حال، CI/CD مجموعهای از مهارتها، فرآیندها، ابزارها و بازسازی فرهنگی است؛ چنین تغییراتی فقط میتوانند به صورت سیستماتیک اجرا شوند.
چه چیز دیگری در مورد موضوع بخوانید:
منبع: www.habr.com