കോഴ്‌സ് വിദ്യാർത്ഥികൾക്കായി തയ്യാറാക്കിയ ലേഖനത്തിന്റെ പരിഭാഷ "DevOps പ്രാക്ടീസുകളും ടൂളുകളും" OTUS വിദ്യാഭ്യാസ പദ്ധതിയിൽ.

നിങ്ങൾ ഒരു മോണോപോസിറ്ററി തിരഞ്ഞെടുക്കണം, കാരണം അത് നിങ്ങളുടെ ടീമുകളിൽ പ്രോത്സാഹിപ്പിക്കുന്ന പെരുമാറ്റം സുതാര്യതയും ഉത്തരവാദിത്തവും പങ്കിടുന്നു, പ്രത്യേകിച്ച് ടീമുകൾ വളരുന്നതിനനുസരിച്ച്. ഏതുവിധേനയും, നിങ്ങൾ ടൂളിങ്ങിൽ നിക്ഷേപിക്കേണ്ടിവരും, എന്നാൽ നിങ്ങളുടെ കമാൻഡുകളിൽ നിങ്ങൾ ആഗ്രഹിക്കുന്ന സ്വഭാവരീതിയാണ് ഡിഫോൾട്ട് സ്വഭാവമെങ്കിൽ അത് എല്ലായ്പ്പോഴും നല്ലതാണ്.

എന്തുകൊണ്ടാണ് നമ്മൾ ഇതിനെക്കുറിച്ച് സംസാരിക്കുന്നത്?

മാറ്റ് ക്ലീൻ ലേഖനം എഴുതി "മോണോറെപോസ്: ദയവായി ചെയ്യരുത്!"  (വിവർത്തകന്റെ കുറിപ്പ്: ഹബ്രെയിലെ വിവർത്തനം "മോണോപോസിറ്ററികൾ: ദയവായി ചെയ്യരുത്"). എനിക്ക് മാറ്റിനെ ഇഷ്ടമാണ്, അവൻ വളരെ മിടുക്കനാണെന്ന് ഞാൻ കരുതുന്നു, നിങ്ങൾ അവന്റെ കാഴ്ചപ്പാട് വായിക്കണം. അദ്ദേഹം ആദ്യം വോട്ടെടുപ്പ് ട്വിറ്ററിൽ പോസ്റ്റ് ചെയ്തു:

പരിഭാഷ:
ഈ പുതുവത്സര ദിനത്തിൽ, മോണോപോസിറ്ററികൾ എത്രമാത്രം പരിഹാസ്യമാണെന്ന് ഞാൻ വാദിക്കാൻ പോകുന്നു. 2019 നിശബ്ദമായി ആരംഭിച്ചു. ഇതിന്റെ ആത്മാവിൽ, ഞാൻ നിങ്ങൾക്ക് ഒരു സർവേ വാഗ്ദാനം ചെയ്യുന്നു. ആരാണ് വലിയ മതഭ്രാന്തന്മാർ? പിന്തുണയ്ക്കുന്നവർ:
- മോണോറെപ്പോ
- തുരുന്വ്
- തെറ്റായ വോട്ടെടുപ്പ് / രണ്ടും

എന്റെ പ്രതികരണം, "ഞാൻ അക്ഷരാർത്ഥത്തിൽ ആ രണ്ടുപേരും ആണ്." റസ്റ്റ് എങ്ങനെ ഒരു മരുന്നാണ് എന്നതിനെക്കുറിച്ച് സംസാരിക്കുന്നതിനുപകരം, മോണോപോസിറ്ററികളെക്കുറിച്ച് അദ്ദേഹം തെറ്റിദ്ധരിക്കുന്നത് എന്തുകൊണ്ടാണെന്ന് നോക്കാം. നിങ്ങളെക്കുറിച്ച് കുറച്ച്. ഞാൻ ഷെഫ് സോഫ്റ്റ്‌വെയറിന്റെ CTO ആണ്. ഞങ്ങൾക്ക് ഏകദേശം 100 എഞ്ചിനീയർമാർ ഉണ്ട്, ഏകദേശം 11-12 വർഷം പഴക്കമുള്ള ഒരു കോഡ് ബേസ്, കൂടാതെ 4 പ്രധാന ഉൽപ്പന്നങ്ങൾ. ഈ കോഡിൽ ചിലത് ഒരു പോളിറെപോസിറ്ററിയിലാണ് (എന്റെ ആരംഭ സ്ഥാനം), ചിലത് ഒരു മോണോപോസിറ്ററിയിലാണ് (എന്റെ നിലവിലെ സ്ഥാനം).

