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

உங்கள் குறியீட்டை எழுதியவுடன், அதை உறுதிசெய்ய வேண்டும்:

1. இது வேலை செய்கிறது.
2. இது உங்கள் சக ஊழியர்கள் எழுதிய குறியீடு உட்பட எதையும் உடைக்காது.

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

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

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

Avito மொபைல் டெவலப்மென்ட் குழுவில் தொடர்ச்சியான ஒருங்கிணைப்பு எவ்வாறு செயல்படுத்தப்பட்டது மற்றும் உருவாக்கப்பட்டது, அவை ஒரு நாளைக்கு 0 முதல் 450 பில்ட்கள் வரை சென்றது மற்றும் ஒரு நாளைக்கு 200 மணிநேரம் கூடும் இயந்திரங்களை உருவாக்குகிறது என்று நிகோலாய் நெஸ்டெரோவ் கூறுகிறார் (nnesterov) CI/CD ஆண்ட்ராய்டு பயன்பாட்டின் அனைத்து பரிணாம மாற்றங்களிலும் பங்கேற்பவர்.

கதை Android கட்டளையின் உதாரணத்தை அடிப்படையாகக் கொண்டது, ஆனால் பெரும்பாலான அணுகுமுறைகள் iOS க்கும் பொருந்தும்.

ஒரு காலத்தில், ஒருவர் Avito Android குழுவில் பணிபுரிந்தார். வரையறையின்படி, அவருக்கு தொடர்ச்சியான ஒருங்கிணைப்பிலிருந்து எதுவும் தேவையில்லை: ஒருங்கிணைக்க யாரும் இல்லை.

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

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

காசோலைகளை

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

• முதலில், நாங்கள் சரிபார்க்கிறோம் ARK சட்டசபை.
• நிறைய ஜூனிட் சோதனைகள்.
• குறியீடு கவரேஜை நாங்கள் கருதுகிறோம், நாங்கள் சோதனைகளை நடத்துவதால்.

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

இது பின்வருமாறு திட்டவட்டமாக குறிப்பிடப்படலாம்:

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

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

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

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

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

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

அடிப்படை சிஐயை முழுமையாக அமைக்க எங்களுக்கு இரண்டு நாட்கள் பிடித்தது (இனி நேர மதிப்பீடு தோராயமாக இருக்கும், அளவுகோலுக்குத் தேவை).

அதன் பிறகு, நாங்கள் மேலும் சிந்திக்க ஆரம்பித்தோம் - நாங்கள் சரியாக சரிபார்க்கிறோமா? இழுக்கும் கோரிக்கைகளை நாங்கள் சரியாக இயக்குகிறோமா?

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

இதைச் செய்ய, நாங்கள் ஒரு எளிய பாஷ் ஸ்கிரிப்டை எழுதினோம் premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

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

பிரச்சனையை உள்ளூர்மயமாக்கவும், தீர்வு காணவும், இந்த ஸ்கிரிப்டை எழுதவும் மூன்று நாட்கள் ஆனது.

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

இது எவ்வாறு நிகழ்கிறது என்பதற்கான எடுத்துக்காட்டு:

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

டெவலப்பர்கள் தங்கள் வேலையை முடித்துவிட்டு, ஒரே நேரத்தில் இழுக்கும் கோரிக்கையைத் திறக்கிறார்கள். உருவாக்கங்கள் தொடங்கப்பட்டன, premerge.sh சமீபத்திய டெவலப் ஸ்டேட் தொடர்பான இரண்டு கோரிக்கைகளையும் சரிபார்க்கிறது - அனைத்து காசோலைகளும் பச்சை நிறத்தில் உள்ளன. அதன் பிறகு, அம்சம் A இன் இழுக்கும் கோரிக்கை இணைக்கப்பட்டது, அம்சம் B இன் இழுத்தல் கோரிக்கை ஒன்றிணைக்கப்படுகிறது... பூம்! டெவலப் குறியீட்டில் இல்லாத செயல்பாட்டிற்கான அழைப்பு இருப்பதால் இடைவேளைகளை உருவாக்கவும்.

அது வளர்ச்சியடையாதபோது, ​​​​அது உள்ளூர் பேரழிவு. முழு குழுவும் எதையும் சேகரித்து சோதனைக்கு சமர்ப்பிக்க முடியாது.

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

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

வளர்ச்சியை எப்படி உடைக்கக்கூடாது

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

இது எவ்வளவு நேரம் எடுக்கும் என்பதைப் புரிந்து கொள்ள, இரண்டு PRகளுடன் ஒரு உதாரணத்தைக் கவனியுங்கள். நாங்கள் இரண்டு PRகளை திறக்கிறோம்: இரண்டு கட்டங்கள், இரண்டு ரன் காசோலைகள். முதல் PR உருவாக்கத்தில் இணைக்கப்பட்ட பிறகு, இரண்டாவது மீண்டும் உருவாக்கப்பட வேண்டும். மொத்தத்தில், இரண்டு PRகளுக்கு மூன்று ரன் காசோலைகள் தேவை: 2 + 1 = 3.

கொள்கையளவில், அது நன்றாக இருக்கிறது. ஆனால் நாங்கள் புள்ளிவிவரங்களைப் பார்த்தோம், எங்கள் குழுவில் வழக்கமான சூழ்நிலை 10 திறந்த PRகளாக இருந்தது, பின்னர் காசோலைகளின் எண்ணிக்கை முன்னேற்றத்தின் கூட்டுத்தொகை: 10 + 9 +... + 1 = 55. அதாவது, 10 ஐ ஏற்றுக்கொள்வது PRகள், நீங்கள் 55 முறை மீண்டும் உருவாக்க வேண்டும். மேலும் இது ஒரு சிறந்த சூழ்நிலையில் உள்ளது, அனைத்து காசோலைகளும் முதல் முறையாக கடந்து செல்லும் போது, ​​இந்த டஜன் செயல்படுத்தப்படும் போது யாரும் கூடுதல் இழுப்பு கோரிக்கையைத் திறக்கவில்லை.

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

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

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

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

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

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

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

Bitbucket செருகுநிரலின் முதல் பதிப்பை எழுத எங்களுக்கு இரண்டு வாரங்கள் ஆனது.

புதிய காசோலைகள்

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

நாங்கள் நினைத்தோம்: தடுக்க முடிந்தால் தவறுகளை ஏன் செய்ய வேண்டும்? அதனால்தான் செயல்படுத்தினார்கள் நிலையான குறியீடு பகுப்பாய்வு. ஆண்ட்ராய்டு SDK இல் சேர்க்கப்பட்டுள்ள லின்ட் உடன் தொடங்கினோம். ஆனால் அந்த நேரத்தில் அவருக்கு கோட்லின் குறியீட்டுடன் எவ்வாறு வேலை செய்வது என்று தெரியவில்லை, மேலும் எங்களிடம் ஏற்கனவே 75% விண்ணப்பம் கோட்லினில் எழுதப்பட்டது. எனவே, உள்ளமைக்கப்பட்டவை பஞ்சில் சேர்க்கப்பட்டன Android Studio சோதனைகள்.

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

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

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

ஃபயர்பேஸ் சோதனை ஆய்வகம்

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

எங்கள் CI இல் Firebase சோதனை ஆய்வகத்தை செயல்படுத்த தோராயமாக மூன்று வாரங்கள் ஆனது.

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

டோக்கர் + பைதான் + பாஷ்

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

எங்கள் சொந்த சோதனை சூழலை உருவாக்க ஐந்து வாரங்கள் ஆனது.

இதன் விளைவாக, ஒவ்வொரு இழுக்கும் கோரிக்கைக்கும் காசோலைகளின் விரிவான ஒன்றிணைப்பு-தடுப்பு பட்டியல் இருந்தது:

• ARK சட்டசபை;
• ஜூனிட் சோதனைகள்;
• லிண்ட்;
• Android Studio சோதனைகள்;
• கருவி சோதனைகள்;
• ஸ்கிரீன்ஷாட் சோதனைகள்.

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

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

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

வேகப்படுத்துவோம்

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

அதிக நேரம் எடுக்கும் காசோலைகளை நீக்குகிறது

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

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

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

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

இதன் விளைவாக, நாங்கள் எஞ்சியுள்ளோம்:

• ARK சட்டசபை;
• ஜூனிட் சோதனைகள்;
• கருவி சோதனைகள்.

கிரேடில் ரிமோட் கேச்

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

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

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

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

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

கேச் மிஸ்ஸ் வரைபடம் கீழே உள்ளது.

ஆரம்பத்தில், கேச் மிஸ்ஸின் சதவீதம் சுமார் 65 ஆக இருந்தது. மூன்று வாரங்களுக்குப் பிறகு, இந்த மதிப்பை 20% ஆக அதிகரிக்க முடிந்தது. Android பயன்பாடு சேகரிக்கும் பணிகள் விசித்திரமான இடைநிலை சார்புகளைக் கொண்டுள்ளன, இதன் காரணமாக கிரேடில் தற்காலிக சேமிப்பை தவறவிட்டார்.

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

தாக்க பகுப்பாய்வு

இழுக்கும் கோரிக்கையின் பேரில், நாங்கள் git diffஐச் சேகரித்து, மாற்றியமைக்கப்பட்ட Gradle தொகுதிக்கூறுகளைக் கண்டறிவோம்.

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

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

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

சோதனைகளை விரைவுபடுத்துவதற்கான நடவடிக்கைகள் வெற்றிகரமாகச் செயல்பட்டன. 45 நிமிடங்களில் இருந்து சுமார் 15 வரை சென்றோம். கட்டுவதற்கு கால் மணி நேரம் காத்திருப்பது ஏற்கனவே சாதாரணமானது.

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

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

விரிவான பின்னூட்டங்களுக்கு ஆறு வாரங்கள் செலவிடப்பட்டன.

திட்டங்களை

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

கூடுதலாக, மற்ற திட்டங்கள் உள்ளன.

• லிண்ட் திரும்பவும் (மற்றும் பிற நிலையான பகுப்பாய்வு). இந்த திசையில் நாங்கள் ஏற்கனவே செயல்பட்டு வருகிறோம்.
• PR தடுப்பானில் அனைத்தையும் இயக்கவும் இறுதி முதல் இறுதி வரை சோதனைகள் அனைத்து SDK பதிப்புகளிலும்.

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

குறிப்புகள்

நான் ஒரே ஒரு ஆலோசனையை வழங்க முடிந்தால், அது இதுதான்:

ஷெல் ஸ்கிரிப்ட்களில் கவனமாக இருங்கள்!

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

இது அனைத்தும் எங்கள் உருவாக்க இயந்திரங்களில் இயங்கும் எளிய ஸ்கிரிப்ட்களுடன் தொடங்கியது:

#!/usr/bin/env bash
./gradlew assembleDebug

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

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

என்ன மாற்றலாம்?

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

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

உதவிக்குறிப்பு #2: உள்கட்டமைப்பை குறியீட்டில் சேமிக்கவும்.

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

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

உதவிக்குறிப்பு #3: டோக்கர் சுற்றுச்சூழலுக்கு உதவ முடியும்.

இது நிச்சயமாக ஆண்ட்ராய்டு டெவலப்பர்களுக்கு உதவும்; துரதிர்ஷ்டவசமாக, iOS இல் இன்னும் ஒன்று இல்லை.

jdk மற்றும் android-sdk ஆகியவற்றைக் கொண்ட எளிய டாக்கர் கோப்பின் எடுத்துக்காட்டு இது:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

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

இது அர்த்தமுள்ளதாக இருப்பதற்கு இரண்டு முக்கிய காரணங்கள் அளவிடுதல் மற்றும் மீண்டும் மீண்டும் செய்யக்கூடியது. டோக்கரைப் பயன்படுத்தி, முந்தையதைப் போலவே அதே சூழலைக் கொண்டிருக்கும் ஒரு டஜன் உருவாக்க முகவர்களை நீங்கள் விரைவாக உருவாக்கலாம். இது CI பொறியாளர்களின் வாழ்க்கையை மிகவும் எளிதாக்குகிறது. Android-sdk ஐ டோக்கரில் தள்ளுவது மிகவும் எளிதானது, ஆனால் எமுலேட்டர்களில் இது இன்னும் கொஞ்சம் கடினம்: நீங்கள் கொஞ்சம் கடினமாக உழைக்க வேண்டும் (அல்லது GitHub இலிருந்து முடிக்கப்பட்டதை மீண்டும் பதிவிறக்கவும்).

உதவிக்குறிப்பு எண் 4: ஆய்வுகள் ஆய்வுகளுக்காக செய்யப்படவில்லை, ஆனால் மக்களுக்காக என்பதை மறந்துவிடாதீர்கள்.

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

உதவிக்குறிப்பு #5: தொடர்ச்சியான ஒருங்கிணைப்பை உருவாக்கும் போது நடைமுறையில் இருங்கள்.

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

உதவிக்குறிப்பு #6: ஆயத்த கருவிகளைப் பயன்படுத்தவும்.

கிளவுட் சிஐ வழங்கும் பல நிறுவனங்கள் இப்போது உள்ளன.

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

உதவிக்குறிப்பு #7: ஒரு பெரிய குழுவில், உள் தீர்வுகள் அதிக லாபம் தரக்கூடியவை.

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

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

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

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

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

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

தொடர்ச்சியான ஒருங்கிணைப்பு பயிற்சி. ஆனால் மிதமாக.

மூலம், நிகோலாய் நெஸ்டெரோவ் சிறந்த அறிக்கைகளை வழங்குவதோடு மட்டுமல்லாமல், நிரல் குழுவின் உறுப்பினராகவும் உள்ளார். AppsConf மற்றும் பிறர் உங்களுக்காக அர்த்தமுள்ள பேச்சுகளைத் தயாரிக்க உதவுகிறது. அடுத்த மாநாட்டுத் திட்டத்தின் முழுமையையும் பயனையும் தலைப்புகள் மூலம் மதிப்பிடலாம் அட்டவணை. மேலும் விவரங்களுக்கு, ஏப்ரல் 22-23 தேதிகளில் இன்ஃபோஸ்பேஸுக்கு வரவும்.

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