അടിസ്ഥാന സൗകര്യങ്ങൾ കോഡായി: എക്സ്പി ഉപയോഗിച്ച് എങ്ങനെ പ്രശ്നങ്ങൾ മറികടക്കാം

ഹലോ, ഹബ്ർ! മുമ്പ്, അടിസ്ഥാന സൗകര്യങ്ങളിലെ ജീവിതത്തെക്കുറിച്ച് കോഡ് മാതൃകയായി ഞാൻ പരാതിപ്പെട്ടു, നിലവിലെ സാഹചര്യം പരിഹരിക്കാൻ ഒന്നും വാഗ്ദാനം ചെയ്തില്ല. നിരാശയുടെ പടുകുഴിയിൽ നിന്ന് രക്ഷപ്പെടാനും സാഹചര്യത്തെ ശരിയായ ദിശയിലേക്ക് നയിക്കാനും നിങ്ങളെ സഹായിക്കുന്ന സമീപനങ്ങളും പ്രയോഗങ്ങളും ഏതൊക്കെയാണെന്ന് ഇന്ന് നിങ്ങളോട് പറയാൻ ഞാൻ തിരിച്ചെത്തുകയാണ്.

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

നമ്മൾ ആരാണ്, നമ്മൾ എവിടെയാണ്, എന്തൊക്കെ പ്രശ്നങ്ങളുണ്ട്

ഞങ്ങൾ നിലവിൽ ആറ് പ്രോഗ്രാമർമാരും മൂന്ന് ഇൻഫ്രാസ്ട്രക്ചർ എഞ്ചിനീയർമാരും അടങ്ങുന്ന Sre ഓൺബോർഡിംഗ് ടീമിലാണ്. നാമെല്ലാവരും ഇൻഫ്രാസ്ട്രക്ചർ കോഡായി (IaC) എഴുതാൻ ശ്രമിക്കുന്നു. ഞങ്ങൾ ഇത് ചെയ്യുന്നത് അടിസ്ഥാനപരമായി കോഡ് എങ്ങനെ എഴുതണമെന്ന് ഞങ്ങൾക്ക് അറിയാമെന്നതിനാലും "ശരാശരിക്ക് മുകളിൽ" ഡെവലപ്പർമാരുടെ ചരിത്രമുള്ളതിനാലുമാണ്.

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

ഞങ്ങളുടെ IaC-യിൽ ഞങ്ങൾ ഉപയോഗിക്കുന്ന ടെക്നോളജി സ്റ്റാക്ക്.

• വിഭവങ്ങൾ സൃഷ്ടിക്കുന്നതിനുള്ള ടെറാഫോം.
• ചിത്രങ്ങൾ കൂട്ടിച്ചേർക്കുന്നതിനുള്ള പാക്കർ. വിൻഡോസ്, സെന്റോസ് 7 ചിത്രങ്ങൾ ഇവയാണ്.
• drone.io-യിൽ ശക്തമായ ഒരു ബിൽഡ് നിർമ്മിക്കുന്നതിനും അതുപോലെ പാക്കർ json-ഉം ഞങ്ങളുടെ ടെറാഫോം മൊഡ്യൂളുകളും സൃഷ്ടിക്കുന്നതിനും Jsonnet.
• അസൂർ.
• ചിത്രങ്ങൾ തയ്യാറാക്കുമ്പോൾ അൻസിബിൾ.
• സഹായ സേവനങ്ങൾക്കും പ്രൊവിഷനിംഗ് സ്ക്രിപ്റ്റുകൾക്കുമുള്ള പൈത്തൺ.
• ടീം അംഗങ്ങൾക്കിടയിൽ പങ്കിട്ട പ്ലഗിനുകൾ ഉള്ള VSCode-ൽ ഇതെല്ലാം.

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

ഇനിപ്പറയുന്ന IaC പ്രശ്‌നങ്ങളുമായി ഞങ്ങൾ നിലവിൽ പോരാടുകയാണ്:

• കോഡ് വികസനത്തിനുള്ള ഉപകരണങ്ങളുടെയും മാർഗങ്ങളുടെയും അപൂർണത.
• മന്ദഗതിയിലുള്ള വിന്യാസം. അടിസ്ഥാന സൗകര്യങ്ങൾ യഥാർത്ഥ ലോകത്തിന്റെ ഭാഗമാണ്, അത് മന്ദഗതിയിലാകാം.
• സമീപനങ്ങളുടെയും പ്രയോഗങ്ങളുടെയും അഭാവം.
• ഞങ്ങൾ പുതിയവരാണ്, കൂടുതൽ അറിയില്ല.

രക്ഷാപ്രവർത്തനത്തിലേക്ക് എക്സ്ട്രീം പ്രോഗ്രാമിംഗ് (എക്സ്പി).

എല്ലാ ഡെവലപ്പർമാർക്കും എക്‌സ്ട്രീം പ്രോഗ്രാമിംഗും (എക്‌സ്‌പി) അതിന്റെ പിന്നിൽ നിൽക്കുന്ന രീതികളും പരിചിതമാണ്. ഞങ്ങളിൽ പലരും ഈ സമീപനത്തിൽ പ്രവർത്തിച്ചിട്ടുണ്ട്, അത് വിജയിക്കുകയും ചെയ്തു. അടിസ്ഥാന സൗകര്യ വെല്ലുവിളികളെ അതിജീവിക്കാൻ അവിടെ പറഞ്ഞിരിക്കുന്ന തത്വങ്ങളും സമ്പ്രദായങ്ങളും എന്തുകൊണ്ട് ഉപയോഗിച്ചുകൂടാ? ഈ സമീപനം സ്വീകരിക്കാനും എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണാനും ഞങ്ങൾ തീരുമാനിച്ചു.

