DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

பகுதி 1: இணையம்/ஆண்ட்ராய்டு

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

DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

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

எனது நிபுணத்துவம் ஒரு சோதனை ஆட்டோமேஷன் இன்ஜினியர் (QA ஆட்டோமேஷன் இன்ஜினியர்), ஆனால் இது தானியங்கு சோதனைகளை எழுதுவது அல்லது சோதனை கட்டமைப்பை உருவாக்குவது ஆகியவற்றுடன் மட்டுமே தொடர்புடையதாக இருக்கக்கூடாது என்று நான் நம்புகிறேன். 2020 ஆம் ஆண்டில், ஆட்டோமேஷன் உள்கட்டமைப்பு பற்றிய அறிவும் அவசியம். சோதனைகளை நடத்துவது முதல் உங்கள் இலக்குகளுக்கு ஏற்ப அனைத்து பங்குதாரர்களுக்கும் முடிவுகளை வழங்குவது வரை தன்னியக்க செயல்முறையை நீங்களே ஒழுங்கமைக்க இது உங்களை அனுமதிக்கிறது. இதன் விளைவாக, வேலையைச் செய்ய DevOps திறன்கள் அவசியம். இவை அனைத்தும் நல்லது, ஆனால், துரதிர்ஷ்டவசமாக, ஒரு சிக்கல் உள்ளது (ஸ்பாய்லர்: இந்த கட்டுரை இந்த சிக்கலை எளிதாக்க முயற்சிக்கிறது) விஷயம் என்னவென்றால், DevOps கடினமானது. மேலும் இது வெளிப்படையானது, ஏனென்றால் நிறுவனங்கள் எளிதாகச் செய்யக்கூடிய ஒரு விஷயத்திற்கு அதிக கட்டணம் செலுத்தாது... DevOps உலகில், அதிக எண்ணிக்கையிலான கருவிகள், விதிமுறைகள் மற்றும் நடைமுறைகள் தேர்ச்சி பெற வேண்டும். தொழில் வாழ்க்கையின் தொடக்கத்தில் இது மிகவும் கடினம் மற்றும் திரட்டப்பட்ட தொழில்நுட்ப அனுபவத்தைப் பொறுத்தது.

DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை
ஆதாரம்: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

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

இந்தக் கட்டுரை எதைப் பற்றியது?

இந்த கட்டுரையில், சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்குவதற்கான எனது அனுபவத்தைப் பகிர்ந்து கொள்ளப் போகிறேன். இணையத்தில் பல்வேறு கருவிகள் மற்றும் அவற்றை எவ்வாறு பயன்படுத்துவது என்பது பற்றிய தகவல்களின் பல ஆதாரங்கள் உள்ளன, ஆனால் நான் அவற்றை முற்றிலும் ஆட்டோமேஷனின் சூழலில் பார்க்க விரும்புகிறேன். பல தன்னியக்க பொறியியலாளர்கள் உங்களைத் தவிர வேறு யாரும் வளர்ந்த சோதனைகளை நடத்தாத அல்லது அவற்றைப் பராமரிப்பதில் அக்கறை காட்டாத சூழ்நிலையை நன்கு அறிந்திருக்கிறார்கள் என்று நான் நம்புகிறேன். இதன் விளைவாக, சோதனைகள் காலாவதியாகிவிட்டன, மேலும் அவற்றைப் புதுப்பிப்பதில் நேரத்தை செலவிட வேண்டியிருக்கும். மீண்டும், ஒரு தொழிலின் தொடக்கத்தில், இது மிகவும் கடினமான பணியாக இருக்கலாம்: கொடுக்கப்பட்ட சிக்கலை அகற்ற எந்த கருவிகள் உதவ வேண்டும், அவற்றை எவ்வாறு தேர்ந்தெடுப்பது, கட்டமைப்பது மற்றும் பராமரிப்பது என்பதை புத்திசாலித்தனமாக தீர்மானிப்பது. சில சோதனையாளர்கள் உதவிக்காக DevOps (மனிதர்கள்) பக்கம் திரும்பி, நேர்மையாக இருக்கட்டும், இந்த அணுகுமுறை வேலை செய்கிறது. பல சந்தர்ப்பங்களில், எல்லா சார்புகளிலும் நமக்குத் தெரிவுநிலை இல்லாததால் இதுவே ஒரே விருப்பமாக இருக்கலாம். ஆனால், DevOps மிகவும் பிஸியாக இருக்கும் தோழர்களே, ஏனென்றால் அவர்கள் முழு நிறுவனத்தின் உள்கட்டமைப்பு, வரிசைப்படுத்தல், கண்காணிப்பு, மைக்ரோ சர்வீஸ் மற்றும் பிற ஒத்த பணிகளை நிறுவனம்/குழுவைப் பொறுத்து சிந்திக்க வேண்டும். வழக்கமாக நடப்பது போல, ஆட்டோமேஷன் ஒரு முன்னுரிமை அல்ல. அத்தகைய சூழ்நிலையில், ஆரம்பம் முதல் இறுதி வரை நம்மால் முடிந்த அனைத்தையும் செய்ய முயற்சிக்க வேண்டும். இது சார்புகளைக் குறைக்கும், பணிப்பாய்வுகளை விரைவுபடுத்தும், எங்கள் திறன்களை மேம்படுத்தும் மற்றும் என்ன நடக்கிறது என்பதைப் பற்றிய பெரிய படத்தைப் பார்க்க அனுமதிக்கும்.

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

இந்தக் கட்டுரையில் என்ன இல்லை

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

இது செய்யப்படுகிறது ஏனெனில்: 

  • இந்த பொருள் பல்வேறு ஆதாரங்களில் (ஆவணங்கள், புத்தகங்கள், வீடியோ படிப்புகள்) கண்டுபிடிக்க மிகவும் எளிதானது;
  • நாம் ஆழமாகச் செல்லத் தொடங்கினால், இந்த கட்டுரையின் 10, 20, 30 பகுதிகளை எழுத வேண்டும் (திட்டங்கள் 2-3 ஆகும்);
  • அதே இலக்குகளை அடைய நீங்கள் மற்ற கருவிகளைப் பயன்படுத்த விரும்புவதால், உங்கள் நேரத்தை வீணடிக்க நான் விரும்பவில்லை.

பயிற்சி

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

திட்டம்

படி
தொழில்நுட்ப
கருவிகள்

1
உள்ளூர் இயக்கம் (வலை / ஆண்ட்ராய்டு டெமோ சோதனைகளைத் தயாரித்து உள்நாட்டில் இயக்கவும்) 
Node.js, செலினியம், அப்பியம்

2
பதிப்பு கட்டுப்பாட்டு அமைப்புகள் 
Git தகவல்

3
கொள்கலன்மயமாக்கல்
டோக்கர், செலினியம் கட்டம், செலினாய்டு (இணையம், ஆண்ட்ராய்டு)

4
CI/CD
கிட்லாப் சிஐ

5
மேகக்கணி தளங்கள்
Google மேகக்கணி இயங்குதளம்

6
இசைக்குழு
Kubernetes

7
ஒரு குறியீடாக உள்கட்டமைப்பு (IaC)
டெர்ராஃபார்ம், அன்சிபிள்

ஒவ்வொரு பிரிவின் அமைப்பு

விளக்கத்தை தெளிவாக வைத்திருக்க, ஒவ்வொரு பகுதியும் பின்வரும் அவுட்லைன் படி விவரிக்கப்பட்டுள்ளது:

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

1. சோதனைகளை உள்நாட்டில் இயக்கவும்

தொழில்நுட்பத்தின் சுருக்கமான விளக்கம்

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

இருப்பினும், ஆட்டோமேஷன் கருவிகளாக, முறையே இணைய தளங்களுக்கு Selenium WebDriver மற்றும் ஆண்ட்ராய்டு இயங்குதளத்திற்கு Appium ஐப் பயன்படுத்த பரிந்துரைக்கிறேன், ஏனெனில் அடுத்த படிகளில் இந்த கருவிகளுடன் குறிப்பாக வேலை செய்ய வடிவமைக்கப்பட்ட டோக்கர் படங்களைப் பயன்படுத்துவோம். மேலும், வேலைத் தேவைகளைக் குறிப்பிடுகையில், இந்த கருவிகள் சந்தையில் மிகவும் தேவைப்படுகின்றன.

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

