டெவொப்ஸ் ஒரு முறை அல்லது கருவி அல்ல, இது ஒரு கலாச்சாரம்

கலாச்சாரம் பெரும்பாலும் புறக்கணிக்கப்படுகிறது மற்றும் தவறாக புரிந்து கொள்ளப்படுகிறது, இருப்பினும் இது ஒரு நிறுவனத்தின் செயல்திறனுக்கு முக்கிய காரணியாகும். எங்கள் கலாச்சாரத்தை நாங்கள் நிர்வகிக்கவில்லை என்றால், தவறான நடைமுறைகளைச் செய்வோம், இது இறுதியில் எங்கள் வணிக இலக்குகளை பாதிக்கும்.

ஒரு அமைப்பின் தற்போதைய கலாச்சாரத்தைப் புரிந்துகொள்வது

ஒரு குழு அல்லது நிறுவனத்தில் உள்ள மதிப்புகள் மற்றும் விதிமுறைகளைப் பற்றி கலாச்சாரம் சொல்கிறது. இது முக்கியமானது மற்றும் மக்கள் எவ்வாறு ஒருவருக்கொருவர் அணுகுவது மற்றும் செயல்படுவது என்பதையும் அடையாளம் காட்டுகிறது.

நிரல் முடிவுக்கு ஜாவா குறியீடு

கலாச்சாரம் = “விஷயங்களை வெற்றிகரமாக எப்படிச் செய்ய முடியும்”

வாடிக்கையாளர் ஆதரவு குழுவின் உதாரணத்தை எடுத்துக் கொள்வோம். அந்த அணியின் கலாச்சாரம் 97-98% வாடிக்கையாளர் திருப்தியை அடைய முடிகிறது.

வாடிக்கையாளர் மகிழ்ச்சியைக் கருத்தில் கொண்டு, முதலில் அவர்கள் கண்ணியமாக இருக்க வேண்டும், கடினமான சூழ்நிலைகளில் கூட அவர்கள் தேவைக்கேற்ப வேலைக்கு முன்னுரிமை அளிக்க வேண்டிய குழப்பத்தைத் தவிர்க்க நல்ல கேட்பவர்களாக இருக்க வேண்டும்.

ஒரு கணம் இடைநிறுத்தி, சில கேள்விகளை நாமே கேட்டுக்கொள்வோம்:

• இப்போது எனது நிறுவனத்தின் கலாச்சாரம் என்ன?
• இந்த கலாச்சாரம் எனது வணிக இலக்குகள் அல்லது கே.ஆர்.ஏக்களுடன் எவ்வளவு நன்றாக ஒத்துப்போகிறது?
• தவறான வடிவமைப்பால் நான் என்ன சிக்கல்களை எதிர்பார்க்க முடியும்?

ஒவ்வொரு நிறுவனத்திற்கும், 4 சி கள் முக்கிய பங்கு வகிக்கின்றன

இப்போது, ​​ஒரு மென்பொருள் வளரும் அமைப்பின் கலாச்சாரத்தைப் பார்ப்போம். ஒரு மென்பொருள் அலகு கட்டுவதற்கும் பராமரிப்பதற்கும் பல அணிகள் ஈடுபட்டுள்ளன. இந்த அணிகள் அனைத்தும் தனித்தனி குறிக்கோள்களையும் தனி கலாச்சாரத்தையும் கொண்டுள்ளன.

வாடிக்கையாளரால் தேவைகள் உறுதிசெய்யப்பட்ட பின்னர் இந்த செயல்முறை தொடங்குகிறது.

டெவலப்பர்கள் தங்கள் நிறுவனத்தால் வரையறுக்கப்பட்ட குறியீட்டு வழிகாட்டுதல்களைப் பின்பற்றுகிறார்கள் மற்றும் குறியீட்டை உருவாக்க கம்பைலர்கள், உரைபெயர்ப்பாளர்கள், பிழைத்திருத்தங்கள் போன்ற நிரலாக்க கருவிகள் பயன்படுத்தப்படுகின்றன. சி, சி ++, பாஸ்கல், ஜாவா மற்றும் பி.எச்.பி போன்ற பல்வேறு உயர் மட்ட நிரலாக்க மொழிகள் குறியீட்டுக்கு பயன்படுத்தப்படுகின்றன.

அவை முழுமையான தொகுப்பை சிறிய கோப்புறைகளாகப் பிரித்து அதற்கேற்ப சிறிய குறியீடுகளை உருவாக்குகின்றன.

