உங்கள் நிறுவனம் DevOps அல்லது CI/CD கருவிகளை அறிமுகப்படுத்தினால், மிகவும் பொதுவான தவறுகளை நீங்கள் அறிந்து கொள்வது பயனுள்ளதாக இருக்கும்.
அணி கட்டுரையை மொழிபெயர்த்தார் .
கலாச்சாரம் மற்றும் செயல்முறைகளை மாற்ற ஆயத்தமின்மை
நீங்கள் சுழற்சி வரைபடத்தைப் பார்த்தால் , DevOps நடைமுறைகளில் சோதனை என்பது ஒரு தொடர்ச்சியான செயல்பாடு, ஒவ்வொரு வரிசைப்படுத்தலின் அடிப்படை பகுதியாகும் என்பது தெளிவாகிறது.
DevOps இன்ஃபினைட் சுழற்சி விளக்கப்படம்
டெவலப்பர்கள் செய்யும் எல்லாவற்றிலும் டெவலப் மற்றும் டெலிவரியின் போது சோதனை மற்றும் தர உத்தரவாதம் இன்றியமையாத பகுதியாகும். ஒவ்வொரு பணியிலும் சோதனையை இணைப்பதற்கான மனநிலை மாற்றம் இதற்கு தேவைப்படுகிறது.
சோதனை ஒவ்வொரு குழு உறுப்பினரின் தினசரி வேலையின் ஒரு பகுதியாகும். நிலையான சோதனைக்கு மாறுவது எளிதானது அல்ல, அதற்கு நீங்கள் தயாராக இருக்க வேண்டும்.
பின்னூட்டம் இல்லாமை
DevOps செயல்திறன் நிலையான பின்னூட்டத்தைப் பொறுத்தது. ஒத்துழைப்பு மற்றும் தகவல்தொடர்புக்கு இடமில்லை என்றால் தொடர்ச்சியான முன்னேற்றம் சாத்தியமற்றது.
பின்னோக்கி சந்திப்புகளை ஒழுங்கமைக்காத நிறுவனங்கள், CI/CD இல் தொடர்ச்சியான பின்னூட்டத்தின் கலாச்சாரத்தை செயல்படுத்துவது கடினம். ஒவ்வொரு மறு செய்கையின் முடிவிலும் ரெட்ரோஸ்பெக்டிவ் மீட்டிங் நடத்தப்படுகிறது, இதன் போது குழு உறுப்பினர்கள் எது நன்றாக நடந்தது, எது மோசமாக நடந்தது என்று விவாதிக்கிறார்கள். பின்னோக்கி சந்திப்புகள் ஸ்க்ரம்/அஜிலின் அடித்தளமாகும், ஆனால் அவை DevOps க்கும் அவசியம்.
ஏனென்றால், பின்னோக்கிச் சந்திப்புகள் கருத்துக்களையும் கருத்துக்களையும் பரிமாறிக்கொள்ளும் பழக்கத்தை ஏற்படுத்துகின்றன. தொடக்கத்தில் மிக முக்கியமான புள்ளிகளில் ஒன்று, தொடர்ச்சியான ரெட்ரோ சந்திப்புகளை ஒழுங்கமைப்பதாகும், இதனால் அவை முழு குழுவிற்கும் புரியும் மற்றும் நன்கு தெரிந்திருக்கும்.
மென்பொருளின் தரம் என்று வரும்போது, அதை பராமரிக்கும் பொறுப்பு அனைத்து குழு உறுப்பினர்களுக்கும் உள்ளது. எடுத்துக்காட்டாக, டெவலப்பர்கள் யூனிட் சோதனைகளை எழுதலாம் மற்றும் சோதனைத்திறனை மனதில் கொண்டு குறியீட்டை எழுதலாம், இது தொடக்கத்திலிருந்தே ஆபத்தைக் குறைக்க உதவுகிறது.
சோதனையைப் பற்றிய சிந்தனையில் மாற்றத்தை பிரதிபலிக்க ஒரு எளிய வழி, சோதனையாளர்களை QA அல்ல, ஆனால் மென்பொருள் சோதனையாளர் அல்லது தர பொறியாளர் என்று அழைப்பது. இந்த மாற்றம் மிகவும் எளிமையானதாகவோ அல்லது முட்டாள்தனமாகவோ தோன்றலாம். ஆனால் ஒருவரை "மென்பொருள் தர உறுதி நபர்" என்று அழைப்பது, தயாரிப்பின் தரத்திற்கு யார் பொறுப்பு என்பது பற்றிய தவறான எண்ணத்தை அளிக்கிறது. சுறுசுறுப்பான, CI/CD மற்றும் DevOps நடைமுறைகளில், மென்பொருள் தரத்திற்கு அனைவரும் பொறுப்பு.
மற்றொரு முக்கியமான விஷயம் என்னவென்றால், முழு குழு மற்றும் அதன் உறுப்பினர்கள், அமைப்பு மற்றும் பங்குதாரர்கள் அனைவருக்கும் தரம் என்றால் என்ன என்பதைப் புரிந்துகொள்வது.
மேடை நிறைவு பற்றிய தவறான புரிதல்
தரம் என்பது தொடர்ச்சியான மற்றும் பொதுவான செயல்முறையாக இருந்தால், நிலை நிறைவு பற்றிய பொதுவான புரிதல் தேவை. ஒரு கட்டம் முடிந்துவிட்டால் உங்களுக்கு எப்படித் தெரியும்? ட்ரெல்லோ அல்லது பிற கான்பன் போர்டில் ஒரு படி முடிந்ததாகக் குறிக்கப்பட்டால் என்ன நடக்கும்?
முடிந்தது (DoD) என்பதன் வரையறை CD DevOps/CI இன் சூழலில் ஒரு சக்திவாய்ந்த கருவியாகும். குழு என்ன, எப்படி உருவாக்குகிறது என்பதற்கான தரத் தரங்களை நன்கு புரிந்துகொள்ள இது உதவுகிறது.
"முடிந்தது" என்றால் என்ன என்பதை மேம்பாட்டுக் குழு தீர்மானிக்க வேண்டும். அவர்கள் உட்கார்ந்து, ஒவ்வொரு கட்டத்திலும் பூர்த்தி செய்யப்பட வேண்டிய பண்புகளின் பட்டியலை உருவாக்க வேண்டும்.
DoD ஆனது செயல்முறையை மிகவும் வெளிப்படையானதாக ஆக்குகிறது மற்றும் CI/CDஐ அனைத்து குழு உறுப்பினர்களும் புரிந்துகொண்டு பரஸ்பரம் ஒப்புக்கொண்டால் செயல்படுத்துவதை எளிதாக்குகிறது.
யதார்த்தமான, தெளிவாக வரையறுக்கப்பட்ட இலக்குகளின் பற்றாக்குறை
இது அடிக்கடி மேற்கோள் காட்டப்படும் அறிவுரைகளில் ஒன்றாகும், ஆனால் இது மீண்டும் மீண்டும் கூறுகிறது. CI/CD அல்லது DevOps உட்பட எந்தவொரு பெரிய முயற்சியிலும் வெற்றிபெற, நீங்கள் யதார்த்தமான இலக்குகளை அமைத்து, அவற்றிற்கு எதிரான செயல்திறனை அளவிட வேண்டும். CI/CD மூலம் நீங்கள் எதை அடைய முயற்சிக்கிறீர்கள்? சிறந்த தரத்துடன் விரைவான வெளியீடுகளை இது அனுமதிக்கிறதா?
நிர்ணயிக்கப்பட்ட எந்த இலக்குகளும் வெளிப்படையானதாகவும் யதார்த்தமாகவும் இருக்க வேண்டும், ஆனால் நிறுவனத்தின் தற்போதைய செயல்பாடுகளுடன் ஒத்துப்போக வேண்டும். எடுத்துக்காட்டாக, உங்கள் வாடிக்கையாளர்களுக்கு எத்தனை முறை புதிய இணைப்புகள் அல்லது பதிப்புகள் தேவை? பயனர்களுக்கு கூடுதல் நன்மை இல்லை என்றால் செயல்முறைகளை ஓவர்லோட் செய்து வேகமாக வெளியிட வேண்டிய அவசியமில்லை.
கூடுதலாக, நீங்கள் எப்போதும் CD மற்றும் CI இரண்டையும் செயல்படுத்த வேண்டியதில்லை. எடுத்துக்காட்டாக, வங்கிகள் மற்றும் மருத்துவ கிளினிக்குகள் போன்ற மிகவும் ஒழுங்குபடுத்தப்பட்ட நிறுவனங்கள் CI உடன் மட்டுமே வேலை செய்யலாம்.
DevOps ஐ செயல்படுத்தும் எந்தவொரு நிறுவனத்திற்கும் CI ஒரு நல்ல தொடக்க புள்ளியாக செயல்படுகிறது. இது செயல்படுத்தப்படும் போது, மென்பொருள் விநியோகத்திற்கான நிறுவனங்களின் அணுகுமுறைகள் கணிசமாக மாறுகின்றன. CI தேர்ச்சி பெற்றவுடன், முழு செயல்முறையையும் மேம்படுத்துவது, வெளியீட்டு வேகத்தை அதிகரிப்பது மற்றும் பிற மாற்றங்களைப் பற்றி நீங்கள் சிந்திக்கலாம்.
பல நிறுவனங்களுக்கு, CI மட்டுமே போதுமானது, மேலும் CD மதிப்பைக் கூட்டினால் மட்டுமே செயல்படுத்தப்பட வேண்டும்.
பொருத்தமான டாஷ்போர்டுகள் மற்றும் அளவீடுகள் இல்லாதது
உங்கள் இலக்குகளை நிர்ணயித்தவுடன், KPIகளை அளவிடுவதற்கு மேம்பாட்டுக் குழு ஒரு டாஷ்போர்டை உருவாக்கலாம். அதன் வளர்ச்சிக்கு முன், கண்காணிக்கப்படும் அளவுருக்களை மதிப்பிடுவது மதிப்பு.
வெவ்வேறு குழு உறுப்பினர்களுக்கு வெவ்வேறு அறிக்கைகள் மற்றும் பயன்பாடுகள் பயனுள்ளதாக இருக்கும். ஸ்க்ரம் மாஸ்டர் அந்தஸ்து மற்றும் அடைவதில் அதிக ஆர்வம் கொண்டவர். மூத்த நிர்வாகம் நிபுணர்களின் எரிதல் விகிதத்தில் ஆர்வமாக இருக்கலாம்.
சில குழுக்கள் சிஐ/சிடியின் நிலையை மதிப்பிடுவதற்கு சிவப்பு, மஞ்சள் மற்றும் பச்சை நிற குறிகாட்டிகள் கொண்ட டாஷ்போர்டைப் பயன்படுத்துகின்றன. சிவப்பு என்றால் என்ன நடக்கிறது என்பதில் கவனம் செலுத்த வேண்டும்.
இருப்பினும், டாஷ்போர்டுகள் தரப்படுத்தப்படவில்லை என்றால், அவை தவறாக வழிநடத்தும். ஒவ்வொருவருக்கும் என்ன தரவு தேவை என்பதை பகுப்பாய்வு செய்து, அதன் அர்த்தம் என்ன என்பதை தரப்படுத்தப்பட்ட விளக்கத்தை உருவாக்கவும். கிராபிக்ஸ், டெக்ஸ்ட் அல்லது எண்கள்: பங்குதாரர்களுக்கு எது அதிக அர்த்தமுள்ளதாக இருக்கும் என்பதைக் கண்டறியவும்.
கைமுறை சோதனைகள் இல்லை
சோதனை ஆட்டோமேஷன் ஒரு நல்ல CI/CD பைப்லைனுக்கு அடித்தளம் அமைக்கிறது. ஆனால் அனைத்து நிலைகளிலும் தானியங்கு சோதனை நீங்கள் கைமுறையாக சோதனை நடத்த கூடாது என்று அர்த்தம் இல்லை.
பயனுள்ள CI/CD பைப்லைனை உருவாக்க, உங்களுக்கு கைமுறை சோதனைகளும் தேவை. மனித பகுப்பாய்வு தேவைப்படும் சோதனையின் சில அம்சங்கள் எப்போதும் இருக்கும்.
உங்கள் பைப்லைனில் கைமுறை சோதனை முயற்சிகளை ஒருங்கிணைப்பதை கருத்தில் கொள்வது மதிப்பு. சில சோதனை நிகழ்வுகளின் கைமுறை சோதனை முடிந்ததும், நீங்கள் வரிசைப்படுத்தல் கட்டத்திற்கு செல்லலாம்.
சோதனைகளை மேம்படுத்த முயற்சிக்காதீர்கள்
ஒரு பயனுள்ள CI/CD பைப்லைனுக்கு சரியான கருவிகளுக்கான அணுகல் தேவைப்படுகிறது, அது சோதனை மேலாண்மை அல்லது ஒருங்கிணைப்பு மற்றும் தொடர்ந்து கண்காணிப்பு.
ஒரு வலுவான, தரம் சார்ந்த கலாச்சாரத்தை உருவாக்குவது இதன் நோக்கமாகும் , வரிசைப்படுத்தலுக்குப் பிந்தைய வாடிக்கையாளர் தொடர்புகளைக் கண்காணித்தல் மற்றும் மேம்பாடுகளைக் கண்காணிப்பது.
நீங்கள் எளிதாக செயல்படுத்தக்கூடிய சில நடைமுறை உதவிக்குறிப்புகள் இங்கே:
- உங்கள் சோதனைகள் எழுத எளிதானது மற்றும் குறியீட்டை மறுவடிவமைக்கும்போது உடைக்காத அளவுக்கு நெகிழ்வானது என்பதை உறுதிப்படுத்தவும்.
- சோதனைச் செயல்பாட்டில் மேம்பாட்டுக் குழுக்கள் சேர்க்கப்பட வேண்டும் - CI பைப்லைன்களின் போது சோதிக்க வேண்டிய முக்கியமான பயனர் சிக்கல்கள் மற்றும் கோரிக்கைகளின் பட்டியலைப் பார்க்கவும்.
- உங்களிடம் முழு சோதனைக் கவரேஜ் இல்லாமல் இருக்கலாம், ஆனால் UX மற்றும் வாடிக்கையாளர் அனுபவத்திற்கு முக்கியமான ஃப்ளோக்கள் சோதிக்கப்படுவதை எப்போதும் உறுதிசெய்யவும்.
கடைசி ஆனால் மிக முக்கியமான விஷயம்
CI/CD க்கு மாறுவது பொதுவாக கீழிருந்து மேல்நோக்கி இயக்கப்படுகிறது, ஆனால் இறுதியில் அது நிறுவனத்திடமிருந்து தலைமை வாங்குதல், நேரம் மற்றும் வளங்கள் தேவைப்படும் ஒரு மாற்றமாகும். எல்லாவற்றிற்கும் மேலாக, CI/CD என்பது திறன்கள், செயல்முறைகள், கருவிகள் மற்றும் கலாச்சார மறுசீரமைப்பு ஆகியவற்றின் தொகுப்பாகும்; அத்தகைய மாற்றங்களை முறையாக மட்டுமே செயல்படுத்த முடியும்.
தலைப்பில் வேறு என்ன படிக்க வேண்டும்:
- .
- .
- .
ஆதாரம்: www.habr.com