നിങ്ങളുടെ വ്യവസായത്തിന് XP സമീപനത്തിന്റെ പ്രയോഗക്ഷമത പരിശോധിക്കുന്നുഎക്‌സ്‌പിക്ക് അനുയോജ്യമായ പരിതസ്ഥിതിയുടെ ഒരു വിവരണം ഇതാ, അത് ഞങ്ങളുമായി എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നു:

1. ചലനാത്മകമായി മാറിക്കൊണ്ടിരിക്കുന്ന സോഫ്റ്റ്‌വെയർ ആവശ്യകതകൾ. അന്തിമ ലക്ഷ്യം എന്താണെന്ന് ഞങ്ങൾക്ക് വ്യക്തമായി. എന്നാൽ വിശദാംശങ്ങൾ വ്യത്യാസപ്പെടാം. ടാക്സി എവിടെ വേണമെന്ന് ഞങ്ങൾ സ്വയം തീരുമാനിക്കുന്നു, അതിനാൽ ആവശ്യകതകൾ ഇടയ്ക്കിടെ മാറുന്നു (പ്രധാനമായും സ്വയം). ഓട്ടോമേഷൻ സ്വയം ചെയ്യുന്നതും ജോലിയുടെ ആവശ്യകതകളും വ്യാപ്തിയും പരിമിതപ്പെടുത്തുന്നതുമായ SRE ടീമിനെ ഞങ്ങൾ എടുക്കുകയാണെങ്കിൽ, ഈ പോയിന്റ് നന്നായി യോജിക്കുന്നു.

2. പുതിയ സാങ്കേതികവിദ്യ ഉപയോഗിച്ചുള്ള നിശ്ചിത സമയ പദ്ധതികൾ മൂലമുണ്ടാകുന്ന അപകടസാധ്യതകൾ. നമുക്ക് അറിയാത്ത ചില കാര്യങ്ങൾ ഉപയോഗിക്കുമ്പോൾ നമ്മൾ അപകടസാധ്യതകൾ നേരിട്ടേക്കാം. ഇത് 100% ഞങ്ങളുടെ കാര്യമാണ്. ഞങ്ങൾക്ക് പൂർണ്ണമായി പരിചിതമല്ലാത്ത സാങ്കേതിക വിദ്യകളുടെ ഉപയോഗമായിരുന്നു ഞങ്ങളുടെ മുഴുവൻ പദ്ധതിയും. പൊതുവേ, ഇതൊരു സ്ഥിരമായ പ്രശ്നമാണ്, കാരണം ... ഇൻഫ്രാസ്ട്രക്ചർ മേഖലയിൽ എല്ലാ കാലത്തും നിരവധി പുതിയ സാങ്കേതികവിദ്യകൾ ഉയർന്നുവരുന്നുണ്ട്.

3,4 ചെറിയ, ഒരുമിച്ച് സ്ഥിതി ചെയ്യുന്ന വിപുലമായ വികസന ടീം. നിങ്ങൾ ഉപയോഗിക്കുന്ന ഓട്ടോമേറ്റഡ് ടെക്നോളജി യൂണിറ്റ്, ഫങ്ഷണൽ ടെസ്റ്റുകൾ അനുവദിക്കുന്നു. ഈ രണ്ട് പോയിന്റുകളും നമുക്ക് തികച്ചും അനുയോജ്യമല്ല. ഒന്നാമതായി, ഞങ്ങൾ ഒരു ഏകോപിത ടീമല്ല, രണ്ടാമതായി, ഞങ്ങളിൽ ഒമ്പത് പേരുണ്ട്, അത് ഒരു വലിയ ടീമായി കണക്കാക്കാം. എന്നിരുന്നാലും, "വലിയ" ടീമിന്റെ ചില നിർവചനങ്ങൾ അനുസരിച്ച്, 14+ ആളുകളാണ്.

ചില XP സമ്പ്രദായങ്ങളും അവ ഫീഡ്‌ബാക്കിന്റെ വേഗതയും ഗുണനിലവാരവും എങ്ങനെ ബാധിക്കുന്നുവെന്നും നോക്കാം.

XP ഫീഡ്ബാക്ക് ലൂപ്പ് തത്വം

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

ഞങ്ങളുടെ ഐടി വ്യവസായത്തിൽ ഒരു OS വേഗത്തിൽ ലഭിക്കുമെന്നത് ചർച്ച ചെയ്യാനുള്ള രസകരമായ ഒരു വിഷയമാണ്. ആറുമാസം ഒരു പ്രൊജക്‌റ്റ് ചെയ്‌ത് തുടക്കത്തിലേ പിഴവ് സംഭവിച്ചുവെന്ന് കണ്ടെത്തുന്നത് എത്ര വേദനാജനകമാണെന്ന് സങ്കൽപ്പിക്കുക. സങ്കീർണ്ണമായ സംവിധാനങ്ങളുടെ രൂപകൽപ്പനയിലും ഏതെങ്കിലും നിർമ്മാണത്തിലും ഇത് സംഭവിക്കുന്നു.

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

പ്രധാനപ്പെട്ടത്: മുകളിൽ പറഞ്ഞിരിക്കുന്ന എല്ലാ പ്രശ്നങ്ങൾക്കും ഫീഡ്ബാക്ക് ഒരു പരിഹാരമാകും. XP പ്രാക്ടീസുകൾക്കൊപ്പം, നിരാശയുടെ പടുകുഴിയിൽ നിന്ന് നിങ്ങളെ പുറത്തെടുക്കാൻ ഇതിന് കഴിയും.

നിരാശയുടെ പടുകുഴിയിൽ നിന്ന് സ്വയം എങ്ങനെ പുറത്തെടുക്കാം: മൂന്ന് പരിശീലനങ്ങൾ

ടെസ്റ്റുകൾ

എക്സ്പി ഫീഡ്ബാക്ക് ലൂപ്പിൽ ടെസ്റ്റുകൾ രണ്ടുതവണ പരാമർശിച്ചിരിക്കുന്നു. അത് വെറുതെ അല്ല. എക്സ്ട്രീം പ്രോഗ്രാമിംഗ് ടെക്നിക്കിന് അവ വളരെ പ്രധാനമാണ്.