நிலை 1 : இந்த சிறிய அலகுகளின் குறியீடுகள் பின்னர் ஒரு பெரிய அலகு உருவாகின்றன. சிறிய சில்லுகளை ஒருங்கிணைக்கும்போது, ​​ஒருங்கிணைப்பு சோதனை எனப்படும் திட்ட அளவிலான சோதனை செய்யப்பட வேண்டும்.

நிலை 2 : வெற்றிகரமான ஒருங்கிணைப்பிற்குப் பிறகு, இது ஒரு போலி அமைப்பில் பயன்படுத்தப்படுகிறது. இந்த போலி அமைப்பு கிளையன்ட் இயந்திரம் அல்லது இந்த திட்டத்தை இறுதியாக பயன்படுத்த வேண்டிய இயந்திரம் போன்ற உள்ளமைவைக் கொண்டுள்ளது.

நிலை 3 : இறுதியாக, போலி அமைப்பில் உள்ள அனைத்து அம்சங்களையும் சோதித்தபின், திட்டம் தயாரிப்பு சேவையகம் அல்லது கிளையன்ட் இயந்திரத்தில் பயன்படுத்தப்படுகிறது.

இந்த செயல்முறை வார்த்தைகளில் மிகவும் மென்மையாகவும் எளிதாகவும் இருப்பதாகத் தோன்றினாலும், தொழில்நுட்ப அடிப்படையில் இது அடைய மிகவும் கடினம்.

நாம் என்ன சிக்கல்களை எதிர்கொள்ள நேரிடும் என்று பார்ப்போம்:

நிலை 1 :

தயாரிப்பு எப்போதும் தரத்தை மேம்படுத்த வாடிக்கையாளர் மாற்றங்களைத் தேடுவார். முதல் மறு செய்கை செய்யப்பட்ட பெரும்பாலான நேரங்களில், வாடிக்கையாளர் சில மாற்றங்களை பரிந்துரைப்பார். டெவலப்பர்கள் மாற்றங்களைப் பெறும்போது, ​​அவை இணைக்கத் தொடங்குகின்றன, இது உடைந்த கட்டமைப்பிற்கு வழிவகுக்கும் ஒருங்கிணைப்பை பாதிக்கிறது.

நிலை 2:

பெரும்பாலும், சோதனையாளர்கள் அல்லது பிற ஆபரேஷன் தோழர்கள் செய்ய வேண்டிய புதிய மாற்றங்கள் குறித்து அறிந்திருக்க மாட்டார்கள். டெவலப்பர்களிடமிருந்து குறியீட்டைப் பெற்றவுடன், அவர்கள் அவற்றைச் சோதிக்கத் தொடங்குவார்கள். பின் இறுதியில் டெவலப்பர்கள் இன்னும் மாற்றங்களைச் செய்கிறார்கள்.

புதிய மாற்றங்களைச் செயல்படுத்த அவர்களுக்கு போதுமான நேரம் கிடைக்காததால், அவை பிற நெட்வொர்க் மற்றும் தரவுத்தள சிக்கல்களை எதிர்கொள்ளும் திறனற்ற குறியீடுகளை உருவாக்கி முடிக்கின்றன, அவை அவற்றின் விநியோக நேரத்தை மீண்டும் தாமதப்படுத்துகின்றன.

அவர்கள் இறுதியாக செயல்பாட்டுக் குழுவுக்கு குறியீடுகளை வழங்கும்போது, ​​புதிய சோதனை நிகழ்வுகளை உருவாக்கி செயல்படுத்த அவர்களுக்கு மிகக் குறைந்த நேரம் மட்டுமே உள்ளது. எனவே அவை பல சோதனை வழக்குகளைத் தவிர்க்கின்றன, அவை அதிக முன்னுரிமை கொண்டவை என்பதை பின்னர் புரிந்துகொள்கின்றன.

நிலை 3:

கிட்டத்தட்ட உருவாக்க தயாரிப்புக்குத் தயாராக இருப்பதாகத் தோன்றினாலும், முடிவுகள் முற்றிலும் எதிர்பாராதவை. உருவாக்கம் தோல்வியுற்றது மற்றும் பல பிழைகள் ஏற்படுகின்றன.

