அறிக்கை சில DevOps நடைமுறைகளைப் பற்றி பேசும், ஆனால் டெவலப்பரின் பார்வையில். பொதுவாக, DevOps இல் சேரும் அனைத்து பொறியாளர்களும் ஏற்கனவே பல வருட நிர்வாக அனுபவத்தைப் பெற்றுள்ளனர். ஆனால் டெவலப்பருக்கு இங்கு இடமில்லை என்று இது அர்த்தப்படுத்துவதில்லை. பெரும்பாலும், டெவலப்பர்கள் "அந்த நாளின் அடுத்த அவசரமான முக்கியமான பிழையை" சரிசெய்வதில் மும்முரமாக உள்ளனர், மேலும் DevOps புலத்தை விரைவாகப் பார்க்கக் கூட அவர்களுக்கு நேரமில்லை. ஆசிரியரின் புரிதலில், DevOps, முதலில், பொது அறிவு. இரண்டாவதாக, இது மிகவும் பயனுள்ளதாக இருக்க ஒரு வாய்ப்பு. நீங்கள் ஒரு டெவலப்பர், பொது அறிவு மற்றும் ஒரு குழு வீரராக மிகவும் பயனுள்ளதாக இருக்க விரும்பினால், இந்த அறிக்கை உங்களுக்கானது.
என்னை அறிமுகப்படுத்திக் கொள்கிறேன், என்னைத் தெரியாதவர்கள் அறையில் இருக்கிறார்கள் என்பதை நான் முழுமையாக ஒப்புக்கொள்கிறேன். என் பெயர் அன்டன் பாய்கோ, நான் மைக்ரோசாஃப்ட் அஸூர் எம்விபி. எம்விபி என்றால் என்ன? இது மாதிரி காட்சி வழங்குபவர். மாடல்-வியூ-பிரசன்டர் சரியாக நான்தான்.
கூடுதலாக, நான் தற்போது சிக்லமில் தீர்வு வடிவமைப்பாளராக பதவி வகிக்கிறேன். சமீபத்தில் நான் அத்தகைய அழகான டொமைனை வாங்கினேன், மேலும் எனது மின்னஞ்சலைப் புதுப்பித்தேன், அதை நான் வழக்கமாக விளக்கக்காட்சிகளில் காண்பிக்கிறேன். நீங்கள் எனக்கு இங்கு எழுதலாம்: me [dog] byokoant.pro. கேள்விகளுடன் நீங்கள் எனக்கு மின்னஞ்சல் அனுப்பலாம். நான் பொதுவாக அவர்களுக்கு பதில் சொல்வேன். ஒரே விஷயம் என்னவென்றால், அரசியல் மற்றும் மதம் ஆகிய இரண்டு தலைப்புகளுடன் தொடர்புடைய கேள்விகளை மின்னஞ்சல் மூலம் பெற நான் விரும்பவில்லை. மற்ற அனைத்தையும் பற்றி நீங்கள் எனக்கு மின்னஞ்சல் மூலம் எழுதலாம். சிறிது நேரம் போகும், நான் பதில் சொல்கிறேன்.
என்னைப் பற்றி சில வார்த்தைகள்:
- நான் 10 வருடங்களாக இந்தத் துறையில் இருக்கிறேன்.
- நான் மைக்ரோசாப்ட் நிறுவனத்தில் பணிபுரிந்தேன்.
- நான் 2014 இல் எங்காவது நிறுவிய உக்ரேனிய அசூர் சமூகத்தின் நிறுவனர் தந்தை. எங்களிடம் இன்னும் உள்ளது மற்றும் அதை உருவாக்குகிறோம்.
- உக்ரைனில் நாங்கள் நடத்தும் அஸூர் மாநாட்டின் நிறுவனரின் தந்தையும் நான்தான்.
- Kyiv இல் Global Azure Bootcamp ஐ ஏற்பாடு செய்வதற்கும் நான் உதவுகிறேன்.
- நான் சொன்னது போல், நான் ஒரு மைக்ரோசாஃப்ட் அஸூர் எம்விபி.
- நான் அடிக்கடி மாநாடுகளில் பேசுவேன். மாநாடுகளில் பேசுவது எனக்கு மிகவும் பிடிக்கும். கடந்த ஒரு வருடத்தில் சுமார் 40 முறை என்னால் நடிக்க முடிந்தது. நீங்கள் உக்ரைன், பெலாரஸ், போலந்து, பல்கேரியா, ஸ்வீடன், டென்மார்க், நெதர்லாந்து, ஸ்பெயின் ஆகிய நாடுகளைக் கடந்து சென்றால் அல்லது ஐரோப்பாவில் வேறொரு நாட்டைக் கொடுத்தால் அல்லது எடுத்துக் கொண்டால், அதன் ஸ்ட்ரீமில் கிளவுட் தீம் கொண்ட ஒரு மாநாட்டிற்குச் செல்லும்போது அது சாத்தியமாகும். பேச்சாளர்கள் பட்டியலில் நீங்கள் என்னைப் பார்க்கலாம்.
- நானும் ஒரு ஸ்டார் ட்ரெக் ரசிகன்.
நிகழ்ச்சி நிரலைப் பற்றி கொஞ்சம் பேசலாம். எங்கள் நிகழ்ச்சி நிரல் மிகவும் எளிமையானது:
- DevOps என்றால் என்ன என்பதைப் பற்றி பேசுவோம். இது ஏன் முக்கியமானது என்று பேசலாம். முன்பு, DevOps என்பது உங்கள் பயோடேட்டாவில் நீங்கள் எழுதிய ஒரு முக்கிய வார்த்தையாக இருந்தது மற்றும் உடனடியாக +$500 சம்பளத்தைப் பெற்றது. இப்போது நீங்கள் உங்கள் சம்பளத்திற்கு +500 டாலர்களைப் பெற உங்கள் விண்ணப்பத்தில் பிளாக்செயின் எழுத வேண்டும்.
- பின்னர், இது என்ன என்பதைப் பற்றி கொஞ்சம் புரிந்து கொள்ளும்போது, DevOps நடைமுறைகள் என்ன என்பதைப் பற்றி பேசுவோம். ஆனால் பொதுவாக DevOps சூழலில் அதிகம் இல்லை, ஆனால் டெவலப்பர்களுக்கு ஆர்வமாக இருக்கும் அந்த DevOps நடைமுறைகள் பற்றி. அவை ஏன் உங்களுக்கு ஆர்வமாக இருக்கலாம் என்று நான் உங்களுக்கு சொல்கிறேன். நீங்கள் ஏன் இதை செய்ய வேண்டும் மற்றும் குறைந்த வலியை அனுபவிக்க இது எப்படி உதவும் என்பதை நான் உங்களுக்கு சொல்கிறேன்.
பலர் காட்டும் ஒரு பாரம்பரிய படம். பல திட்டங்களில் இதுதான் நடக்கிறது. எங்கள் மென்பொருளை ஆதரிக்கும் மேம்பாடு மற்றும் செயல்பாட்டுத் துறைகள் எங்களிடம் இருக்கும்போது இதுவே. மேலும் இந்த துறைகள் ஒன்றுக்கொன்று தொடர்பு கொள்வதில்லை.
ஒருவேளை, DevOps மற்றும் செயல்பாட்டுத் துறைகளில் நீங்கள் அதை அவ்வளவு தெளிவாக உணர முடியாவிட்டால், நீங்கள் Dev மற்றும் QA துறைகளுடன் ஒரு ஒப்புமையை வரையலாம். மென்பொருளை உருவாக்குபவர்கள் உள்ளனர் மற்றும் டெவலப்பர்களின் பார்வையில் மோசமான QA நபர்களும் உள்ளனர். எடுத்துக்காட்டாக, நான் எனது அற்புதமான குறியீட்டை களஞ்சியத்தில் ஒப்படைத்தேன், அங்கே அமர்ந்திருக்கும் சில அயோக்கியர்கள் இந்தக் குறியீட்டை என்னிடம் திருப்பி உங்கள் குறியீடு மோசமாக உள்ளது என்று கூறுகிறார்.
மக்கள் ஒருவருக்கொருவர் தொடர்பு கொள்ளாததால் இவை அனைத்தும் நிகழ்கின்றன. அவர்கள் சில தொகுப்புகளை, சில பயன்பாடுகளை தவறான புரிதலின் சுவர் வழியாக ஒருவருக்கொருவர் தூக்கி எறிந்துவிட்டு, அவர்களுடன் ஏதாவது செய்ய முயற்சிக்கிறார்கள்.
துல்லியமாக இந்தச் சுவர்தான் DevOps கலாச்சாரம் அழிக்க வடிவமைக்கப்பட்டுள்ளது, அதாவது. மக்கள் ஒருவருக்கொருவர் தொடர்பு கொள்ள கட்டாயப்படுத்துங்கள் மற்றும் திட்டத்தில் உள்ள வெவ்வேறு நபர்கள் என்ன செய்கிறார்கள் மற்றும் அவர்களின் பணி ஏன் முக்கியமானது என்பதைப் புரிந்துகொள்ளவும்.
நாம் DevOps பற்றி பேசும்போது, திட்டமானது தொடர்ச்சியான ஒருங்கிணைப்பைக் கொண்டிருக்கும் போது DevOps என்று யாராவது உங்களுக்குச் சொல்வார்கள்; திட்டமானது "குறியீடாக உள்கட்டமைப்பு" நடைமுறையை செயல்படுத்தினால் DevOps என்று யாராவது கூறுவார்கள்; DevOps இன் முதல் படி அம்சம் கிளைகள், அம்சக் கொடிகள் என்று யாராவது கூறுவார்கள்.
அடிப்படையில், இது அனைத்தும் அதன் சொந்த வழியில் உண்மை. ஆனால் இவை மட்டுமே நம்மிடம் உள்ள இறுதி நடைமுறைகள். இந்த நடைமுறைகளுக்குச் செல்வதற்கு முன், இந்த ஸ்லைடைப் பார்க்க பரிந்துரைக்கிறேன், இது உங்கள் நிறுவனத்தில் உங்கள் திட்டத்தில் Dev-Ops முறையை செயல்படுத்துவதற்கான 3 நிலைகளைக் காட்டுகிறது.
இந்த ஸ்லைடில் இரண்டாவது அதிகாரப்பூர்வமற்ற பெயரும் உள்ளது. DevOps இன் 3 மஸ்கடியர்கள் என்ன என்பதைக் கண்டறிய ஆன்லைனில் தேடலாம். இந்த கட்டுரையை நீங்கள் காணலாம். ஏன் 3 மஸ்கடியர்கள்? அது கீழே கூறுகிறது: மக்கள், செயல்முறைகள் மற்றும் தயாரிப்புகள், அதாவது. PPP - போர்தோஸ், போர்தோஸ் மற்றும் போர்தோஸ். DevOps இன் 3 மஸ்கடியர்கள் இதோ. இது ஏன் முக்கியமானது மற்றும் அது என்ன என்பதை இந்த கட்டுரை இன்னும் விரிவாக விவரிக்கிறது.
நீங்கள் ஒரு DevOps கலாச்சாரத்தை செயல்படுத்தத் தொடங்கும்போது, அது பின்வரும் வரிசையில் செயல்படுத்தப்படுவது மிகவும் முக்கியம்.
ஆரம்பத்தில் நீங்கள் மக்களுடன் பேச வேண்டும். மேலும் அது என்ன என்பதையும், அதிலிருந்து அவர்கள் எவ்வாறு சில நன்மைகளைப் பெற முடியும் என்பதையும் மக்களுக்கு நீங்கள் விளக்க வேண்டும்.
எங்கள் மாநாடு DotNet Fest என்று அழைக்கப்படுகிறது. அமைப்பாளர்கள் என்னிடம் கூறியது போல், நாங்கள் முக்கியமாக டெவலப்பர்களின் பார்வையாளர்களை இங்கு அழைத்தோம், எனவே மண்டபத்தில் உள்ள பெரும்பாலான மக்கள் வளர்ச்சியில் ஈடுபட்டுள்ளனர் என்று நம்புகிறேன்.
நாங்கள் மக்களைப் பற்றி பேசுவோம், டெவலப்பர்கள் ஒவ்வொரு நாளும் என்ன செய்ய விரும்புகிறார்கள் என்பதைப் பற்றி பேசுவோம். அவர்கள் அதிகம் விரும்புவது என்ன? அவர்கள் சில புதிய குறியீட்டை எழுத விரும்புகிறார்கள், புதிய ஃபிரேம்வொர்க்குகளைப் பயன்படுத்துகிறார்கள், புதிய அம்சங்களை உருவாக்குகிறார்கள். டெவலப்பர்கள் குறைந்தபட்சம் என்ன விரும்புகிறார்கள்? பழைய பிழைகளை சரிசெய்யவும். நீங்கள் என்னுடன் உடன்படுவீர்கள் என்று நம்புகிறேன். இதைத்தான் டெவலப்பர்கள் விரும்புகிறார்கள். அவர்கள் புதிய அம்சங்களை எழுத விரும்புகிறார்கள், அவர்கள் பிழைகளை சரிசெய்ய விரும்பவில்லை.
ஒரு குறிப்பிட்ட டெவலப்பர் உருவாக்கும் பிழைகளின் எண்ணிக்கை, அவரது கைகள் எவ்வளவு நேராக உள்ளன மற்றும் அவை அவரது தோள்களில் இருந்து எவ்வளவு வளரும் என்பதைப் பொறுத்தது, ஆனால் அவரது பட் பாக்கெட்டுகளிலிருந்து அல்ல. ஆயினும்கூட, எங்களிடம் ஒரு பெரிய திட்டம் இருக்கும்போது, சில நேரங்களில் எல்லாவற்றையும் கண்காணிக்க இயலாது, எனவே இன்னும் நிலையான மற்றும் உயர்தர குறியீட்டை எழுத உதவும் சில அணுகுமுறைகளைப் பயன்படுத்துவது எங்களுக்கு நன்றாக இருக்கும்.
QAக்கள் அதிகம் விரும்புவது என்ன? ஹாலில் இருக்கிறார்களா என்று தெரியவில்லை. எனக்கு QA வேண்டும் என்று சொல்வது கடினம், ஏனென்றால் நான் ஒருபோதும் ஒருவராக இருந்ததில்லை. மற்றும் தோழர்களுக்கு எந்த குற்றமும் இல்லை, நான் ஒருபோதும் மாட்டேன் என்று நம்புகிறேன் என்று கூறப்படும். ஆனால் அவர்களின் வேலையை அர்த்தமற்றதாகவும் பயனற்றதாகவும் கருதுகிறேன் என்பதற்காக அல்ல, ஆனால் இந்த வேலையை திறமையாக செய்யக்கூடிய ஒரு நபராக நான் கருதவில்லை, எனவே நான் அதை செய்ய முயற்சிக்க மாட்டேன். ஆனால் நான் புரிந்துகொண்டதிலிருந்து, QA க்கு மிகவும் பிடிக்காதது காலையில் வேலை செய்யப் போகிறது, தொடர்ந்து சில வகையான பின்னடைவு சோதனைகளை நடத்துவது, டெவலப்பர்களிடம் 3 ஸ்பிரிண்ட்டுகளுக்கு முன்பு அவர்கள் புகாரளித்த அதே பிழைகளை அடியெடுத்து வைத்து, “நீங்கள் எப்போது செய்வீர்கள் , Monsieur D 'Artagnan, இந்த பிழையை சரிசெய்யவும்.' மான்சியர் டி'ஆர்டக்னன் அவருக்கு பதிலளிக்கிறார்: "ஆம், ஆம், ஆம், நான் ஏற்கனவே அதை சரிசெய்துவிட்டேன்." நான் ஒரு பிழையை சரிசெய்து, வழியில் 5 ஐ உருவாக்கினேன்.
தயாரிப்பில் இந்த தீர்வை ஆதரிக்கும் நபர்கள், இந்த தீர்வு பிழைகள் இல்லாமல் வேலை செய்ய வேண்டும் என்று விரும்புகிறார்கள், இதனால் ஒவ்வொரு வெள்ளிக்கிழமையும் சாதாரண மக்கள் அனைவரும் பட்டிக்கு செல்லும்போது அவர்கள் சர்வரை மறுதொடக்கம் செய்ய வேண்டியதில்லை. வெள்ளிக்கிழமையன்று டெவலப்பர்கள் பணியமர்த்தப்பட்டனர், நிர்வாகிகள் சனிக்கிழமை வரை அமர்ந்து, இந்த வரிசைப்படுத்தலைச் சரிசெய்வதற்கு முயற்சி செய்கிறார்கள்.
அதே சிக்கல்களைத் தீர்ப்பதை நோக்கமாகக் கொண்டவர்கள் என்று நீங்கள் மக்களுக்கு விளக்கும்போது, செயல்முறைகளை முறைப்படுத்துவதற்கு நீங்கள் செல்லலாம். இது மிகவும் முக்கியமானது. ஏன்? ஏனென்றால், "முறைப்படுத்தல்" என்று நாங்கள் கூறும்போது, உங்கள் செயல்முறைகள் ஒரு துடைக்கும் மீது எங்காவது எப்படி நிகழ்கின்றன என்பதை விவரிப்பது முக்கியம். உதாரணமாக, நீங்கள் QA சூழல் அல்லது உற்பத்தி சூழலுக்குப் பயன்படுத்தினால், அது எப்போதும் இந்த வரிசையில் நடக்கும் என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும்; இந்த நிலைகளில் நாங்கள் இயக்குகிறோம், எடுத்துக்காட்டாக, தானியங்கி அலகு சோதனைகள் மற்றும் UI சோதனைகள். வரிசைப்படுத்திய பிறகு, வரிசைப்படுத்தல் சரியாக நடந்ததா அல்லது மோசமாக நடந்ததா என்பதை நாங்கள் சரிபார்க்கிறோம். ஆனால் நீங்கள் தயாரிப்பில் ஈடுபடும் போது மீண்டும் மீண்டும் செய்ய வேண்டிய செயல்களின் தெளிவான பட்டியல் உங்களிடம் ஏற்கனவே உள்ளது.
உங்கள் செயல்முறைகள் முறைப்படுத்தப்பட்டால் மட்டுமே, இந்த செயல்முறைகளை தானியக்கமாக்க உதவும் தயாரிப்புகளைத் தேர்ந்தெடுக்கத் தொடங்குவீர்கள்.
துரதிர்ஷ்டவசமாக, இது தலைகீழாக நடப்பதை நான் அடிக்கடி பார்க்கிறேன். யாராவது "DevOps" என்ற வார்த்தையைக் கேட்டவுடன், அவர்கள் உடனடியாக ஜென்கின்ஸ் நிறுவ பரிந்துரைக்கிறார்கள், ஏனென்றால் அவர்கள் ஜென்கின்ஸ் நிறுவியவுடன், அவர்களுக்கு DevOps இருக்கும் என்று அவர்கள் நம்புகிறார்கள். அவர்கள் Jenkins ஐ நிறுவி, Jenkins இணையதளத்தில் "How to" கட்டுரைகளைப் படித்து, இந்த How to கட்டுரைகளில் செயல்முறைகளை திணிக்க முயற்சித்தார்கள், பின்னர் மக்களிடம் வந்து மக்களை வளைத்து, நீங்கள் இதை இப்படி செய்ய வேண்டும் என்று புத்தகம் கூறுகிறது, எனவே நாங்கள் அதை இந்த வழியில் செய்கிறோம்.
ஜென்கின்ஸ் ஒரு மோசமான கருவி என்பதல்ல. நான் அதை எந்த வகையிலும் சொல்ல விரும்பவில்லை. ஆனால் இது தயாரிப்புகளில் ஒன்றாகும். நீங்கள் எந்த தயாரிப்பைப் பயன்படுத்துகிறீர்கள் என்பது உங்கள் கடைசி முடிவாக இருக்க வேண்டும், எந்த வகையிலும் உங்கள் முதல் முடிவாக இருக்கக்கூடாது. உங்கள் தயாரிப்பு கலாச்சாரம் மற்றும் அணுகுமுறைகளை செயல்படுத்துவதன் மூலம் இயக்கப்படக்கூடாது. இதைப் புரிந்துகொள்வது மிகவும் முக்கியம், அதனால்தான் நான் இந்த ஸ்லைடில் அதிக நேரம் செலவழித்து இவ்வளவு நேரம் இதையெல்லாம் விளக்குகிறேன்.
பொதுவாக DevOps நடைமுறைகளைப் பற்றி பேசலாம். அவை என்ன? என்ன வேறுபாடு உள்ளது? அவற்றை எப்படி முயற்சி செய்வது? அவை ஏன் முக்கியம்?
நீங்கள் கேள்விப்பட்ட முதல் நடைமுறையானது தொடர்ச்சியான ஒருங்கிணைப்பு என்று அழைக்கப்படுகிறது. ஒருவேளை திட்டத்தில் யாரோ ஒருவருக்கு தொடர்ச்சியான ஒருங்கிணைப்பு (CI) இருக்கலாம்.
மிகப் பெரிய பிரச்சனை என்னவென்றால், நான் ஒருவரிடம் அடிக்கடி கேட்கும்போது: "உங்களிடம் திட்டத்தில் CI இருக்கிறதா?" மேலும் அவர் கூறுகிறார்: "ஆம்," பின்னர் அவர் என்ன செய்கிறார் என்று நான் கேட்கும்போது, அவர் எனக்கு முழு ஆட்டோமேஷன் செயல்முறையையும் விவரிக்கிறார். இது முற்றிலும் உண்மையல்ல.
உண்மையில், CI இன் நடைமுறையானது வெவ்வேறு நபர்கள் எழுதும் குறியீட்டை ஒருவித ஒற்றைக் குறியீட்டுத் தளத்தில் ஒருங்கிணைப்பதை நோக்கமாகக் கொண்டது. அவ்வளவுதான்.
CI உடன், தொடர்ச்சியான வரிசைப்படுத்தல், வெளியீட்டு மேலாண்மை போன்ற பிற நடைமுறைகள் வழக்கமாக உள்ளன, ஆனால் அதைப் பற்றி பின்னர் பேசுவோம்.
வெவ்வேறு நபர்கள் குறியீட்டை எழுதுகிறார்கள் மற்றும் இந்த குறியீடு தொடர்ந்து ஒரு குறியீட்டுத் தளத்தில் ஒருங்கிணைக்கப்பட வேண்டும் என்று CI தானே சொல்கிறது.
இது நமக்கு என்ன தருகிறது, அது ஏன் முக்கியமானது? எங்களிடம் டாட்நெட் இருந்தால், அது நல்லது, இது தொகுக்கப்பட்ட மொழி, எங்கள் விண்ணப்பத்தைத் தொகுக்கலாம். இது தொகுக்கப்பட்டால், இது ஏற்கனவே ஒரு நல்ல அறிகுறியாகும். இது இன்னும் எதையும் குறிக்கவில்லை, ஆனால் நாம் குறைந்தபட்சம் தொகுக்க முடியும் என்பதற்கான முதல் நல்ல அறிகுறி இது.
பின்னர் நாம் சில சோதனைகளை நடத்தலாம், அதுவும் ஒரு தனி நடைமுறை. சோதனைகள் அனைத்தும் பச்சை நிறத்தில் உள்ளன - இது இரண்டாவது நல்ல அறிகுறியாகும். ஆனால் மீண்டும், இது எதையும் குறிக்காது.
ஆனால் இதை ஏன் செய்ய வேண்டும்? இன்று நான் பேசும் அனைத்து நடைமுறைகளும் ஏறக்குறைய ஒரே மதிப்பைக் கொண்டுள்ளன, அதாவது தோராயமாக அதே நன்மைகள் மற்றும் தோராயமாக அதே வழியில் அளவிடப்படுகின்றன.
முதலில், இது விநியோகத்தை விரைவுபடுத்த உங்களை அனுமதிக்கிறது. விநியோகத்தை விரைவுபடுத்த இது எவ்வாறு உங்களை அனுமதிக்கிறது? நமது குறியீட்டு தளத்தில் சில புதிய மாற்றங்களைச் செய்யும்போது, உடனடியாக இந்தக் குறியீட்டைக் கொண்டு ஏதாவது செய்ய முயற்சி செய்யலாம். வியாழன் வரும் வரை நாங்கள் காத்திருக்க மாட்டோம், ஏனென்றால் வியாழன் அன்று நாங்கள் அதை QA சூழலுக்கு வெளியிடுகிறோம், நாங்கள் அதை இங்கேயும் இங்கேயும் செய்கிறோம்.
என் வாழ்க்கையிலிருந்து ஒரு சோகமான கதையைச் சொல்கிறேன். அது நீண்ட காலத்திற்கு முன்பு, நான் இன்னும் இளமையாகவும் அழகாகவும் இருந்தபோது. இப்போது நான் ஏற்கனவே இளமையாகவும், அழகாகவும், புத்திசாலியாகவும், அடக்கமாகவும் இருக்கிறேன். சில காலத்திற்கு முன்பு நான் ஒரு திட்டத்தில் இருந்தேன். எங்களிடம் சுமார் 30 டெவலப்பர்களைக் கொண்ட ஒரு பெரிய குழு இருந்தது. எங்களிடம் ஒரு பெரிய, பெரிய நிறுவனத் திட்டம் இருந்தது, அது சுமார் 10 ஆண்டுகளாக வளர்ந்தது. நாங்கள் வெவ்வேறு கிளைகளைக் கொண்டிருந்தோம். களஞ்சியத்தில் டெவலப்பர்கள் நடந்த ஒரு கிளை எங்களிடம் இருந்தது. உற்பத்தியில் உள்ள குறியீட்டின் பதிப்பைக் காண்பிக்கும் ஒரு கிளை இருந்தது.
உற்பத்திக் கிளை டெவலப்பர்களுக்குக் கிடைத்த கிளையை விட 3 மாதங்கள் பின்தங்கியிருந்தது. இதன் பொருள் என்ன? இதன் பொருள், டெவலப்பர்களின் தவறு காரணமாக எங்காவது ஒரு பிழை ஏற்பட்டவுடன், அவர்கள் அதை அனுமதித்ததால், மற்றும் QA இன் தவறு காரணமாக, அவர்கள் அதைப் பார்த்ததால், இதன் பொருள் நான் ஒரு பெறினால் உற்பத்திக்கான ஹாட்ஃபிக்ஸ் பணி, பின்னர் 3 மாதங்களுக்கு முன்பு எனது குறியீடு மாற்றங்களை நான் திரும்பப் பெற வேண்டும். 3 மாதங்களுக்கு முன்பு என்னிடம் இருந்ததை நினைவில் வைத்துக் கொண்டு அதை சரிசெய்ய முயற்சிக்க வேண்டும்.
உங்களுக்கு இதுவரை இந்த அனுபவம் இல்லை என்றால், உங்கள் வீட்டு திட்டத்தில் இதை முயற்சி செய்யலாம். முக்கிய விஷயம் என்னவென்றால், அதை வணிக ரீதியாக முயற்சிக்க வேண்டாம். இரண்டு கோடுகளின் குறியீட்டை எழுதவும், ஆறு மாதங்களுக்கு அவற்றை மறந்துவிடவும், பின்னர் திரும்பி வந்து, அந்தக் குறியீட்டின் வரிகள் எதைப் பற்றியது மற்றும் அவற்றை எவ்வாறு சரிசெய்யலாம் அல்லது மேம்படுத்தலாம் என்பதை விரைவாக விளக்க முயற்சிக்கவும். இது மிக மிக அற்புதமான அனுபவம்.
எங்களிடம் தொடர்ச்சியான ஒருங்கிணைப்பு நடைமுறை இருந்தால், நான் எனது குறியீட்டை எழுதியவுடன், இங்கே மற்றும் இப்போதே பல தானியங்கி கருவிகள் மூலம் அதைச் சரிபார்க்க இது அனுமதிக்கிறது. இது எனக்கு முழுப் படத்தையும் தராமல் போகலாம், இருப்பினும், குறைந்தபட்சம் சில அபாயங்களை இது நீக்கும். ஏதேனும் சாத்தியமான பிழை இருந்தால், அதைப் பற்றி இப்போது நான் அறிவேன், அதாவது இரண்டு நிமிடங்களில். நான் 3 மாதங்கள் பின்வாங்க வேண்டியதில்லை. நான் 2 நிமிடங்கள் மட்டுமே திரும்ப வேண்டும். ஒரு நல்ல காபி இயந்திரத்திற்கு 2 நிமிடங்களில் காபி காய்ச்சுவதற்கு நேரம் இருக்காது, அதனால் அது மிகவும் அருமையாக இருக்கிறது.
இது ஒவ்வொரு திட்டத்திலும் அவ்வப்போது மீண்டும் மீண்டும் செய்யக்கூடிய மதிப்பைக் கொண்டுள்ளது, அதாவது. நீங்கள் அமைத்தது மட்டும் அல்ல. நீங்கள் நடைமுறையை மீண்டும் செய்யலாம் மற்றும் திட்டத்தில் நீங்கள் செய்யும் ஒவ்வொரு புதிய மாற்றத்திற்கும் CI மீண்டும் மீண்டும் செய்யப்படும். உங்கள் குழு மிகவும் திறமையாக செயல்படுவதால், வளங்களை மேம்படுத்த இது உங்களை அனுமதிக்கிறது. 3 மாதங்களுக்கு முன்பு நீங்கள் பணிபுரிந்த குறியீட்டில் இருந்து பிழை வரும் சூழ்நிலை இனி உங்களுக்கு இருக்காது. நீங்கள் உட்கார்ந்து, முதல் இரண்டு மணிநேரங்களைச் செலவழித்து, பிறகு என்ன நடந்தது என்பதைப் புரிந்துகொண்டு, எதையாவது சரிசெய்யத் தொடங்கும் முன் சூழலின் சாராம்சத்தைப் பெற முயற்சிக்கும் போது, உங்களுக்கு சூழல் மாறுதல் இருக்காது.
இந்த நடைமுறையின் வெற்றி தோல்வியை எப்படி அளவிடுவது? CI திட்டத்தில் நாங்கள் செயல்படுத்தியதை நீங்கள் பெரிய முதலாளியிடம் புகாரளித்தால், அவர் ப்ளா ப்ளா ப்ளா என்று கேட்கிறார். நாங்கள் அதை செயல்படுத்தினோம், சரி, ஆனால் ஏன், அது நமக்கு என்ன கொண்டு வந்தது, அதை எவ்வாறு அளவிடுகிறோம், எவ்வளவு சரியாக அல்லது தவறாக செயல்படுத்துகிறோம்?
முதலாவதாக, CI க்கு நன்றி, நாம் மேலும் மேலும் அடிக்கடி வரிசைப்படுத்தலாம், மேலும் துல்லியமாக எங்கள் குறியீடு மிகவும் நிலையானதாக இருப்பதால். அதே வழியில், ஒரு பிழையைக் கண்டுபிடிப்பதற்கான நேரம் குறைக்கப்படுகிறது, மேலும் இந்த பிழையை சரிசெய்வதற்கான நேரம் குறைகிறது, ஏனெனில் கணினியில் இருந்து இங்கேயும் இப்போதும் ஒரு பதிலைப் பெறுகிறோம், எங்கள் குறியீட்டில் என்ன தவறு.
எங்களிடம் உள்ள மற்றொரு நடைமுறை ஆட்டோமேஷன் டெஸ்டிங் நடைமுறையாகும், இது பெரும்பாலும் CI நடைமுறையுடன் வருகிறது. அவை கைகோர்த்து செல்கின்றன.
இங்கே புரிந்து கொள்ள வேண்டியது என்ன? எங்கள் சோதனைகள் வேறுபட்டவை என்பதைப் புரிந்துகொள்வது அவசியம். ஒவ்வொரு தானியங்கு சோதனையும் அதன் சொந்த சிக்கல்களைத் தீர்ப்பதை நோக்கமாகக் கொண்டுள்ளது. எங்களிடம், எடுத்துக்காட்டாக, ஒரு தொகுதியை தனித்தனியாக சோதிக்க அனுமதிக்கும் அலகு சோதனைகள் உள்ளன, அதாவது. வெற்றிடத்தில் இது எப்படி வேலை செய்கிறது? இது நன்றாக இருக்கிறது.
எங்களிடம் ஒருங்கிணைப்பு சோதனைகள் உள்ளன, அவை வெவ்வேறு தொகுதிகள் ஒருவருக்கொருவர் எவ்வாறு ஒருங்கிணைகின்றன என்பதைப் புரிந்துகொள்ள அனுமதிக்கிறது. அதுவும் நல்லது.
எங்களிடம் UI ஆட்டோமேஷன் சோதனைகள் இருக்கலாம், இது UI உடனான பணி வாடிக்கையாளர் நிர்ணயித்த சில தேவைகளை எவ்வளவு சிறப்பாக பூர்த்தி செய்கிறது என்பதைச் சரிபார்க்க அனுமதிக்கிறது.
நீங்கள் நடத்தும் குறிப்பிட்ட சோதனைகள், அவற்றை எவ்வளவு அடிக்கடி இயக்குகிறீர்கள் என்பதைப் பாதிக்கலாம். அலகுத் தேர்வுகள் பொதுவாக சிறியதாகவும் சிறியதாகவும் எழுதப்படும். மேலும் அவை தொடர்ந்து ஏவப்படலாம்.
UI ஆட்டோமேஷன் சோதனைகளைப் பற்றி நாங்கள் பேசுகிறோம் என்றால், உங்கள் திட்டம் சிறியதாக இருந்தால் நல்லது. உங்கள் UI ஆட்டோமேஷன் சோதனைகள் சில போதுமான நேரத்தை எடுக்கலாம். ஆனால் பொதுவாக UI ஆட்டோமேஷன் சோதனை என்பது ஒரு பெரிய திட்டத்தில் பல மணிநேரம் எடுக்கும். மேலும் சில மணிநேரங்கள் இருந்தால் நல்லது. ஒரே விஷயம் என்னவென்றால், ஒவ்வொரு கட்டத்திற்கும் அவற்றை இயக்குவதில் எந்த அர்த்தமும் இல்லை. இரவில் அவற்றை இயக்குவது அர்த்தமுள்ளதாக இருக்கிறது. எல்லோரும் காலையில் வேலைக்கு வந்தபோது: சோதனையாளர்கள் மற்றும் டெவலப்பர்கள் இருவரும், நாங்கள் இரவில் UI தானியங்கு சோதனையை நடத்தி இந்த முடிவுகளைப் பெற்றோம் என்று சில வகையான அறிக்கைகளைப் பெற்றனர். இங்கே, உங்கள் தயாரிப்பு சில தேவைகளைப் பூர்த்திசெய்கிறதா என்பதைச் சரிபார்க்கும் ஒரு சேவையகத்தின் ஒரு மணிநேர வேலை, அதே QA பொறியாளரின் ஒரு மணிநேர வேலையை விட மிகவும் மலிவானதாக இருக்கும், அவர் உணவுக்காகவும் நன்றிக்காகவும் பணிபுரியும் ஜூனியர் QA இன்ஜினியராக இருந்தாலும் கூட. அதே போல், ஒரு மணிநேர இயந்திர செயல்பாடு மலிவானதாக இருக்கும். அதனால்தான் அதில் முதலீடு செய்வது அர்த்தமுள்ளதாக இருக்கிறது.
நான் வேலை செய்து கொண்டிருக்கும் மற்றொரு திட்டம் உள்ளது. இந்த திட்டத்தில் நாங்கள் இரண்டு வாரங்கள் ஸ்பிரிண்ட் செய்தோம். திட்டம் பெரியது, நிதித் துறைக்கு முக்கியமானது, தவறு செய்ய முடியாது. இரண்டு வார ஸ்பிரிண்டிற்குப் பிறகு, வளர்ச்சி சுழற்சியை ஒரு சோதனை செயல்முறை பின்பற்றியது, இது மேலும் 4 வாரங்கள் எடுத்தது. சோகத்தின் அளவை கற்பனை செய்து பாருங்கள். நாங்கள் இரண்டு வாரங்களுக்கு குறியீட்டை எழுதுகிறோம், பின்னர் அதை அலா கோட்ஃப்ரீஸ் செய்கிறோம், அதை பயன்பாட்டின் புதிய பதிப்பில் தொகுத்து, சோதனையாளர்களுக்கு அனுப்புகிறோம். சோதனையாளர்கள் அதை மற்றொரு 4 வாரங்களுக்கு சோதிக்கிறார்கள், அதாவது. அவர்கள் அதைச் சோதித்துக்கொண்டிருக்கும்போது, அவர்களுக்காக இன்னும் இரண்டு பதிப்புகளைத் தயாரிக்க எங்களுக்கு நேரம் இருக்கிறது. இது மிகவும் சோகமான வழக்கு.
நீங்கள் அதிக உற்பத்தி செய்ய விரும்பினால், தானியங்கு சோதனை நடைமுறைகளை நீங்கள் செயல்படுத்துவது அர்த்தமுள்ளதாக இருக்கும் என்று நாங்கள் அவர்களிடம் கூறினோம், ஏனெனில் இதுவே இப்போது உங்களை காயப்படுத்துகிறது.
தொடர்ச்சியான வரிசைப்படுத்தலைப் பயிற்சி செய்யுங்கள். அருமை, நீங்கள் கட்டி முடித்துவிட்டீர்கள். இது ஏற்கனவே நல்லது. உங்கள் குறியீடு தொகுக்கப்பட்டது. இப்போது இந்த கட்டமைப்பை சில சூழலில் பயன்படுத்தினால் நன்றாக இருக்கும். டெவலப்பர்களுக்கான சூழலில் சொல்லலாம்.
அது ஏன் முக்கியம்? முதலில், வரிசைப்படுத்தல் செயல்முறையில் நீங்கள் எவ்வளவு வெற்றிகரமாக இருக்கிறீர்கள் என்பதைப் பார்க்கலாம். இது போன்ற திட்டங்களை நான் சந்தித்திருக்கிறேன், நான் கேட்கும் போது: “அப்ளிகேஷனின் புதிய பதிப்பை எவ்வாறு வரிசைப்படுத்துவது?”, தோழர்கள் என்னிடம் சொல்கிறார்கள்: “நாங்கள் அதைச் சேகரித்து ஒரு ஜிப் காப்பகத்தில் பேக் செய்கிறோம். நாங்கள் அதை நிர்வாகிக்கு அஞ்சல் மூலம் அனுப்புகிறோம். நிர்வாகி இந்த காப்பகத்தை பதிவிறக்கம் செய்து விரிவுபடுத்துகிறார். சர்வர் புதிய பதிப்பை எடுக்க வேண்டும் என்று முழு அலுவலகமும் பிரார்த்தனை செய்யத் தொடங்குகிறது.
எளிமையான ஒன்றைத் தொடங்குவோம். உதாரணமாக, அவர்கள் காப்பகத்தில் CSS ஐ வைக்க மறந்துவிட்டார்கள் அல்லது ஜாவா-ஸ்கிரிப்ட் கோப்பு பெயரில் ஹேஷ்டேக்கை மாற்ற மறந்துவிட்டார்கள். மேலும் நாம் சர்வரில் கோரிக்கை வைக்கும் போது, உலாவி தன்னிடம் ஏற்கனவே இந்த ஜாவா-ஸ்கிரிப்ட் கோப்பு இருப்பதாக நினைத்து, அதைப் பதிவிறக்க வேண்டாம் என்று முடிவு செய்கிறது. ஒரு பழைய பதிப்பு இருந்தது, ஏதோ காணவில்லை. பொதுவாக, பல சிக்கல்கள் இருக்கலாம். எனவே, தொடர்ச்சியான வரிசைப்படுத்தல் நடைமுறையானது, நீங்கள் ஒரு சுத்தமான குறிப்புப் படத்தை எடுத்து முற்றிலும் சுத்தமான புதிய சூழலில் பதிவேற்றினால் என்ன நடக்கும் என்பதைச் சோதிக்க உங்களை அனுமதிக்கிறது. இது எங்கு செல்கிறது என்பதை நீங்கள் பார்க்கலாம்.
மேலும், நீங்கள் ஒருவருக்கொருவர் குறியீட்டை ஒருங்கிணைக்கும்போது, அதாவது. கட்டளைக்கு இடையில், இது UI இல் எப்படி இருக்கிறது என்பதைப் பார்க்கவும் இது உங்களை அனுமதிக்கிறது.
அதிக வெண்ணிலா ஜாவா-ஸ்கிரிப்ட் பயன்படுத்தப்படும் போது ஏற்படும் பிரச்சனைகளில் ஒன்று, இரண்டு டெவலப்பர்கள் ஒரே பெயரில் ஒரு மாறியை விண்டோ ஆப்ஜெக்ட்டில் திடீரென அறிவித்தனர். பின்னர், உங்கள் அதிர்ஷ்டத்தைப் பொறுத்து. யாருடைய ஜாவா-ஸ்கிரிப்ட் கோப்பு இரண்டாவதாக வெளியே இழுக்கப்படுகிறதோ, மற்றவற்றின் மாற்றங்களை மேலெழுதும். மிகவும் உற்சாகமாகவும் இருக்கிறது. நீங்கள் உள்ளே வாருங்கள்: ஒன்று ஒருவருக்கு வேலை செய்கிறது, மற்றொன்று மற்றொருவருக்கு வேலை செய்யாது. இது அனைத்தும் உற்பத்தியில் வெளிவரும்போது அது "அற்புதம்".
எங்களிடம் உள்ள அடுத்த நடைமுறையானது தானியங்கி மீட்டெடுப்பின் நடைமுறையாகும், அதாவது பயன்பாட்டின் முந்தைய பதிப்பிற்கு திரும்பும்.
டெவலப்பர்களுக்கு இது ஏன் முக்கியமானது? கணினிகள் பெரியதாகவும், நிரல்கள் சிறியதாகவும் இருந்த தொலைதூர, தொலைதூர 90 களை நினைவில் வைத்திருப்பவர்கள் இன்னும் இருக்கிறார்கள். மேலும் இணைய வளர்ச்சிக்கான ஒரே வழி PHP மூலம் தான். PHP ஒரு மோசமான மொழி என்று இல்லை, அது இருந்தாலும்.
ஆனால் பிரச்சனை வேறு விதமாக இருந்தது. எங்கள் php தளத்தின் புதிய பதிப்பை நாங்கள் பயன்படுத்தியபோது, அதை எவ்வாறு பயன்படுத்தினோம்? பெரும்பாலும் நாங்கள் ஃபார் மேனேஜர் அல்லது வேறு ஏதாவது ஒன்றைத் திறந்தோம். இந்த கோப்புகளை FTP க்கு பதிவேற்றியது. எங்களிடம் சில சிறிய, சிறிய பிழைகள் இருப்பதை நாங்கள் திடீரென்று உணர்ந்தோம், எடுத்துக்காட்டாக, அரைப்புள்ளியை வைக்க மறந்துவிட்டோம் அல்லது தரவுத்தளத்திற்கான கடவுச்சொல்லை மாற்ற மறந்துவிட்டோம், மேலும் தரவுத்தளத்திற்கான கடவுச்சொல் உள்ளது, இது உள்ளூர் ஹோஸ்டில் உள்ளது. FTP உடன் விரைவாக இணைக்கவும், கோப்புகளை அங்கேயே திருத்தவும் நாங்கள் முடிவு செய்கிறோம். இது வெறும் நெருப்பு! இது 90களில் பிரபலமாக இருந்தது.
ஆனால், நீங்கள் காலெண்டரைப் பார்க்கவில்லை என்றால், 90 கள் கிட்டத்தட்ட 30 ஆண்டுகளுக்கு முன்பு. இப்போது எல்லாம் கொஞ்சம் வித்தியாசமாக நடக்கிறது. அவர்கள் உங்களிடம் கூறும்போது சோகத்தின் அளவை கற்பனை செய்து பாருங்கள்: "நாங்கள் உற்பத்திக்கு அனுப்பினோம், ஆனால் அங்கு ஏதோ தவறு ஏற்பட்டது. உங்கள் FTP உள்நுழைவு மற்றும் கடவுச்சொல் இதோ, உற்பத்தியுடன் இணைத்து, அதை விரைவாக அங்கேயே சரிசெய்யவும். நீங்கள் சக் நோரிஸ் என்றால், இது வேலை செய்யும். இல்லையெனில், நீங்கள் ஒரு பிழையை சரிசெய்தால், நீங்கள் இன்னும் 10 பிழைகளை உருவாக்கும் அபாயம் உள்ளது. அதனால்தான் முந்தைய பதிப்பிற்கு திரும்பும் இந்த நடைமுறையில் நீங்கள் நிறைய சாதிக்க முடியும்.
ஏதாவது கெட்டது எப்படியாவது எங்காவது விளைந்தாலும், அது மோசமானது, ஆனால் ஆபத்தானது அல்ல. உங்களிடம் உள்ள முந்தைய பதிப்பிற்கு நீங்கள் திரும்பலாம். அந்த சொற்களஞ்சியத்தில் அதை உணர எளிதாக இருந்தால், அதை காப்புப்பிரதி என்று அழைக்கவும். நீங்கள் இந்த முந்தைய பதிப்பிற்கு திரும்பலாம், மேலும் பயனர்கள் உங்கள் தயாரிப்பில் வேலை செய்ய முடியும், மேலும் உங்களுக்கு போதுமான இடையக நேரம் இருக்கும். நீங்கள் அமைதியாக, அவசரப்படாமல், இதையெல்லாம் எடுத்து உள்நாட்டில் சோதித்து, சரிசெய்து, பின்னர் புதிய பதிப்பைப் பதிவேற்றலாம். இதைச் செய்வது உண்மையில் அர்த்தமுள்ளதாக இருக்கிறது.
இப்போது எப்படியாவது முந்தைய இரண்டு நடைமுறைகளையும் ஒன்றாக இணைக்க முயற்சிப்போம். ரிலீஸ் மேனேஜ்மென்ட் எனப்படும் மூன்றாவது ஒன்றைப் பெறுவோம்.
தொடர்ச்சியான வரிசைப்படுத்தல் பற்றி அதன் கிளாசிக்கல் வடிவத்தில் பேசும்போது, தொகுப்பிலிருந்து சில கிளைகளிலிருந்து குறியீட்டை இழுத்து, அதைத் தொகுத்து அதை வரிசைப்படுத்த வேண்டும் என்று கூறுகிறோம். அதே சூழல் நமக்கும் இருந்தால் நல்லது. எங்களிடம் பல சூழல்கள் இருந்தால், ஒவ்வொரு முறையும் ஒரே உறுதிப்பாட்டில் இருந்து குறியீட்டை இழுக்க வேண்டும் என்பதே இதன் பொருள். ஒவ்வொரு முறையும் அதை வெளியே இழுப்போம், ஒவ்வொரு முறையும் கட்டுவோம், புதிய சூழலுக்குப் பயன்படுத்துவோம். முதலாவதாக, இது நேரம், ஏனென்றால் ஒரு திட்டத்தை உருவாக்க, உங்களிடம் பெரியது மற்றும் 90 களில் இருந்து வந்திருந்தால், அதற்கு பல மணிநேரம் ஆகலாம்.
தவிர, இன்னொரு சோகமும் இருக்கிறது. நீங்கள் உருவாக்கும்போது, அதே இயந்திரத்தில் கூட, நீங்கள் அதே ஆதாரங்களை உருவாக்குவீர்கள், இந்த இயந்திரம் கடைசி கட்டத்தின் போது இருந்த அதே நிலையில் உள்ளது என்பதற்கு உங்களுக்கு இன்னும் உத்தரவாதம் இல்லை.
யாரோ ஒருவர் வந்து உங்களுக்காக டாட்நெட்டைப் புதுப்பித்ததாக வைத்துக்கொள்வோம் அல்லது அதற்கு மாறாக, யாரோ எதையாவது நீக்க முடிவு செய்தனர். இரண்டு வாரங்களுக்கு முன்பு இந்த கமிட்டிலிருந்து நாங்கள் ஒரு கட்டத்தை உருவாக்கிக்கொண்டிருந்தோம், எல்லாம் நன்றாக இருந்தது, ஆனால் இப்போது அதே இயந்திரம், அதே கமிட், அதே குறியீடு, நாங்கள் உருவாக்க முயற்சிக்கும் அதே குறியீடு போல் தெரிகிறது, ஆனால் அது வேலை செய்யவில்லை. . நீங்கள் இதை நீண்ட காலமாக கையாள்வீர்கள், அதை நீங்கள் கண்டுபிடிப்பீர்கள் என்பது உண்மையல்ல. குறைந்தபட்சம், நீங்கள் உங்கள் நரம்புகளை மிகவும் கெடுத்துவிடுவீர்கள்.
எனவே, கலைப்பொருள் களஞ்சியம் அல்லது கேலரி அல்லது நூலகம் எனப்படும் கூடுதல் சுருக்கத்தை அறிமுகப்படுத்த வெளியீட்டு மேலாண்மை நடைமுறை பரிந்துரைக்கிறது. நீங்கள் என்ன வேண்டுமானாலும் அழைக்கலாம்.
முக்கிய யோசனை என்னவென்றால், நாங்கள் எங்கள் வெவ்வேறு சூழல்களுக்கு வரிசைப்படுத்தத் தயாராக உள்ள ஒரு கிளையில் ஏதேனும் ஒரு வகையான அர்ப்பணிப்பு இருந்தால், இந்த கமிட் மற்றும் இந்த பயன்பாட்டிற்கு தேவையான அனைத்தையும் நாங்கள் சேகரிக்கிறோம், நாங்கள் அதை பேக் செய்கிறோம். ஒரு ஜிப் காப்பகத்தில் அதை சில நம்பகமான சேமிப்பகத்தில் சேமிக்கவும். இந்த சேமிப்பகத்திலிருந்து எந்த நேரத்திலும் இந்த ஜிப் காப்பகத்தைப் பெறலாம்.
பின்னர் அதை எடுத்து தானாகவே தேவ் சூழலுக்கு வரிசைப்படுத்துவோம். நாங்கள் அங்கு ஓடுகிறோம், எல்லாம் நன்றாக இருந்தால், நாங்கள் மேடைக்கு அனுப்புகிறோம். எல்லாம் நன்றாக இருந்தால், அதே காப்பகத்தை உற்பத்திக்கு பயன்படுத்துவோம், அதே பைனரிகள், சரியாக ஒரு முறை தொகுக்கப்படும்.
கூடுதலாக, எங்களிடம் இதுபோன்ற கேலரி இருக்கும்போது, முந்தைய பதிப்பிற்கு திரும்பப் பெறுவது பற்றி நாங்கள் பேசியபோது கடைசி ஸ்லைடில் நாங்கள் உரையாற்றிய அபாயங்களையும் இது எங்களுக்கு உதவுகிறது. நீங்கள் தற்செயலாக ஏதேனும் தவறாகப் பயன்படுத்தினால், இந்த கேலரியில் இருந்து வேறு ஏதேனும் முந்தைய பதிப்பை நீங்கள் எப்பொழுதும் எடுத்து, அதே வழியில் இந்தச் சூழல்களில் பயன்படுத்திக்கொள்ளலாம். ஏதேனும் தவறு நடந்தால், முந்தைய பதிப்பிற்கு எளிதாகச் செல்ல இது உங்களை அனுமதிக்கிறது.
மற்றொரு சிறந்த நடைமுறை உள்ளது. எங்கள் பயன்பாடுகளை முந்தைய பதிப்பிற்கு திரும்பப் பெறும்போது, முந்தைய பதிப்பின் உள்கட்டமைப்பும் நமக்குத் தேவை என்பதை இது குறிக்கலாம் என்பதை நீங்களும் நானும் அனைவரும் புரிந்துகொள்கிறோம்.
மெய்நிகர் உள்கட்டமைப்பு பற்றி நாம் பேசும்போது, இது நிர்வாகிகளால் அமைக்கப்பட்ட ஒன்று என்று பலர் நினைக்கிறார்கள். உங்கள் பயன்பாட்டின் புதிய பதிப்பைச் சோதிக்க விரும்பும் புதிய சேவையகத்தைப் பெற உங்களுக்குத் தேவைப்பட்டால், நீங்கள் நிர்வாகிகள் அல்லது டெவொப்களுக்கு ஒரு டிக்கெட்டை எழுத வேண்டும். இதற்கு டெவொப்ஸ் 3 வாரங்கள் எடுக்கும். 3 வாரங்களுக்குப் பிறகு, நாங்கள் உங்களுக்காக ஒரு மெய்நிகர் இயந்திரத்தை நிறுவியுள்ளோம், ஒரு கோர், இரண்டு ஜிகாபைட் ரேம் மற்றும் டாட்நெட் இல்லாத விண்டோஸ் சர்வர் ஆகியவற்றைக் கூறுவார்கள். நீங்கள் சொல்கிறீர்கள்: "ஆனால் எனக்கு டாட்நெட் தேவை." அவர்கள்: "சரி, 3 வாரங்களில் திரும்பி வாருங்கள்."
உள்கட்டமைப்பை குறியீடு நடைமுறைகளாகப் பயன்படுத்துவதன் மூலம், உங்கள் மெய்நிகர் உள்கட்டமைப்பை மற்றொரு ஆதாரமாகக் கருதலாம்.
ஒருவேளை, உங்களில் யாராவது டாட்நெட்டில் அப்ளிகேஷன்களை உருவாக்கினால், என்டிட்டி ஃபிரேம்வொர்க் என்ற நூலகத்தைப் பற்றி நீங்கள் கேள்விப்பட்டிருக்கலாம். மைக்ரோசாப்ட் தீவிரமாக முன்வைக்கும் அணுகுமுறைகளில் என்டிட்டி ஃபிரேம்வொர்க் ஒன்று என்று நீங்கள் கேள்விப்பட்டிருக்கலாம். தரவுத்தளத்துடன் பணிபுரிய, இது கோட் ஃபர்ஸ்ட் எனப்படும் அணுகுமுறை. உங்கள் தரவுத்தளம் எப்படி இருக்க வேண்டும் என்பதை குறியீட்டில் விவரிக்கும் போது இது நடக்கும். பின்னர் நீங்கள் பயன்பாட்டை வரிசைப்படுத்துங்கள். இது தரவுத்தளத்துடன் இணைக்கிறது, எந்த அட்டவணைகள் உள்ளன மற்றும் எந்த அட்டவணைகள் இல்லை என்பதை அது தானே தீர்மானிக்கிறது, மேலும் உங்களுக்கு தேவையான அனைத்தையும் உருவாக்குகிறது.
உங்கள் உள்கட்டமைப்பிலும் நீங்கள் அதையே செய்யலாம். ஒரு திட்டத்திற்கு உங்களுக்கு தரவுத்தளம் தேவையா அல்லது ஒரு திட்டத்திற்கு விண்டோஸ் சர்வர் தேவையா என்பதில் எந்த வித்தியாசமும் இல்லை. இது ஒரு ஆதாரம் மட்டுமே. இந்த வளத்தை உருவாக்குவதை நீங்கள் தானியங்குபடுத்தலாம், இந்த வளத்தின் உள்ளமைவை தானியக்கமாக்கலாம். அதன்படி, ஒவ்வொரு முறையும் நீங்கள் சில புதிய கருத்தை, சில புதிய அணுகுமுறைகளை சோதிக்க விரும்பினால், நீங்கள் டெவொப்களுக்கு டிக்கெட் எழுத வேண்டிய அவசியமில்லை, ஆயத்த வார்ப்புருக்கள், ஆயத்த ஸ்கிரிப்ட்கள் ஆகியவற்றிலிருந்து உங்களுக்காக தனிமைப்படுத்தப்பட்ட உள்கட்டமைப்பை வரிசைப்படுத்தலாம். உங்கள் எல்லா சோதனைகளும் உள்ளன. நீங்கள் இதை நீக்கலாம், சில முடிவுகளைப் பெறலாம் மற்றும் அதைப் பற்றி மேலும் புகாரளிக்கலாம்.
அடுத்த நடைமுறை, இதுவும் உள்ளது மற்றும் முக்கியமானது, ஆனால் சிலர் பயன்படுத்தும் பயன்பாடு செயல்திறன் கண்காணிப்பு ஆகும்.
அப்ளிகேஷன் பெர்ஃபார்மென்ஸ் மானிட்டரிங் பற்றி ஒரே ஒரு விஷயத்தை மட்டும் சொல்ல விரும்பினேன். இந்த நடைமுறையில் மிக முக்கியமானது என்ன? அப்ளிகேஷன் பெர்ஃபார்மென்ஸ் மானிட்டரிங் என்பது அடுக்குமாடி குடியிருப்பை சரிசெய்வதற்கு சமம். இது ஒரு இறுதி நிலை அல்ல, இது ஒரு செயல்முறை. நீங்கள் அதை தொடர்ந்து செய்ய வேண்டும்.
ஒரு நல்ல வழியில், கிட்டத்தட்ட ஒவ்வொரு கட்டமைப்பிலும் பயன்பாட்டு செயல்திறன் கண்காணிப்பை மேற்கொள்வது நல்லது, இருப்பினும், நீங்கள் புரிந்து கொண்டபடி, இது எப்போதும் சாத்தியமில்லை. ஆனால், குறைந்தபட்சம், ஒவ்வொரு வெளியீட்டிற்கும் இது மேற்கொள்ளப்பட வேண்டும்.
அது ஏன் முக்கியம்? ஏனெனில் நீங்கள் திடீரென்று செயல்திறனில் வீழ்ச்சியை சந்தித்தால், ஏன் என்பதை நீங்கள் தெளிவாக புரிந்து கொள்ள வேண்டும். உங்கள் குழுவில் இரண்டு வார ஸ்பிரிண்ட்கள் இருந்தால், குறைந்தது இரண்டு வாரங்களுக்கு ஒரு முறையாவது உங்கள் விண்ணப்பத்தை ஏதேனும் ஒரு தனி சர்வரில் பயன்படுத்த வேண்டும், அங்கு உங்களிடம் தெளிவாக நிலையான செயலி, ரேம், வட்டுகள் போன்றவை உள்ளன. அதே செயல்திறன் சோதனைகளை இயக்கவும். . உங்களுக்கு பலன் கிடைக்கும். முந்தைய ஸ்பிரிண்டிலிருந்து இது எப்படி மாறிவிட்டது என்பதைப் பாருங்கள்.
டிராடவுன் எங்காவது கூர்மையாகக் குறைந்துவிட்டது என்பதை நீங்கள் கண்டறிந்தால், அது கடந்த இரண்டு வாரங்களில் ஏற்பட்ட மாற்றங்களால் தான் என்று அர்த்தம். இது சிக்கலை மிக விரைவாகக் கண்டறிந்து சரிசெய்ய உங்களை அனுமதிக்கும். மீண்டும், இவை தோராயமாக அதே அளவீடுகள் ஆகும், இதன் மூலம் நீங்கள் அதை எவ்வளவு வெற்றிகரமாக செய்தீர்கள் என்பதை அளவிட முடியும்.
எங்களிடம் உள்ள அடுத்த நடைமுறை கட்டமைப்பு மேலாண்மை பயிற்சி ஆகும். இதை சீரியஸாக எடுத்துக்கொள்வது வெகு சிலரே. ஆனால் என்னை நம்புங்கள், இது உண்மையில் மிகவும் தீவிரமான விஷயம்.
சமீபத்தில் ஒரு வேடிக்கையான கதை இருந்தது. தோழர்களே என்னிடம் வந்து சொன்னார்கள்: "எங்கள் விண்ணப்பத்தின் பாதுகாப்பு தணிக்கையை நடத்த எங்களுக்கு உதவுங்கள்." நாங்கள் நீண்ட காலமாக குறியீட்டை ஒன்றாகப் பார்த்தோம், அவர்கள் பயன்பாட்டைப் பற்றி என்னிடம் சொன்னார்கள், வரைபடங்களை வரைந்தனர். பிளஸ் அல்லது மைனஸ் எல்லாம் தர்க்கரீதியானது, புரிந்துகொள்ளக்கூடியது, பாதுகாப்பானது, ஆனால் ஒன்று இருந்தது ஆனால்! அவர்கள் தங்கள் மூலக் கட்டுப்பாட்டில் உள்ளமைவு கோப்புகளை வைத்திருந்தனர், இதில் ஐபி தரவுத்தளத்துடன் உற்பத்தி செய்யப்பட்டவை, இந்த தரவுத்தளங்களுடன் இணைப்பதற்கான உள்நுழைவுகள் மற்றும் கடவுச்சொற்கள் போன்றவை அடங்கும்.
நான் சொல்கிறேன்: “நண்பர்களே, சரி, நீங்கள் உங்கள் தயாரிப்பு சூழலை ஃபயர்வால் மூலம் மூடிவிட்டீர்கள், ஆனால் உற்பத்தி தரவுத்தளத்திற்கான உள்நுழைவு மற்றும் கடவுச்சொல்லை மூலக் கட்டுப்பாட்டிலேயே வைத்திருப்பது மற்றும் எந்த டெவலப்பரும் அதைப் படிக்க முடியும் என்பது ஏற்கனவே மிகப்பெரிய பாதுகாப்பு அபாயமாகும். . குறியீட்டுப் பார்வையில் உங்கள் பயன்பாடு எவ்வளவு பாதுகாப்பானதாக இருந்தாலும், அதை மூலக் கட்டுப்பாட்டில் விட்டால், நீங்கள் எங்கும் எந்த தணிக்கையிலும் தேர்ச்சி பெற மாட்டீர்கள். அதைபற்றிதான் பேசினேன்.
கட்டமைப்பு மேலாண்மை. வெவ்வேறு சூழல்களில் நாம் வெவ்வேறு கட்டமைப்புகளைக் கொண்டிருக்கலாம். எடுத்துக்காட்டாக, QA, டெமோ, உற்பத்தி சூழல் போன்றவற்றிற்கான தரவுத்தளங்களுக்கான வெவ்வேறு உள்நுழைவுகள் மற்றும் கடவுச்சொற்கள் எங்களிடம் இருக்கலாம்.
இந்த உள்ளமைவை தானியக்கமாகவும் செய்யலாம். இது எப்போதும் பயன்பாட்டிலிருந்து தனித்தனியாக இருக்க வேண்டும். ஏன்? நீங்கள் ஒரு முறை பயன்பாட்டை உருவாக்கியதால், நீங்கள் SQL சேவையகத்துடன் அத்தகைய மற்றும் அத்தகைய IP அல்லது அத்தகைய மற்றும் அத்தகைய IP வழியாக இணைக்கிறீர்களா என்பதை பயன்பாடு பொருட்படுத்தாது, அது ஒரே மாதிரியாக செயல்பட வேண்டும். எனவே, திடீரென்று உங்களில் ஒருவர் இன்னும் குறியீட்டில் உள்ள இணைப்பு சரத்தை ஹார்ட்கோடிங் செய்கிறார் என்றால், என்னுடன் அதே திட்டத்தில் நீங்கள் இருப்பதைக் கண்டால் நான் உங்களைக் கண்டுபிடித்து தண்டிப்பேன் என்பதை நினைவில் கொள்ளுங்கள். இது எப்போதும் ஒரு தனி கட்டமைப்பில் வைக்கப்படுகிறது, எடுத்துக்காட்டாக, web.config இல்.
இந்த உள்ளமைவு ஏற்கனவே தனித்தனியாக நிர்வகிக்கப்படுகிறது, அதாவது டெவலப்பரும் நிர்வாகியும் ஒரே அறையில் வந்து உட்காரக்கூடிய தருணம் இதுதான். மேலும் டெவலப்பர் இவ்வாறு கூறலாம்: “இதோ, எனது விண்ணப்பத்தின் பைனரிகள் உள்ளன. அவர்கள் வேலை செய்கிறார்கள். பயன்பாட்டிற்கு வேலை செய்ய ஒரு தரவுத்தளம் தேவை. இங்கே பைனரிகளுக்கு அடுத்ததாக ஒரு கோப்பு உள்ளது. இந்த கோப்பில், இந்த புலம் உள்நுழைவுக்கு பொறுப்பாகும், இது கடவுச்சொல்லுக்கானது, இது ஐபிக்கானது. எங்கு வேண்டுமானாலும் வரிசைப்படுத்துங்கள்." மேலும் இது நிர்வாகிக்கு எளிமையானது மற்றும் தெளிவானது. இந்த உள்ளமைவை நிர்வகிப்பதன் மூலம் அவர் உண்மையில் எங்கு வேண்டுமானாலும் பயன்படுத்த முடியும்.
நான் பேச விரும்பும் கடைசி நடைமுறை மேகங்களுடன் மிகவும் தொடர்புடையது. நீங்கள் கிளவுட்டில் வேலை செய்தால் அது அதிகபட்ச விளைவைக் கொண்டுவருகிறது. இது உங்கள் சூழலை தானாக அகற்றும்.
இந்த மாநாட்டில் நான் பணிபுரியும் குழுக்களில் இருந்து பலர் உள்ளனர் என்பது எனக்குத் தெரியும். நான் பணிபுரியும் அனைத்து குழுக்களுடனும், நாங்கள் இந்த நடைமுறையைப் பயன்படுத்துகிறோம்.
ஏன்? நிச்சயமாக, ஒவ்வொரு டெவலப்பருக்கும் 24/7 வேலை செய்யும் ஒரு மெய்நிகர் இயந்திரம் இருந்தால் நன்றாக இருக்கும். ஆனால் இது உங்களுக்கு செய்தியாக இருக்கலாம், ஒருவேளை நீங்கள் கவனம் செலுத்தவில்லை, ஆனால் டெவலப்பர் 24/7 வேலை செய்யவில்லை. ஒரு டெவலப்பர் பொதுவாக ஒரு நாளைக்கு 8 மணிநேரம் வேலை செய்கிறார். சீக்கிரம் வேலைக்கு வந்தாலும், ஜிம்முக்குச் செல்லும் போது பெரிய மதிய உணவு சாப்பிடுவார். டெவலப்பர் இந்த ஆதாரங்களைப் பயன்படுத்தும் போது ஒரு நாளைக்கு 12 மணிநேரம் இருக்கட்டும். எங்கள் சட்டத்தின்படி, வாரத்தில் 5 நாட்களில் 7 நாட்கள் வேலை நாட்களாகக் கருதப்படுகின்றன.
அதன்படி, வார நாட்களில் இந்த இயந்திரம் 24 மணிநேரம் வேலை செய்யக்கூடாது, ஆனால் 12 மணிநேரம் மட்டுமே வேலை செய்ய வேண்டும், வார இறுதி நாட்களில் இந்த இயந்திரம் வேலை செய்யக்கூடாது. எல்லாம் மிகவும் எளிமையானது என்று தோன்றுகிறது, ஆனால் இங்கே சொல்ல வேண்டியது என்ன? இந்த அடிப்படை அட்டவணையில் இந்த எளிய நடைமுறையைச் செயல்படுத்துவதன் மூலம், இந்த சூழல்களை பராமரிப்பதற்கான செலவை 70% குறைக்க இது உங்களை அனுமதிக்கிறது, அதாவது உங்கள் dev, QA, டெமோ, சூழலின் விலையை எடுத்து 3 ஆல் வகுத்தீர்கள்.
மீதி பணத்தை என்ன செய்வது என்பதுதான் கேள்வி. எடுத்துக்காட்டாக, டெவலப்பர்கள் ஏற்கனவே வாங்கவில்லை என்றால் ReSharper ஐ வாங்க வேண்டும். அல்லது ஒரு காக்டெய்ல் பார்ட்டி. தேவ் மற்றும் க்யூஏ ஆகிய இரண்டும் மேய்ந்த ஒரு சூழலை நீங்கள் முன்பு வைத்திருந்தால், அவ்வளவுதான், இப்போது நீங்கள் தனிமைப்படுத்தப்படும் 3 வெவ்வேறுவற்றை உருவாக்கலாம், மேலும் மக்கள் ஒருவருக்கொருவர் தலையிட மாட்டார்கள்.
தொடர்ச்சியான செயல்திறன் அளவீடு கொண்ட ஸ்லைடைப் பொறுத்தவரை, திட்டத்தில் தரவுத்தளத்தில் 1 பதிவுகள் இருந்தால், இரண்டு மாதங்களுக்குப் பிறகு ஒரு மில்லியன் இருந்தால் செயல்திறனை எவ்வாறு ஒப்பிடலாம்? செயல்திறன் அளவிடும் புள்ளி ஏன் மற்றும் என்ன என்பதைப் புரிந்துகொள்வது எப்படி?
இது ஒரு நல்ல கேள்வி, ஏனென்றால் நீங்கள் எப்போதும் அதே ஆதாரங்களில் செயல்திறனை அளவிட வேண்டும். அதாவது, நீங்கள் புதிய குறியீட்டை வெளியிடுகிறீர்கள், புதிய குறியீட்டில் செயல்திறனை அளவிடுகிறீர்கள். எடுத்துக்காட்டாக, நீங்கள் வெவ்வேறு செயல்திறன் காட்சிகளை சோதிக்க வேண்டும், 1 பயனர்கள் மற்றும் தரவுத்தள அளவு 000 ஜிகாபைட்கள் இருக்கும் இடத்தில், லேசான சுமையில் பயன்பாடு எவ்வாறு செயல்படுகிறது என்பதை நீங்கள் சோதிக்க விரும்புகிறீர்கள் என்று வைத்துக்கொள்வோம். நீங்கள் அதை அளந்து எண்களைப் பெற்றீர்கள். அடுத்து இன்னொரு காட்சியை எடுத்துக்கொள்வோம். எடுத்துக்காட்டாக, 5 பயனர்கள், தரவுத்தள அளவு 5 டெராபைட். நாங்கள் முடிவுகளைப் பெற்று அவற்றை நினைவில் வைத்தோம்.
இங்கே என்ன முக்கியம்? இங்கே முக்கியமான விஷயம் என்னவென்றால், சூழ்நிலை, தரவின் அளவு, ஒரே நேரத்தில் பயனர்களின் எண்ணிக்கை போன்றவற்றைப் பொறுத்து, நீங்கள் சில வரம்புகளுக்குள் செல்லலாம். எடுத்துக்காட்டாக, பிணைய அட்டையின் வரம்பு, அல்லது ஹார்ட் டிரைவின் வரம்பு அல்லது செயலி திறன்களின் வரம்பு. நீங்கள் புரிந்து கொள்ள வேண்டியது இதுதான். வெவ்வேறு சூழ்நிலைகளில் நீங்கள் குறிப்பிட்ட வரம்புகளுக்குள் செல்கிறீர்கள். நீங்கள் அவற்றை அடிக்கும்போது எண்களைப் புரிந்து கொள்ள வேண்டும்.
ஒரு சிறப்பு சோதனை சூழலில் செயல்திறனை அளவிடுவது பற்றி நாம் பேசுகிறோமா? அதாவது, இது உற்பத்தி இல்லையா?
ஆம், இது உற்பத்தி அல்ல, இது ஒரு சோதனை சூழல், இது எப்போதும் ஒரே மாதிரியாக இருக்கும், எனவே நீங்கள் முந்தைய அளவீடுகளுடன் ஒப்பிடலாம்.
புரிந்தது நன்றி!
கேள்விகள் இல்லை என்றால் முடித்துவிடலாம் என்று நினைக்கிறேன். நன்றி!
ஆதாரம்: www.habr.com