Agar kompaniyangiz DevOps yoki CI/CD vositalarini hozirgina joriy etayotgan bo'lsa, ularni takrorlamaslik va boshqa birovning rakesini bosib o'tmaslik uchun eng ko'p uchraydigan xatolar bilan tanishib chiqish foydali bo'lishi mumkin.
komanda maqolani tarjima qilgan .
Madaniyat va jarayonlarni o'zgartirishga tayyor emaslik
Agar siz tsiklik diagrammaga qarasangiz , DevOps amaliyotlarida test uzluksiz faoliyat, har bir joylashtirishning asosiy qismi ekanligi aniq.
DevOps Infinite Cycle Chart
Ishlab chiqish va yetkazib berish jarayonida sinov va sifat kafolati ishlab chiquvchilar qiladigan barcha ishlarning muhim qismidir. Bu har bir vazifaga testni kiritish uchun fikrlashni o'zgartirishni talab qiladi.
Sinov har bir jamoa a'zosining kundalik ishining bir qismiga aylanadi. Doimiy sinovga o'tish oson emas, siz bunga tayyor bo'lishingiz kerak.
Fikr-mulohazalarning etishmasligi
DevOps samaradorligi doimiy fikr-mulohazalarga bog'liq. Agar hamkorlik va muloqot uchun joy bo'lmasa, doimiy takomillashtirish mumkin emas.
Retrospektiv uchrashuvlar tashkil etmaydigan kompaniyalar CI/CDda uzluksiz fikr almashish madaniyatini joriy etishda qiynaladi. Har bir iteratsiya oxirida retrospektiv yig'ilishlar o'tkaziladi, unda jamoa a'zolari nima yaxshi va nima yomon ketganini muhokama qiladilar. Retrospektiv uchrashuvlar Scrum/Agile asosidir, lekin ular DevOps uchun ham zarurdir.
Buning sababi shundaki, retrospektiv uchrashuvlar fikr-mulohaza va fikr almashish odatini singdiradi. Boshlanishdagi eng muhim nuqtalardan biri bu butun jamoaga tushunarli va tanish bo'lishi uchun takrorlanadigan retro uchrashuvlarni tashkil qilishdir.
Dasturiy ta'minot sifati haqida gap ketganda, uni saqlash uchun barcha jamoa a'zolari javobgardir. Misol uchun, ishlab chiquvchilar birlik testlarini yozishlari va sinovdan o'tish imkoniyatini hisobga olgan holda kod yozishlari mumkin, bu esa boshidanoq xavfni kamaytirishga yordam beradi.
Sinov haqidagi fikrlashdagi o'zgarishlarni aks ettirishning oddiy usullaridan biri testchilarni QA emas, balki dasturiy ta'minot sinovchisi yoki sifat muhandisini chaqirishdir. Bu o'zgarish juda oddiy yoki hatto ahmoqona tuyulishi mumkin. Lekin kimnidir "dasturiy ta'minot sifatini ta'minlovchi shaxs" deb atash, mahsulot sifati uchun kim mas'ul ekanligi haqida noto'g'ri tasavvur beradi. Agile, CI/CD va DevOps amaliyotlarida hamma dastur sifati uchun javobgardir.
Yana bir muhim jihat - butun jamoa va uning har bir a'zosi, tashkilot va manfaatdor tomonlar uchun sifat nimani anglatishini tushunishdir.
Bosqichni yakunlashni noto'g'ri tushunish
Agar sifat uzluksiz va umumiy jarayon bo'lsa, bosqichni yakunlash haqida umumiy tushuncha kerak. Bosqich tugaganini qanday bilasiz? Trello yoki boshqa Kanban taxtasida qadam tugallangan deb belgilansa nima bo'ladi?
Bajarildi ta'rifi (DoD) CD DevOps/CI kontekstida kuchli vositadir. Bu jamoa nima va qanday qurayotganining sifat standartlarini yaxshiroq tushunishga yordam beradi.
Rivojlanish guruhi "Bajarildi" nimani anglatishini hal qilishi kerak. Ular o'tirib, har bir bosqichda bajarilishi kerak bo'lgan xususiyatlar ro'yxatini to'liq deb hisoblashlari kerak.
DoD jarayonni yanada shaffof qiladi va agar u barcha jamoa a'zolari tomonidan tushunilsa va o'zaro kelishilgan bo'lsa, CI/CDni amalga oshirishni osonlashtiradi.
Haqiqiy, aniq belgilangan maqsadlarning yo'qligi
Bu eng ko'p iqtibos keltiriladigan maslahatlardan biridir, lekin uni takrorlash kerak. Har qanday yirik urinishda, jumladan CI/CD yoki DevOpsda muvaffaqiyatga erishish uchun siz aniq maqsadlar qo'yishingiz va ularga nisbatan samaradorlikni o'lchashingiz kerak. CI/CD bilan nimaga erishmoqchisiz? Bu tezroq va sifatliroq nashrlarga ruxsat beradimi?
Belgilangan har qanday maqsadlar nafaqat shaffof va real bo'lishi, balki kompaniyaning joriy faoliyatiga ham mos kelishi kerak. Masalan, mijozlaringizga yangi yamoqlar yoki versiyalar qanchalik tez-tez kerak bo'ladi? Agar foydalanuvchilarga qo'shimcha foyda bo'lmasa, jarayonlarni ortiqcha yuklash va tezroq chiqarishga hojat yo'q.
Bundan tashqari, har doim ham CD va CI ni amalga oshirishingiz shart emas. Masalan, banklar va tibbiy klinikalar kabi yuqori darajada tartibga solinadigan kompaniyalar faqat CI bilan ishlashi mumkin.
CI DevOpsni amalga oshiruvchi har qanday kompaniya uchun yaxshi boshlanish nuqtasi bo'lib xizmat qiladi. U amalga oshirilganda, kompaniyalarning dasturiy ta'minotni etkazib berishga yondashuvlari sezilarli darajada o'zgaradi. CI o'zlashtirilgach, siz butun jarayonni takomillashtirish, ishga tushirish tezligini oshirish va boshqa o'zgarishlar haqida o'ylashingiz mumkin.
Ko'pgina tashkilotlar uchun CIning o'zi kifoya qiladi va CD faqat qiymat qo'shsagina amalga oshirilishi kerak.
Tegishli asboblar paneli va ko'rsatkichlarning yo'qligi
Maqsadlaringizni belgilab qo'yganingizdan so'ng, ishlab chiqish guruhi KPIlarni o'lchash uchun asboblar panelini yaratishi mumkin. Uni ishlab chiqishdan oldin, nazorat qilinadigan parametrlarni baholashga arziydi.
Turli hisobotlar va ilovalar turli jamoa a'zolari uchun foydalidir. Scrum Master maqom va imkoniyatlarga ko'proq qiziqadi. Yuqori rahbariyat mutaxassislarning charchash darajasi bilan qiziqishi mumkin.
Ba'zi jamoalar hamma narsani to'g'ri bajaryaptimi yoki xato bor-yo'qligini tushunish uchun CI/CD holatini baholash uchun qizil, sariq va yashil ko'rsatkichli asboblar panelidan foydalanadilar. Qizil rang nima bo'layotganiga e'tibor berish kerakligini anglatadi.
Biroq, asboblar paneli standartlashtirilmagan bo'lsa, ular noto'g'ri bo'lishi mumkin. Har kimga kerak bo'lgan ma'lumotlarni tahlil qiling va keyin nimani anglatishini standartlashtirilgan tavsifini yarating. Manfaatdor tomonlarga nima mantiqiy ekanligini bilib oling: grafika, matn yoki raqamlar.
Qo'lda testlar yo'q
Sinovlarni avtomatlashtirish yaxshi CI/CD quvur liniyasi uchun asos yaratadi. Ammo barcha bosqichlarda avtomatlashtirilgan test qo'lda test o'tkazmaslik kerak degani emas.
Samarali CI/CD quvur liniyasini qurish uchun sizga qo'lda testlar ham kerak bo'ladi. Har doim inson tahlilini talab qiladigan testning ba'zi jihatlari bo'ladi.
Qo'lda sinovdan o'tkazish harakatlarini quvur liniyasiga qo'shishni ko'rib chiqishga arziydi. Ba'zi sinov holatlarini qo'lda sinovdan o'tkazish tugallangandan so'ng, siz joylashtirish bosqichiga o'tishingiz mumkin.
Sinovlarni yaxshilashga urinmang
Samarali CI/CD quvur liniyasi test boshqaruvi yoki integratsiya va doimiy monitoring bo'ladimi, to'g'ri vositalarga kirishni talab qiladi.
Kuchli, sifatga yo'naltirilgan madaniyatni yaratish maqsadi , joylashtirishdan keyingi mijozlarning o'zaro ta'sirini kuzatish va yaxshilanishlarni kuzatish.
Bu erda siz osongina amalga oshirishingiz mumkin bo'lgan ba'zi amaliy maslahatlar:
- Sinovlaringizni yozish oson va kodni qayta tiklaganingizda buzilmasligi uchun etarlicha moslashuvchanligiga ishonch hosil qiling.
- Rivojlanish guruhlari sinov jarayoniga kiritilishi kerak - CI quvurlari davomida sinab ko'rish uchun muhim bo'lgan foydalanuvchi muammolari va so'rovlari ro'yxatini ko'ring.
- Sizda toʻliq test qamroviga ega boʻlmasligingiz mumkin, lekin har doim UX va mijozlar tajribasi uchun muhim boʻlgan oqimlar sinovdan oʻtkazilishiga ishonch hosil qiling.
Oxirgi, lekin eng muhim nuqta
CI/CD-ga o'tish odatda pastdan yuqoriga yo'naltiriladi, lekin oxir-oqibatda bu o'zgarish bo'lib, kompaniya rahbariyatini sotib olish, vaqt va resurslarni talab qiladi. Axir, CI/CD - bu ko'nikmalar, jarayonlar, vositalar va madaniy qayta qurish to'plami; bunday o'zgarishlar faqat tizimli ravishda amalga oshirilishi mumkin.
Mavzu bo'yicha yana nimani o'qish kerak:
- .
- .
- .
Manba: www.habr.com