അടിസ്ഥാന സൗകര്യങ്ങൾ കോഡായി: ആദ്യ പരിചയം

ഞങ്ങളുടെ കമ്പനി ഒരു SRE ടീമിനെ ഉൾപ്പെടുത്താനുള്ള പ്രക്രിയയിലാണ്. വികസനത്തിന്റെ ഭാഗത്ത് നിന്നാണ് ഞാൻ ഈ മുഴുവൻ കഥയിലേക്കും വന്നത്. ഈ പ്രക്രിയയിൽ, മറ്റ് ഡെവലപ്പർമാരുമായി പങ്കിടാൻ ആഗ്രഹിക്കുന്ന ചിന്തകളും ഉൾക്കാഴ്ചകളും ഞാൻ കണ്ടെത്തി. ഈ പ്രതിഫലന ലേഖനത്തിൽ ഞാൻ എന്താണ് സംഭവിക്കുന്നത്, അത് എങ്ങനെ സംഭവിക്കുന്നു, എല്ലാവർക്കും എങ്ങനെ ജീവിക്കാൻ കഴിയും എന്നതിനെക്കുറിച്ച് സംസാരിക്കുന്നു.

ഞങ്ങളുടെ ആന്തരിക പരിപാടിയിലെ പ്രസംഗങ്ങളെ അടിസ്ഥാനമാക്കി എഴുതിയ ലേഖനങ്ങളുടെ ഒരു പരമ്പരയുടെ തുടർച്ച DevForum:

1. ബോക്സില്ലാത്ത ഷ്രോഡിംഗറുടെ പൂച്ച: വിതരണം ചെയ്ത സിസ്റ്റങ്ങളിലെ സമവായത്തിന്റെ പ്രശ്നം.
2. അടിസ്ഥാന സൗകര്യങ്ങൾ കോഡായി. (നീ ഇവിടെയാണ്)
3. C# മോഡലുകൾ ഉപയോഗിച്ച് ടൈപ്പ്സ്ക്രിപ്റ്റ് കരാറുകളുടെ ജനറേഷൻ. (പുരോഗതിയിൽ...)
4. റാഫ്റ്റ് സമവായ അൽഗോരിതത്തിലേക്കുള്ള ആമുഖം. (പുരോഗതിയിൽ...)
പങ്ക് € |

ആശയങ്ങൾ നടപ്പിലാക്കിക്കൊണ്ട് ഒരു SRE ടീം സൃഷ്ടിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു ഗൂഗിൾ ശ്രീ. അവർ സ്വന്തം ഡെവലപ്പർമാരിൽ നിന്ന് പ്രോഗ്രാമർമാരെ റിക്രൂട്ട് ചെയ്യുകയും മാസങ്ങളോളം അവരെ പരിശീലിപ്പിക്കുകയും ചെയ്തു.

ടീമിന് ഇനിപ്പറയുന്ന പരിശീലന ചുമതലകൾ ഉണ്ടായിരുന്നു:

• മൈക്രോസോഫ്റ്റ് അസ്യൂറിൽ കോഡിന്റെ രൂപത്തിൽ (ടെറാഫോമും ചുറ്റുമുള്ള എല്ലാം) ഉള്ള ഞങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ വിവരിക്കുക.
• അടിസ്ഥാന സൗകര്യങ്ങളുമായി എങ്ങനെ പ്രവർത്തിക്കണമെന്ന് ഡവലപ്പർമാരെ പഠിപ്പിക്കുക.
• ഡവലപ്പർമാരെ ഡ്യൂട്ടിക്കായി തയ്യാറാക്കുക.

ഇൻഫ്രാസ്ട്രക്ചർ എന്ന ആശയം ഞങ്ങൾ കോഡായി അവതരിപ്പിക്കുന്നു

ലോകത്തിന്റെ സാധാരണ മാതൃകയിൽ (ക്ലാസിക്കൽ അഡ്മിനിസ്ട്രേഷൻ), ഇൻഫ്രാസ്ട്രക്ചറിനെക്കുറിച്ചുള്ള അറിവ് രണ്ട് സ്ഥലങ്ങളിൽ സ്ഥിതിചെയ്യുന്നു:

1. അല്ലെങ്കിൽ വിദഗ്ധരുടെ തലയിൽ അറിവിന്റെ രൂപത്തിൽ.
2. അല്ലെങ്കിൽ ഈ വിവരങ്ങൾ ചില ടൈപ്പ്റൈറ്ററുകളിലാണുള്ളത്, അവയിൽ ചിലത് വിദഗ്ധർക്ക് അറിയാം. എന്നാൽ പുറത്തുനിന്നുള്ള ഒരാൾക്ക് (ഞങ്ങളുടെ മുഴുവൻ ടീമും പെട്ടെന്ന് മരണപ്പെട്ടാൽ) എന്താണ് പ്രവർത്തിക്കുന്നത്, എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് കണ്ടുപിടിക്കാൻ കഴിയുമെന്നത് ഒരു വസ്തുതയല്ല. ഒരു മെഷീനിൽ ധാരാളം വിവരങ്ങൾ ഉണ്ടായിരിക്കാം: ആക്സസറികൾ, ക്രോൺജോബ്സ്, ഭീഷണിപ്പെടുത്തിയത് (കാണുക. ഡിസ്ക് മൗണ്ടിംഗ്) ഡിസ്കും സംഭവിക്കാവുന്ന കാര്യങ്ങളുടെ അനന്തമായ പട്ടികയും. യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് മനസ്സിലാക്കാൻ പ്രയാസമാണ്.

രണ്ട് സാഹചര്യങ്ങളിലും, ആശ്രിതരാകുന്നതിൽ നാം കുടുങ്ങിക്കിടക്കുന്നതായി കാണുന്നു:

• അല്ലെങ്കിൽ മാരകമായ, അസുഖത്തിന് വിധേയനായ, പ്രണയത്തിലാകുന്നത്, മാനസികാവസ്ഥയിലെ മാറ്റങ്ങളും നിസ്സാരമായ പിരിച്ചുവിടലുകളും;
• അല്ലെങ്കിൽ ശാരീരികമായി പ്രവർത്തിക്കുന്ന ഒരു യന്ത്രത്തിൽ നിന്ന്, അത് വീഴുകയും മോഷ്ടിക്കുകയും ആശ്ചര്യങ്ങളും അസൗകര്യങ്ങളും അവതരിപ്പിക്കുകയും ചെയ്യുന്നു.

മനുഷ്യർക്ക് വായിക്കാവുന്നതും പരിപാലിക്കാവുന്നതും നന്നായി എഴുതപ്പെട്ടതുമായ കോഡിലേക്ക് എല്ലാം വിവർത്തനം ചെയ്യണമെന്ന് പറയാതെ വയ്യ.

അങ്ങനെ, ഇൻഫ്രാസ്ട്രക്ചർ കോഡായി (Incfastructure as Code - IaC) നിലവിലുള്ള മുഴുവൻ ഇൻഫ്രാസ്ട്രക്ചറിന്റെയും കോഡിന്റെ രൂപത്തിലുള്ള വിവരണമാണ്, അതോടൊപ്പം പ്രവർത്തിക്കുന്നതിനും അതിൽ നിന്ന് യഥാർത്ഥ ഇൻഫ്രാസ്ട്രക്ചർ നടപ്പിലാക്കുന്നതിനുമുള്ള അനുബന്ധ ഉപകരണങ്ങൾ.

എന്തിനാണ് എല്ലാം കോഡിലേക്ക് വിവർത്തനം ചെയ്യുന്നത്?ആളുകൾ യന്ത്രങ്ങളല്ല. അവർക്ക് എല്ലാം ഓർക്കാൻ കഴിയില്ല. ഒരു വ്യക്തിയുടെയും യന്ത്രത്തിന്റെയും പ്രതികരണം വ്യത്യസ്തമാണ്. ഓട്ടോമേറ്റഡ് ആയ എന്തും മനുഷ്യൻ ചെയ്യുന്നതിനേക്കാൾ വേഗതയുള്ളതാണ്. ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം സത്യത്തിന്റെ ഒരൊറ്റ ഉറവിടമാണ്.