നിങ്ങൾക്ക് യൂണിറ്റ്, സ്വീകാര്യത പരിശോധനകൾ ഉണ്ടെന്ന് അനുമാനിക്കപ്പെടുന്നു. ചിലർ കുറച്ച് മിനിറ്റുകൾക്കുള്ളിൽ നിങ്ങൾക്ക് ഫീഡ്‌ബാക്ക് നൽകുന്നു, മറ്റുള്ളവർ കുറച്ച് ദിവസങ്ങൾക്കുള്ളിൽ, അതിനാൽ അവ എഴുതാൻ കൂടുതൽ സമയമെടുക്കും, കുറച്ച് തവണ അവലോകനം ചെയ്യപ്പെടും.

ഒരു ക്ലാസിക് ടെസ്റ്റിംഗ് പിരമിഡ് ഉണ്ട്, അത് കൂടുതൽ ടെസ്റ്റുകൾ ഉണ്ടായിരിക്കണമെന്ന് കാണിക്കുന്നു.

ഒരു IaC പ്രോജക്റ്റിൽ ഈ ചട്ടക്കൂട് ഞങ്ങൾക്ക് എങ്ങനെ ബാധകമാകും? യഥാർത്ഥത്തിൽ... ഇല്ല.

• യൂണിറ്റ് ടെസ്റ്റുകൾ, അവയിൽ ധാരാളം ഉണ്ടായിരിക്കണം എന്ന വസ്തുത ഉണ്ടായിരുന്നിട്ടും, വളരെയധികം ആകാൻ കഴിയില്ല. അല്ലെങ്കിൽ അവർ വളരെ പരോക്ഷമായി എന്തെങ്കിലും പരീക്ഷിക്കുകയാണ്. വാസ്തവത്തിൽ, ഞങ്ങൾ അവയൊന്നും എഴുതുന്നില്ല എന്ന് പറയാം. എന്നാൽ അത്തരം പരിശോധനകൾക്കായി ഞങ്ങൾക്ക് ചെയ്യാൻ കഴിഞ്ഞ കുറച്ച് ആപ്ലിക്കേഷനുകൾ ഇതാ:
  1. jsonnet കോഡ് പരിശോധിക്കുന്നു. ഉദാഹരണത്തിന്, ഇത് ഞങ്ങളുടെ ഡ്രോൺ അസംബ്ലി പൈപ്പ്ലൈൻ ആണ്, ഇത് വളരെ സങ്കീർണ്ണമാണ്. jsonnet കോഡ് ടെസ്റ്റുകളാൽ നന്നായി ഉൾക്കൊള്ളുന്നു.
     ഞങ്ങൾ ഇത് ഉപയോഗിക്കുന്നു Jsonnet-നുള്ള യൂണിറ്റ് ടെസ്റ്റിംഗ് ഫ്രെയിംവർക്ക്.
  2. റിസോഴ്സ് ആരംഭിക്കുമ്പോൾ എക്സിക്യൂട്ട് ചെയ്യുന്ന സ്ക്രിപ്റ്റുകൾക്കായുള്ള ടെസ്റ്റുകൾ. സ്ക്രിപ്റ്റുകൾ പൈത്തണിലാണ് എഴുതിയിരിക്കുന്നത്, അതിനാൽ അവയിൽ ടെസ്റ്റുകൾ എഴുതാം.
• ടെസ്റ്റുകളിൽ കോൺഫിഗറേഷൻ പരിശോധിക്കുന്നത് സാധ്യമാണ്, പക്ഷേ ഞങ്ങൾ അത് ചെയ്യുന്നില്ല. ഇതുവഴി റിസോഴ്‌സ് കോൺഫിഗറേഷൻ നിയമങ്ങൾ പരിശോധിക്കാനും കോൺഫിഗർ ചെയ്യാവുന്നതാണ് tflint. എന്നിരുന്നാലും, അവിടെയുള്ള ചെക്കുകൾ ടെറാഫോമിന് വളരെ അടിസ്ഥാനപരമാണ്, എന്നാൽ പല ടെസ്റ്റ് സ്ക്രിപ്റ്റുകളും AWS-നായി എഴുതിയതാണ്. ഞങ്ങൾ അസ്യൂറിലാണ്, അതിനാൽ ഇത് വീണ്ടും ബാധകമല്ല.
• കോംപോണന്റ് ഇന്റഗ്രേഷൻ ടെസ്റ്റുകൾ: നിങ്ങൾ അവയെ എങ്ങനെ തരംതിരിക്കുന്നു, എവിടെ വയ്ക്കുന്നു എന്നതിനെ ആശ്രയിച്ചിരിക്കുന്നു. എന്നാൽ അവർ അടിസ്ഥാനപരമായി പ്രവർത്തിക്കുന്നു.

  ഇന്റഗ്രേഷൻ ടെസ്റ്റുകൾ ഇങ്ങനെയാണ്.

  
  
  ഡ്രോൺ സിഐയിൽ ചിത്രങ്ങൾ നിർമ്മിക്കുമ്പോൾ ഇതൊരു ഉദാഹരണമാണ്. അവയിൽ എത്തിച്ചേരാൻ, പാക്കർ ഇമേജ് രൂപപ്പെടുന്നതിന് നിങ്ങൾ 30 മിനിറ്റ് കാത്തിരിക്കണം, തുടർന്ന് അവ കടന്നുപോകാൻ മറ്റൊരു 15 മിനിറ്റ് കാത്തിരിക്കുക. എന്നാൽ അവ നിലനിൽക്കുന്നു!

  ഇമേജ് സ്ഥിരീകരണ അൽഗോരിതം

  1. പാക്കർ ആദ്യം ചിത്രം പൂർണ്ണമായും തയ്യാറാക്കണം.
  2. ടെസ്റ്റിന് അടുത്തായി ഒരു പ്രാദേശിക സംസ്ഥാനമുള്ള ഒരു ടെറാഫോം ഉണ്ട്, അത് ഞങ്ങൾ ഈ ചിത്രം വിന്യസിക്കാൻ ഉപയോഗിക്കുന്നു.
  3. തുറക്കുമ്പോൾ, ഇമേജിനൊപ്പം പ്രവർത്തിക്കുന്നത് എളുപ്പമാക്കുന്നതിന് സമീപത്ത് കിടക്കുന്ന ഒരു ചെറിയ മൊഡ്യൂൾ ഉപയോഗിക്കുന്നു.
  4. ചിത്രത്തിൽ നിന്ന് VM വിന്യസിച്ചുകഴിഞ്ഞാൽ, പരിശോധനകൾ ആരംഭിക്കാം. അടിസ്ഥാനപരമായി, പരിശോധനകൾ കാറിലാണ് നടത്തുന്നത്. സ്റ്റാർട്ടപ്പിൽ സ്ക്രിപ്റ്റുകൾ എങ്ങനെ പ്രവർത്തിച്ചുവെന്നും ഡെമണുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും ഇത് പരിശോധിക്കുന്നു. ഇത് ചെയ്യുന്നതിന്, ssh അല്ലെങ്കിൽ winrm വഴി ഞങ്ങൾ പുതുതായി ഉയർത്തിയ മെഷീനിലേക്ക് ലോഗിൻ ചെയ്യുകയും കോൺഫിഗറേഷൻ സ്റ്റാറ്റസ് പരിശോധിക്കുകയും സേവനങ്ങൾ സജീവമാണോ എന്ന് പരിശോധിക്കുകയും ചെയ്യുന്നു.