ഞാൻ ആരംഭിക്കുന്നതിന് മുമ്പ്: ഞാൻ ഇവിടെ ഉന്നയിക്കുന്ന എല്ലാ വാദങ്ങളും രണ്ട് തരത്തിലുള്ള റിപ്പോസിറ്ററികൾക്കും ബാധകമായിരിക്കും. എന്റെ അഭിപ്രായത്തിൽ, നിങ്ങൾ ഒരു തരത്തിലുള്ള ശേഖരം മറ്റൊന്നിനേക്കാൾ തിരഞ്ഞെടുക്കുന്നതിന് സാങ്കേതിക കാരണങ്ങളൊന്നുമില്ല. നിങ്ങൾക്ക് ഏത് സമീപനവും പ്രവർത്തിക്കാൻ കഴിയും. അതിനെക്കുറിച്ച് സംസാരിക്കുന്നതിൽ എനിക്ക് സന്തോഷമുണ്ട്, പക്ഷേ ഒരാൾ മറ്റൊന്നിനേക്കാൾ ശ്രേഷ്ഠനാകാനുള്ള കൃത്രിമ സാങ്കേതിക കാരണങ്ങളിൽ എനിക്ക് താൽപ്പര്യമില്ല.

മാറ്റിന്റെ പോയിന്റിന്റെ ആദ്യ ഭാഗത്തോട് ഞാൻ യോജിക്കുന്നു:

കാരണം, സ്കെയിലിൽ, ഒരു പോളിറെപോസിറ്ററി പരിഹരിക്കുന്ന എല്ലാ പ്രശ്നങ്ങളും ഒരു മോണോപോസിറ്ററി പരിഹരിക്കും, എന്നാൽ അതേ സമയം നിങ്ങളുടെ കോഡ് കർശനമായി ജോടിയാക്കാൻ നിങ്ങളെ നിർബന്ധിക്കുകയും നിങ്ങളുടെ പതിപ്പ് നിയന്ത്രണ സംവിധാനത്തിന്റെ സ്കേലബിളിറ്റി വർദ്ധിപ്പിക്കുന്നതിന് അവിശ്വസനീയമായ ശ്രമങ്ങൾ ആവശ്യമാണ്.

നിങ്ങൾ ഒരു മോണോപോസിറ്ററി അല്ലെങ്കിൽ പോളിറെപോസിറ്ററി തിരഞ്ഞെടുക്കുന്നുണ്ടോ എന്നത് പരിഗണിക്കാതെ തന്നെ നിങ്ങൾക്ക് സമാന പ്രശ്നങ്ങൾ പരിഹരിക്കേണ്ടി വരും. നിങ്ങൾ എങ്ങനെയാണ് റിലീസുകൾ റിലീസ് ചെയ്യുന്നത്? അപ്‌ഡേറ്റുകളോടുള്ള നിങ്ങളുടെ സമീപനം എന്താണ്? പിന്നോക്ക അനുയോജ്യത? ക്രോസ് പ്രോജക്റ്റ് ഡിപൻഡൻസികൾ? ഏത് വാസ്തുവിദ്യാ ശൈലികളാണ് സ്വീകാര്യമായത്? എങ്ങനെയാണ് നിങ്ങളുടെ ബിൽഡ് ആൻഡ് ടെസ്റ്റ് ഇൻഫ്രാസ്ട്രക്ചർ മാനേജ് ചെയ്യുന്നത്? പട്ടിക അനന്തമാണ്. നിങ്ങൾ വളരുമ്പോൾ അവയെല്ലാം പരിഹരിക്കും. സൗജന്യ ചീസ് ഇല്ല.