ஒவ்வொரு பிழை ஏற்பட்டாலும், அது ஏன் நிகழ்ந்தது, எங்கு நிகழ்ந்தது, அதைக் கடக்க என்ன மாற்றங்கள் செய்யப்பட வேண்டும், முந்தைய குறியீடுகளுடன் இணக்கமாக இருக்க மற்ற குறியீடுகளில் மாற்றம் இருக்கும் என்பதை அவர்கள் கண்காணிக்க வேண்டும். இறுதியாக, இந்த பிழைகள் அனைத்திற்கும், ஒரு பிழை அறிக்கை உருவாக்கப்பட வேண்டும்.

குறியீட்டின் செயல்திறனில் தரவுத்தள டெவலப்பரின் அறியாமை, சோதனை நிகழ்வுகளின் எண்ணிக்கையில் சோதனையாளரின் அறியாமை போன்றவற்றின் காரணமாக கணினி பிழைகள் தான் தோல்விக்கு காரணம்.

வாடிக்கையாளர் எப்போதும் காலக்கெடுவை இறுக்கமாக வைத்திருப்பதால், அவற்றை அடைவதில் ஈடுபடும் ஊழியர்கள் ஒட்டுமொத்த தரத்தில் சமரசம் செய்ய வேண்டியிருந்தாலும் இறுதி வெளியீட்டில் மட்டுமே கவனம் செலுத்துவார்கள்.

வேலையை ஒருங்கிணைப்பதில் இது ஒரு சிக்கலாகத் தோன்றினாலும், இது உண்மையில் ஏற்றுக்கொள்ளப்பட்ட கலாச்சாரத்தின் தோல்வி.

கையேடு செயல்முறைகளில் அதிக சார்பு இருப்பதால் இது நிகழ்கிறது. வெவ்வேறு துறையில் அணுகல் இல்லாமை அல்லது ஆர்வமின்மை பற்றிய அறிவு இல்லாததால் ஒரே அணியில் ஓடுவது நம் சொந்த சுமை மற்றும் வலியை அதிகரிக்கிறது.

c இல் மறுநிகழ்வைப் பயன்படுத்தி காரணியாலானது

நாம் பல்துறை திறன் கொண்டவர்களாக இருக்க வேண்டிய அதிக நேரம் இது. ஒரு அமைப்பில் சம்பந்தப்பட்ட அனைத்து செயல்முறைகளுக்கும் மாஸ்டர் ஆக கடினமாக இருக்கலாம், ஆனால் நாம் அனைவரின் பலாவாக இருக்க முடியும், அவற்றில் ஒன்றை மாஸ்டரிங் செய்யலாம். பின்னர் மட்டுமே நம் கணினியை தானியக்கமாக்கலாம் அல்லது ரோல்பேக்குகளை விட மீட்கும் அளவுக்கு புத்திசாலித்தனமாக மாற்ற முடியும்.

இப்போது, ​​ஏன் என்று நீங்கள் நினைத்துக் கொண்டிருக்கலாம்?

ஏனென்றால், நீங்கள் தேர்ச்சி பெற்றவர் மற்றவர்களை மிகவும் சார்ந்து இருக்கிறார். எனவே சார்பு புள்ளியைப் பற்றி அறிய, முழு அமைப்பையும் நாம் புரிந்து கொள்ள வேண்டும்.

எனவே கலாச்சாரத்தை மாற்றுவதற்கான ஒரு செயல்முறையைப் பற்றி சிந்திக்கலாம். அதற்கு முன் கீழேயுள்ள கேள்விகளுக்கு உங்களிடம் பதில் இருக்கிறதா?

• உங்கள் தற்போதைய கலாச்சாரம் எங்கே தோல்வியடைகிறது?
• செயல்முறையை ஏன் மாற்ற விரும்புகிறீர்கள்?
• தேவையான அனைத்து மாற்றங்களையும் நீங்கள் தெளிவாக அடையாளம் கண்டுள்ளீர்களா?
• பாதிக்கப்பட்ட அனைத்து பங்குதாரர்களிடமிருந்தும் நீங்கள் கருத்துக்களைப் பெற்றுள்ளீர்களா?
• மாற்றத்திற்கான செயல்முறை ஒழுக்கம், தரவு மற்றும் அளவீட்டு முறையை நீங்கள் மறுபரிசீலனை செய்துள்ளீர்களா?