• ടെറാഫോമിനായുള്ള മൊഡ്യൂളുകളിലെ ഇന്റഗ്രേഷൻ ടെസ്റ്റുകളുടെ സ്ഥിതി സമാനമാണ്. അത്തരം പരിശോധനകളുടെ സവിശേഷതകൾ വിശദീകരിക്കുന്ന ഒരു ചെറിയ പട്ടിക ഇതാ.

  
  
  പൈപ്പ്ലൈനിലെ ഫീഡ്ബാക്ക് ഏകദേശം 40 മിനിറ്റാണ്. എല്ലാം വളരെക്കാലം സംഭവിക്കുന്നു. ഇത് റിഗ്രേഷനായി ഉപയോഗിക്കാം, പക്ഷേ പുതിയ വികസനത്തിന് ഇത് പൊതുവെ അയഥാർത്ഥമാണ്. നിങ്ങൾ ഇതിന് വളരെ തയ്യാറാണെങ്കിൽ, റണ്ണിംഗ് സ്ക്രിപ്റ്റുകൾ തയ്യാറാക്കുക, തുടർന്ന് നിങ്ങൾക്ക് ഇത് 10 മിനിറ്റായി കുറയ്ക്കാം. എന്നാൽ ഇവ ഇപ്പോഴും യൂണിറ്റ് ടെസ്റ്റുകളല്ല, ഇത് 5 സെക്കൻഡിനുള്ളിൽ 100 ​​കഷണങ്ങൾ ചെയ്യുന്നു.

ഇമേജുകളോ ടെറാഫോം മൊഡ്യൂളുകളോ കൂട്ടിച്ചേർക്കുമ്പോൾ യൂണിറ്റ് ടെസ്റ്റുകളുടെ അഭാവം, REST വഴിയോ പൈത്തൺ സ്ക്രിപ്റ്റുകളിലേക്കോ പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്ന പ്രത്യേക സേവനങ്ങളിലേക്ക് ജോലി മാറ്റാൻ പ്രോത്സാഹിപ്പിക്കുന്നു.

ഉദാഹരണത്തിന്, വെർച്വൽ മെഷീൻ ആരംഭിക്കുമ്പോൾ, അത് സേവനത്തിൽ സ്വയം രജിസ്റ്റർ ചെയ്യുന്നുവെന്ന് ഞങ്ങൾ ഉറപ്പാക്കേണ്ടതുണ്ട് സ്കെയിൽഎഫ്ടി, കൂടാതെ വെർച്വൽ മെഷീൻ നശിപ്പിക്കപ്പെട്ടപ്പോൾ, അത് സ്വയം ഇല്ലാതാക്കി.

ഞങ്ങൾക്ക് ഒരു സേവനമായി ScaleFT ഉള്ളതിനാൽ, API വഴി അത് ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ ഞങ്ങൾ നിർബന്ധിതരാകുന്നു. നിങ്ങൾക്ക് വലിച്ചിട്ട് പറയാവുന്ന ഒരു റാപ്പർ അവിടെ എഴുതിയിരുന്നു: “അകത്തേക്ക് പോയി ഇതും അതും ഇല്ലാതാക്കുക.” ആവശ്യമായ എല്ലാ ക്രമീകരണങ്ങളും ആക്‌സസുകളും ഇത് സംഭരിക്കുന്നു.

സാധാരണ സോഫ്‌റ്റ്‌വെയറിൽ നിന്ന് വ്യത്യസ്‌തമല്ലാത്തതിനാൽ ഞങ്ങൾക്ക് ഇതിനകം തന്നെ ഇതിനായി സാധാരണ ടെസ്റ്റുകൾ എഴുതാം: ഒരുതരം അപിഹയെ പരിഹസിക്കുന്നു, നിങ്ങൾ അത് വലിച്ചെറിയുക, എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണുക.

ടെസ്റ്റുകളുടെ ഫലങ്ങൾ: ഒരു മിനിറ്റിനുള്ളിൽ OS നൽകേണ്ട യൂണിറ്റ് ടെസ്റ്റിംഗ്, അത് നൽകുന്നില്ല. പിരമിഡിലെ ഉയർന്ന പരിശോധനകൾ ഫലപ്രദമാണ്, പക്ഷേ പ്രശ്നങ്ങളുടെ ഒരു ഭാഗം മാത്രമേ ഉൾക്കൊള്ളൂ.

