ஸ்கிரிப்ட்கள் முதல் எங்கள் சொந்த இயங்குதளம் வரை: CIAN இல் வளர்ச்சியை எவ்வாறு தானியக்கமாக்கினோம்

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

பூஜ்ஜிய நிலை

"பூஜ்ஜிய நிலை என்று எதுவும் இல்லை, எனக்கு அப்படி ஒன்றும் தெரியாது"
"குங் ஃபூ பாண்டா" படத்தின் மாஸ்டர் ஷிஃபு

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

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

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

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

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

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

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

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

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

நாங்கள் சோதனையை தானியங்குபடுத்துகிறோம்

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

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

ஆட்டோமேஷன் குழு

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

CIAN தளத்தின் Dev/Beta சூழலுக்கு DevOps பொறுப்பாகும், ஒருங்கிணைந்த சூழல், டெவலப்பர்கள் சிக்கல்களைத் தீர்க்க உதவுகிறது மற்றும் அளவிடும் சூழல்களுக்கு புதிய அணுகுமுறைகளை உருவாக்குகிறது. Integro டெவலப்மெண்ட் திசையானது Integro மற்றும் தொடர்புடைய சேவைகள் இரண்டையும் கையாள்கிறது, எடுத்துக்காட்டாக, Jenkins, Jira, Confluence க்கான செருகுநிரல்கள் மற்றும் மேம்பாட்டுக் குழுக்களுக்கான துணைப் பயன்பாடுகள் மற்றும் பயன்பாடுகளையும் உருவாக்குகிறது. 

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

CIAN இல் ஆட்டோமேஷனின் லேயர் கேக்

ஆட்டோமேஷனில் ஈடுபட்டுள்ள அனைத்து அமைப்புகளையும் பல அடுக்குகளாகப் பிரிக்கலாம்:

1. வெளிப்புற அமைப்புகள் (ஜிரா, பிட்பக்கெட், முதலியன). மேம்பாட்டுக் குழுக்கள் அவர்களுடன் இணைந்து செயல்படுகின்றன.
2. ஒருங்கிணைந்த தளம். பெரும்பாலும், டெவலப்பர்கள் அதனுடன் நேரடியாக வேலை செய்வதில்லை, ஆனால் அதுவே அனைத்து ஆட்டோமேஷனையும் இயங்க வைக்கிறது.
3. டெலிவரி, ஆர்கெஸ்ட்ரேஷன் மற்றும் கண்டுபிடிப்பு சேவைகள் (உதாரணமாக, ஜெக்னின்ஸ், கான்சல், நாடோடி). அவர்களின் உதவியுடன், நாங்கள் சேவையகங்களில் குறியீட்டைப் பயன்படுத்துகிறோம் மற்றும் சேவைகள் ஒன்றோடொன்று செயல்படுவதை உறுதிசெய்கிறோம்.
4. இயற்பியல் அடுக்கு (சர்வர்கள், OS, தொடர்புடைய மென்பொருள்). எங்கள் குறியீடு இந்த மட்டத்தில் செயல்படுகிறது. இது இயற்பியல் சேவையகம் அல்லது மெய்நிகர் (LXC, KVM, Docker) ஆக இருக்கலாம்.

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

அப்படியே

இன்டெக்ரோவில் கவனம் செலுத்தி, தொழில்நுட்ப அடுக்கில் தொடங்குவோம்:

• CentOS 7
• டோக்கர் + நாடோடி + கன்சல் + வால்ட்
• ஜாவா 11 (பழைய இண்டிக்ரோ மோனோலித் ஜாவா 8 இல் இருக்கும்)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• முயல்MQ 
• அப்பாச்சி பற்றவைப்பு
• கமுண்டா (உட்பொதிக்கப்பட்ட)
• கிராஃபானா + கிராஃபைட் + ப்ரோமிதியஸ் + ஜெகர் + ELK
• Web UI: React (CSR) + MobX
• SSO: கீக்ளோக்

மைக்ரோ சர்வீஸ் மேம்பாட்டின் கொள்கையை நாங்கள் கடைபிடிக்கிறோம், இருப்பினும் இன்டிக்ரோவின் ஆரம்ப பதிப்பின் ஒற்றைப்பாதை வடிவத்தில் எங்களிடம் உள்ளது. ஒவ்வொரு மைக்ரோ சர்வீஸும் அதன் சொந்த டோக்கர் கொள்கலனில் இயங்குகிறது, மேலும் சேவைகள் HTTP கோரிக்கைகள் மற்றும் RabbitMQ செய்திகள் மூலம் ஒருவருக்கொருவர் தொடர்பு கொள்கின்றன. மைக்ரோ சர்வீஸ்கள் ஒருவரையொருவர் தூதரகத்தின் மூலம் கண்டுபிடித்து, SSO (Keycloak, OAuth 2/OpenID கனெக்ட்) மூலம் அங்கீகாரம் அளிக்கும் கோரிக்கையை முன்வைக்கின்றன.

நிஜ வாழ்க்கை உதாரணமாக, பின்வரும் படிகளைக் கொண்ட ஜென்கின்ஸ் உடன் தொடர்புகொள்வதைக் கவனியுங்கள்:

1. பணிப்பாய்வு மேலாண்மை மைக்ரோ சர்வீஸ் (இனி ஃப்ளோ மைக்ரோ சர்வீஸ் என குறிப்பிடப்படுகிறது) ஜென்கின்ஸ் ஒரு கட்டமைப்பை இயக்க விரும்புகிறது. இதைச் செய்ய, ஜென்கின்ஸ் உடன் ஒருங்கிணைக்க மைக்ரோ சர்வீஸின் IP:PORT ஐக் கண்டறிய அவர் தூதரகத்தைப் பயன்படுத்துகிறார் (இனிமேல் ஜென்கின்ஸ் மைக்ரோ சர்வீஸ் என குறிப்பிடப்படுகிறது) மற்றும் ஜென்கின்ஸ் உருவாக்கத்தைத் தொடங்குவதற்கு ஒத்திசைவற்ற கோரிக்கையை அனுப்புகிறார்.
2. ஒரு கோரிக்கையைப் பெற்ற பிறகு, ஜென்கின்ஸ் மைக்ரோ சர்வீஸ் ஒரு வேலை ஐடியை உருவாக்கி பதிலளிக்கிறது, இது வேலையின் முடிவைக் கண்டறியப் பயன்படும். அதே நேரத்தில், இது REST API அழைப்பு மூலம் ஜென்கின்ஸ் கட்டமைப்பைத் தூண்டுகிறது.
3. ஜென்கின்ஸ் கட்டமைக்கிறார், முடிந்ததும், ஜென்கின்ஸ் மைக்ரோ சர்வீஸுக்கு மரணதண்டனை முடிவுகளுடன் ஒரு வெப்ஹூக்கை அனுப்புகிறார்.
4. ஜென்கின்ஸ் மைக்ரோ சர்வீஸ், வெப்ஹூக்கைப் பெற்ற பிறகு, கோரிக்கை செயலாக்கத்தை முடித்தது பற்றிய செய்தியை உருவாக்கி, அதனுடன் செயல்படுத்தல் முடிவுகளை இணைக்கிறது. உருவாக்கப்பட்ட செய்தி RabbitMQ வரிசைக்கு அனுப்பப்பட்டது.
5. RabbitMQ மூலம், வெளியிடப்பட்ட செய்தி ஃப்ளோ மைக்ரோ சர்வீஸை அடைகிறது, இது கோரிக்கை மற்றும் பெறப்பட்ட செய்தியிலிருந்து வேலை ஐடியைப் பொருத்துவதன் மூலம் அதன் பணியைச் செயலாக்குவதன் முடிவைப் பற்றி அறியும்.

இப்போது எங்களிடம் சுமார் 30 மைக்ரோ சர்வீஸ்கள் உள்ளன, அவை பல குழுக்களாக பிரிக்கப்படலாம்:

1. கட்டமைப்பு மேலாண்மை.
2. பயனர்களுடனான தகவல் மற்றும் தொடர்பு (தூதர்கள், அஞ்சல்).
3. மூலக் குறியீட்டுடன் பணிபுரிதல்.
4. வரிசைப்படுத்தல் கருவிகளுடன் ஒருங்கிணைப்பு (ஜென்கின்ஸ், நாடோடி, கன்சல், முதலியன).
5. கண்காணிப்பு (வெளியீடுகள், பிழைகள், முதலியன).
6. இணையப் பயன்பாடுகள் (சோதனை சூழல்களை நிர்வகிப்பதற்கான UI, புள்ளிவிவரங்களைச் சேகரிப்பது போன்றவை).
7. பணி கண்காணிப்பாளர்கள் மற்றும் ஒத்த அமைப்புகளுடன் ஒருங்கிணைப்பு.
8. வெவ்வேறு பணிகளுக்கான பணிப்பாய்வு மேலாண்மை.

பணிப்பாய்வு பணிகள்

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

நாம் அடிக்கடி பயன்படுத்தும் பணிப்பாய்வுகளைப் பார்ப்போம்:

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

கேனரி சோதனைகள் இல்லாமல் DEV+BETA இல் முழுமையாக கைமுறையாகச் சோதனை செய்தல் (வழக்கமாக இப்படித்தான் ஒரு மோனோலித்தை வெளியிடுகிறோம்):

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

பணி இயக்கம்

"DEV சோதனை + கேனரி சோதனைகள்" பணிப்பாய்வு மூலம் ஒரு பணி நகரும் போது செய்யப்படும் முக்கிய படிகளைப் பார்ப்போம்:

1. டெவலப்பர் அல்லது PM பணியை உருவாக்குகிறது.

2. டெவலப்பர் பணியை எடுத்துச் செல்கிறார். முடிந்ததும், அது IN REVIEW நிலைக்கு மாறுகிறது.

3. ஜிரா ஜிரா மைக்ரோ சர்வீஸுக்கு ஒரு வெப்ஹூக்கை அனுப்புகிறார் (ஜிராவுடன் ஒருங்கிணைப்பதற்கு பொறுப்பு).

4. ஜிரா மைக்ரோ சர்வீஸ் ஃப்ளோ சேவைக்கு (வேலை செய்யப்படும் உள் பணிப்பாய்வுகளுக்குப் பொறுப்பு) பணிப்பாய்வுகளைத் தொடங்க ஒரு கோரிக்கையை அனுப்புகிறது.

5. ஃப்ளோ சேவையின் உள்ளே:

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

  i) முதன்மைக் கிளையைப் புதுப்பித்தல் (குறியீட்டுடன் பணிபுரியும் Git microservice).
  ii) டெவலப்பர் (பிட்பக்கெட் மைக்ரோ சர்வீஸ்) மூலம் மாற்றங்களிலிருந்து கிளை தடுக்கப்பட்டது.
  iii) இந்தக் கிளைக்காக ஒரு இழுப்புக் கோரிக்கை உருவாக்கப்பட்டது (பிட்பக்கெட் மைக்ரோ சர்வீஸ்).
  iv) புதிய இழுத்தல் கோரிக்கை பற்றிய செய்தி டெவலப்பர் அரட்டைகளுக்கு அனுப்பப்படுகிறது (அறிவிப்புகளுடன் பணிபுரிய மைக்ரோ சர்வீஸுக்கு அறிவிக்கவும்).
  v) DEV (ஜென்கின்ஸ் உடன் பணிபுரிவதற்கான ஜென்கின்ஸ் மைக்ரோ சர்வீஸ்) இல் பணிகளை உருவாக்குதல், சோதனை செய்தல் மற்றும் வரிசைப்படுத்துதல் ஆகியவை தொடங்கப்படுகின்றன.
  vi) முந்தைய அனைத்து படிகளும் வெற்றிகரமாக முடிந்தால், Integro அதன் அனுமதியை இழுக்கும் கோரிக்கையில் (Bitbucket microservice) வைக்கிறது.

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

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

7. Integro பணி வெளியீட்டிற்குத் தயாராக இருப்பதை "பார்க்கிறது" மற்றும் கேனரி பயன்முறையில் (ஜென்கின்ஸ் மைக்ரோ சர்வீஸ்) அதன் வரிசைப்படுத்தலைத் தொடங்குகிறது. வெளியீட்டிற்கான தயார்நிலை விதிகளின் தொகுப்பால் தீர்மானிக்கப்படுகிறது. எடுத்துக்காட்டாக, பணி தேவையான நிலையில் உள்ளது, பிற பணிகளில் பூட்டுகள் இல்லை, இந்த மைக்ரோ சர்வீஸின் செயலில் பதிவேற்றங்கள் எதுவும் இல்லை, முதலியன.

8. பணி கேனரி நிலைக்கு மாற்றப்படுகிறது (ஜிரா மைக்ரோ சர்வீஸ்).

9. ஜென்கின்ஸ் நோமட் மூலம் கேனரி பயன்முறையில் (பொதுவாக 1-3 நிகழ்வுகள்) வரிசைப்படுத்தல் பணியைத் தொடங்குகிறார் மற்றும் வரிசைப்படுத்தல் குறித்து வெளியீட்டு கண்காணிப்பு சேவைக்கு (DeployWatch microservice) தெரிவிக்கிறார்.

10. DeployWatch microservice பிழை பின்னணியைச் சேகரித்து, தேவைப்பட்டால், அதற்கு எதிர்வினையாற்றுகிறது. பிழை பின்னணி மீறப்பட்டால் (பின்னணி விதிமுறை தானாக கணக்கிடப்படும்), டெவலப்பர்களுக்கு Notify microservice மூலம் அறிவிக்கப்படும். 5 நிமிடங்களுக்குப் பிறகு டெவலப்பர் பதிலளிக்கவில்லை என்றால் (திரும்பவும் அல்லது தங்கவும் என்பதைக் கிளிக் செய்யவும்), கேனரி நிகழ்வுகளின் தானியங்கு பின்னடைவு தொடங்கப்படும். பின்னணியை மீறவில்லை எனில், டெவலப்பர் பணி வரிசைப்படுத்தலை உற்பத்திக்கு கைமுறையாகத் தொடங்க வேண்டும் (UI இல் உள்ள பொத்தானைக் கிளிக் செய்வதன் மூலம்). 60 நிமிடங்களுக்குள் டெவெலப்பர் உற்பத்திக்கான வரிசைப்படுத்தலைத் தொடங்கவில்லை என்றால், பாதுகாப்பு காரணங்களுக்காக கேனரி நிகழ்வுகளும் திரும்பப் பெறப்படும்.

11. உற்பத்திக்கான வரிசைப்படுத்தலைத் தொடங்கிய பிறகு:

• பணி உற்பத்தி நிலைக்கு மாற்றப்பட்டது (ஜிரா மைக்ரோ சர்வீஸ்).
• ஜென்கின்ஸ் மைக்ரோ சர்வீஸ் வரிசைப்படுத்தல் செயல்முறையைத் தொடங்குகிறது மற்றும் வரிசைப்படுத்தல் பற்றி DeployWatch மைக்ரோ சர்வீஸுக்கு தெரிவிக்கிறது.
• DeployWatch மைக்ரோ சர்வீஸ் தயாரிப்பில் உள்ள அனைத்து கொள்கலன்களும் புதுப்பிக்கப்பட்டுள்ளதா என்பதைச் சரிபார்க்கிறது (அனைத்தும் புதுப்பிக்கப்படாத சந்தர்ப்பங்களும் உள்ளன).
• Notify microservice மூலம், வரிசைப்படுத்தலின் முடிவுகள் பற்றிய அறிவிப்பு உற்பத்திக்கு அனுப்பப்படும்.

12. தவறான மைக்ரோ சர்வீஸ் நடத்தை கண்டறியப்பட்டால், தயாரிப்பிலிருந்து ஒரு பணியைத் திரும்பப் பெற டெவலப்பர்களுக்கு 30 நிமிடங்கள் இருக்கும். இந்த நேரத்திற்குப் பிறகு, பணி தானாகவே முதன்மையாக (Git microservice) இணைக்கப்படும்.

13. மாஸ்டரில் வெற்றிகரமாக இணைந்த பிறகு, பணி நிலை மூடப்பட்டதாக மாற்றப்படும் (ஜிரா மைக்ரோ சர்வீஸ்).

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

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

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

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

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