ஆட்டோமேஷன் உள்கட்டமைப்புக்கான மதிப்பு

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

உள்கட்டமைப்பின் தற்போதைய நிலையின் விளக்கம்

DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

ஆராய்வதற்கான இணைப்புகள்

ஒத்த கருவிகள்

  • செலினியம்/ஆப்பியம் சோதனைகளுடன் நீங்கள் விரும்பும் எந்த நிரலாக்க மொழியும்;
  • ஏதேனும் சோதனைகள்;
  • எந்த டெஸ்ட் ரன்னர்.

2. பதிப்பு கட்டுப்பாட்டு அமைப்புகள் (Git)

தொழில்நுட்பத்தின் சுருக்கமான விளக்கம்

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

ஆட்டோமேஷன் உள்கட்டமைப்புக்கான மதிப்பு

இங்கே நீங்கள் ஒரு நியாயமான கேள்வியைக் கேட்கலாம்: “அவர் ஏன் ஜிட் பற்றி எங்களிடம் கூறுகிறார்? அனைவருக்கும் இது தெரியும், மேலும் இதை டெவலப்மெண்ட் குறியீடு மற்றும் தானியங்கு சோதனைக் குறியீடு ஆகிய இரண்டிற்கும் பயன்படுத்துகிறது. நீங்கள் சொல்வது முற்றிலும் சரி, ஆனால் இந்த கட்டுரையில் நாங்கள் உள்கட்டமைப்பைப் பற்றி பேசுகிறோம், மேலும் இந்த பிரிவு பிரிவு 7 க்கான முன்னோட்டமாக செயல்படுகிறது: "உள்கட்டமைப்பு குறியீடு (IaC)". எங்களைப் பொறுத்தவரை, சோதனை உட்பட முழு உள்கட்டமைப்பும் குறியீட்டின் வடிவத்தில் விவரிக்கப்பட்டுள்ளது, எனவே நாங்கள் பதிப்பு அமைப்புகளைப் பயன்படுத்தலாம் மற்றும் மேம்பாடு மற்றும் ஆட்டோமேஷன் குறியீட்டைப் போன்ற பலன்களைப் பெறலாம்.

படி 7 இல் IaC ஐ இன்னும் விரிவாகப் பார்ப்போம், ஆனால் இப்போதும் நீங்கள் உள்ளூர் களஞ்சியத்தை உருவாக்குவதன் மூலம் Git ஐ உள்நாட்டில் பயன்படுத்தத் தொடங்கலாம். உள்கட்டமைப்பில் தொலை களஞ்சியத்தைச் சேர்க்கும்போது பெரிய படம் விரிவடையும்.

உள்கட்டமைப்பின் தற்போதைய நிலையின் விளக்கம்

DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

ஆராய்வதற்கான இணைப்புகள்

ஒத்த கருவிகள்

3. கொள்கலன் (டாக்கர்)

தொழில்நுட்பத்தின் சுருக்கமான விளக்கம்

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

பரிணாம வளர்ச்சியின் அடுத்த கட்டம் மெய்நிகர் இயந்திரங்கள் (VMs) ஆகும், இது பயன்படுத்தப்படாத வளங்களில் பணத்தை வீணடிக்கும் சிக்கலைத் தீர்த்தது. இந்த தொழில்நுட்பம் முற்றிலும் தனிமைப்படுத்தப்பட்ட இடத்தை ஒதுக்கி, ஒரே சர்வரில் ஒருவருக்கொருவர் சுயாதீனமாக பயன்பாடுகளை இயக்குவதை சாத்தியமாக்கியது. ஆனால், துரதிர்ஷ்டவசமாக, எந்தவொரு தொழில்நுட்பத்திற்கும் அதன் குறைபாடுகள் உள்ளன. VMஐ இயக்குவதற்கு CPU, RAM, சேமிப்பகம் மற்றும் OSஐப் பொறுத்து, உரிமச் செலவுகள் கணக்கில் எடுத்துக்கொள்ளப்பட வேண்டிய முழு இயக்க முறைமை தேவைப்படுகிறது. இந்த காரணிகள் ஏற்றுதல் வேகத்தை பாதிக்கிறது மற்றும் பெயர்வுத்திறனை கடினமாக்குகிறது.

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

நிச்சயமாக, கொள்கலன் தொழில்நுட்பம் ஒன்றும் புதிதல்ல மற்றும் 70 களின் பிற்பகுதியில் அறிமுகப்படுத்தப்பட்டது. அந்த நாட்களில், நிறைய ஆராய்ச்சிகள், முன்னேற்றங்கள் மற்றும் முயற்சிகள் மேற்கொள்ளப்பட்டன. ஆனால் டோக்கர் தான் இந்த தொழில்நுட்பத்தை மாற்றியமைத்து வெகுஜனங்களுக்கு எளிதில் சென்றடையச் செய்தார். இப்போதெல்லாம், கொள்கலன்களைப் பற்றி பேசும்போது, ​​​​பெரும்பாலான சந்தர்ப்பங்களில் நாம் டோக்கரைக் குறிக்கிறோம். டோக்கர் கொள்கலன்களைப் பற்றி பேசும்போது, ​​​​லினக்ஸ் கொள்கலன்களைக் குறிக்கிறோம். கொள்கலன்களை இயக்க Windows மற்றும் macOS அமைப்புகளைப் பயன்படுத்தலாம், ஆனால் இந்த விஷயத்தில் கூடுதல் அடுக்கு தோன்றும் என்பதைப் புரிந்துகொள்வது அவசியம். எடுத்துக்காட்டாக, Mac இல் உள்ள Docker, ஒரு இலகுரக லினக்ஸ் VMக்குள் கன்டெய்னர்களை அமைதியாக இயக்குகிறது. கொள்கலன்களுக்குள் ஆண்ட்ராய்டு எமுலேட்டர்களை இயக்குவது பற்றி விவாதிக்கும்போது இந்த தலைப்புக்குத் திரும்புவோம், எனவே இங்கே ஒரு மிக முக்கியமான நுணுக்கம் உள்ளது, அது இன்னும் விரிவாக விவாதிக்கப்பட வேண்டும்.

ஆட்டோமேஷன் உள்கட்டமைப்புக்கான மதிப்பு

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

  • செலினியம் மற்றும் குறிப்பாக அப்பியத்தை நிறுவும் போது ஏராளமான சார்புகள்;
  • உலாவிகள், சிமுலேட்டர்கள் மற்றும் இயக்கிகளின் பதிப்புகளுக்கு இடையே பொருந்தக்கூடிய சிக்கல்கள்;
  • உலாவிகள்/சிமுலேட்டர்களுக்கு தனிமைப்படுத்தப்பட்ட இடமின்மை, இணையாக இயங்குவதற்கு இது மிகவும் முக்கியமானது;
  • நீங்கள் ஒரே நேரத்தில் 10, 50, 100 அல்லது 1000 உலாவிகளை இயக்க வேண்டும் என்றால் நிர்வகிப்பது மற்றும் பராமரிப்பது கடினம்.

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

டாக்கரில் செலினியம் கட்டம்