ഞാൻ ബഹുമാനിക്കുന്ന പല എഞ്ചിനീയർമാരും (മാനേജർമാരും) പങ്കിടുന്ന കാഴ്ചപ്പാടുകൾക്ക് സമാനമാണ് മാറ്റിന്റെ വാദമെന്ന് ഞാൻ കരുതുന്നു. ഘടകത്തിൽ പ്രവർത്തിക്കുന്ന എഞ്ചിനീയറുടെ അല്ലെങ്കിൽ ഘടകത്തിൽ പ്രവർത്തിക്കുന്ന ടീമിന്റെ വീക്ഷണകോണിൽ നിന്നാണ് ഇത് സംഭവിക്കുന്നത്. ഇതുപോലുള്ള കാര്യങ്ങൾ നിങ്ങൾ കേൾക്കുന്നു:

• കോഡ്ബേസ് വലുതാണ് - എനിക്ക് ഈ ജങ്ക് ആവശ്യമില്ല.
• ടെസ്റ്റ് ചെയ്യാൻ ബുദ്ധിമുട്ടാണ്, കാരണം എനിക്ക് ആവശ്യമില്ലാത്ത ഈ ജങ്ക് എല്ലാം ഞാൻ പരീക്ഷിക്കേണ്ടതുണ്ട്.
• ബാഹ്യ ഡിപൻഡൻസികളുമായി പ്രവർത്തിക്കുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാണ്.
• എനിക്ക് എന്റെ സ്വന്തം വെർച്വൽ പതിപ്പ് നിയന്ത്രണ സംവിധാനങ്ങൾ ആവശ്യമാണ്.

തീർച്ചയായും, ഈ പോയിന്റുകളെല്ലാം ന്യായീകരിക്കപ്പെടുന്നു. ഇത് രണ്ട് സാഹചര്യങ്ങളിലും സംഭവിക്കുന്നു - പോളിറെപോസിറ്ററിയിൽ എനിക്ക് എന്റെ സ്വന്തം ജങ്ക് ഉണ്ട്, നിർമ്മാണത്തിന് ആവശ്യമായ ഒന്ന് കൂടാതെ... എനിക്ക് മറ്റ് ജങ്കുകളും ആവശ്യമായി വന്നേക്കാം. അതിനാൽ മുഴുവൻ പ്രോജക്റ്റും പരിശോധിക്കുന്ന ഉപകരണങ്ങൾ ഞാൻ "ലളിതമായി" സൃഷ്ടിക്കുന്നു. അല്ലെങ്കിൽ സബ്‌മോഡ്യൂളുകൾ ഉപയോഗിച്ച് ഞാൻ ഒരു വ്യാജ മോണോപോസിറ്ററി സൃഷ്ടിക്കുന്നു. ദിവസം മുഴുവനും നമുക്ക് ചുറ്റും നടക്കാം. എന്നാൽ മാറ്റിന്റെ വാദത്തിന് പ്രധാന കാരണം നഷ്ടമായെന്ന് ഞാൻ കരുതുന്നു, അത് മോണോപോസിറ്ററിക്ക് അനുകൂലമായി ഞാൻ വളരെയധികം മറിച്ചു:

ഇത് ആശയവിനിമയത്തെ പ്രകോപിപ്പിക്കുകയും പ്രശ്നങ്ങൾ കാണിക്കുകയും ചെയ്യുന്നു

ഞങ്ങൾ ശേഖരണങ്ങൾ വേർതിരിക്കുമ്പോൾ, ഏകോപനത്തിന്റെയും സുതാര്യതയുടെയും ഒരു യഥാർത്ഥ പ്രശ്നം ഞങ്ങൾ സൃഷ്ടിക്കുന്നു. ടീമുകളെക്കുറിച്ച് നമ്മൾ ചിന്തിക്കുന്ന രീതിയുമായി ഇത് യോജിക്കുന്നു (പ്രത്യേകിച്ച് വ്യക്തിഗത അംഗങ്ങൾ അവരെക്കുറിച്ച് ചിന്തിക്കുന്ന രീതി): ഒരു പ്രത്യേക ഘടകത്തിന് ഞങ്ങൾ ഉത്തരവാദികളാണ്. ഞങ്ങൾ ആപേക്ഷികമായ ഒറ്റപ്പെടലിലാണ് പ്രവർത്തിക്കുന്നത്. എന്റെ ടീമിലും ഞങ്ങൾ പ്രവർത്തിക്കുന്ന ഘടകങ്ങളിലും അതിരുകൾ നിശ്ചയിച്ചിരിക്കുന്നു.

