கடந்த சில ஆண்டுகளாக DevOps மிகவும் பிரபலமான தலைப்பு. பலர் அதில் சேர வேண்டும் என்று கனவு காண்கிறார்கள், ஆனால், நடைமுறையில் காண்பிக்கிறபடி, பெரும்பாலும் சம்பளத்தின் அளவு காரணமாக மட்டுமே.
சிலர் டெவொப்ஸை தங்கள் விண்ணப்பத்தில் பட்டியலிடுகிறார்கள், இருப்பினும் அவர்கள் இந்த வார்த்தையின் சாராம்சத்தை எப்போதும் அறியவில்லை அல்லது புரிந்து கொள்ளவில்லை. Ansible, GitLab, Jenkins, Terraform போன்றவற்றைப் படித்த பிறகு (உங்கள் ரசனைக்கு ஏற்ப பட்டியலைத் தொடரலாம்), நீங்கள் உடனடியாக "டெவொப்சிஸ்ட்" ஆகிவிடுவீர்கள் என்று சிலர் நினைக்கிறார்கள். இது, உண்மையல்ல.
கடந்த சில ஆண்டுகளாக, நான் முக்கியமாக பல்வேறு நிறுவனங்களில் DevOps செயல்படுத்துவதில் ஈடுபட்டுள்ளேன். அதற்கு முன், சிஸ்டம் அட்மினிஸ்ட்ரேட்டர் முதல் ஐடி டைரக்டர் வரை 20 ஆண்டுகளுக்கும் மேலாக பணிபுரிந்தார். தற்போது Playgendary இல் DevOps முன்னணி பொறியாளர்.
டெவொப்ஸ் யார்
"DevOps யார்?" என்ற மற்றொரு கேள்விக்குப் பிறகு ஒரு கட்டுரை எழுதுவதற்கான யோசனை எழுந்தது. அது என்ன அல்லது யார் என்பதற்கு இன்னும் நிறுவப்பட்ட சொல் இல்லை. சில பதில்கள் ஏற்கனவே இதில் உள்ளன . முதலில், அதிலிருந்து முக்கிய புள்ளிகளை முன்னிலைப்படுத்துவேன், பின்னர் எனது அவதானிப்புகள் மற்றும் எண்ணங்களைப் பகிர்ந்து கொள்கிறேன்.
DevOps பணியமர்த்தப்படக்கூடிய ஒரு நிபுணர் அல்ல, பயன்பாடுகளின் தொகுப்பு அல்ல, மேலும் பொறியாளர்களைக் கொண்ட டெவலப்பர்களின் துறை அல்ல.
DevOps என்பது ஒரு தத்துவம் மற்றும் வழிமுறை.
வேறு வார்த்தைகளில் கூறுவதானால், டெவலப்பர்கள் கணினி நிர்வாகிகளுடன் தீவிரமாக தொடர்பு கொள்ள உதவும் நடைமுறைகளின் தொகுப்பாகும். அதாவது, வேலை செயல்முறைகளை ஒன்றோடொன்று இணைக்கவும் ஒருங்கிணைக்கவும்.
DevOps இன் வருகையுடன், நிபுணர்களின் கட்டமைப்பு மற்றும் பாத்திரங்கள் அப்படியே இருந்தன (டெவலப்பர்கள் உள்ளனர், பொறியாளர்கள் உள்ளனர்), ஆனால் தொடர்பு விதிகள் மாறிவிட்டன. துறைகளுக்கு இடையிலான எல்லைகள் மங்கலாகிவிட்டன.
DevOps இன் இலக்குகளை மூன்று புள்ளிகளில் விவரிக்கலாம்:
- மென்பொருள் தொடர்ந்து புதுப்பிக்கப்பட வேண்டும்.
- மென்பொருள் விரைவாக செய்யப்பட வேண்டும்.
- மென்பொருளானது வசதியாகவும் குறுகிய நேரத்திலும் பயன்படுத்தப்பட வேண்டும்.
DevOps க்கு எந்த ஒரு கருவியும் இல்லை. பல தயாரிப்புகளை கட்டமைத்தல், வழங்குதல் மற்றும் ஆய்வு செய்தல் ஆகியவை DevOps நிறுவனத்தில் தோன்றியதாக அர்த்தமல்ல. நிறைய கருவிகள் உள்ளன, அவை அனைத்தும் வெவ்வேறு நிலைகளில் பயன்படுத்தப்படுகின்றன, ஆனால் ஒரு பொதுவான நோக்கத்திற்காக சேவை செய்கின்றன.
இது DevOps கருவிகளின் ஒரு பகுதி மட்டுமே
நான் இப்போது 2 ஆண்டுகளுக்கும் மேலாக DevOps இன்ஜினியர் பதவிக்காக மக்களை நேர்காணல் செய்து வருகிறேன், மேலும் இந்த வார்த்தையின் சாரத்தை தெளிவாக புரிந்துகொள்வது எவ்வளவு முக்கியம் என்பதை நான் உணர்ந்தேன். நான் பகிர்ந்து கொள்ள விரும்பும் குறிப்பிட்ட அனுபவங்கள், அவதானிப்புகள் மற்றும் எண்ணங்களை சேகரித்துள்ளேன்.
நேர்காணல் அனுபவத்திலிருந்து, நான் பின்வரும் படத்தைப் பார்க்கிறேன்: DevOps ஒரு வேலை தலைப்பு என்று கருதும் வல்லுநர்கள் பொதுவாக சக ஊழியர்களுடன் தவறான புரிதல்களைக் கொண்டுள்ளனர்.
ஒரு குறிப்பிடத்தக்க உதாரணம் இருந்தது. ஒரு இளைஞன் தனது விண்ணப்பத்தில் நிறைய புத்திசாலித்தனமான வார்த்தைகளுடன் நேர்காணலுக்கு வந்தான். அவரது கடைசி மூன்று வேலைகளில், அவருக்கு 5-6 மாதங்கள் அனுபவம் இருந்தது. நான் இரண்டு ஸ்டார்ட்அப்களை விட்டுவிட்டேன், ஏனெனில் அவை "எடுக்கவில்லை." ஆனால் மூன்றாவது நிறுவனத்தைப் பற்றி, அங்கு யாரும் அவரைப் புரிந்து கொள்ளவில்லை என்று அவர் கூறினார்: டெவலப்பர்கள் விண்டோஸில் குறியீட்டை எழுதுகிறார்கள், மேலும் இயக்குனர் இந்த குறியீட்டை வழக்கமான டோக்கரில் "சுற்றப்பட்டு" சிஐ / சிடி பைப்லைனில் ஒருங்கிணைக்க கட்டாயப்படுத்துகிறார். பையன் தனது தற்போதைய வேலை செய்யும் இடம் மற்றும் சக ஊழியர்களைப் பற்றி நிறைய எதிர்மறையான விஷயங்களைக் கூறினார் - நான் பதிலளிக்க விரும்பினேன்: "எனவே நீங்கள் யானையை விற்க மாட்டீர்கள்."
ஒவ்வொரு வேட்பாளரிடமும் எனது பட்டியலில் அதிகம் உள்ள ஒரு கேள்வியை அவரிடம் கேட்டேன்.
— தனிப்பட்ட முறையில் DevOps உங்களுக்கு என்ன அர்த்தம்?
- பொதுவாக அல்லது நான் அதை எப்படி உணருவது?
அவருடைய தனிப்பட்ட கருத்தில் நான் ஆர்வமாக இருந்தேன். இந்த வார்த்தையின் கோட்பாடு மற்றும் தோற்றம் அவருக்கு தெரியும், ஆனால் அவர் அவற்றை கடுமையாக ஏற்கவில்லை. DevOps ஒரு வேலை தலைப்பு என்று அவர் நம்பினார். இங்குதான் அவனுடைய பிரச்சனைகளின் வேர் உள்ளது. அதே கருத்தை மற்ற நிபுணர்கள்.
"DevOps இன் மேஜிக்" பற்றி நிறைய கேள்விப்பட்ட முதலாளிகள், வந்து இந்த "மேஜிக்கை" உருவாக்கும் ஒரு நபரைக் கண்டுபிடிக்க விரும்புகிறார்கள். மேலும் “DevOps ஒரு வேலை” வகையைச் சேர்ந்த விண்ணப்பதாரர்கள் இந்த அணுகுமுறையால் எதிர்பார்ப்புகளை பூர்த்தி செய்ய முடியாது என்பதை புரிந்து கொள்ளவில்லை. மேலும், பொதுவாக, அவர்கள் DevOps அவர்களின் விண்ணப்பத்தில் எழுதினார்கள், ஏனெனில் இது ஒரு போக்கு மற்றும் அதற்கு அவர்கள் நிறைய பணம் செலுத்துகிறார்கள்.
DevOps முறை மற்றும் தத்துவம்
முறை கோட்பாட்டு மற்றும் நடைமுறைக்குரியதாக இருக்கலாம். எங்கள் விஷயத்தில், இது இரண்டாவது. நான் மேலே குறிப்பிட்டுள்ளபடி, DevOps என்பது குறிப்பிட்ட இலக்குகளை அடைய பயன்படுத்தப்படும் நடைமுறைகள் மற்றும் உத்திகளின் தொகுப்பாகும். ஒவ்வொரு விஷயத்திலும், நிறுவனத்தின் வணிக செயல்முறைகளைப் பொறுத்து, அது கணிசமாக வேறுபடலாம். எது அதை சிறப்பாகவோ அல்லது மோசமாகவோ செய்யாது.
DevOps முறை என்பது இலக்குகளை அடைவதற்கான ஒரு வழிமுறை மட்டுமே.
இப்போது DevOps தத்துவம் என்ன என்பதைப் பற்றி. இது அநேகமாக மிகவும் கடினமான கேள்வி.
ஒரு குறுகிய மற்றும் சுருக்கமான பதிலை உருவாக்குவது மிகவும் கடினம், ஏனெனில் அது இன்னும் முறைப்படுத்தப்படவில்லை. மேலும் DevOps தத்துவத்தைப் பின்பற்றுபவர்கள் நடைமுறையில் அதிக ஈடுபாடு கொண்டவர்களாக இருப்பதால், தத்துவமயமாக்குவதற்கு நேரமில்லை. இருப்பினும், இது மிகவும் முக்கியமான செயல்முறையாகும். மேலும், இது நேரடியாக பொறியியல் செயல்பாடுகளுடன் தொடர்புடையது. அறிவின் ஒரு சிறப்புப் பகுதி கூட உள்ளது - .
எனது பல்கலைக்கழகத்தில் அத்தகைய பாடம் எதுவும் இல்லை, 90 களில் நான் கண்டுபிடிக்கக்கூடிய பொருட்களைப் பயன்படுத்தி எல்லாவற்றையும் சொந்தமாகப் படிக்க வேண்டியிருந்தது. பொறியியல் கல்விக்கான தலைப்பு விருப்பமானது, எனவே பதில் முறைப்படுத்தப்படவில்லை. ஆனால் DevOps இல் தீவிரமாக மூழ்கியிருப்பவர்கள், நிறுவனத்தின் அனைத்து செயல்முறைகளிலும் ஒரு குறிப்பிட்ட "ஆவி" அல்லது "நினைவற்ற விரிவான தன்மையை" உணரத் தொடங்குகின்றனர்.
எனது சொந்த அனுபவத்தைப் பயன்படுத்தி, இந்த தத்துவத்தின் சில "போஸ்டுலேட்டுகளை" முறைப்படுத்த முயற்சித்தேன். இதன் விளைவு பின்வருமாறு:
- DevOps என்பது அறிவு அல்லது செயல்பாட்டின் ஒரு தனிப் பகுதியில் பிரிக்கக்கூடிய சுயாதீனமான ஒன்று அல்ல.
- அனைத்து நிறுவன ஊழியர்களும் தங்கள் செயல்பாடுகளைத் திட்டமிடும்போது DevOps முறையால் வழிநடத்தப்பட வேண்டும்.
- DevOps ஒரு நிறுவனத்தில் உள்ள அனைத்து செயல்முறைகளையும் பாதிக்கிறது.
- டெவொப்ஸ் நிறுவனம் அதன் சேவைகளின் வளர்ச்சி மற்றும் அதிகபட்ச வாடிக்கையாளர் வசதியை உறுதி செய்வதற்காக ஒரு நிறுவனத்தில் உள்ள எந்தவொரு செயல்முறைக்கும் நேர செலவைக் குறைக்க உள்ளது.
- DevOps, நவீன மொழியில், நிறுவனத்தின் ஒவ்வொரு பணியாளரின் செயலூக்கமான நிலையாகும், இது நேரச் செலவுகளைக் குறைப்பது மற்றும் நம்மைச் சுற்றியுள்ள IT தயாரிப்புகளின் தரத்தை மேம்படுத்துவதை நோக்கமாகக் கொண்டது.
எனது "போஸ்டுலேட்டுகள்" விவாதத்திற்கு ஒரு தனி தலைப்பு என்று நான் நினைக்கிறேன். ஆனால் இப்போது கட்டியெழுப்ப ஏதாவது இருக்கிறது.
DevOps என்ன செய்கிறது
இங்கே முக்கிய வார்த்தை தொடர்பு. நிறைய தகவல்தொடர்புகள் உள்ளன, அதைத் துவக்குபவர் அதே DevOps இன்ஜினியராக இருக்க வேண்டும். அது ஏன்? ஏனெனில் இது தத்துவம் மற்றும் வழிமுறை, அதன் பிறகுதான் பொறியியல் அறிவு.
மேற்கத்திய தொழிலாளர் சந்தை பற்றி 100% நம்பிக்கையுடன் என்னால் பேச முடியாது. ஆனால் ரஷ்யாவில் DevOps சந்தையைப் பற்றி எனக்கு நிறைய தெரியும். நூற்றுக்கணக்கான நேர்காணல்களுக்கு மேலதிகமாக, கடந்த ஒன்றரை ஆண்டுகளில் நான் பெரிய ரஷ்ய நிறுவனங்கள் மற்றும் வங்கிகளுக்கான "DevOps செயல்படுத்தல்" சேவைக்கான நூற்றுக்கணக்கான தொழில்நுட்ப முன் விற்பனைகளில் பங்கேற்றுள்ளேன்.
ரஷ்யாவில், DevOps இன்னும் மிகவும் இளமையானது, ஆனால் ஏற்கனவே பிரபலமான தலைப்பு. எனக்குத் தெரிந்தவரை, மாஸ்கோவில் மட்டும் 2019 இல் அத்தகைய நிபுணர்களின் பற்றாக்குறை 1000 க்கும் அதிகமான மக்கள். முதலாளிகளுக்கான குபெர்னெட்டஸ் என்ற வார்த்தை காளைக்கு ஒரு சிவப்பு துணியைப் போன்றது. இந்த கருவியைப் பின்பற்றுபவர்கள் தேவையில்லாத மற்றும் பொருளாதார ரீதியாக லாபம் ஈட்டக்கூடிய இடங்களில் கூட அதைப் பயன்படுத்தத் தயாராக உள்ளனர். எந்த சந்தர்ப்பங்களில் எதைப் பயன்படுத்துவது மிகவும் பொருத்தமானது என்பதை முதலாளி எப்போதும் புரிந்துகொள்வதில்லை, மேலும் முறையான வரிசைப்படுத்தலுடன், வழக்கமான கிளஸ்டர் திட்டத்தைப் பயன்படுத்தி பயன்பாட்டைப் பயன்படுத்துவதை விட 2-3 மடங்கு அதிகமாக குபெர்னெட்ஸ் கிளஸ்டரைப் பராமரிப்பது செலவாகும். உங்களுக்கு உண்மையில் தேவைப்படும் இடத்தில் அதைப் பயன்படுத்தவும்.
DevOps ஐ செயல்படுத்துவது பணத்தின் அடிப்படையில் விலை உயர்ந்தது. அது மற்ற பகுதிகளில் பொருளாதார நன்மைகளை கொண்டு வரும் இடத்தில் மட்டுமே நியாயப்படுத்தப்படுகிறது, மற்றும் அதன் சொந்த அல்ல.
DevOps பொறியாளர்கள், உண்மையில் முன்னோடிகளாக உள்ளனர் - அவர்கள்தான் நிறுவனத்தில் இந்த முறையை முதலில் செயல்படுத்தி செயல்முறைகளை உருவாக்க வேண்டும். இது வெற்றிகரமாக இருக்க, நிபுணர் தொடர்ந்து அனைத்து மட்டங்களிலும் உள்ள ஊழியர்கள் மற்றும் சக ஊழியர்களுடன் தொடர்பு கொள்ள வேண்டும். நான் வழக்கமாக சொல்வது போல், அனைத்து நிறுவன ஊழியர்களும் DevOps செயல்படுத்தும் செயல்பாட்டில் ஈடுபட வேண்டும்: சுத்தம் செய்யும் பெண் முதல் CEO வரை. மேலும் இது ஒரு முன்நிபந்தனை. குழுவின் மிக இளைய உறுப்பினருக்கு DevOps என்றால் என்ன மற்றும் சில நிறுவனச் செயல்கள் ஏன் செய்யப்படுகின்றன என்பதை அறியாமலும் புரிந்து கொள்ளாமலும் இருந்தால், வெற்றிகரமான செயல்படுத்தல் வேலை செய்யாது.
மேலும், ஒரு DevOps பொறியாளர் அவ்வப்போது நிர்வாக வளத்தைப் பயன்படுத்த வேண்டும். எடுத்துக்காட்டாக, "சுற்றுச்சூழல் எதிர்ப்பை" சமாளிக்க - குழு DevOps கருவிகள் மற்றும் வழிமுறைகளை ஏற்கத் தயாராக இல்லாத போது.
டெவலப்பர் குறியீடு மற்றும் சோதனைகளை மட்டுமே எழுத வேண்டும். இதைச் செய்ய, அவருக்கு சக்திவாய்ந்த மடிக்கணினி தேவையில்லை, அதில் அவர் முழு திட்ட உள்கட்டமைப்பையும் உள்நாட்டில் பயன்படுத்துவார். எடுத்துக்காட்டாக, ஒரு முன்-இறுதி டெவலப்பர், டேட்டாபேஸ், எஸ்3 எமுலேட்டர் (மினியோ) உள்ளிட்ட பயன்பாட்டின் அனைத்து கூறுகளையும் தனது லேப்டாப்பில் வைத்திருப்பார். அதாவது, அவர் இந்த உள்ளூர் உள்கட்டமைப்பைப் பராமரிப்பதில் நிறைய நேரம் செலவிடுகிறார் மற்றும் அத்தகைய தீர்வுக்கான அனைத்து பிரச்சனைகளிலும் தனித்து போராடுகிறார். முன்புறத்திற்கான குறியீட்டை உருவாக்குவதற்குப் பதிலாக. அத்தகையவர்கள் எந்த மாற்றத்தையும் மிகவும் எதிர்க்க முடியும்.
ஆனால், மாறாக, புதிய கருவிகள் மற்றும் முறைகளை அறிமுகப்படுத்துவதில் மகிழ்ச்சியடையும் அணிகள் உள்ளன, மேலும் இந்த செயல்பாட்டில் தீவிரமாக பங்கேற்கின்றன. இந்த வழக்கில் கூட, DevOps பொறியாளருக்கும் குழுவிற்கும் இடையிலான தொடர்பு ரத்து செய்யப்படவில்லை.
DevOps தேவைப்படாதபோது
DevOps தேவைப்படாத சூழ்நிலைகள் உள்ளன. இது ஒரு உண்மை - புரிந்து கொள்ள வேண்டும் மற்றும் ஏற்றுக்கொள்ள வேண்டும்.
முதலாவதாக, இது எந்த நிறுவனங்களுக்கும் (குறிப்பாக சிறு வணிகங்களுக்கு) பொருந்தும், வாடிக்கையாளர்களுக்கு தகவல் சேவைகளை வழங்கும் IT தயாரிப்புகளின் இருப்பு அல்லது இல்லாமையை நேரடியாக சார்ந்து இருக்காது. இங்கே நாங்கள் நிறுவனத்தின் வலைத்தளத்தைப் பற்றி பேசவில்லை, அது நிலையான “வணிக அட்டை” அல்லது டைனமிக் செய்தித் தொகுதிகள் போன்றவை.
உங்கள் வாடிக்கையாளரின் திருப்தி மற்றும் மீண்டும் உங்களிடம் திரும்புவதற்கான அவரது விருப்பம் ஆகியவை வாடிக்கையாளருடன் தொடர்புகொள்வதற்கான இந்த தகவல் சேவைகளின் கிடைக்கும் தன்மை, அவற்றின் தரம் மற்றும் இலக்கு ஆகியவற்றைச் சார்ந்திருக்கும் போது DevOps தேவைப்படுகிறது.
ஒரு குறிப்பிடத்தக்க உதாரணம் ஒரு நன்கு அறியப்பட்ட வங்கி. நிறுவனத்திற்கு பாரம்பரிய கிளையன்ட் அலுவலகங்கள் இல்லை, ஆவண ஓட்டம் அஞ்சல் அல்லது கூரியர் மூலம் மேற்கொள்ளப்படுகிறது, மேலும் பல ஊழியர்கள் வீட்டிலிருந்து வேலை செய்கிறார்கள். இந்நிறுவனம் வெறும் வங்கியாக இருந்துவிட்டு, வளர்ந்த DevOps தொழில்நுட்பங்களைக் கொண்ட IT நிறுவனமாக மாறிவிட்டது என்பது என் கருத்து.
பல எடுத்துக்காட்டுகள் மற்றும் விரிவுரைகளை கருப்பொருள் சந்திப்புகள் மற்றும் மாநாடுகளின் பதிவுகளில் காணலாம். அவர்களில் சிலரை நான் தனிப்பட்ட முறையில் பார்வையிட்டேன் - இந்த திசையில் வளர விரும்புவோருக்கு இது மிகவும் பயனுள்ள அனுபவம். DevOps இல் நல்ல விரிவுரைகள் மற்றும் உள்ளடக்கத்துடன் கூடிய YouTube சேனல்களுக்கான இணைப்புகள் இதோ:
இப்போது உங்கள் வணிகத்தைப் பார்த்து இதைப் பற்றி சிந்தியுங்கள்: வாடிக்கையாளர் தொடர்புகளை செயல்படுத்த உங்கள் நிறுவனமும் அதன் லாபமும் எவ்வளவு IT தயாரிப்புகளைச் சார்ந்துள்ளது?
உங்கள் நிறுவனம் ஒரு சிறிய கடையில் மீன் விற்கிறது மற்றும் ஒரே IT தயாரிப்பு இரண்டு 1C: நிறுவன உள்ளமைவுகள் (கணக்கியல் மற்றும் UNF), DevOps பற்றி பேசுவதில் அர்த்தமில்லை.
நீங்கள் ஒரு பெரிய வர்த்தகம் மற்றும் உற்பத்தி நிறுவனத்தில் பணிபுரிந்தால் (உதாரணமாக, நீங்கள் வேட்டையாடும் துப்பாக்கிகளை உற்பத்தி செய்கிறீர்கள்), நீங்கள் அதைப் பற்றி சிந்திக்க வேண்டும். நீங்கள் முன்முயற்சி எடுத்து, DevOps ஐ செயல்படுத்துவதற்கான வாய்ப்புகளை உங்கள் நிர்வாகத்திற்கு தெரிவிக்கலாம். சரி, அதே நேரத்தில், இந்த செயல்முறையை வழிநடத்துங்கள். DevOps தத்துவத்தின் முக்கியமான கோட்பாடுகளில் ஒரு செயலூக்கமான நிலைப்பாடு ஒன்றாகும்.
உங்கள் நிறுவனத்திற்கு DevOps தேவையா என்பதைத் தீர்மானிப்பதற்கான முக்கிய அளவுகோல் வருடாந்திர நிதி வருவாயின் அளவு மற்றும் அளவு அல்ல.
வாடிக்கையாளர்களுடன் நேரடியாக தொடர்பு கொள்ளாத ஒரு பெரிய தொழில்துறை நிறுவனத்தை கற்பனை செய்வோம். உதாரணமாக, சில வாகன உற்பத்தியாளர்கள் மற்றும் ஆட்டோமொபைல் உற்பத்தி நிறுவனங்கள். எனக்கு இப்போது உறுதியாகத் தெரியவில்லை, ஆனால் எனது கடந்த கால அனுபவத்தின் அடிப்படையில், பல ஆண்டுகளாக அனைத்து வாடிக்கையாளர் தொடர்புகளும் மின்னஞ்சல் மற்றும் தொலைபேசி மூலமாகவே செய்யப்பட்டன.
அவர்களின் வாடிக்கையாளர்கள் கார் டீலர்களின் வரையறுக்கப்பட்ட பட்டியல். ஒவ்வொருவருக்கும் உற்பத்தியாளரிடமிருந்து ஒரு நிபுணர் நியமிக்கப்படுகிறார். அனைத்து உள் ஆவண ஓட்டமும் SAP ERP மூலம் நிகழ்கிறது. உள் பணியாளர்கள் அடிப்படையில் தகவல் அமைப்பின் வாடிக்கையாளர்கள். ஆனால் இந்த IS கிளஸ்டர் அமைப்புகளை நிர்வகிப்பதற்கான கிளாசிக்கல் வழிமுறைகளால் கட்டுப்படுத்தப்படுகிறது. இது DevOps நடைமுறைகளைப் பயன்படுத்துவதற்கான வாய்ப்பை விலக்குகிறது.
எனவே முடிவு: கட்டுரையின் தொடக்கத்திலிருந்தே முறையின் குறிக்கோள்களை நாம் நினைவு கூர்ந்தால், அத்தகைய நிறுவனங்களுக்கு, DevOps செயல்படுத்துவது முக்கியமான ஒன்று அல்ல. ஆனால் அவர்கள் இன்று சில DevOps கருவிகளைப் பயன்படுத்துகிறார்கள் என்பதை நான் நிராகரிக்கவில்லை.
மறுபுறம், DevOps முறை, தத்துவம், நடைமுறைகள் மற்றும் கருவிகளைப் பயன்படுத்தி மென்பொருளை உருவாக்கும் பல சிறிய நிறுவனங்கள் உள்ளன. மேலும் DevOps ஐ செயல்படுத்துவதற்கான செலவு மென்பொருள் சந்தையில் திறம்பட போட்டியிட அனுமதிக்கும் செலவு என்று அவர்கள் நம்புகிறார்கள். அத்தகைய நிறுவனங்களின் உதாரணங்களைக் காணலாம் .
DevOps தேவையா என்பதைப் புரிந்துகொள்வதற்கான முக்கிய அளவுகோல்: உங்கள் IT தயாரிப்புகள் நிறுவனம் மற்றும் வாடிக்கையாளர்களுக்கு என்ன மதிப்பைக் கொண்டுள்ளன.
லாபத்தை உருவாக்கும் நிறுவனத்தின் முக்கிய தயாரிப்பு மென்பொருள் என்றால், உங்களுக்கு DevOps தேவை. மற்ற தயாரிப்புகளைப் பயன்படுத்தி நீங்கள் உண்மையான பணம் சம்பாதித்தால் அது அவ்வளவு முக்கியமல்ல. ஆன்லைன் ஸ்டோர்கள் அல்லது கேம்களுடன் கூடிய மொபைல் பயன்பாடுகளும் இதில் அடங்கும்.
எந்த விளையாட்டுகளும் நிதியளிப்பதால் உள்ளன: நேரடியாகவோ அல்லது மறைமுகமாகவோ பிளேயர்களிடமிருந்து. Playgendary இல், 200 க்கும் மேற்பட்டவர்கள் நேரடியாக தங்கள் உருவாக்கத்தில் ஈடுபட்டுள்ள இலவச மொபைல் கேம்களை நாங்கள் உருவாக்குகிறோம். DevOps எவ்வாறு பயன்படுத்துவது?
ஆம், மேலே விவரிக்கப்பட்டதைப் போலவே. நான் டெவலப்பர்கள் மற்றும் சோதனையாளர்களுடன் தொடர்ந்து தொடர்புகொள்கிறேன், மேலும் DevOps முறை மற்றும் கருவிகளில் ஊழியர்களுக்கு உள் பயிற்சியை நடத்துகிறேன்.
யூனிட்டியுடன் அனைத்து அசெம்பிளி பைப்லைன்களையும் செயல்படுத்துவதற்கும், ஆப் ஸ்டோர் மற்றும் ப்ளே மார்கெட்டிற்குப் பயன்படுத்துவதற்கும் ஜென்கின்ஸ்ஸை சிஐ/சிடி பைப்லைன் கருவியாக இப்போது தீவிரமாகப் பயன்படுத்துகிறோம். கிளாசிக் கருவித்தொகுப்பிலிருந்து மேலும்:
- ஆசனம் - திட்ட மேலாண்மைக்கு. ஜென்கின்ஸ் உடனான ஒருங்கிணைப்பு கட்டமைக்கப்பட்டுள்ளது.
- Google Meet - வீடியோ சந்திப்புகளுக்கு.
- ஸ்லாக் - தகவல்தொடர்புகள் மற்றும் ஜென்கின்ஸின் அறிவிப்புகள் உட்பட பல்வேறு விழிப்பூட்டல்களுக்கு.
- அட்லாசியன் சங்கமம் - ஆவணப்படுத்தல் மற்றும் குழுப்பணிக்காக.
எங்களின் உடனடித் திட்டங்களில் SonarQube ஐப் பயன்படுத்தி நிலையான குறியீடு பகுப்பாய்வை அறிமுகப்படுத்துதல் மற்றும் தொடர்ச்சியான ஒருங்கிணைப்பு நிலையில் செலினியத்தைப் பயன்படுத்தி தானியங்கு UI சோதனை நடத்துதல் ஆகியவை அடங்கும்.
அதற்கு பதிலாக, ஒரு முடிவுக்கும்
நான் பின்வரும் சிந்தனையுடன் முடிக்க விரும்புகிறேன்: உயர் தகுதி வாய்ந்த DevOps இன்ஜினியராக ஆவதற்கு, மக்களுடன் நேரலையில் எவ்வாறு தொடர்புகொள்வது என்பதைக் கற்றுக்கொள்வது இன்றியமையாதது.
ஒரு DevOps பொறியாளர் ஒரு குழு வீரர். மற்றும் வேறு எதுவும் இல்லை. சக ஊழியர்களுடன் தொடர்புகொள்வதில் முன்முயற்சி அவரிடமிருந்து வர வேண்டும், சில சூழ்நிலைகளின் செல்வாக்கின் கீழ் அல்ல. ஒரு DevOps நிபுணர் குழுவிற்கு சிறந்த தீர்வைப் பார்த்து முன்மொழிய வேண்டும்.
ஆம், எந்தவொரு தீர்வையும் செயல்படுத்துவதற்கு நிறைய விவாதங்கள் தேவைப்படும், இறுதியில் அது முற்றிலும் மாறலாம். சுயாதீனமாக அபிவிருத்தி செய்வது, தனது யோசனைகளை முன்மொழிதல் மற்றும் செயல்படுத்துதல், அத்தகைய நபர் குழுவிற்கும் முதலாளிக்கும் மதிப்பு அதிகரிக்கும். இது, இறுதியில், அவரது மாதாந்திர ஊதியத்தின் அளவு அல்லது கூடுதல் போனஸ் வடிவத்தில் பிரதிபலிக்கிறது.
ஆதாரம்: www.habr.com