பல உலாவிகளை பல கணினிகளில் இயக்குவதற்கும் அவற்றை மைய மையத்திலிருந்து நிர்வகிப்பதற்கும் இந்த கருவி செலினியம் உலகில் மிகவும் பிரபலமானது. தொடங்குவதற்கு, நீங்கள் குறைந்தது 2 பகுதிகளை பதிவு செய்ய வேண்டும்: Hub மற்றும் Node(கள்). Hub என்பது ஒரு மைய முனையாகும், இது சோதனைகளிலிருந்து அனைத்து கோரிக்கைகளையும் பெற்று அவற்றை பொருத்தமான முனைகளுக்கு விநியோகிக்கும். ஒவ்வொரு முனைக்கும் நாம் ஒரு குறிப்பிட்ட உள்ளமைவை உள்ளமைக்கலாம், எடுத்துக்காட்டாக, விரும்பிய உலாவி மற்றும் அதன் பதிப்பைக் குறிப்பிடுவதன் மூலம். இருப்பினும், இணக்கமான உலாவி இயக்கிகளை நாமே கவனித்து, விரும்பிய முனைகளில் அவற்றை நிறுவ வேண்டும். இந்த காரணத்திற்காக, Linux OS இல் நிறுவ முடியாத உலாவிகளுடன் நாம் வேலை செய்ய வேண்டியிருக்கும் போது தவிர, Selenium கட்டம் அதன் தூய வடிவத்தில் பயன்படுத்தப்படாது. மற்ற எல்லா நிகழ்வுகளுக்கும், செலினியம் கிரிட் ஹப் மற்றும் நோட்ஸை இயக்க டோக்கர் படங்களைப் பயன்படுத்துவது குறிப்பிடத்தக்க நெகிழ்வான மற்றும் சரியான தீர்வாக இருக்கும். இந்த அணுகுமுறை முனை நிர்வாகத்தை பெரிதும் எளிதாக்குகிறது, ஏனெனில் ஏற்கனவே நிறுவப்பட்ட உலாவிகள் மற்றும் இயக்கிகளின் இணக்கமான பதிப்புகளுடன் நமக்குத் தேவையான படத்தைத் தேர்ந்தெடுக்கலாம்.

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

இணையத்திற்கான செலினாய்டு

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

ஆனால், ஐயோ, செலினாய்டு இன்னும் ஒரு வெள்ளி புல்லட் அல்ல. 'பிரவுசர் ஆன் டிமாண்ட்' அம்சத்தைப் பெற்றுள்ளோம், ஆனால் 'ரீசோர்ஸ் ஆன் டிமாண்ட்' அம்சம் இன்னும் கிடைக்கவில்லை. Selenoid ஐப் பயன்படுத்த, நாம் அதை இயற்பியல் வன்பொருள் அல்லது VM இல் பயன்படுத்த வேண்டும், அதாவது எத்தனை வளங்கள் ஒதுக்கப்பட வேண்டும் என்பதை நாம் முன்கூட்டியே தெரிந்து கொள்ள வேண்டும். 10, 20 அல்லது 30 உலாவிகளை இணையாக இயக்கும் சிறிய திட்டங்களுக்கு இது ஒரு பிரச்சனையாக இருக்காது என்று நினைக்கிறேன். ஆனால் நமக்கு 100, 500, 1000 அல்லது அதற்கு மேல் தேவைப்பட்டால் என்ன செய்வது? எல்லா நேரத்திலும் பல வளங்களை பராமரிப்பதிலும் பணம் செலுத்துவதிலும் அர்த்தமில்லை. இந்த கட்டுரையின் பிரிவு 5 மற்றும் 6 இல், உங்களை அளவிட அனுமதிக்கும் தீர்வுகளைப் பற்றி விவாதிப்போம், இதன் மூலம் நிறுவனத்தின் செலவுகளை கணிசமாகக் குறைக்கலாம்.

Android க்கான Selenoid

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

இந்த கருவியின் எதிர்மறை அம்சங்களைப் பற்றி நான் பேச விரும்பவில்லை, ஏனெனில் நான் அதை மிகவும் விரும்புகிறேன். ஆனால் இன்னும், இணைய ஆட்டோமேஷனுக்குப் பொருந்தும் அதே தீமைகள் மற்றும் அளவிடுதலுடன் தொடர்புடையவை. இது தவிர, நாம் முதல் முறையாக கருவியை அமைக்கும் போது ஆச்சரியப்படக்கூடிய மற்றொரு வரம்பு பற்றி பேச வேண்டும். ஆண்ட்ராய்டு படங்களை இயக்க, உள்ளமைக்கப்பட்ட மெய்நிகராக்க ஆதரவுடன் கூடிய இயற்பியல் இயந்திரம் அல்லது VM தேவை. எப்படி செய்வது என்ற வழிகாட்டியில், லினக்ஸ் விஎம்மில் இதை எப்படி இயக்குவது என்பதை நான் விளக்கிக் காட்டுகிறேன். இருப்பினும், நீங்கள் ஒரு macOS பயனராக இருந்து, Selenoid ஐ உள்நாட்டில் பயன்படுத்த விரும்பினால், இது Android சோதனைகளை இயக்க முடியாது. ஆனால் உள்ளமைக்கப்பட்ட 'உள்ளமை மெய்நிகராக்கத்துடன்' நீங்கள் எப்போதும் Linux VM ஐ இயக்கலாம் மற்றும் உள்ளே Selenoid ஐப் பயன்படுத்தலாம்.

உள்கட்டமைப்பின் தற்போதைய நிலையின் விளக்கம்

இந்தக் கட்டுரையின் சூழலில், உள்கட்டமைப்பை விளக்குவதற்கு 2 கருவிகளைச் சேர்ப்போம். இவை இணைய சோதனைகளுக்கான செலினியம் கட்டம் மற்றும் ஆண்ட்ராய்டு சோதனைகளுக்கான செலினாய்டு. GitHub டுடோரியலில், இணைய சோதனைகளை இயக்க Selenoid ஐ எவ்வாறு பயன்படுத்துவது என்பதையும் நான் உங்களுக்குக் காண்பிப்பேன். 

DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

ஆராய்வதற்கான இணைப்புகள்

ஒத்த கருவிகள்

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

4.CI/CD

தொழில்நுட்பத்தின் சுருக்கமான விளக்கம்

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

எனவே, 3 விதிமுறைகள் உள்ளன: CI - தொடர்ச்சியான ஒருங்கிணைப்பு, CD - தொடர்ச்சியான விநியோகம் மற்றும் மீண்டும் CD - தொடர்ச்சியான வரிசைப்படுத்தல். (கீழே நான் இந்த சொற்களை ஆங்கிலத்தில் பயன்படுத்துவேன்) ஒவ்வொரு மாற்றமும் உங்கள் மேம்பாட்டுக் குழாய்க்கு பல கூடுதல் படிகளைச் சேர்க்கிறது. ஆனால் வார்த்தை தொடர்ச்சியான (தொடர்ந்து) மிக முக்கியமான விஷயம். இந்தச் சூழலில், ஆரம்பம் முதல் இறுதி வரை குறுக்கீடு அல்லது கைமுறையான தலையீடு இல்லாமல் நடக்கும் ஒன்றைக் குறிக்கிறோம். இந்த சூழலில் CI & CD மற்றும் CD ஆகியவற்றைப் பார்ப்போம்.

  • தொடர்ச்சியான ஒருங்கிணைப்பு இது பரிணாம வளர்ச்சியின் ஆரம்ப கட்டமாகும். சேவையகத்தில் புதிய குறியீட்டைச் சமர்ப்பித்த பிறகு, எங்களின் மாற்றங்கள் சரி என்று விரைவான கருத்தைப் பெறுவோம். பொதுவாக, CI ஆனது இயங்கும் நிலையான குறியீடு பகுப்பாய்வு கருவிகள் மற்றும் அலகு/உள் API சோதனைகளை உள்ளடக்கியது. இது சில நொடிகள்/நிமிடங்களில் எங்கள் குறியீட்டைப் பற்றிய தகவலைப் பெற அனுமதிக்கிறது.
  • தொடர்ச்சியான டெலிவரி ஒருங்கிணைப்பு/UI சோதனைகளை நாங்கள் இயக்கும் ஒரு மேம்பட்ட படியாகும். இருப்பினும், இந்த கட்டத்தில் CI போன்ற முடிவுகளை விரைவாகப் பெற முடியாது. முதலில், இந்த வகையான சோதனைகள் முடிவடைய அதிக நேரம் எடுக்கும். இரண்டாவதாக, தொடங்குவதற்கு முன், சோதனை/நிலைப்படுத்தல் சூழலில் நமது மாற்றங்களை வரிசைப்படுத்த வேண்டும். மேலும், நாங்கள் மொபைல் மேம்பாட்டைப் பற்றி பேசுகிறோம் என்றால், எங்கள் பயன்பாட்டின் கட்டமைப்பை உருவாக்க கூடுதல் படி தோன்றும்.
  • தொடர்ச்சியான வரிசைப்படுத்தல் முந்தைய நிலைகளில் அனைத்து ஏற்றுக்கொள்ளும் சோதனைகளும் நிறைவேற்றப்பட்டிருந்தால், உற்பத்திக்கான எங்கள் மாற்றங்களை தானாகவே வெளியிடுவோம் என்று கருதுகிறது. இது தவிர, வெளியீட்டு நிலைக்குப் பிறகு, உற்பத்தியில் புகை சோதனைகளை இயக்குதல் மற்றும் ஆர்வத்தின் அளவீடுகளை சேகரிப்பது போன்ற பல்வேறு நிலைகளை நீங்கள் கட்டமைக்கலாம். தானியங்கு சோதனைகள் மூலம் நல்ல பாதுகாப்புடன் மட்டுமே தொடர்ச்சியான வரிசைப்படுத்தல் சாத்தியமாகும். சோதனை உட்பட ஏதேனும் கைமுறையான தலையீடுகள் தேவைப்பட்டால், இது இனி இல்லை தொடர்ச்சியான (தொடர்ச்சியான). எங்கள் பைப்லைன் தொடர்ச்சியான டெலிவரி நடைமுறைக்கு மட்டுமே இணங்குகிறது என்று சொல்லலாம்.

ஆட்டோமேஷன் உள்கட்டமைப்புக்கான மதிப்பு

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

கட்டிடக்கலை மாற்றத்தின் விளக்கத்தைப் பார்ப்பதற்கு முன், GitLab CI பற்றி சில வார்த்தைகளைச் சொல்ல விரும்புகிறேன். மற்ற CI/CD கருவிகளைப் போலல்லாமல், GitLab ஒரு ரிமோட் களஞ்சியத்தையும் பல கூடுதல் அம்சங்களையும் வழங்குகிறது. எனவே, GitLab CI ஐ விட அதிகமாக உள்ளது. இதில் மூல குறியீடு மேலாண்மை, சுறுசுறுப்பான மேலாண்மை, CI/CD பைப்லைன்கள், பதிவு செய்யும் கருவிகள் மற்றும் அளவீடுகள் சேகரிப்பு ஆகியவை அடங்கும். GitLab கட்டமைப்பு Gitlab CI/CD மற்றும் GitLab ரன்னர் ஆகியவற்றைக் கொண்டுள்ளது. அதிகாரப்பூர்வ வலைத்தளத்திலிருந்து ஒரு சிறிய விளக்கம் இங்கே:

கிட்லாப் சிஐ/சிடி என்பது ஏபிஐ கொண்ட ஒரு வலைப் பயன்பாடாகும், இது அதன் நிலையை தரவுத்தளத்தில் சேமித்து, திட்டங்களை நிர்வகிக்கிறது/கட்டமைக்கிறது மற்றும் பயனர் இடைமுகத்தை வழங்குகிறது. GitLab Runner என்பது உருவாக்கங்களைச் செயலாக்கும் ஒரு பயன்பாடாகும். இது தனித்தனியாக பயன்படுத்தப்படலாம் மற்றும் API மூலம் GitLab CI/CD உடன் வேலை செய்யும். இயங்கும் சோதனைகளுக்கு உங்களுக்கு கிட்லாப் நிகழ்வு மற்றும் ரன்னர் இரண்டும் தேவை.

உள்கட்டமைப்பின் தற்போதைய நிலையின் விளக்கம்

DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

ஆராய்வதற்கான இணைப்புகள்

ஒத்த கருவிகள்

5. கிளவுட் தளங்கள்

தொழில்நுட்பத்தின் சுருக்கமான விளக்கம்

இந்தப் பகுதியில் 'பொது மேகங்கள்' என்ற பிரபலமான போக்கைப் பற்றிப் பேசுவோம். மேலே விவரிக்கப்பட்ட மெய்நிகராக்கம் மற்றும் கொள்கலன் தொழில்நுட்பங்கள் வழங்கும் மகத்தான நன்மைகள் இருந்தபோதிலும், எங்களுக்கு இன்னும் கணினி ஆதாரங்கள் தேவை. நிறுவனங்கள் விலையுயர்ந்த சேவையகங்களை வாங்குகின்றன அல்லது டேட்டா சென்டர்களை வாடகைக்கு எடுக்கின்றன, ஆனால் இந்த விஷயத்தில் நமக்கு எத்தனை ஆதாரங்கள் தேவைப்படும், அவற்றை 24/7 பயன்படுத்துவோமா மற்றும் எந்த நோக்கங்களுக்காக கணக்கீடுகளை (சில நேரங்களில் நம்பத்தகாதது) செய்வது அவசியம். எடுத்துக்காட்டாக, உற்பத்திக்கு XNUMX/XNUMX இயங்கும் சேவையகம் தேவை, ஆனால் வேலை நேரத்துக்கு வெளியே சோதனை செய்வதற்கு நமக்கு இது போன்ற ஆதாரங்கள் தேவையா? இது செய்யப்படும் சோதனை வகையையும் சார்ந்துள்ளது. ஒரு உதாரணம், அடுத்த நாள் முடிவுகளைப் பெறுவதற்காக வேலை செய்யாத நேரங்களில் இயக்கத் திட்டமிடும் சுமை/அழுத்தச் சோதனைகள். ஆனால் நிச்சயமாக XNUMX/XNUMX சர்வர் கிடைக்கும் என்பது எண்ட்-டு-எண்ட் தானியங்கு சோதனைகளுக்கு தேவையில்லை மற்றும் குறிப்பாக கைமுறை சோதனை சூழல்களுக்கு தேவையில்லை. அத்தகைய சூழ்நிலைகளுக்கு, தேவைக்கேற்ப பல ஆதாரங்களைப் பெற்று, அவற்றைப் பயன்படுத்தவும், அவை தேவைப்படாதபோது பணம் செலுத்துவதை நிறுத்தவும் நல்லது. மேலும், சில மவுஸ் கிளிக்குகள் அல்லது இரண்டு ஸ்கிரிப்ட்களை இயக்குவதன் மூலம் அவற்றை உடனடியாகப் பெறுவது நன்றாக இருக்கும். இதற்குத்தான் பொது மேகங்கள் பயன்படுத்தப்படுகின்றன. வரையறையைப் பார்ப்போம்:

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

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

ஆட்டோமேஷன் உள்கட்டமைப்புக்கான மதிப்பு

இறுதி முதல் இறுதி UI சோதனைகளுக்கு என்ன குறிப்பிட்ட ஆதாரங்கள் தேவை? அடிப்படையில் இவை விர்ச்சுவல் மெஷின்கள் அல்லது கிளஸ்டர்கள் (அடுத்த பகுதியில் குபெர்னெட்ஸ் பற்றி பேசுவோம்) உலாவிகள் மற்றும் எமுலேட்டர்களை இயக்குவதற்கு. அதிக பிரவுசர்கள் மற்றும் எமுலேட்டர்களை ஒரே நேரத்தில் இயக்க விரும்புகிறோம், அதிக CPU மற்றும் நினைவகம் தேவைப்படுகிறது மற்றும் அதற்கு அதிக பணம் செலுத்த வேண்டும். எனவே, சோதனை ஆட்டோமேஷன் சூழலில் பொது மேகங்கள் தேவைக்கேற்ப அதிக எண்ணிக்கையிலான (100, 200, 1000...) உலாவிகள்/முன்மாதிரிகளை இயக்க அனுமதிக்கின்றன, விரைவில் சோதனை முடிவுகளைப் பெறுகின்றன, மேலும் இது போன்ற அசாத்தியமான ஆதாரங்களுக்கு பணம் செலுத்துவதை நிறுத்துகின்றன. சக்தி. 

மிகவும் பிரபலமான கிளவுட் வழங்குநர்கள் Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). ஜிசிபியை எப்படிப் பயன்படுத்துவது என்பதற்கான எடுத்துக்காட்டுகளை எப்படிச் செய்வது வழிகாட்டி வழங்குகிறது, ஆனால் பொதுவாக நீங்கள் ஆட்டோமேஷன் பணிகளுக்கு எதைப் பயன்படுத்துகிறீர்கள் என்பது முக்கியமல்ல. அவை அனைத்தும் ஏறக்குறைய ஒரே மாதிரியான செயல்பாட்டை வழங்குகின்றன. பொதுவாக, ஒரு வழங்குநரைத் தேர்ந்தெடுக்க, நிர்வாகம் நிறுவனத்தின் முழு உள்கட்டமைப்பு மற்றும் வணிகத் தேவைகளில் கவனம் செலுத்துகிறது, இது இந்தக் கட்டுரையின் எல்லைக்கு அப்பாற்பட்டது. ஆட்டோமேஷன் பொறியாளர்களுக்கு, கிளவுட் வழங்குநர்களின் பயன்பாட்டை குறிப்பாக சோஸ் லேப்ஸ், பிரவுசர்ஸ்டாக், பிட்பார் போன்ற சோதனை நோக்கங்களுக்காக கிளவுட் பிளாட்ஃபார்ம்களின் பயன்பாட்டுடன் ஒப்பிடுவது மிகவும் சுவாரஸ்யமாக இருக்கும். அதனால் நாமும் செய்வோம்! என் கருத்துப்படி, சாஸ் லேப்ஸ் மிகவும் பிரபலமான கிளவுட் டெஸ்டிங் பண்ணை, அதனால்தான் நான் அதை ஒப்பிட பயன்படுத்தினேன். 

ஆட்டோமேஷன் நோக்கங்களுக்காக GCP vs சாஸ் லேப்ஸ்:

நாம் ஒரே நேரத்தில் 8 இணைய சோதனைகள் மற்றும் 8 ஆண்ட்ராய்டு சோதனைகளை இயக்க வேண்டும் என்று கற்பனை செய்து கொள்வோம். இதற்கு நாம் GCP ஐப் பயன்படுத்துவோம் மற்றும் Selenoid உடன் 2 மெய்நிகர் இயந்திரங்களை இயக்குவோம். முதல் ஒன்றில் உலாவிகளுடன் 8 கொள்கலன்களை உயர்த்துவோம். இரண்டாவதாக முன்மாதிரிகளுடன் 8 கொள்கலன்கள் உள்ளன. விலைகளைப் பார்ப்போம்:  

DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை
Chrome உடன் ஒரு கொள்கலனை இயக்க, நமக்குத் தேவை n1-தரநிலை-1 கார். ஆண்ட்ராய்டு விஷயத்தில் அது இருக்கும் n1-தரநிலை-4 ஒரு முன்மாதிரிக்கு. உண்மையில், CPU/Memoryக்கான குறிப்பிட்ட பயனர் மதிப்புகளை அமைப்பதே மிகவும் நெகிழ்வான மற்றும் மலிவான வழி, ஆனால் தற்போது இது Sauce Labs உடன் ஒப்பிடுவதற்கு முக்கியமில்லை.

சாஸ் லேப்களைப் பயன்படுத்துவதற்கான கட்டணங்கள் இங்கே:

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

தேவையான ஆதாரங்கள்
மாதந்தோறும்
வேலை நேரம்(காலை 8 - இரவு 8 மணி)
வேலை நேரம்+ தடுக்கக்கூடியது

இணையத்திற்கான ஜி.சி.பி
n1-தரநிலை-1 x 8 = n1-தரநிலை-8
$194.18
23 நாட்கள் * 12h * 0.38 = $104.88 
23 நாட்கள் * 12h * 0.08 = $22.08

இணையத்திற்கான சாஸ் ஆய்வகங்கள்
மெய்நிகர் Cloud8 இணையான சோதனைகள்
$1.559
-
-

Android க்கான GCP
n1-தரநிலை-4 x 8: n1-தரநிலை-16
$776.72
23 நாட்கள் * 12h * 1.52 = $419.52 
23 நாட்கள் * 12h * 0.32 = $88.32

ஆண்ட்ராய்டுக்கான சாஸ் லேப்ஸ்
உண்மையான சாதன கிளவுட் 8 இணையான சோதனைகள்
$1.999
-
-

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

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

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

அது இன்னும் முடியவில்லை! உண்மையில், இடைவேளையின்றி யாரும் 12 மணிநேரம் சோதனைகளை நடத்த மாட்டார்கள் என்று நான் உறுதியாக நம்புகிறேன். அப்படியானால், மெய்நிகர் இயந்திரங்கள் தேவையில்லாதபோது தானாகவே தொடங்கலாம் மற்றும் நிறுத்தலாம். உண்மையான பயன்பாட்டு நேரம் ஒரு நாளைக்கு 6 மணிநேரமாக குறைக்கப்படலாம். எங்கள் பணியின் சூழலில் கட்டணம் 11 உலாவிகளுக்கு மாதத்திற்கு $8 ஆக குறையும். இது அற்புதம் இல்லையா? ஆனால் முன்னெச்சரிக்கை இயந்திரங்கள் மூலம் நாம் கவனமாக இருக்க வேண்டும் மற்றும் குறுக்கீடுகள் மற்றும் உறுதியற்ற தன்மைக்கு தயாராக இருக்க வேண்டும், இருப்பினும் இந்த சூழ்நிலைகளை மென்பொருளில் வழங்கலாம் மற்றும் கையாளலாம். அது மதிப்பு தான்!

ஆனால், 'கிளவுட் டெஸ்ட் பண்ணைகளை ஒருபோதும் பயன்படுத்த வேண்டாம்' என்று நான் கூறவில்லை. அவர்களுக்கு பல நன்மைகள் உள்ளன. முதலாவதாக, இது ஒரு மெய்நிகர் இயந்திரம் மட்டுமல்ல, முழு அளவிலான சோதனை ஆட்டோமேஷன் தீர்வாகும். பல சூழ்நிலைகளில், இது ஒரு அத்தியாவசிய புதுப்பாணியான மாற்றாக இருக்கலாம். பொது மேகங்கள் Linux/Windows சிஸ்டங்களை மட்டுமே வழங்கும் போது, ​​சோதனை தளங்கள் IOS ஆட்டோமேஷனுக்கு மிகவும் பயனுள்ளதாக இருக்கும். ஆனால் பின்வரும் கட்டுரைகளில் iOS பற்றி பேசுவோம். நான் எப்போதும் நிலைமையைப் பார்த்து, பணிகளில் இருந்து தொடங்க பரிந்துரைக்கிறேன்: சில சந்தர்ப்பங்களில் பொது மேகங்களைப் பயன்படுத்துவது மலிவானது மற்றும் திறமையானது, மற்றவற்றில் சோதனை தளங்கள் செலவழித்த பணத்திற்கு நிச்சயமாக மதிப்புள்ளது.

உள்கட்டமைப்பின் தற்போதைய நிலையின் விளக்கம்

DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

ஆராய்வதற்கான இணைப்புகள்

இதே போன்ற கருவிகள்:

6. இசைக்குழு

தொழில்நுட்பத்தின் சுருக்கமான விளக்கம்

எனக்கு ஒரு நல்ல செய்தி உள்ளது - நாங்கள் கட்டுரையின் முடிவில் இருக்கிறோம்! இந்த நேரத்தில், எங்களின் ஆட்டோமேஷன் உள்கட்டமைப்பு இணையம் மற்றும் ஆண்ட்ராய்டு சோதனைகளைக் கொண்டுள்ளது, நாங்கள் கிட்லேப் சிஐ மூலம் இணையாக, டோக்கர்-இயக்கப்பட்ட கருவிகளைப் பயன்படுத்தி இயக்குகிறோம்: செலினியம் கட்டம் மற்றும் செலினாய்டு. மேலும், உலாவிகள் மற்றும் முன்மாதிரிகளுடன் கொள்கலன்களை ஹோஸ்ட் செய்ய GCP வழியாக உருவாக்கப்பட்ட மெய்நிகர் இயந்திரங்களைப் பயன்படுத்துகிறோம். செலவுகளைக் குறைக்க, இந்த மெய்நிகர் இயந்திரங்களை தேவைக்கேற்ப மட்டுமே தொடங்குகிறோம், மேலும் சோதனை மேற்கொள்ளப்படாதபோது அவற்றை நிறுத்துகிறோம். நமது உள்கட்டமைப்பை மேம்படுத்த வேறு ஏதாவது உள்ளதா? பதில் ஆம்! குபெர்னெட்ஸை (K8s) சந்திக்கவும்!