വാസ്തുവിദ്യ കൂടുതൽ സങ്കീർണ്ണമാകുമ്പോൾ, ഒരു ടീമിന് ഒറ്റയ്ക്ക് കൈകാര്യം ചെയ്യാൻ കഴിയില്ല. വളരെ കുറച്ച് എഞ്ചിനീയർമാരുടെ തലയിൽ മുഴുവൻ സംവിധാനവും ഉണ്ട്. B, C, D ടീമുകൾ ഉപയോഗിക്കുന്ന ഒരു പങ്കിട്ട ഘടകം നിങ്ങൾ മാനേജ് ചെയ്യുന്നുവെന്ന് കരുതുക. ടീം A റീഫാക്‌ടറിംഗ് ചെയ്യുന്നു, API മെച്ചപ്പെടുത്തുന്നു, കൂടാതെ ആന്തരിക നടപ്പാക്കലും മാറ്റുന്നു. തൽഫലമായി, മാറ്റങ്ങൾ പിന്നോട്ട് പൊരുത്തപ്പെടുന്നില്ല. നിങ്ങൾക്ക് എന്ത് ഉപദേശമാണ് ഉള്ളത്?

• പഴയ API ഉപയോഗിക്കുന്ന എല്ലാ സ്ഥലങ്ങളും കണ്ടെത്തുക.
• പുതിയ API ഉപയോഗിക്കാൻ കഴിയാത്ത സ്ഥലങ്ങളുണ്ടോ?
• മറ്റ് ഘടകങ്ങൾ തകരാറിലാകുന്നില്ലെന്ന് ഉറപ്പാക്കാൻ നിങ്ങൾക്ക് അവ ശരിയാക്കാനും പരിശോധിക്കാനും കഴിയുമോ?
• ഈ ടീമുകൾക്ക് ഇപ്പോൾ നിങ്ങളുടെ മാറ്റങ്ങൾ പരിശോധിക്കാനാകുമോ?

ഈ ചോദ്യങ്ങൾ റിപ്പോസിറ്ററി തരത്തിൽ നിന്ന് സ്വതന്ത്രമാണെന്ന് ദയവായി ശ്രദ്ധിക്കുക. നിങ്ങൾ B, C, D ടീമുകളെ കണ്ടെത്തേണ്ടതുണ്ട്. നിങ്ങൾ അവരോട് സംസാരിക്കുകയും സമയം കണ്ടെത്തുകയും അവരുടെ മുൻഗണനകൾ മനസ്സിലാക്കുകയും വേണം. കുറഞ്ഞത് നിങ്ങൾ ചെയ്യുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

ആരും ഇത് ചെയ്യാൻ ശരിക്കും ആഗ്രഹിക്കുന്നില്ല. കേവലം നശിച്ച API ശരിയാക്കുന്നതിനേക്കാൾ വളരെ കുറവാണ് ഇത്. അതെല്ലാം മാനുഷികവും കുഴപ്പവുമാണ്. ഒരു പോളിറെപോസിറ്ററിയിൽ, നിങ്ങൾക്ക് ലളിതമായി മാറ്റങ്ങൾ വരുത്താനും ആ ഘടകത്തിൽ പ്രവർത്തിക്കുന്ന ആളുകൾക്ക് (ഒരുപക്ഷേ ബി, സി അല്ലെങ്കിൽ ഡി അല്ല) അവലോകനത്തിനായി നൽകാനും, മുന്നോട്ട് പോകാനും കഴിയും. 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-കൾ തിരഞ്ഞെടുത്തുവെന്ന് പറയാം. ഈ സാഹചര്യത്തിൽ, നമുക്ക് രണ്ട് കോഡ് ഉണ്ട്. പഴയതും പുതിയതും. ചില സാഹചര്യങ്ങളിൽ വളരെ സൗകര്യപ്രദമാണ്. ഞങ്ങൾ പഴയ കോഡ് വീണ്ടും പരിശോധിക്കുകയും അത് ഒഴിവാക്കിയതായി അടയാളപ്പെടുത്തുകയും ഡി ടീമുമായി ഒരു നീക്കം ചെയ്യൽ ഷെഡ്യൂൾ അംഗീകരിക്കുകയും ചെയ്യുന്നു. പോളി, മോണോ റിപ്പോസിറ്ററികൾക്ക് അടിസ്ഥാനപരമായി സമാനമാണ്.