எனவே, இப்போது அனைவருக்கும் பதில் இருக்கும்போது, ​​நம் அமைப்பில் ஒரு புரட்சியைப் பற்றி நினைக்கிறோம். இந்த புரட்சி எவ்வாறு நடக்கும்? நாம் இப்போது இருப்பதைக் கொல்லும்போதுதான் அதை அடைய முடியும். அணிகள் மத்தியில் குறியீடு இடம்பெயர்வதில் நிறைய நேரம் வீணடிக்கப்படுகிறது. தொடர்ச்சியான ஒருங்கிணைப்பு மற்றும் தொடர்ச்சியான வரிசைப்படுத்தல் ஆகியவற்றைச் செய்யக்கூடிய செயல்முறையை நாம் கொண்டு வர வேண்டும்.

தொடர்ச்சியான ஒருங்கிணைப்பு மற்றும் வரிசைப்படுத்தல் இந்த செயல்முறை மேலும் சுறுசுறுப்பானது. இந்த சுறுசுறுப்பைக் கொண்டுவருவது DevOps கலாச்சாரமாக கருதப்படுகிறது.

டெவொப்ஸ் என்பது வடிவமைப்பு மற்றும் மேம்பாட்டு செயல்முறை மூலம் உற்பத்தி ஆதரவு வரை முழு சேவை வாழ்க்கைச் சுழற்சியில் செயல்படும் செயல்பாடுகள் மற்றும் மேம்பாட்டு பொறியியலாளர்கள்.

காலப்போக்கில் வேலை முறையை மாற்றுவது எளிதல்ல. ஒரு வெற்றிகரமான மாற்றத்தை உருவாக்குவது, மறுகட்டமைப்பதை விட, கணினியை புதுப்பிப்பதாகும்.

இதை நாம் எவ்வாறு அடையலாம் என்பதை இப்போது பார்ப்போம். அணுக இரண்டு வழிகள் இருக்கலாம்.

1) மேலே இருந்து கீழே

2) கீழே

இந்த நுட்பங்களை ஆழமாக மூழ்கடித்து, எங்கள் நிறுவனத்திற்கு எது மிகவும் பொருத்தமானது என்பதை நாங்கள் உணருவோம்.

டாப் டவுன் அணுகுமுறையில், நாங்கள் உயர் நிர்வாகத்திற்குச் சென்று அனைத்து அணிகளிலும் மாற்றங்களைச் செய்யுமாறு அவர்களிடம் கேட்கலாம். நிர்வாகம் உறுதியாக இருந்தால், நாங்கள் அதைச் செய்ய ஆரம்பிக்கலாம்.

ஆனால் “இல்லை” என பதிலைப் பெறுவதற்கான நிகழ்தகவு மிக அதிகம். ஏனென்றால் கணினியை மாற்றுவது நிறுவனத்தை ஸ்திரமின்மைக்கு இட்டுச் செல்லும்.

அமைப்பு, வருவாய், வாடிக்கையாளரின் வட்டி நிலை போன்றவற்றின் கட்டமைப்பை அவர்கள் கவனிக்க வேண்டும். ஆனால் பழைய அமைப்பிலிருந்து வெளியேறுவதிலிருந்து அவர்களை பின்னுக்கு இழுக்கும் மிக முக்கியமான காரணி, அவர்களால் பார்க்க முடியாது புதியதை கொண்டு எதை அடைய முடியும் மற்றும் எவ்வளவு சுமூகமாக அடைய முடியும் என்பதற்கான பெரிய படம்.

வரிசை ஜாவாவில் மிகப்பெரிய எண்ணிக்கையை எவ்வாறு கண்டுபிடிப்பது

இந்த விஷயத்தில், இந்த பெரிய படத்தைப் பெற இரண்டாவது அணுகுமுறையைப் பார்க்கலாம்.

கீழ்நிலை அணுகுமுறை தன்னார்வலர்களை அழைக்கிறது. இங்கே நாம் ஒரு சிறிய குழுவையும் ஒரு சிறிய பணியையும் எடுத்து அதை DevOps மாதிரியில் இயக்க வேண்டும்.

இந்த மாதிரியின் தொழில்நுட்பப் பக்கத்தைப் பார்க்கும்போது, ​​எங்களிடம் பலவிதமான அதிநவீன கருவிகள் உள்ளன, அவை வேலையை மிகவும் திறமையாகவும் வேகமாகவும் ஆக்குகின்றன. ஆனால், டெவொப்ஸ் என குறிப்பிடப்படும் கூட்டு சூழலை உருவாக்க கருவிகள் மட்டும் போதுமானதாக இல்லை.