முதலில், ஆர்கெஸ்ட்ரேஷன், கிளஸ்டர் மற்றும் குபெர்னெட்ஸ் ஆகிய சொற்கள் எவ்வாறு ஒன்றோடொன்று தொடர்புடையவை என்பதைப் பார்ப்போம். உயர் மட்டத்தில், ஆர்கெஸ்ட்ரேஷன் என்பது பயன்பாடுகளை வரிசைப்படுத்தி நிர்வகிக்கும் அமைப்பாகும். சோதனை ஆட்டோமேஷனுக்காக, செலினியம் கட்டம் மற்றும் செலினாய்டு போன்ற கண்டெய்னரைஸ் செய்யப்பட்ட பயன்பாடுகள். டோக்கர் மற்றும் கே8கள் ஒன்றையொன்று பூர்த்தி செய்கின்றன. முதலாவது பயன்பாட்டு வரிசைப்படுத்தலுக்கும், இரண்டாவது ஆர்கெஸ்ட்ரேஷனுக்கும் பயன்படுத்தப்படுகிறது. இதையொட்டி, K8s ஒரு கிளஸ்டர் ஆகும். கிளஸ்டரின் பணியானது VM களை முனைகளாகப் பயன்படுத்துவதாகும், இது ஒரு சேவையகத்தில் (கிளஸ்டர்) பல்வேறு செயல்பாடுகள், நிரல்கள் மற்றும் சேவைகளை நிறுவ உங்களை அனுமதிக்கிறது. முனைகளில் ஏதேனும் தோல்வியுற்றால், மற்ற முனைகள் எடுக்கப்படும், இது எங்கள் பயன்பாட்டின் தடையின்றி செயல்பாட்டை உறுதி செய்கிறது. இது தவிர, K8s அளவிடுதல் தொடர்பான முக்கியமான செயல்பாட்டைக் கொண்டுள்ளது, இதற்கு நன்றி, சுமை மற்றும் வரம்புகளின் அடிப்படையில் வளங்களின் உகந்த அளவை தானாகவே பெறுகிறோம்.

உண்மையில், புதிதாக குபெர்னெட்ஸை கைமுறையாக வரிசைப்படுத்துவது ஒரு சிறிய பணி அல்ல. "குபெர்னெட்ஸ் தி ஹார்ட் வே" என்ற பிரபலமான வழிகாட்டுதலுக்கான இணைப்பை நான் விட்டுவிடுகிறேன், நீங்கள் ஆர்வமாக இருந்தால், அதைப் பயிற்சி செய்யலாம். ஆனால், அதிர்ஷ்டவசமாக, மாற்று முறைகள் மற்றும் கருவிகள் உள்ளன. GCP இல் Google Kubernetes Engine (GKE) ஐப் பயன்படுத்துவது எளிதான வழி, இது ஒரு சில கிளிக்குகளில் ஆயத்த கிளஸ்டரைப் பெற உங்களை அனுமதிக்கும். கற்றலைத் தொடங்க இந்த அணுகுமுறையைப் பயன்படுத்த பரிந்துரைக்கிறேன், ஏனெனில் உள் கூறுகள் எவ்வாறு ஒருங்கிணைக்கப்பட வேண்டும் என்பதைக் கற்றுக்கொள்வதற்குப் பதிலாக உங்கள் பணிகளுக்கு K8களை எவ்வாறு பயன்படுத்துவது என்பதைக் கற்றுக்கொள்வதில் கவனம் செலுத்த இது உங்களை அனுமதிக்கும். 

ஆட்டோமேஷன் உள்கட்டமைப்புக்கான மதிப்பு

K8s வழங்கும் சில குறிப்பிடத்தக்க அம்சங்களைப் பார்ப்போம்:

  • பயன்பாட்டு வரிசைப்படுத்தல்: VMகளுக்குப் பதிலாக மல்டி-நோட்ஸ் கிளஸ்டரைப் பயன்படுத்துதல்;
  • மாறும் அளவிடுதல்: தேவைக்கேற்ப மட்டுமே பயன்படுத்தப்படும் வளங்களின் விலையைக் குறைக்கிறது;
  • சுய-குணப்படுத்துதல்: காய்களின் தானியங்கி மீட்பு (இதன் விளைவாக கொள்கலன்களும் மீட்டமைக்கப்படுகின்றன);
  • வேலையில்லா நேரம் இல்லாமல் புதுப்பிப்புகள் மற்றும் மாற்றங்களை மாற்றியமைத்தல்: கருவிகள், உலாவிகள் மற்றும் முன்மாதிரிகளைப் புதுப்பித்தல் தற்போதைய பயனர்களின் வேலையைத் தடுக்காது

ஆனால் K8s இன்னும் ஒரு வெள்ளி புல்லட் அல்ல. நாம் பரிசீலிக்கும் கருவிகளின் (செலினியம் கட்டம், செலினாய்டு) சூழலில் உள்ள அனைத்து நன்மைகள் மற்றும் வரம்புகளைப் புரிந்து கொள்ள, K8 களின் கட்டமைப்பை சுருக்கமாக விவாதிப்போம். கிளஸ்டரில் இரண்டு வகையான முனைகள் உள்ளன: முதன்மை முனைகள் மற்றும் தொழிலாளர் முனைகள். மேலாண்மை, வரிசைப்படுத்தல் மற்றும் திட்டமிடல் முடிவுகளுக்கு முதன்மை முனைகள் பொறுப்பாகும். விண்ணப்பங்கள் இயக்கப்படும் இடத்தில் தொழிலாளர்கள் முனைகள் உள்ளன. முனைகளில் கொள்கலன் இயக்க நேர சூழலும் உள்ளது. எங்கள் விஷயத்தில், இது டோக்கர் ஆகும், இது கொள்கலன் தொடர்பான செயல்பாடுகளுக்கு பொறுப்பாகும். ஆனால் மாற்று தீர்வுகளும் உள்ளன, உதாரணமாக கொள்கலன். அளவிடுதல் அல்லது சுய-குணப்படுத்துதல் நேரடியாக கொள்கலன்களுக்கு பொருந்தாது என்பதைப் புரிந்துகொள்வது அவசியம். காய்களின் எண்ணிக்கையைச் சேர்ப்பதன் மூலம்/குறைப்பதன் மூலம் இது செயல்படுத்தப்படுகிறது, அதையொட்டி கொள்கலன்கள் (பொதுவாக ஒரு காய் ஒன்றுக்கு ஒரு கொள்கலன், ஆனால் பணியைப் பொறுத்து மேலும் இருக்கலாம்). உயர்மட்ட படிநிலையானது தொழிலாளர் முனைகளைக் கொண்டுள்ளது, அதன் உள்ளே காய்கள் உள்ளன, அதன் உள்ளே கொள்கலன்கள் எழுப்பப்படுகின்றன.

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

இப்போது மேலே உள்ள விதிமுறைகளின் பின்னணியில் எங்கள் கருவிகளைப் பார்ப்போம்.

செலினியம் கட்டம்

முன்னர் குறிப்பிட்டபடி, செலினியம் கட்டம் மிகவும் பிரபலமான கருவியாகும், மேலும் இது கொள்கலனில் உள்ளதில் ஆச்சரியமில்லை. எனவே, செலினியம் கட்டம் K8 களில் பயன்படுத்தப்படலாம் என்பதில் ஆச்சரியமில்லை. இதை எப்படி செய்வது என்பதற்கான உதாரணத்தை அதிகாரப்பூர்வ K8s களஞ்சியத்தில் காணலாம். வழக்கம் போல், பிரிவின் முடிவில் இணைப்புகளை இணைக்கிறேன். கூடுதலாக, டெர்ராஃபார்மில் இதை எப்படி செய்வது என்று வழிகாட்டி காட்டுகிறது. உலாவி கொள்கலன்களைக் கொண்ட காய்களின் எண்ணிக்கையை எவ்வாறு அளவிடுவது என்பதற்கான வழிமுறைகளும் உள்ளன. ஆனால் K8s இன் சூழலில் தானியங்கி அளவிடுதல் செயல்பாடு இன்னும் முற்றிலும் வெளிப்படையான பணியாக இல்லை. நான் படிக்கத் தொடங்கியபோது, ​​எந்த நடைமுறை வழிகாட்டுதலோ பரிந்துரைகளோ கிடைக்கவில்லை. DevOps குழுவின் ஆதரவுடன் பல ஆய்வுகள் மற்றும் சோதனைகளுக்குப் பிறகு, ஒரு பணியாளரின் முனைக்குள் அமைந்துள்ள ஒரு பாட்க்குள் தேவையான உலாவிகளுடன் கொள்கலன்களை உயர்த்துவதற்கான அணுகுமுறையைத் தேர்ந்தெடுத்தோம். இந்த முறையானது முனைகளின் எண்ணிக்கையை அதிகரிப்பதன் மூலம் அவற்றின் கிடைமட்ட அளவிடுதல் மூலோபாயத்தைப் பயன்படுத்த அனுமதிக்கிறது. எதிர்காலத்தில் இது மாறும் என்று நம்புகிறேன், மேலும் சிறந்த அணுகுமுறைகள் மற்றும் ஆயத்த தீர்வுகள் பற்றிய மேலும் மேலும் விளக்கங்களைக் காண்போம், குறிப்பாக செலினியம் கட்டம் 4 மாற்றப்பட்ட உள் கட்டமைப்புடன் வெளியான பிறகு.