പുതിയ SRE എഞ്ചിനീയർമാർ എവിടെ നിന്നാണ് വരുന്നത്?അതിനാൽ, പുതിയ SRE എഞ്ചിനീയർമാരെ നിയമിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു, പക്ഷേ അവരെ എവിടെ നിന്ന് ലഭിക്കും? ശരിയായ ഉത്തരങ്ങളോടെ ബുക്ക് ചെയ്യുക (Google SRE ബുക്ക്) ഞങ്ങളോട് പറയുന്നു: ഡവലപ്പർമാരിൽ നിന്ന്. എല്ലാത്തിനുമുപരി, അവർ കോഡിനൊപ്പം പ്രവർത്തിക്കുന്നു, നിങ്ങൾ അനുയോജ്യമായ അവസ്ഥ കൈവരിക്കുന്നു.

ഞങ്ങളുടെ കമ്പനിക്ക് പുറത്തുള്ള പേഴ്‌സണൽ മാർക്കറ്റിൽ ഞങ്ങൾ അവർക്കായി വളരെക്കാലം തിരഞ്ഞു. എന്നാൽ ഞങ്ങളുടെ അഭ്യർത്ഥനകൾക്ക് അനുയോജ്യമായ ആരെയും ഞങ്ങൾ കണ്ടെത്തിയില്ല എന്ന് സമ്മതിക്കണം. എനിക്ക് എന്റെ സ്വന്തം ആളുകൾക്കിടയിൽ തിരയേണ്ടി വന്നു.

കോഡായി അടിസ്ഥാന സൗകര്യങ്ങൾ പ്രശ്നങ്ങൾ

അടിസ്ഥാന സൗകര്യങ്ങളെ കോഡിലേക്ക് എങ്ങനെ ഹാർഡ്കോഡ് ചെയ്യാം എന്നതിന്റെ ഉദാഹരണങ്ങൾ നോക്കാം. കോഡ് നന്നായി എഴുതിയിരിക്കുന്നു, ഉയർന്ന നിലവാരം, അഭിപ്രായങ്ങളും ഇൻഡന്റേഷനുകളും.

ടെറഫോമയിൽ നിന്നുള്ള ഉദാഹരണ കോഡ്.

അൻസിബിളിൽ നിന്നുള്ള ഉദാഹരണ കോഡ്.

മാന്യരേ, ഇത് വളരെ ലളിതമായിരുന്നെങ്കിൽ! ഞങ്ങൾ യഥാർത്ഥ ലോകത്താണ്, നിങ്ങളെ ആശ്ചര്യപ്പെടുത്താനും ആശ്ചര്യങ്ങളും പ്രശ്നങ്ങളും അവതരിപ്പിക്കാനും അത് എപ്പോഴും തയ്യാറാണ്. ഇവിടെയും അവരില്ലാതെ പറ്റില്ല.

1. ആദ്യത്തെ പ്രശ്നം, മിക്ക കേസുകളിലും IaC ഒരുതരം dsl ആണ്.

DSL, അതാകട്ടെ, ഘടനയുടെ വിവരണമാണ്. കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, നിങ്ങൾക്ക് ഉണ്ടായിരിക്കേണ്ടത്: Json, Yaml, സ്വന്തം ഡിഎസ്എൽ (HCL ടെറാഫോമിൽ ഉപയോഗിക്കുന്നു) കൊണ്ട് വന്ന ചില വലിയ കമ്പനികളിൽ നിന്നുള്ള പരിഷ്കാരങ്ങൾ.

പരിചിതമായ കാര്യങ്ങൾ അതിൽ അടങ്ങിയിരിക്കില്ല എന്നതാണ് കുഴപ്പം:

• വേരിയബിളുകൾ;
• വ്യവസ്ഥകൾ;
• എവിടെയോ അഭിപ്രായങ്ങളൊന്നുമില്ല, ഉദാഹരണത്തിന്, Json-ൽ, സ്ഥിരസ്ഥിതിയായി അവ നൽകിയിട്ടില്ല;
• പ്രവർത്തനങ്ങൾ;
• ക്ലാസുകൾ, അനന്തരാവകാശം തുടങ്ങിയ ഉയർന്ന തലത്തിലുള്ള കാര്യങ്ങളെക്കുറിച്ച് പോലും ഞാൻ സംസാരിക്കുന്നില്ല.

2. അത്തരം കോഡിലെ രണ്ടാമത്തെ പ്രശ്നം മിക്കപ്പോഴും ഇത് ഒരു വൈവിധ്യമാർന്ന അന്തരീക്ഷമാണ് എന്നതാണ്. സാധാരണയായി നിങ്ങൾ C# ഉപയോഗിച്ച് ഇരുന്നു പ്രവർത്തിക്കുന്നു, അതായത്. ഒരു ഭാഷ, ഒരു സ്റ്റാക്ക്, ഒരു ആവാസവ്യവസ്ഥ. ഇവിടെ നിങ്ങൾക്ക് വൈവിധ്യമാർന്ന സാങ്കേതികവിദ്യകളുണ്ട്.

പൈത്തണുള്ള ബാഷ്, Json ചേർത്തിരിക്കുന്ന ചില പ്രക്രിയകൾ സമാരംഭിക്കുമ്പോൾ ഇത് വളരെ യഥാർത്ഥ സാഹചര്യമാണ്. നിങ്ങൾ അത് വിശകലനം ചെയ്യുക, തുടർന്ന് മറ്റേതെങ്കിലും ജനറേറ്റർ മറ്റൊരു 30 ഫയലുകൾ നിർമ്മിക്കുന്നു. ഇതിനെല്ലാം വേണ്ടി, Go-ൽ എഴുതിയ drone.io എന്നതിനായുള്ള ഒരു പ്ലഗിൻ ഉപയോഗിച്ച് വലിക്കുന്ന അസൂർ കീ വോൾട്ടിൽ നിന്ന് ഇൻപുട്ട് വേരിയബിളുകൾ ലഭിക്കുന്നു, കൂടാതെ ഈ വേരിയബിളുകൾ yaml-ലൂടെ കടന്നുപോകുന്നു, ഇത് jsonnet ടെംപ്ലേറ്റ് എഞ്ചിനിൽ നിന്നുള്ള തലമുറയുടെ ഫലമായി ജനറേറ്റുചെയ്‌തതാണ്. നിങ്ങൾക്ക് ഇത്രയും വൈവിധ്യമാർന്ന പരിതസ്ഥിതി ഉള്ളപ്പോൾ കർശനമായി വിവരിച്ച കോഡ് ഉണ്ടാകുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്.

ഒരു ജോലിയുടെ ചട്ടക്കൂടിനുള്ളിലെ പരമ്പരാഗത വികസനം ഒരു ഭാഷയിൽ വരുന്നു. ഇവിടെ ഞങ്ങൾ ധാരാളം ഭാഷകളിൽ പ്രവർത്തിക്കുന്നു.

3. മൂന്നാമത്തെ പ്രശ്നം ട്യൂണിംഗ് ആണ്. ഞങ്ങൾക്ക് വേണ്ടി എല്ലാം ചെയ്യുന്ന എഡിറ്റർമാരെ (Ms Visual Studio, Jetbrains Rider) തണുപ്പിക്കാൻ ഞങ്ങൾ പതിവാണ്. നമ്മൾ വിഡ്ഢികളാണെങ്കിലും നമ്മൾ തെറ്റാണെന്ന് അവർ പറയും. ഇത് സാധാരണവും സ്വാഭാവികവുമാണെന്ന് തോന്നുന്നു.

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

ഇത് എഴുതുന്ന സമയത്ത് vcode-terraform പ്ലഗിൻ പതിപ്പ് 0.12-നെ പിന്തുണയ്ക്കുന്നതിനായി ഇതുവരെ പുറത്തിറക്കിയിട്ടില്ല, എന്നിരുന്നാലും ഇത് 3 മാസമായി പുറത്തിറങ്ങി.

മറക്കാൻ സമയമായി...

1. ഡീബഗ്ഗിംഗ്.
2. റീഫാക്ടറിംഗ് ഉപകരണം.
3. യാന്ത്രിക പൂർത്തീകരണം.
4. സമാഹരിക്കുന്ന സമയത്ത് പിശകുകൾ കണ്ടെത്തൽ.

ഇത് തമാശയാണ്, പക്ഷേ ഇത് വികസന സമയം വർദ്ധിപ്പിക്കുകയും അനിവാര്യമായും സംഭവിക്കുന്ന പിശകുകളുടെ എണ്ണം വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു.