ജോടി പ്രോഗ്രാമിംഗ്

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

കോഡ് എഴുതുമ്പോൾ, അതിന്റെ ഗുണനിലവാരത്തെക്കുറിച്ച് കഴിയുന്നത്ര വേഗത്തിൽ ഫീഡ്ബാക്ക് ലഭിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു. അതെ, നിങ്ങൾക്ക് എല്ലാം ഒരു ഫീച്ചർ ബ്രാഞ്ചിൽ എഴുതാം (ആർക്കും ഒന്നും തകർക്കാതിരിക്കാൻ), Github-ൽ ഒരു പുൾ അഭ്യർത്ഥന നടത്തുക, അഭിപ്രായത്തിന് ഭാരമുള്ള ഒരാൾക്ക് അത് നിയോഗിക്കുക, പ്രതികരണത്തിനായി കാത്തിരിക്കുക.

എന്നാൽ നിങ്ങൾക്ക് വളരെക്കാലം കാത്തിരിക്കാം. ആളുകളെല്ലാം തിരക്കിലാണ്, ഉത്തരമുണ്ടെങ്കിൽപ്പോലും ഉയർന്ന നിലവാരം പുലർത്തണമെന്നില്ല. ഉത്തരം ഉടനടി വന്നുവെന്ന് കരുതുക, അവലോകനം ചെയ്യുന്നയാൾക്ക് മുഴുവൻ ആശയവും ഉടനടി മനസ്സിലായി, പക്ഷേ വസ്തുതയ്ക്ക് ശേഷവും ഉത്തരം വൈകിയാണ് വരുന്നത്. നേരത്തെ ആയിരുന്നെങ്കിൽ എന്ന് ഞാൻ ആഗ്രഹിക്കുന്നു. ജോടി പ്രോഗ്രാമിംഗ് ലക്ഷ്യമിടുന്നത് ഇതാണ് - ഉടൻ തന്നെ, എഴുതുന്ന സമയത്ത്.

ജോടി പ്രോഗ്രാമിംഗ് ശൈലികളും IaC-യിൽ പ്രവർത്തിക്കുന്നതിനുള്ള അവയുടെ പ്രയോഗക്ഷമതയും ചുവടെയുണ്ട്:

1. ക്ലാസിക്, അനുഭവപരിചയമുള്ളവർ+പരിചയമുള്ളവർ, ടൈമർ അനുസരിച്ച് ഷിഫ്റ്റ് ചെയ്യുക. രണ്ട് റോളുകൾ - ഡ്രൈവറും നാവിഗേറ്ററും. രണ്ടു പേർ. അവർ ഒരേ കോഡിൽ പ്രവർത്തിക്കുകയും ഒരു നിശ്ചിത സമയത്തിന് ശേഷം റോളുകൾ മാറുകയും ചെയ്യുന്നു.

ശൈലിയുമായുള്ള ഞങ്ങളുടെ പ്രശ്നങ്ങളുടെ അനുയോജ്യത നമുക്ക് പരിഗണിക്കാം:

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

IaC- ൽ ഈ ശൈലി ഉപയോഗിക്കുന്നതിനുള്ള പ്രധാന പ്രശ്നം ജോലിയുടെ അസമമായ വേഗതയാണ്. പരമ്പരാഗത സോഫ്‌റ്റ്‌വെയർ വികസനത്തിൽ, നിങ്ങൾക്ക് വളരെ ഏകീകൃതമായ ചലനമുണ്ട്. നിങ്ങൾക്ക് അഞ്ച് മിനിറ്റ് ചിലവഴിച്ച് N എന്ന് എഴുതാം. 10 മിനിറ്റ് ചിലവഴിച്ച് 2N, 15 മിനിറ്റ് - 3N എന്നിങ്ങനെ എഴുതാം. ഇവിടെ നിങ്ങൾക്ക് അഞ്ച് മിനിറ്റ് ചിലവഴിച്ച് N എന്ന് എഴുതാം, തുടർന്ന് മറ്റൊരു 30 മിനിറ്റ് ചിലവഴിച്ച് N ന്റെ പത്തിലൊന്ന് എഴുതാം. ഇവിടെ നിങ്ങൾക്ക് ഒന്നും അറിയില്ല, നിങ്ങൾ കുടുങ്ങിപ്പോയിരിക്കുന്നു, വിഡ്ഢിയാണ്. അന്വേഷണത്തിന് സമയമെടുക്കുകയും പ്രോഗ്രാമിംഗിൽ നിന്ന് തന്നെ വ്യതിചലിക്കുകയും ചെയ്യുന്നു.

ഉപസംഹാരം: അതിന്റെ ശുദ്ധമായ രൂപത്തിൽ അത് ഞങ്ങൾക്ക് അനുയോജ്യമല്ല.

2. പിംഗ്-പോംഗ്. ഈ സമീപനത്തിൽ ഒരാൾ പരീക്ഷ എഴുതുകയും മറ്റൊരാൾ അത് നടപ്പിലാക്കുകയും ചെയ്യുന്നു. യൂണിറ്റ് ടെസ്റ്റുകളിൽ എല്ലാം സങ്കീർണ്ണമാണ് എന്ന വസ്തുത കണക്കിലെടുക്കുമ്പോൾ, നിങ്ങൾ ഒരു ഇന്റഗ്രേഷൻ ടെസ്റ്റ് എഴുതണം, അത് പ്രോഗ്രാം ചെയ്യാൻ വളരെ സമയമെടുക്കും, പിംഗ്-പോങ്ങിന്റെ എല്ലാ എളുപ്പവും ഇല്ലാതാകും.

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

ഉപസംഹാരം: അയ്യോ, ജോലിയുടെ വേഗത IaC-യിൽ ഒരു ജോടി പ്രോഗ്രാമിംഗ് പരിശീലനമായി പിംഗ്-പോംഗ് ഉപയോഗിക്കാൻ അനുവദിക്കുന്നില്ല.

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

പഠനത്തിന് നല്ലതാണ്, എന്നാൽ ശക്തമായ മൃദു കഴിവുകൾ ആവശ്യമാണ്. ഇവിടെയാണ് ഞങ്ങൾ കുഴഞ്ഞുവീണത്. സാങ്കേതികത ബുദ്ധിമുട്ടായിരുന്നു. അത് അടിസ്ഥാന സൗകര്യങ്ങളുടെ കാര്യമല്ല.

ഉപസംഹാരം: ഇത് ഉപയോഗിക്കാൻ കഴിയും, ഞങ്ങൾ ശ്രമം ഉപേക്ഷിക്കുന്നില്ല.

4. മൊബ്ബിംഗ്, കൂട്ടം കൂട്ടം, അറിയപ്പെടുന്നതും എന്നാൽ ലിസ്റ്റുചെയ്തിട്ടില്ലാത്തതുമായ എല്ലാ ശൈലികളും ഞങ്ങൾ അത് പരിഗണിക്കുന്നില്ല, കാരണം ഞങ്ങൾ ഇത് പരീക്ഷിച്ചിട്ടില്ല, ഞങ്ങളുടെ ജോലിയുടെ പശ്ചാത്തലത്തിൽ അതിനെക്കുറിച്ച് സംസാരിക്കുന്നത് അസാധ്യമാണ്.

ജോടി പ്രോഗ്രാമിംഗ് ഉപയോഗിക്കുന്നതിനുള്ള പൊതു ഫലങ്ങൾ:

• ഞങ്ങൾക്ക് ജോലിയുടെ അസമമായ വേഗതയുണ്ട്, അത് ആശയക്കുഴപ്പമുണ്ടാക്കുന്നു.
• ഞങ്ങൾക്ക് വേണ്ടത്ര നല്ല സോഫ്റ്റ് സ്‌കില്ലുകൾ ഇല്ലായിരുന്നു. നമ്മുടെ ഈ പോരായ്മകളെ മറികടക്കാൻ വിഷയ മേഖല സഹായിക്കില്ല.
• ദൈർഘ്യമേറിയ പരിശോധനകളും ഉപകരണങ്ങളുമായുള്ള പ്രശ്നങ്ങളും ജോടിയാക്കിയ വികസനം ബുദ്ധിമുട്ടാക്കുന്നു.

5. ഇതൊക്കെയാണെങ്കിലും, വിജയങ്ങൾ ഉണ്ടായിരുന്നു. ഞങ്ങൾ ഞങ്ങളുടെ സ്വന്തം രീതി "കൺവേർജൻസ് - ഡൈവേർജൻസ്" കൊണ്ടുവന്നു. ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ഞാൻ ചുരുക്കമായി വിവരിക്കും.

ഞങ്ങൾക്ക് കുറച്ച് ദിവസത്തേക്ക് (ഒരാഴ്ചയിൽ താഴെ) സ്ഥിര പങ്കാളികളുണ്ട്. ഞങ്ങൾ ഒരുമിച്ച് ഒരു ജോലി ചെയ്യുന്നു. ഞങ്ങൾ കുറച്ചുനേരം ഒരുമിച്ച് ഇരിക്കുന്നു: ഒരാൾ എഴുതുന്നു, മറ്റൊരാൾ ഇരുന്നു പിന്തുണ ടീമിനെ കാണുന്നു. പിന്നീട് ഞങ്ങൾ കുറച്ച് സമയത്തേക്ക് ചിതറുന്നു, ഓരോരുത്തരും ചില സ്വതന്ത്രമായ കാര്യങ്ങൾ ചെയ്യുന്നു, പിന്നെ ഞങ്ങൾ വീണ്ടും ഒത്തുചേരുന്നു, വളരെ വേഗത്തിൽ സമന്വയിപ്പിക്കുന്നു, ഒരുമിച്ച് എന്തെങ്കിലും ചെയ്ത് വീണ്ടും ചിതറുന്നു.

ആസൂത്രണവും ആശയവിനിമയവും

OS പ്രശ്നങ്ങൾ പരിഹരിക്കപ്പെടുന്ന സമ്പ്രദായങ്ങളുടെ അവസാന ബ്ലോക്ക് ടാസ്ക്കുകൾക്കൊപ്പം ജോലിയുടെ ഓർഗനൈസേഷനാണ്. ജോഡി വർക്കിന് പുറത്തുള്ള അനുഭവങ്ങളുടെ കൈമാറ്റവും ഇതിൽ ഉൾപ്പെടുന്നു. മൂന്ന് ആചാരങ്ങൾ നോക്കാം:

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

ഈ സ്കീം ഫീഡ്‌ബാക്കും നൽകുന്നു, ഇത് ഞങ്ങൾ റാലികളിൽ സമന്വയിപ്പിക്കുമ്പോൾ ദിവസത്തിൽ ഒരിക്കൽ സംഭവിക്കുന്നു. എല്ലാവരുടെയും മുന്നിൽ പൊതുവായ ഒരു പ്ലാൻ ഉണ്ടായിരിക്കുന്നത്, എന്നാൽ ഘടനാപരമായതും പൂർണ്ണമായും തുറന്നതും, എന്താണ് സംഭവിക്കുന്നതെന്നും നമ്മൾ എത്രത്തോളം പുരോഗമിച്ചുവെന്നും അറിയാൻ എല്ലാവരെയും അനുവദിക്കുന്നു.

ടാസ്ക്കുകളുടെ വിഷ്വൽ കാഴ്ചയുടെ പ്രയോജനങ്ങൾ:

• കാര്യകാരണത്വം. ഓരോ ജോലിയും ചില ആഗോള ലക്ഷ്യങ്ങളിലേക്ക് നയിക്കുന്നു. ടാസ്ക്കുകൾ ചെറിയ ലക്ഷ്യങ്ങളായി തരം തിരിച്ചിരിക്കുന്നു. ഇൻഫ്രാസ്ട്രക്ചർ ഡൊമെയ്ൻ തന്നെ തികച്ചും സാങ്കേതികമാണ്. മറ്റൊരു nginx-ലേക്ക് മൈഗ്രേറ്റുചെയ്യുമ്പോൾ ഒരു റൺബുക്ക് എഴുതുന്നത് ബിസിനസിൽ എന്ത് പ്രത്യേക സ്വാധീനം ചെലുത്തുന്നുവെന്ന് എല്ലായ്പ്പോഴും പെട്ടെന്ന് വ്യക്തമല്ല. ടാർഗെറ്റ് കാർഡ് സമീപത്ത് ഉള്ളത് അത് കൂടുതൽ വ്യക്തമാക്കുന്നു.
  
  പ്രശ്നങ്ങളുടെ ഒരു പ്രധാന സ്വത്താണ് കാര്യകാരണം. “ഞാൻ ചെയ്യുന്നത് ശരിയാണോ?” എന്ന ചോദ്യത്തിന് ഇത് നേരിട്ട് ഉത്തരം നൽകുന്നു.
• സമാന്തരവാദം. ഞങ്ങളിൽ ഒമ്പത് പേരുണ്ട്, എല്ലാവരേയും ഒരു ജോലിയിലേക്ക് വലിച്ചെറിയുന്നത് ശാരീരികമായി അസാധ്യമാണ്. ഒരു ഏരിയയിൽ നിന്നുള്ള ജോലികൾ എപ്പോഴും മതിയാകണമെന്നില്ല. ചെറിയ വർക്കിംഗ് ഗ്രൂപ്പുകൾക്കിടയിൽ ജോലി സമാന്തരമാക്കാൻ ഞങ്ങൾ നിർബന്ധിതരാകുന്നു. അതേസമയം, ഗ്രൂപ്പുകൾ കുറച്ച് സമയത്തേക്ക് അവരുടെ ചുമതലയിൽ ഇരിക്കുന്നു, അവരെ മറ്റൊരാൾക്ക് ശക്തിപ്പെടുത്താൻ കഴിയും. ചിലപ്പോൾ ആളുകൾ ഈ വർക്കിംഗ് ഗ്രൂപ്പിൽ നിന്ന് അകന്നുപോകും. ആരോ അവധിക്ക് പോകുന്നു, ആരെങ്കിലും DevOps conf-നായി ഒരു റിപ്പോർട്ട് ചെയ്യുന്നു, ആരെങ്കിലും Habr-നെക്കുറിച്ച് ഒരു ലേഖനം എഴുതുന്നു. സമാന്തരമായി എന്തെല്ലാം ലക്ഷ്യങ്ങളും ജോലികളും ചെയ്യാൻ കഴിയുമെന്ന് അറിയുന്നത് വളരെ പ്രധാനമാണ്.

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

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

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

ചെയ്ത ജോലികൾ പരസ്പരം പ്രദർശിപ്പിച്ച് ചർച്ച ചെയ്താണ് പരിഹാരം കണ്ടെത്തിയത്. ഞങ്ങൾ ആഴ്‌ചയിലൊരിക്കൽ ഒരു മണിക്കൂർ കൂടുകയും കഴിഞ്ഞ ആഴ്‌ചയിൽ ചെയ്‌ത ജോലികൾക്കുള്ള പരിഹാരങ്ങളുടെ വിശദാംശങ്ങൾ കാണിക്കുകയും ചെയ്യുന്നു.

പ്രകടനത്തിനിടയിൽ, ചുമതലയുടെ വിശദാംശങ്ങൾ വെളിപ്പെടുത്തുകയും അതിന്റെ പ്രവർത്തനം പ്രകടമാക്കുന്നത് ഉറപ്പാക്കുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്.

ഒരു ചെക്ക്‌ലിസ്റ്റ് ഉപയോഗിച്ച് റിപ്പോർട്ട് നടത്താം.1. സന്ദർഭത്തിലേക്ക് പ്രവേശിക്കുക. ചുമതല എവിടെ നിന്ന് വന്നു, എന്തുകൊണ്ട് അത് ആവശ്യമായി വന്നു?

2. മുമ്പ് എങ്ങനെയാണ് പ്രശ്നം പരിഹരിച്ചത്? ഉദാഹരണത്തിന്, വൻതോതിലുള്ള മൗസ് ക്ലിക്കിംഗ് ആവശ്യമാണ്, അല്ലെങ്കിൽ ഒന്നും ചെയ്യാൻ കഴിയില്ല.

3. ഞങ്ങൾ അത് എങ്ങനെ മെച്ചപ്പെടുത്തുന്നു. ഉദാഹരണത്തിന്: "നോക്കൂ, ഇപ്പോൾ സ്ക്രിപ്റ്റോസിക് ഉണ്ട്, ഇവിടെ വായിക്കാം."

4. ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണിക്കുക. ചില ഉപയോക്തൃ സാഹചര്യങ്ങൾ നേരിട്ട് നടപ്പിലാക്കുന്നതാണ് ഉചിതം. എനിക്ക് X വേണം, ഞാൻ Y ചെയ്യുന്നു, ഞാൻ Y (അല്ലെങ്കിൽ Z) കാണുന്നു. ഉദാഹരണത്തിന്, ഞാൻ NGINX വിന്യസിക്കുകയും url പുകവലിക്കുകയും 200 ശരി നേടുകയും ചെയ്യുന്നു. പ്രവർത്തനം ദൈർഘ്യമേറിയതാണെങ്കിൽ, അത് മുൻകൂട്ടി തയ്യാറാക്കുക, അതുവഴി നിങ്ങൾക്ക് അത് പിന്നീട് കാണിക്കാനാകും. ഡെമോയ്ക്ക് ഒരു മണിക്കൂർ മുമ്പ്, അത് ദുർബലമാണെങ്കിൽ അത് തകർക്കാതിരിക്കുന്നതാണ് ഉചിതം.

5. പ്രശ്നം എത്ര വിജയകരമായി പരിഹരിച്ചു, എന്ത് ബുദ്ധിമുട്ടുകൾ അവശേഷിക്കുന്നു, എന്താണ് പൂർത്തിയാകാത്തത്, ഭാവിയിൽ എന്ത് മെച്ചപ്പെടുത്തലുകൾ സാധ്യമാണ് എന്ന് വിശദീകരിക്കുക. ഉദാഹരണത്തിന്, ഇപ്പോൾ CLI, അപ്പോൾ CI-യിൽ പൂർണ്ണ ഓട്ടോമേഷൻ ഉണ്ടാകും.

ഓരോ സ്പീക്കറും ഇത് 5-10 മിനിറ്റ് വരെ നിലനിർത്തുന്നത് നല്ലതാണ്. നിങ്ങളുടെ സംസാരം വ്യക്തമായും പ്രാധാന്യമുള്ളതും കൂടുതൽ സമയമെടുക്കുന്നതുമാണെങ്കിൽ, sre-ടേക്ക് ഓവർ ചാനലിൽ ഇത് മുൻകൂട്ടി ഏകോപിപ്പിക്കുക.

മുഖാമുഖം ഭാഗത്തിന് ശേഷം ത്രെഡിൽ എപ്പോഴും ഒരു ചർച്ചയുണ്ട്. ഇവിടെയാണ് ഞങ്ങളുടെ ടാസ്‌ക്കുകളിൽ ആവശ്യമായ ഫീഡ്‌ബാക്ക് ദൃശ്യമാകുന്നത്.

തൽഫലമായി, എന്താണ് സംഭവിക്കുന്നതെന്ന് നിർണ്ണയിക്കാൻ ഒരു സർവേ നടത്തുന്നു. ഇത് സംഭാഷണത്തിന്റെ സാരാംശത്തെക്കുറിച്ചും ചുമതലയുടെ പ്രാധാന്യത്തെക്കുറിച്ചും ഉള്ള ഫീഡ്ബാക്ക് ആണ്.

നീണ്ട നിഗമനങ്ങളും അടുത്തത് എന്താണ്

ലേഖനത്തിന്റെ സ്വരം അൽപ്പം അശുഭാപ്തിവിശ്വാസമാണെന്ന് തോന്നാം. ഇത് തെറ്റാണ്. രണ്ട് താഴ്ന്ന തലത്തിലുള്ള ഫീഡ്‌ബാക്ക്, അതായത് ടെസ്റ്റുകളും ജോഡി പ്രോഗ്രാമിംഗും പ്രവർത്തിക്കുന്നു. പരമ്പരാഗത വികസനം പോലെ തികഞ്ഞ അല്ല, എന്നാൽ അതിൽ നിന്ന് ഒരു നല്ല പ്രഭാവം ഉണ്ട്.

ടെസ്റ്റുകൾ, അവയുടെ നിലവിലെ രൂപത്തിൽ, ഭാഗിക കോഡ് കവറേജ് മാത്രമേ നൽകുന്നുള്ളൂ. പല കോൺഫിഗറേഷൻ ഫംഗ്‌ഷനുകളും പരീക്ഷിക്കാതെ അവസാനിക്കുന്നു. കോഡ് എഴുതുമ്പോൾ യഥാർത്ഥ ജോലിയിൽ അവരുടെ സ്വാധീനം കുറവായിരിക്കും. എന്നിരുന്നാലും, ഇന്റഗ്രേഷൻ ടെസ്റ്റുകളിൽ നിന്ന് ഒരു ഫലമുണ്ട്, കൂടാതെ നിർഭയമായി പുനർനിർമ്മാണങ്ങൾ നടത്താൻ അവ നിങ്ങളെ അനുവദിക്കുന്നു. ഇതൊരു വലിയ നേട്ടമാണ്. കൂടാതെ, ഉയർന്ന തലത്തിലുള്ള ഭാഷകളിലെ വികസനത്തിലേക്ക് ശ്രദ്ധ മാറുന്നതോടെ (ഞങ്ങൾക്ക് പൈത്തൺ ഉണ്ട്, പോകുക), പ്രശ്നം ഇല്ലാതാകും. “പശ” യ്‌ക്കായി നിങ്ങൾക്ക് ധാരാളം പരിശോധനകൾ ആവശ്യമില്ല; ഒരു പൊതു ഏകീകരണ പരിശോധന മതി.

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

OS-നെ സ്വാധീനിക്കുന്നതിനുള്ള ഉയർന്ന തലത്തിലുള്ള വഴികൾ - ടാസ്‌ക്കുകൾ ആസൂത്രണം ചെയ്യുകയും പ്രവർത്തിക്കുകയും ചെയ്യുന്നത് കൃത്യമായ ഇഫക്റ്റുകൾ സൃഷ്ടിക്കുന്നു: ഉയർന്ന നിലവാരമുള്ള വിജ്ഞാന കൈമാറ്റവും മെച്ചപ്പെട്ട വികസന നിലവാരവും.

ഒരു വരിയിൽ ഹ്രസ്വ നിഗമനങ്ങൾ

• എച്ച്ആർ പ്രാക്ടീഷണർമാർ IaC-ൽ പ്രവർത്തിക്കുന്നു, പക്ഷേ കാര്യക്ഷമത കുറവാണ്.
• പ്രവർത്തിക്കുന്നത് ശക്തിപ്പെടുത്തുക.
• നിങ്ങളുടെ സ്വന്തം നഷ്ടപരിഹാര സംവിധാനങ്ങളും സമ്പ്രദായങ്ങളും കൊണ്ടുവരിക.

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