செலினாய்டு:

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

சந்திரன்:

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

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

எனவே, சந்திரன் ஒரு சிறந்த தீர்வு, ஆனால் ஒரு சிக்கல் உள்ளது: இது இலவசம் அல்ல. விலை அமர்வுகளின் எண்ணிக்கையைப் பொறுத்தது. நீங்கள் 0-4 அமர்வுகளை மட்டுமே இலவசமாக இயக்க முடியும், இது குறிப்பாக பயனுள்ளதாக இல்லை. ஆனால், ஐந்தாவது அமர்வில் இருந்து, ஒவ்வொன்றிற்கும் $5 செலுத்த வேண்டும். நிலைமை நிறுவனத்திற்கு நிறுவனம் வேறுபடலாம், ஆனால் எங்கள் விஷயத்தில், சந்திரனைப் பயன்படுத்துவது அர்த்தமற்றது. நான் மேலே விவரித்தபடி, தேவைக்கேற்ப செலினியம் கிரிட் மூலம் VMகளை இயக்கலாம் அல்லது கிளஸ்டரில் உள்ள முனைகளின் எண்ணிக்கையை அதிகரிக்கலாம். தோராயமாக ஒரு பைப்லைனுக்கு, நாங்கள் 500 உலாவிகளைத் தொடங்குகிறோம் மற்றும் சோதனைகள் முடிந்ததும் அனைத்து ஆதாரங்களையும் நிறுத்துகிறோம். நாம் சந்திரனைப் பயன்படுத்தினால், எவ்வளவு அடிக்கடி சோதனைகளை நடத்தினாலும், மாதத்திற்கு 500 x 5 = $2500 கூடுதலாக செலுத்த வேண்டியிருக்கும். மீண்டும், நான் சந்திரனைப் பயன்படுத்த வேண்டாம் என்று சொல்லவில்லை. உங்கள் பணிகளுக்கு, இது ஒரு தவிர்க்க முடியாத தீர்வாக இருக்கலாம், எடுத்துக்காட்டாக, உங்கள் நிறுவனத்தில் பல திட்டங்கள்/குழுக்கள் இருந்தால், அனைவருக்கும் ஒரு பெரிய பொதுவான கிளஸ்டர் தேவைப்பட்டால். எப்போதும் போல, நான் ஒரு இணைப்பை இறுதியில் விட்டுவிட்டு, உங்கள் பணியின் சூழலில் தேவையான அனைத்து கணக்கீடுகளையும் செய்ய பரிந்துரைக்கிறேன்.

கால்லிச்டோ: (கவனம்! இது அசல் கட்டுரையில் இல்லை மற்றும் ரஷ்ய மொழிபெயர்ப்பில் மட்டுமே உள்ளது)

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

உள்கட்டமைப்பின் தற்போதைய நிலையின் விளக்கம்

DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

ஆராய்வதற்கான இணைப்புகள்

ஒத்த கருவிகள்

7. உள்கட்டமைப்பு குறியீடு (IaC)

தொழில்நுட்பத்தின் சுருக்கமான விளக்கம்

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

இந்த அணுகுமுறையைப் பயன்படுத்துவதற்கான உந்துதலுடன் ஆரம்பிக்கலாம். கிட்லாப்சிஐயில் சோதனைகளை நடத்த, கிட்லாப் ரன்னரை இயக்க குறைந்தபட்ச ஆதாரங்கள் தேவை என்று நாங்கள் ஏற்கனவே விவாதித்துள்ளோம். உலாவிகள்/முன்மாதிரிகளுடன் கண்டெய்னர்களை இயக்க, நாம் ஒரு VM அல்லது கிளஸ்டரை முன்பதிவு செய்ய வேண்டும். ஆதாரங்களைச் சோதிப்பதைத் தவிர, மேம்பாடு, நிலைப்படுத்தல், உற்பத்திச் சூழல்களை ஆதரிப்பதற்கான கணிசமான அளவு திறன் எங்களுக்குத் தேவை, இதில் தரவுத்தளங்கள், தானியங்கி அட்டவணைகள், நெட்வொர்க் உள்ளமைவுகள், சுமை சமநிலைகள், பயனர் உரிமைகள் மற்றும் பலவும் அடங்கும். அதையெல்லாம் ஆதரிக்க வேண்டிய முயற்சிதான் முக்கியப் பிரச்சினை. மாற்றங்களைச் செய்வதற்கும் புதுப்பிப்புகளை வெளியிடுவதற்கும் பல வழிகள் உள்ளன. எடுத்துக்காட்டாக, GCP இன் சூழலில், உலாவியில் UI கன்சோலைப் பயன்படுத்தலாம் மற்றும் பொத்தான்களைக் கிளிக் செய்வதன் மூலம் அனைத்து செயல்களையும் செய்யலாம். கிளவுட் நிறுவனங்களுடன் தொடர்பு கொள்ள API அழைப்புகளைப் பயன்படுத்துவது அல்லது விரும்பிய கையாளுதல்களைச் செய்ய gCloud கட்டளை வரி பயன்பாட்டைப் பயன்படுத்துவது ஒரு மாற்றாக இருக்கும். ஆனால் உண்மையில் அதிக எண்ணிக்கையிலான பல்வேறு நிறுவனங்கள் மற்றும் உள்கட்டமைப்பு கூறுகள் இருப்பதால், அனைத்து செயல்பாடுகளையும் கைமுறையாகச் செய்வது கடினம் அல்லது சாத்தியமற்றது. மேலும், இந்த கையேடு செயல்கள் அனைத்தும் கட்டுப்படுத்த முடியாதவை. செயல்படுத்துவதற்கு முன் அவற்றை மதிப்பாய்வுக்கு சமர்ப்பிக்க முடியாது, பதிப்புக் கட்டுப்பாட்டு அமைப்பைப் பயன்படுத்த முடியாது, மேலும் சம்பவத்திற்கு வழிவகுத்த மாற்றங்களை விரைவாகப் பின்வாங்க முடியாது. இத்தகைய சிக்கல்களைத் தீர்க்க, பொறியாளர்கள் தானியங்கி பாஷ்/ஷெல் ஸ்கிரிப்ட்களை உருவாக்கி உருவாக்கினர், அவை முந்தைய முறைகளை விட மிகச் சிறந்தவை அல்ல, ஏனெனில் அவை விரைவாகப் படிக்கவும், புரிந்து கொள்ளவும், பராமரிக்கவும் மற்றும் நடைமுறை பாணியில் மாற்றியமைக்கவும் எளிதானவை அல்ல.