ഒന്നിലധികം പതിപ്പുകൾ റിലീസ് ചെയ്യുന്നതിന്, ഞങ്ങൾക്ക് ഒരു ശാഖ ആവശ്യമാണ്. ഇപ്പോൾ നമുക്ക് രണ്ട് ഘടകങ്ങളുണ്ട് - A1, A2. ബി, സി ടീമുകൾ എ2 ഉപയോഗിക്കുന്നു, ഡി എ1 ഉപയോഗിക്കുന്നു. ഡിക്ക് മുന്നോട്ട് പോകുന്നതിന് മുമ്പ് സുരക്ഷാ അപ്‌ഡേറ്റുകളും മറ്റ് ബഗ് പരിഹാരങ്ങളും ആവശ്യമായി വന്നേക്കാം എന്നതിനാൽ എല്ലാ ഘടകങ്ങളും റിലീസിന് തയ്യാറായിരിക്കണം. ഒരു പോളിറെപോസിറ്ററിയിൽ, നല്ലതായി തോന്നുന്ന ഒരു ദീർഘകാല ശാഖയിൽ നമുക്ക് ഇത് മറയ്ക്കാം. ഒരു മോണോപോസിറ്ററിയിൽ, ഒരു പുതിയ മൊഡ്യൂളിൽ കോഡ് സൃഷ്ടിക്കാൻ ഞങ്ങൾ നിർബന്ധിക്കുന്നു. ടീം ഡി ഇപ്പോഴും "പഴയ" ഘടകത്തിൽ മാറ്റങ്ങൾ വരുത്തേണ്ടതുണ്ട്. ഞങ്ങൾ ഇവിടെ അടയ്‌ക്കുന്ന ചെലവ് എല്ലാവർക്കും കാണാൻ കഴിയും - ഞങ്ങൾക്ക് ഇപ്പോൾ അതിന്റെ ഇരട്ടി കോഡ് ഉണ്ട്, കൂടാതെ A1, A2 എന്നിവയ്‌ക്ക് ബാധകമായ ഏതെങ്കിലും ബഗ് പരിഹാരങ്ങൾ അവ രണ്ടിനും ബാധകമാക്കണം. ഒരു പോളിറെപോസിറ്ററിയിലെ ബ്രാഞ്ചിംഗ് സമീപനത്തോടെ, ഇത് ചെറി-പിക്കിന് പിന്നിൽ മറഞ്ഞിരിക്കുന്നു. ഡ്യൂപ്ലിക്കേഷൻ ഇല്ലാത്തതിനാൽ ചെലവ് കുറവാണെന്ന് ഞങ്ങൾ കരുതുന്നു. ഒരു പ്രായോഗിക വീക്ഷണകോണിൽ നിന്ന്, ചെലവ് ഒന്നുതന്നെയാണ്: അവയിലൊന്ന് ഇല്ലാതാക്കാൻ കഴിയുന്നതുവരെ നിങ്ങൾ രണ്ട് സമാന കോഡ്ബേസുകൾ നിർമ്മിക്കുകയും റിലീസ് ചെയ്യുകയും പരിപാലിക്കുകയും ചെയ്യും. ഒരു മോണോപോസിറ്ററി ഉപയോഗിച്ച് ഈ വേദന നേരിട്ടുള്ളതും ദൃശ്യവുമാണ് എന്നതാണ് വ്യത്യാസം. ഇത് അതിലും മോശമാണ്, അത് നല്ലതാണ്.