அத்தகைய சூழலை உருவாக்குவதற்கு நீங்கள் பெட்டியிலிருந்து சிந்திக்க வேண்டும் எ.கா. மக்கள் தங்கள் அணிகள், வணிகம் மற்றும் வாடிக்கையாளர்களைப் பற்றி எப்படி நினைக்கிறார்கள் என்பதை மதிப்பீடு செய்தல் மற்றும் மாற்றியமைத்தல்.

நிறுவன கலாச்சாரத்தை மாற்றுவதை விட புதிய கருவிகளை ஒன்றிணைப்பது எளிது. சமூக விரோத மாஸ்டர் டெவலப்பர்களை ஊக்குவிப்பதன் மூலம், திறமையற்ற குறியீட்டை ஒருங்கிணைக்க அனுமதிப்பதன் மூலம், சரியாக சோதிக்கப்படாத குறியீடுகளை வரிசைப்படுத்துவதன் மூலம், ஒருவருக்கொருவர் தலையில் பழிபோடுவதன் மூலம், செயல்பாட்டுக் குழு முட்டாள் என்று கருதுவதன் மூலம் வணிகத்தை செயல்படுத்த நாங்கள் பின்பற்றும் சிறந்த நடைமுறைகள் எங்கள் வாடிக்கையாளர்களுக்கு மதிப்பை உருவாக்குங்கள்.

இது கருவிகள் அல்ல, அவற்றைப் பயன்படுத்தும் மக்கள் செயல்முறையை சிக்கலாக்குகிறார்கள். கருத்துக்கள் மற்றும் நடத்தைகளை சேகரிப்பதை விட ஒரு சுருக்க மட்டத்தில் சொல்வது, அவற்றுக்கு திறந்திருப்பது நம்மை ஒரு பிரகாசமான பாதையில் கொண்டு செல்கிறது.

6 உறுப்பினர்களைக் கொண்ட குழு மற்றும் 3-புள்ளி கதையுடன் ஆரம்பிக்கலாம். முதலில், டெவலப்பர்கள், செயல்பாடுகள், சோதனையாளர்கள் என நாங்கள் அழைக்கும் அணியை உடைக்க வேண்டும். அவர்கள் அனைவரையும் ஒன்றாக நாங்கள் கருதுகிறோம், “டெவொப்ஸ்” என்று கூறுங்கள். தேவைகளைப் பெறும்போது, ​​ஆபத்து மண்டலங்களை பகுப்பாய்வு செய்ய வேண்டும். கடலின் ஆழமான பகுதிகளை மனதில் வைத்து & ஹெலிப் .. நாங்கள் பயணம் செய்ய ஆரம்பிக்கிறோம்.

இப்போது, ​​'தோல்வியின் நிகழ்தகவைக் குறைக்கும் இந்த தொடர்ச்சியான ஒருங்கிணைப்பு மற்றும் தொடர்ச்சியான வரிசைப்படுத்தலின் x- காரணி என்ன' என்று நீங்கள் நினைத்துக் கொண்டிருக்க வேண்டும்.

மேம்பட்ட பார்வை மற்றும் செயல்முறையுடன், செயல்முறை எவ்வளவு மென்மையானது, தோல்வியின் ஆபத்து எவ்வாறு குறைக்கப்பட்டது, காலக்கெடுவுக்கு முன்னர் பணி எவ்வாறு முடிக்கப்பட்டது போன்ற முடிவுகளின் தெளிவான படத்தை வைத்து நிர்வாகத்தை அணுகலாம்.

இப்போது, ​​ஒவ்வொரு மறு செய்கைக்குப் பின்னரும் மறுபரிசீலனை செய்வதன் மூலம் தொழில்நுட்ப மற்றும் கலாச்சார அடிப்படையில் முழு செயல்முறையும் எவ்வாறு மேம்படுத்தப்பட்டது என்பதை நாம் தெளிவாகக் காணலாம்.

எடுரேகா சிறப்பாக குணப்படுத்தியுள்ளார் இது பப்பட், ஜென்கின்ஸ், அன்சிபில், சால்ட்ஸ்டாக், செஃப் போன்றவற்றைச் சுற்றியுள்ள கருத்துக்களை மாஸ்டர் செய்ய உதவுகிறது.

எங்களுக்கு ஒரு கேள்வி கிடைத்ததா? கருத்துகள் பிரிவில் அவற்றைக் குறிப்பிடுங்கள், நாங்கள் உங்களைத் தொடர்புகொள்வோம்.

தொடர்புடைய இடுகைகள்: