பாடநெறி மாணவர்களுக்காக தயாரிக்கப்பட்ட கட்டுரையின் மொழிபெயர்ப்பு "DevOps நடைமுறைகள் மற்றும் கருவிகள்" OTUS கல்வித் திட்டத்தில்.

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

நாம் ஏன் இதைப் பற்றி பேசுகிறோம்?

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

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

எனது பதில் என்னவென்றால், "நான் உண்மையில் அந்த இரண்டு நபர்களும் தான்." ரஸ்ட் எப்படி ஒரு மருந்து என்பதைப் பற்றி பேசுவதற்குப் பதிலாக, மோனோரோபோசிட்டரிகளைப் பற்றி அவர் ஏன் தவறாக நினைக்கிறார் என்பதைப் பார்ப்போம். உங்களைப் பற்றி கொஞ்சம். நான் செஃப் மென்பொருளின் CTO. எங்களிடம் சுமார் 100 பொறியாளர்கள் உள்ளனர், 11-12 ஆண்டுகளுக்கு முந்தைய குறியீடு அடிப்படை மற்றும் 4 முக்கிய தயாரிப்புகள் உள்ளன. இந்த குறியீட்டில் சில பாலிரெபோசிட்டரியில் உள்ளன (எனது தொடக்க நிலை), சில மோனோரோபோசிட்டரியில் உள்ளன (எனது தற்போதைய நிலை).

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

மாட்டின் முதல் பகுதியுடன் நான் உடன்படுகிறேன்:

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

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

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

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

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

இது தகவல்தொடர்புகளைத் தூண்டுகிறது மற்றும் சிக்கல்களைக் காட்டுகிறது

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

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

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

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

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

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

இந்த சூழ்நிலையிலிருந்து நாம் எவ்வாறு வெளியேறுவது என்பது பற்றி நாம் பேச வேண்டும்:

1. பல உள் APIகளுக்கான ஆதரவு, மேலும் D அதைப் பயன்படுத்துவதை நிறுத்தும் வரை பழைய அல்காரிதம் நிறுத்தப்பட்டதாகக் குறிக்கும்.
2. பல வெளியீட்டு பதிப்புகளுக்கான ஆதரவு, ஒன்று பழைய இடைமுகம், ஒன்று புதியது.
3. B, C மற்றும் D ஒரே நேரத்தில் ஏற்றுக்கொள்ளும் வரை A இன் மாற்றங்களை வெளியிடுவதை தாமதப்படுத்தவும்.

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

பல பதிப்புகளை வெளியிட, எங்களுக்கு ஒரு கிளை தேவை. இப்போது எங்களிடம் இரண்டு கூறுகள் உள்ளன - A1 மற்றும் A2. B மற்றும் C அணிகள் A2 ஐப் பயன்படுத்துகின்றன மற்றும் D A1 ஐப் பயன்படுத்துகிறது. D ஐ முன்னோக்கி நகர்த்துவதற்கு முன் பாதுகாப்பு புதுப்பிப்புகள் மற்றும் பிற பிழை திருத்தங்கள் தேவைப்படலாம் என்பதால், ஒவ்வொரு கூறுகளும் வெளியீட்டிற்கு தயாராக இருக்க வேண்டும். ஒரு பாலிரெபோசிட்டரியில், இதை நாம் ஒரு நீண்ட கால கிளையில் மறைக்க முடியும். ஒரு மோனோபோசிட்டரியில், குறியீட்டை புதிய தொகுதியில் உருவாக்குமாறு கட்டாயப்படுத்துகிறோம். குழு D இன்னும் "பழைய" கூறுக்கு மாற்றங்களைச் செய்ய வேண்டும். நாங்கள் இங்கு செலுத்தும் கட்டணத்தை அனைவரும் பார்க்கலாம் - இப்போது எங்களிடம் இரண்டு மடங்கு குறியீடு உள்ளது, மேலும் A1 மற்றும் A2 க்கு பொருந்தும் பிழை திருத்தங்கள் இரண்டுக்கும் பொருந்தும். ஒரு பாலிரெபோசிட்டரியில் கிளை அணுகுமுறையுடன், இது செர்ரி-பிக் பின்னால் மறைக்கப்பட்டுள்ளது. நகல் இல்லாததால் செலவு குறைவாக இருப்பதாக கருதுகிறோம். நடைமுறைக் கண்ணோட்டத்தில், செலவு ஒன்றுதான்: இரண்டு ஒரே மாதிரியான கோட்பேஸ்களில் ஒன்றை நீக்கும் வரை அவற்றை உருவாக்கி, விடுவித்து, பராமரிக்கலாம். வித்தியாசம் என்னவென்றால், ஒரு மோனோபோசிட்டரி மூலம் இந்த வலி நேரடியாகவும் தெரியும். இது இன்னும் மோசமானது, அது நல்லது.

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

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

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

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

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

யார் மிகப்பெரிய வெறியர்கள்? ஆதரவாளர்கள்:

• மோனோரெபோ

• துரு

• தவறான கருத்துக்கணிப்பு / இரண்டும்

33 பயனர்கள் வாக்களித்தனர். 13 பயனர்கள் வாக்களிக்கவில்லை.

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