இந்த கட்டுரையில் மற்றும் எப்படி வழிகாட்டுவது, IaC நடைமுறை தொடர்பான 2 கருவிகளைப் பயன்படுத்துகிறேன். இவை டெர்ராஃபார்ம் மற்றும் அன்சிபிள். சிலர் ஒரே நேரத்தில் அவற்றைப் பயன்படுத்துவதில் அர்த்தமில்லை என்று நம்புகிறார்கள், ஏனெனில் அவற்றின் செயல்பாடு ஒரே மாதிரியானது மற்றும் அவை ஒன்றுக்கொன்று மாறக்கூடியவை. ஆனால் உண்மை என்னவென்றால், ஆரம்பத்தில் அவர்களுக்கு முற்றிலும் மாறுபட்ட பணிகள் வழங்கப்படுகின்றன. இந்த கருவிகள் ஒன்றுக்கொன்று பூர்த்தி செய்ய வேண்டும் என்பது HashiCorp மற்றும் RedHat ஐ பிரதிநிதித்துவப்படுத்தும் டெவலப்பர்களால் ஒரு கூட்டு விளக்கக்காட்சியில் உறுதிப்படுத்தப்பட்டது. கருத்தியல் வேறுபாடு என்னவென்றால், டெர்ராஃபார்ம் என்பது சேவையகங்களை நிர்வகிப்பதற்கான ஒரு வழங்கல் கருவியாகும். அன்சிபிள் என்பது ஒரு உள்ளமைவு மேலாண்மை கருவியாகும், இதன் பணி இந்த சேவையகங்களில் மென்பொருளை நிறுவுதல், கட்டமைத்தல் மற்றும் நிர்வகித்தல்.

இந்த கருவிகளின் மற்றொரு முக்கிய தனித்துவமான அம்சம் குறியீட்டு பாணி. பாஷ் மற்றும் அன்சிபிள் போலல்லாமல், டெர்ராஃபார்ம் செயல்பாட்டின் விளைவாக அடைய விரும்பும் இறுதி நிலையின் விளக்கத்தின் அடிப்படையில் ஒரு அறிவிப்பு பாணியைப் பயன்படுத்துகிறது. எடுத்துக்காட்டாக, நாம் 10 விஎம்களை உருவாக்கி, டெர்ராஃபார்ம் மூலம் மாற்றங்களைப் பயன்படுத்தப் போகிறோம் என்றால், நமக்கு 10 விஎம்கள் கிடைக்கும். ஸ்கிரிப்டை மீண்டும் இயக்கினால், எங்களிடம் ஏற்கனவே 10 விஎம்கள் இருப்பதால் எதுவும் நடக்காது, மேலும் டெர்ராஃபார்ம் இதைப் பற்றி அறிந்திருக்கிறது, ஏனெனில் இது உள்கட்டமைப்பின் தற்போதைய நிலையை மாநில கோப்பில் சேமித்து வைக்கிறது. ஆனால் அன்சிபிள் ஒரு நடைமுறை அணுகுமுறையைப் பயன்படுத்துகிறது, மேலும் 10 விஎம்களை உருவாக்குமாறு நீங்கள் கேட்டால், முதல் வெளியீட்டில் டெர்ராஃபார்மைப் போலவே 10 விஎம்களைப் பெறுவோம். ஆனால் மறுதொடக்கம் செய்த பிறகு எங்களிடம் ஏற்கனவே 20 VMகள் இருக்கும். இதுதான் முக்கியமான வேறுபாடு. நடைமுறை பாணியில், நாங்கள் தற்போதைய நிலையைச் சேமிக்க மாட்டோம் மற்றும் செய்ய வேண்டிய படிகளின் வரிசையை விவரிக்கிறோம். நிச்சயமாக, நாம் பல்வேறு சூழ்நிலைகளைக் கையாளலாம், வளங்களின் இருப்பு மற்றும் தற்போதைய நிலைக்கு பல காசோலைகளைச் சேர்க்கலாம், ஆனால் இந்த தர்க்கத்தைக் கட்டுப்படுத்துவதில் நம் நேரத்தை வீணடிப்பதில் எந்த அர்த்தமும் இல்லை. கூடுதலாக, இது தவறு செய்யும் அபாயத்தை அதிகரிக்கிறது. 

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

ஆட்டோமேஷன் உள்கட்டமைப்புக்கான மதிப்பு

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

சோதனை ஆட்டோமேஷனின் சூழலில் Terraform மற்றும் Ansible ஐப் பயன்படுத்துவதற்கான சில எடுத்துக்காட்டுகள் மற்றும் நாங்கள் முன்பு விவாதித்த கருவிகள்:

1. Terraform ஐப் பயன்படுத்தி VMகள் மற்றும் கிளஸ்டர்களின் தேவையான பண்புகள் மற்றும் அளவுருக்களை விவரிக்கவும்.

2. Ansible ஐப் பயன்படுத்தி, சோதனைக்குத் தேவையான கருவிகளை நிறுவவும்: docker, Selenoid, Selenium Grid மற்றும் உலாவிகள்/முன்மாதிரிகளின் தேவையான பதிப்புகளைப் பதிவிறக்கவும்.

3. Terraform ஐப் பயன்படுத்தி, GitLab Runner தொடங்கப்படும் VM இன் பண்புகளை விவரிக்கவும்.

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

உள்கட்டமைப்பின் தற்போதைய நிலையின் விளக்கம்

DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

ஆராய்வதற்கான இணைப்புகள்:

ஒத்த கருவிகள்

சுருக்கமாகச் சொல்லலாம்!

படி
தொழில்நுட்ப
கருவிகள்
ஆட்டோமேஷன் உள்கட்டமைப்புக்கான மதிப்பு

1
உள்ளூர் ஓட்டம்
Node.js, செலினியம், அப்பியம்

  • இணையம் மற்றும் மொபைலுக்கான மிகவும் பிரபலமான கருவிகள்
  • பல மொழிகள் மற்றும் தளங்களை ஆதரிக்கிறது (Node.js உட்பட)

2
பதிப்பு கட்டுப்பாட்டு அமைப்புகள் 
Git தகவல்

  • வளர்ச்சிக் குறியீட்டுடன் இதே போன்ற பலன்கள்

3
கொள்கலன்மயமாக்கல்
டோக்கர், செலினியம் கட்டம், செலினாய்டு (இணையம், ஆண்ட்ராய்டு)

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

4
CI/CD
கிட்லாப் சிஐ

  • குழாயின் ஒரு பகுதியை சோதிக்கிறது
  • விரைவான கருத்து
  • முழு நிறுவனம்/குழுவிற்கான தெரிவுநிலை

5
மேகக்கணி தளங்கள்
Google மேகக்கணி இயங்குதளம்

  • தேவைக்கேற்ப வளங்கள் (தேவைப்படும் போது மட்டுமே நாங்கள் செலுத்துகிறோம்)
  • நிர்வகிக்க மற்றும் புதுப்பிக்க எளிதானது
  • அனைத்து வளங்களின் பார்வை மற்றும் கட்டுப்பாடு

6
இசைக்குழு
Kubernetes
காய்களுக்குள் உலாவிகள்/முன்மாதிரிகள் கொண்ட கொள்கலன்களின் சூழலில்:

  • அளவிடுதல்/தானியங்கு அளவிடுதல்
  • சுய சிகிச்சைமுறை
  • தடையின்றி புதுப்பிப்புகள் மற்றும் திரும்பப் பெறுதல்

7
ஒரு குறியீடாக உள்கட்டமைப்பு (IaC)
டெர்ராஃபார்ம், அன்சிபிள்

  • வளர்ச்சி உள்கட்டமைப்பு போன்ற நன்மைகள்
  • குறியீடு பதிப்பின் அனைத்து நன்மைகளும்
  • மாற்றங்களைச் செய்வது மற்றும் பராமரிப்பது எளிது
  • முழுமையாக தானியங்கி

மன வரைபட வரைபடங்கள்: உள்கட்டமைப்பின் பரிணாமம்

படி 1: உள்ளூர்
DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

படி 2: VCS
DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

படி 3: கொள்கலன் 
DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

படி 4: CI/CD 
DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

படி 5: கிளவுட் இயங்குதளங்கள்
DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

படி 6: ஆர்கெஸ்ட்ரேஷன்
DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

படி 7: IaC
DevOps கருவிகள் DevOps க்கு மட்டும் அல்ல. புதிதாக ஒரு சோதனை ஆட்டோமேஷன் உள்கட்டமைப்பை உருவாக்கும் செயல்முறை

அடுத்து என்ன?

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

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

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

என் பக்கத்தில் இருந்து

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

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

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

ஆதாரம்: www.habr.com

கருத்தைச் சேர்