ഒടുവിൽ, ഞങ്ങൾ മൂന്നാമത്തെ പോയിന്റിൽ എത്തി. റിലീസ് കാലതാമസം. എ വരുത്തിയ മാറ്റങ്ങൾ ടീമിന്റെ ജീവിതം മെച്ചപ്പെടുത്താൻ സാധ്യതയുണ്ട്. പ്രധാനം, എന്നാൽ അടിയന്തിരമല്ല. നമുക്ക് വെറുതെ താമസിപ്പിക്കാമോ? ഒരു പോളിറെപോസിറ്ററിയിൽ, ആർട്ടിഫാക്റ്റ് പിൻ ചെയ്യാൻ ഞങ്ങൾ ഇത് തള്ളുന്നു. തീർച്ചയായും ഞങ്ങൾ ഇത് ഡി ടീമിനോട് പറയുകയാണ്. നിങ്ങൾ കണ്ടെത്തുന്നത് വരെ പഴയ പതിപ്പിൽ തന്നെ തുടരുക! ഭീരുവായി കളിക്കാൻ ഇത് നിങ്ങളെ സജ്ജമാക്കുന്നു. ടീം ഡി കൂടുതൽ കാലഹരണപ്പെട്ട പതിപ്പാണ് ഉപയോഗിക്കുന്നതെന്ന വസ്തുത അവഗണിച്ച് ടീം എ അവരുടെ ഘടകത്തിൽ പ്രവർത്തിക്കുന്നത് തുടരുന്നു (അതാണ് ടീം ഡിയുടെ പ്രശ്നം, അവർ മണ്ടന്മാരാണ്). അതേസമയം, കോഡ് സ്ഥിരതയോടുള്ള ടീം എയുടെ അശ്രദ്ധമായ മനോഭാവത്തെക്കുറിച്ച് ടീം ഡി മോശമായി സംസാരിക്കുന്നു, അവർ അതിനെക്കുറിച്ച് സംസാരിക്കുകയാണെങ്കിൽ. മാസങ്ങൾ കടന്നുപോകുന്നു. അവസാനമായി, അപ്‌ഡേറ്റ് ചെയ്യാനുള്ള സാധ്യത പരിശോധിക്കാൻ ടീം ഡി തീരുമാനിക്കുന്നു, എന്നാൽ എയ്ക്ക് മാത്രമേ കൂടുതൽ മാറ്റങ്ങൾ ഉള്ളൂ. എപ്പോൾ അല്ലെങ്കിൽ എങ്ങനെ ഡി തകർത്തുവെന്ന് ടീം എ ഓർമ്മിക്കുന്നില്ല. അപ്‌ഗ്രേഡ് കൂടുതൽ വേദനാജനകവും കൂടുതൽ സമയമെടുക്കുന്നതുമാണ്. ഇത് മുൻഗണനാ സ്റ്റാക്കിൽ നിന്ന് കൂടുതൽ താഴേക്ക് അയയ്ക്കുന്നു. ഒരു ശാഖ ഉണ്ടാക്കാൻ ഞങ്ങളെ പ്രേരിപ്പിക്കുന്ന ഒരു സുരക്ഷാ പ്രശ്‌നം A-യിൽ ഉള്ള ദിവസം വരെ. ടീം എ സമയത്തേക്ക് തിരികെ പോകണം, ഡി സ്ഥിരതയുള്ളപ്പോൾ ഒരു പോയിന്റ് കണ്ടെത്തണം, അവിടെയുള്ള പ്രശ്നം പരിഹരിച്ച് റിലീസിന് തയ്യാറാകണം. ഇത് ആളുകൾ നടത്തുന്ന യഥാർത്ഥ തിരഞ്ഞെടുപ്പാണ്, ഇത് ഏറ്റവും മോശമാണ്. നമുക്ക് പരസ്പരം അവഗണിക്കാൻ കഴിയുന്നിടത്തോളം കാലം എ ടീമിനും ഡി ടീമിനും ഇത് നല്ലതാണെന്ന് തോന്നുന്നു.

ഒരു മോണോപോസിറ്ററിയിൽ, മൂന്നാമത്തേത് ശരിക്കും ഒരു ഓപ്ഷനല്ല. രണ്ട് വഴികളിൽ ഒന്ന് സാഹചര്യം കൈകാര്യം ചെയ്യാൻ നിങ്ങൾ നിർബന്ധിതരാകുന്നു. രണ്ട് റിലീസ് ബ്രാഞ്ചുകൾ ഉള്ളതിന്റെ ചിലവ് നിങ്ങൾ കാണേണ്ടതുണ്ട്. പിന്നോക്ക അനുയോജ്യത തകർക്കുന്ന അപ്‌ഡേറ്റുകളിൽ നിന്ന് സ്വയം പരിരക്ഷിക്കാൻ പഠിക്കുക. എന്നാൽ ഏറ്റവും പ്രധാനമായി: നിങ്ങൾക്ക് ബുദ്ധിമുട്ടുള്ള സംഭാഷണം ഒഴിവാക്കാൻ കഴിയില്ല.