ഏറ്റവും മോശം കാര്യം, എങ്ങനെ രൂപകൽപ്പന ചെയ്യാം, ഫയലുകൾ ഫോൾഡറുകളായി ക്രമീകരിക്കാം, വിഘടിപ്പിക്കാം, കോഡ് പരിപാലിക്കാൻ കഴിയുന്നതും വായിക്കാൻ കഴിയുന്നതും മറ്റും എങ്ങനെ ചെയ്യാം എന്നതിനെക്കുറിച്ചല്ല, മറിച്ച് ഈ കമാൻഡ് എങ്ങനെ ശരിയായി എഴുതാം എന്നതിനെക്കുറിച്ചല്ല, കാരണം ഞാൻ എങ്ങനെയെങ്കിലും ഇത് തെറ്റായി എഴുതി. .

ഒരു തുടക്കക്കാരൻ എന്ന നിലയിൽ, നിങ്ങൾ ടെറാഫോമുകൾ പഠിക്കാൻ ശ്രമിക്കുന്നു, കൂടാതെ IDE നിങ്ങളെ ഒട്ടും സഹായിക്കുന്നില്ല. ഡോക്യുമെന്റേഷൻ ഉള്ളപ്പോൾ, അകത്ത് പോയി നോക്കുക. എന്നാൽ നിങ്ങൾ ഒരു പുതിയ പ്രോഗ്രാമിംഗ് ഭാഷയാണ് നൽകുന്നതെങ്കിൽ, അത്തരമൊരു തരം ഉണ്ടെന്ന് IDE നിങ്ങളോട് പറയും, എന്നാൽ അങ്ങനെയൊന്നുമില്ല. കുറഞ്ഞത് ഇൻറ്റ് അല്ലെങ്കിൽ സ്ട്രിംഗ് തലത്തിലെങ്കിലും. ഇത് പലപ്പോഴും ഉപയോഗപ്രദമാണ്.

ടെസ്റ്റുകളുടെ കാര്യമോ?

നിങ്ങൾ ചോദിക്കുന്നു: "ടെസ്റ്റുകളുടെ കാര്യമോ, മാന്യരായ പ്രോഗ്രാമർമാരേ?" ഗുരുതരമായ ആളുകൾ ഉൽപ്പാദനത്തിൽ എല്ലാം പരീക്ഷിക്കുന്നു, അത് കഠിനമാണ്. വെബ്‌സൈറ്റിൽ നിന്നുള്ള ടെറാഫോം മൊഡ്യൂളിനായുള്ള യൂണിറ്റ് ടെസ്റ്റിന്റെ ഒരു ഉദാഹരണം ഇതാ മൈക്രോസോഫ്റ്റ്.

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

നിങ്ങൾക്കും എനിക്കും Json ഔട്ട്‌പുട്ടിന്റെ കൃത്യത പരിശോധിക്കാൻ കഴിയും എന്നതാണ് ഒരു യൂണിറ്റ് ടെസ്റ്റിന്റെ പ്രശ്നം. ഞാൻ 5 പാരാമീറ്ററുകൾ എറിഞ്ഞു, 2000 വരികളുള്ള ഒരു Json ഫുട്‌ക്ലോത്ത് നൽകി. എനിക്ക് ഇവിടെ എന്താണ് സംഭവിക്കുന്നതെന്ന് വിശകലനം ചെയ്യാം, പരിശോധനാ ഫലം സാധൂകരിക്കാം...

Go-യിൽ Json പാഴ്‌സ് ചെയ്യുന്നത് ബുദ്ധിമുട്ടാണ്. നിങ്ങൾ Go-യിൽ എഴുതേണ്ടതുണ്ട്, കാരണം Go-യിലെ ടെറാഫോം നിങ്ങൾ എഴുതുന്ന ഭാഷയിൽ പരീക്ഷിക്കുന്നതിനുള്ള ഒരു നല്ല പരിശീലനമാണ്. കോഡിന്റെ ഓർഗനൈസേഷൻ തന്നെ വളരെ ദുർബലമാണ്. അതേ സമയം, ഇത് പരീക്ഷണത്തിനുള്ള ഏറ്റവും മികച്ച ലൈബ്രറിയാണ്.

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

അടിസ്ഥാന സൗകര്യങ്ങളെ കോഡായി മികച്ച രീതിയിൽ പരിശീലിക്കുന്നു

നമുക്ക് നീങ്ങാം. IaC-യിൽ പരിശോധനകളൊന്നും ഇല്ലെങ്കിൽ, IDE-യും ട്യൂണിംഗും മോശമാണെങ്കിൽ, ഏറ്റവും മികച്ച രീതികളെങ്കിലും ഉണ്ടായിരിക്കണം. ഞാൻ Google Analytics-ലേക്ക് പോയി രണ്ട് തിരയൽ അന്വേഷണങ്ങൾ താരതമ്യം ചെയ്തു: Terraform best practices and c# best practices.

നമ്മൾ എന്താണ് കാണുന്നത്? ക്രൂരമായ സ്ഥിതിവിവരക്കണക്കുകൾ ഞങ്ങൾക്ക് അനുകൂലമല്ല. മെറ്റീരിയലിന്റെ അളവ് തുല്യമാണ്. C# ഡെവലപ്‌മെന്റിൽ, ഞങ്ങൾ മെറ്റീരിയലുകളിൽ അലഞ്ഞുതിരിയുന്നു, ഞങ്ങൾക്ക് മികച്ച രീതികളുണ്ട്, വിദഗ്ധർ എഴുതിയ പുസ്തകങ്ങളുണ്ട്, കൂടാതെ ആ പുസ്‌തകങ്ങളെ വിമർശിക്കുന്ന മറ്റ് വിദഗ്ധരുടെ പുസ്തകങ്ങളിൽ എഴുതിയ പുസ്തകങ്ങളും ഉണ്ട്. ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ, ലേഖനങ്ങൾ, പരിശീലന കോഴ്‌സുകൾ, ഇപ്പോൾ ഓപ്പൺ സോഴ്‌സ് വികസനം എന്നിവയുടെ ഒരു കടൽ.

IaC അഭ്യർത്ഥനയെ സംബന്ധിച്ചിടത്തോളം: ഇവിടെ നിങ്ങൾ ഹൈലോഡ് അല്ലെങ്കിൽ HashiConf റിപ്പോർട്ടുകളിൽ നിന്നും ഔദ്യോഗിക ഡോക്യുമെന്റേഷനിൽ നിന്നും Github-ലെ നിരവധി പ്രശ്നങ്ങളിൽ നിന്നും വിവരങ്ങൾ ശേഖരിക്കാൻ ശ്രമിക്കുന്നു. ഈ മൊഡ്യൂളുകൾ പൊതുവായി എങ്ങനെ വിതരണം ചെയ്യാം, അവയുമായി എന്തുചെയ്യണം? ഇതൊരു യഥാർത്ഥ പ്രശ്‌നമാണെന്ന് തോന്നുന്നു... ഒരു കമ്മ്യൂണിറ്റിയുണ്ട്, മാന്യരേ, ഏത് ചോദ്യത്തിനും നിങ്ങൾക്ക് ഗിത്തബിൽ 10 അഭിപ്രായങ്ങൾ നൽകും. എന്നാൽ അത് കൃത്യമായി അല്ല.

നിർഭാഗ്യവശാൽ, ഈ സമയത്ത്, വിദഗ്ധർ ഉയർന്നുവരാൻ തുടങ്ങിയിരിക്കുന്നു. ഇതുവരെ അവയിൽ വളരെ കുറവാണ്. സമൂഹം തന്നെ അടിസ്ഥാന തലത്തിൽ തൂങ്ങിക്കിടക്കുകയാണ്.

ഇതെല്ലാം എവിടെ പോകുന്നു, എന്തുചെയ്യണം

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

വ്യക്തിപരമായി, ഞാൻ ചില കാര്യങ്ങളിൽ പന്തയം വെക്കുന്നു:

1. ഈ മേഖലയിൽ വികസനം വളരെ വേഗത്തിലാണ് നടക്കുന്നത്. DevOps-നുള്ള അഭ്യർത്ഥനകളുടെ ഒരു ഷെഡ്യൂൾ ഇതാ.

   
   
   വിഷയം ഹൈപ്പ് ആയിരിക്കാം, പക്ഷേ ഗോളം വളരുന്നു എന്നത് കുറച്ച് പ്രതീക്ഷ നൽകുന്നു.

   എന്തെങ്കിലും പെട്ടെന്ന് വളരുകയാണെങ്കിൽ, എന്താണ് ചെയ്യേണ്ടതെന്നും എന്തുചെയ്യരുതെന്നും നിങ്ങളോട് പറയുന്ന മിടുക്കരായ ആളുകൾ തീർച്ചയായും പ്രത്യക്ഷപ്പെടും. ജനപ്രീതിയിലെ വർദ്ധനവ്, ctrl+shift+f വഴി തിരയുന്നതിനുപകരം, vcode-നായി jsonnet-ലേക്ക് ഒരു പ്ലഗിൻ ചേർക്കാൻ ആർക്കെങ്കിലും സമയമുണ്ടായേക്കാം എന്ന വസ്തുതയിലേക്ക് നയിക്കുന്നു. കാര്യങ്ങൾ വികസിക്കുമ്പോൾ, കൂടുതൽ മെറ്റീരിയലുകൾ പ്രത്യക്ഷപ്പെടുന്നു. എസ്ആർഇയെക്കുറിച്ച് ഗൂഗിളിൽ നിന്നുള്ള ഒരു പുസ്തകത്തിന്റെ പ്രകാശനം ഇതിന് മികച്ച ഉദാഹരണമാണ്.

2. നമുക്ക് ഇവിടെ വിജയകരമായി പ്രയോഗിക്കാൻ കഴിയുന്ന പരമ്പരാഗത വികസനത്തിൽ വികസിപ്പിച്ച സാങ്കേതിക വിദ്യകളും സമ്പ്രദായങ്ങളും ഉണ്ട്. അതെ, പരിശോധനയിലും വൈവിധ്യമാർന്ന അന്തരീക്ഷത്തിലും അപര്യാപ്തമായ ഉപകരണങ്ങളിലും സൂക്ഷ്മതകളുണ്ട്, പക്ഷേ ഉപയോഗപ്രദവും സഹായകരവുമായ ധാരാളം പരിശീലനങ്ങൾ ശേഖരിച്ചു.

   ഒരു നിസ്സാര ഉദാഹരണം: ജോടി പ്രോഗ്രാമിംഗിലൂടെയുള്ള സഹകരണം. അത് കണ്ടുപിടിക്കാൻ വളരെയധികം സഹായിക്കുന്നു. എന്തെങ്കിലും മനസ്സിലാക്കാൻ ശ്രമിക്കുന്ന ഒരു അയൽക്കാരൻ നിങ്ങളുടെ സമീപത്തുണ്ടെങ്കിൽ, ഒരുമിച്ച് നിങ്ങൾ നന്നായി മനസ്സിലാക്കും.

   റീഫാക്‌ടറിംഗ് എങ്ങനെയാണെന്ന് മനസ്സിലാക്കുന്നത് അത്തരമൊരു സാഹചര്യത്തിൽ പോലും അത് നടപ്പിലാക്കാൻ സഹായിക്കുന്നു. അതായത്, നിങ്ങൾക്ക് എല്ലാം ഒറ്റയടിക്ക് മാറ്റാൻ കഴിയില്ല, പക്ഷേ നാമകരണം മാറ്റുക, തുടർന്ന് സ്ഥാനം മാറ്റുക, തുടർന്ന് നിങ്ങൾക്ക് കുറച്ച് ഭാഗം ഹൈലൈറ്റ് ചെയ്യാം, ഓ, പക്ഷേ ഇവിടെ മതിയായ അഭിപ്രായങ്ങൾ ഇല്ല.

തീരുമാനം

എന്റെ ന്യായവാദം അശുഭാപ്തിവിശ്വാസമാണെന്ന് തോന്നുമെങ്കിലും, ഞാൻ ഭാവിയിലേക്ക് പ്രതീക്ഷയോടെ നോക്കുന്നു, എല്ലാം ഞങ്ങൾക്കായി (നിങ്ങൾക്കും) പ്രവർത്തിക്കുമെന്ന് ആത്മാർത്ഥമായി പ്രതീക്ഷിക്കുന്നു.

ലേഖനത്തിന്റെ രണ്ടാം ഭാഗം അടുത്തതായി തയ്യാറാക്കുകയാണ്. അതിൽ, ഞങ്ങളുടെ പഠന പ്രക്രിയ മെച്ചപ്പെടുത്തുന്നതിനും ഇൻഫ്രാസ്ട്രക്ചറുമായി പ്രവർത്തിക്കുന്നതിനും ഞങ്ങൾ എങ്ങനെ ചടുലമായ വികസന രീതികൾ ഉപയോഗിക്കാൻ ശ്രമിച്ചുവെന്നതിനെക്കുറിച്ച് ഞാൻ സംസാരിക്കും.

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