എന്റെ അനുഭവത്തിൽ, ടീമുകൾ വലുതാകുമ്പോൾ, മുഴുവൻ സിസ്റ്റവും മനസ്സിൽ സൂക്ഷിക്കാൻ ഇനി സാധ്യമല്ല, അതാണ് ഏറ്റവും പ്രധാനപ്പെട്ട ഭാഗം. സിസ്റ്റത്തിലെ വിയോജിപ്പിന്റെ ദൃശ്യപരത നിങ്ങൾ മെച്ചപ്പെടുത്തണം. ടീമുകളെ അവരുടെ ഘടകങ്ങളിൽ നിന്ന് അകറ്റിനിർത്തുന്നതിനും മറ്റ് ടീമുകളുടെയും ഉപഭോക്താക്കളുടെയും ജോലി നോക്കുന്നതിനും നിങ്ങൾ സജീവമായി പ്രവർത്തിക്കണം.

അതെ, പോളിറെപോസിറ്ററി പ്രശ്നം പരിഹരിക്കാൻ ശ്രമിക്കുന്ന ഉപകരണങ്ങൾ നിങ്ങൾക്ക് സൃഷ്ടിക്കാൻ കഴിയും. എന്നാൽ വലിയ സംരംഭങ്ങളിൽ തുടർച്ചയായ ഡെലിവറിയും ഓട്ടോമേഷനും പഠിപ്പിക്കുന്ന എന്റെ അനുഭവം എന്നോട് പറയുന്നത് ഇതാണ്: അധിക ടൂളുകൾ ഉപയോഗിക്കാതെയുള്ള ഡിഫോൾട്ട് സ്വഭാവം നിങ്ങൾ കാണാൻ പ്രതീക്ഷിക്കുന്ന സ്വഭാവമാണ്. ഒരു പോളിറെപോസിറ്ററിയുടെ ഡിഫോൾട്ട് സ്വഭാവം ഒറ്റപ്പെടലാണ്, അതാണ് മുഴുവൻ പോയിന്റ്. ഒരു മോണോപോസിറ്ററിയുടെ ഡിഫോൾട്ട് പെരുമാറ്റം ഉത്തരവാദിത്തവും സുതാര്യതയും പങ്കിടുന്നു, അതാണ് മുഴുവൻ പോയിന്റും. രണ്ട് സാഹചര്യങ്ങളിലും, പരുക്കൻ അരികുകൾ മിനുസപ്പെടുത്തുന്ന ഒരു ഉപകരണം ഞാൻ സൃഷ്ടിക്കാൻ പോകുന്നു. ഒരു നേതാവ് എന്ന നിലയിൽ, ഓരോ തവണയും ഞാൻ ഒരു മോണോപോസിറ്ററി തിരഞ്ഞെടുക്കും, കാരണം ഉപകരണങ്ങൾ എനിക്ക് ആവശ്യമുള്ള സംസ്കാരത്തെ ശക്തിപ്പെടുത്തേണ്ടതുണ്ട്, കൂടാതെ സംസ്കാരം വരുന്നത് ചെറിയ തീരുമാനങ്ങളിൽ നിന്നും ടീമിന്റെ ദൈനംദിന പ്രവർത്തനങ്ങളിൽ നിന്നുമാണ്.

രജിസ്റ്റർ ചെയ്ത ഉപയോക്താക്കൾക്ക് മാത്രമേ സർവേയിൽ പങ്കെടുക്കാൻ കഴിയൂ. സൈൻ ഇൻദയവായി.

ആരാണ് ഏറ്റവും വലിയ മതഭ്രാന്തന്മാർ? പിന്തുണയ്ക്കുന്നവർ:

• മോണോറെപ്പോ

• തുരുന്വ്

• തെറ്റായ വോട്ടെടുപ്പ് / രണ്ടും

33 ഉപയോക്താക്കൾ വോട്ട് ചെയ്തു. 13 ഉപയോക്താക്കൾ വിട്ടുനിന്നു.

അവലംബം: www.habr.com