ഡെവലപ്പർമാർക്കുള്ള മികച്ച DevOps സമ്പ്രദായങ്ങൾ. ആന്റൺ ബോയ്‌കോ (2017)

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

ഞാൻ എന്നെത്തന്നെ പരിചയപ്പെടുത്തട്ടെ, എന്നെ അറിയാത്ത ആളുകൾ മുറിയിലുണ്ടെന്ന് ഞാൻ പൂർണ്ണമായും സമ്മതിക്കുന്നു. എന്റെ പേര് ആന്റൺ ബോയ്‌കോ, ഞാൻ ഒരു മൈക്രോസോഫ്റ്റ് അസൂർ എംവിപിയാണ്. എന്താണ് MVP? ഇതാണ് മോഡൽ-വ്യൂ-പ്രസന്റർ. മോഡൽ-വ്യൂ-അവതാരകൻ കൃത്യമായി ഞാനാണ്.

കൂടാതെ, ഞാൻ നിലവിൽ സിക്ലമിൽ സൊല്യൂഷൻ ആർക്കിടെക്റ്റ് പദവി വഹിക്കുന്നു. അടുത്തിടെ ഞാൻ അത്തരമൊരു മനോഹരമായ ഡൊമെയ്‌ൻ വാങ്ങി, ഞാൻ എന്റെ ഇമെയിൽ അപ്‌ഡേറ്റ് ചെയ്‌തു, അത് ഞാൻ സാധാരണയായി അവതരണങ്ങളിൽ കാണിക്കുന്നു. നിങ്ങൾക്ക് ഇവിടെ എനിക്ക് എഴുതാം: me [dog] byokoant.pro. നിങ്ങൾക്ക് ചോദ്യങ്ങൾ സഹിതം എനിക്ക് ഇമെയിൽ ചെയ്യാവുന്നതാണ്. ഞാൻ സാധാരണയായി അവർക്ക് ഉത്തരം നൽകുന്നു. രാഷ്ട്രീയവും മതവും എന്ന രണ്ട് വിഷയങ്ങളുമായി ബന്ധപ്പെട്ട ചോദ്യങ്ങൾ ഇമെയിൽ വഴി സ്വീകരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നില്ല എന്നതാണ് ഒരേയൊരു കാര്യം. മറ്റെല്ലാ കാര്യങ്ങളെക്കുറിച്ചും നിങ്ങൾക്ക് ഇമെയിൽ വഴി എനിക്ക് എഴുതാം. കുറച്ച് സമയം കടന്നുപോകും, ​​ഞാൻ ഉത്തരം നൽകും.

എന്നെക്കുറിച്ച് കുറച്ച് വാക്കുകൾ:

• ഞാൻ ഇപ്പോൾ 10 വർഷമായി ഈ ഫീൽഡിൽ ഉണ്ട്.
• ഞാൻ മൈക്രോസോഫ്റ്റിൽ ജോലി ചെയ്തു.
• 2014 ൽ ഞങ്ങൾ എവിടെയോ സ്ഥാപിച്ച ഉക്രേനിയൻ അസൂർ കമ്മ്യൂണിറ്റിയുടെ സ്ഥാപക പിതാവാണ് ഞാൻ. ഞങ്ങൾക്ക് ഇപ്പോഴും അത് ഉണ്ട്, അത് വികസിപ്പിക്കുന്നു.
• ഞങ്ങൾ ഉക്രെയ്നിൽ ആതിഥേയത്വം വഹിക്കുന്ന അസൂർ കോൺഫറൻസിന്റെ സ്ഥാപകന്റെ പിതാവ് കൂടിയാണ് ഞാൻ.
• കൈവിലെ ഗ്ലോബൽ അസൂർ ബൂട്ട്‌ക്യാമ്പ് സംഘടിപ്പിക്കാനും ഞാൻ സഹായിക്കുന്നു.
• ഞാൻ പറഞ്ഞതുപോലെ, ഞാൻ ഒരു Microsoft Azure MVP ആണ്.
• ഞാൻ പലപ്പോഴും കോൺഫറൻസുകളിൽ സംസാരിക്കാറുണ്ട്. കോൺഫറൻസുകളിൽ സംസാരിക്കുന്നത് എനിക്ക് ശരിക്കും ഇഷ്ടമാണ്. കഴിഞ്ഞ ഒരു വർഷത്തിനിടെ ഏകദേശം 40 തവണ എനിക്ക് അഭിനയിക്കാൻ കഴിഞ്ഞു. നിങ്ങൾ ഉക്രെയ്ൻ, ബെലാറസ്, പോളണ്ട്, ബൾഗേറിയ, സ്വീഡൻ, ഡെൻമാർക്ക്, നെതർലാൻഡ്സ്, സ്പെയിൻ എന്നിവയിലൂടെ കടന്നുപോകുകയോ യൂറോപ്പിലെ മറ്റൊരു രാജ്യം നൽകുകയോ എടുക്കുകയോ ചെയ്യുകയാണെങ്കിൽ, നിങ്ങൾ ഒരു ക്ലൗഡ് തീം ഉള്ള ഒരു കോൺഫറൻസിൽ പോകുമ്പോൾ അത് തികച്ചും സാദ്ധ്യമാണ്. സ്പീക്കറുകളുടെ പട്ടികയിൽ നിങ്ങൾ എന്നെ കണ്ടേക്കാം.
• ഞാനും ഒരു സ്റ്റാർ ട്രെക്ക് ആരാധകനാണ്.

അജണ്ടയെക്കുറിച്ച് കുറച്ച് സംസാരിക്കാം. ഞങ്ങളുടെ അജണ്ട വളരെ ലളിതമാണ്:

• DevOps എന്താണെന്നതിനെക്കുറിച്ച് ഞങ്ങൾ സംസാരിക്കും. എന്തുകൊണ്ടാണ് ഇത് പ്രധാനമായതെന്ന് നമുക്ക് സംസാരിക്കാം. മുമ്പ്, DevOps എന്നത് നിങ്ങളുടെ ബയോഡാറ്റയിൽ നിങ്ങൾ എഴുതിയ ഒരു കീവേഡായിരുന്നു, ഉടനെ ശമ്പളമായി +$500 ലഭിച്ചു. നിങ്ങളുടെ ശമ്പളത്തിലേക്ക് +500 ഡോളർ ലഭിക്കുന്നതിന്, ഉദാഹരണത്തിന്, നിങ്ങളുടെ ബയോഡാറ്റയിൽ ബ്ലോക്ക്ചെയിൻ എഴുതേണ്ടതുണ്ട്.
• തുടർന്ന്, ഇത് എന്താണെന്ന് കുറച്ച് മനസ്സിലാക്കുമ്പോൾ, DevOps പ്രാക്ടീസുകൾ എന്താണെന്ന് ഞങ്ങൾ സംസാരിക്കും. എന്നാൽ പൊതുവെ DevOps-ന്റെ പശ്ചാത്തലത്തിൽ അത്രയല്ല, ഡെവലപ്പർമാർക്ക് താൽപ്പര്യമുള്ള DevOps സമ്പ്രദായങ്ങളെക്കുറിച്ച്. എന്തുകൊണ്ടാണ് അവ നിങ്ങൾക്ക് താൽപ്പര്യമുള്ളതെന്ന് ഞാൻ നിങ്ങളോട് പറയും. എന്തുകൊണ്ടാണ് നിങ്ങൾ ഇത് ചെയ്യേണ്ടതെന്നും വേദന കുറയ്ക്കാൻ ഇത് നിങ്ങളെ എങ്ങനെ സഹായിക്കുമെന്നും ഞാൻ നിങ്ങളോട് പറയും.

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

ഒരുപക്ഷേ, DevOps, ഓപ്പറേഷൻസ് ഡിപ്പാർട്ട്‌മെന്റുകളിൽ നിങ്ങൾക്ക് ഇത് വ്യക്തമായി അനുഭവിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് Dev, QA വകുപ്പുകളുമായി ഒരു സാമ്യം വരയ്ക്കാം. സോഫ്‌റ്റ്‌വെയർ വികസിപ്പിക്കുന്ന ആളുകളുണ്ട്, ഡെവലപ്പർമാരുടെ കാഴ്ചപ്പാടിൽ മോശമായ QA ആളുകളുണ്ട്. ഉദാഹരണത്തിന്, ഞാൻ എന്റെ അത്ഭുതകരമായ കോഡ് ശേഖരണത്തിലേക്ക് സമർപ്പിക്കുന്നു, അവിടെ ഇരിക്കുന്ന ചില അഴിമതിക്കാരൻ ഈ കോഡ് എനിക്ക് തിരികെ നൽകുകയും നിങ്ങളുടെ കോഡ് മോശമാണെന്ന് പറയുകയും ചെയ്യുന്നു.

ആളുകൾ പരസ്പരം ആശയവിനിമയം നടത്താത്തതിനാലാണ് ഇതെല്ലാം സംഭവിക്കുന്നത്. അവർ ചില പൊതികൾ, ചില പ്രയോഗങ്ങൾ, തെറ്റിദ്ധാരണയുടെ ചില മതിലുകളിലൂടെ പരസ്പരം എറിയുകയും അവ ഉപയോഗിച്ച് എന്തെങ്കിലും ചെയ്യാൻ ശ്രമിക്കുകയും ചെയ്യുന്നു.

കൃത്യമായി ഈ മതിലാണ് DevOps സംസ്കാരം നശിപ്പിക്കാൻ രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്, അതായത്. പരസ്പരം ആശയവിനിമയം നടത്താൻ ആളുകളെ നിർബന്ധിക്കുകയും പ്രോജക്റ്റിലെ വ്യത്യസ്ത ആളുകൾ എന്താണ് ചെയ്യുന്നതെന്നും അവരുടെ ജോലി പ്രധാനമായിരിക്കുന്നത് എന്തുകൊണ്ടാണെന്നും മനസ്സിലാക്കുക.

ഞങ്ങൾ DevOps-നെ കുറിച്ച് സംസാരിക്കുമ്പോൾ, പ്രോജക്റ്റിന് തുടർച്ചയായ സംയോജനം ഉള്ളപ്പോഴാണ് DevOps എന്ന് ആരെങ്കിലും നിങ്ങളോട് പറയും; "ഇൻഫ്രാസ്ട്രക്ചർ കോഡ്" പ്രാക്ടീസ് നടപ്പിലാക്കുകയാണെങ്കിൽ, DevOps ആണ് എന്ന് ആരെങ്കിലും പറയും; DevOps-ലേക്കുള്ള ആദ്യപടി ഫീച്ചർ ബ്രാഞ്ചിംഗ്, ഫീച്ചർ ഫ്ലാഗുകൾ ആണെന്ന് ആരെങ്കിലും പറയും.

അടിസ്ഥാനപരമായി, ഇതെല്ലാം അതിന്റേതായ രീതിയിൽ ശരിയാണ്. എന്നാൽ ഇവയൊക്കെയാണ് നമുക്കുള്ള ആത്യന്തിക സമ്പ്രദായങ്ങൾ. ഈ രീതികളിലേക്ക് നീങ്ങുന്നതിന് മുമ്പ്, ഈ സ്ലൈഡ് നോക്കാൻ ഞാൻ നിർദ്ദേശിക്കുന്നു, ഇത് നിങ്ങളുടെ പ്രോജക്റ്റിൽ, നിങ്ങളുടെ കമ്പനിയിൽ Dev-Ops രീതിശാസ്ത്രം നടപ്പിലാക്കുന്നതിന്റെ 3 ഘട്ടങ്ങൾ കാണിക്കുന്നു.

ഈ സ്ലൈഡിന് രണ്ടാമത്തെ അനൗദ്യോഗിക നാമവുമുണ്ട്. DevOps-ന്റെ 3 മസ്കറ്റിയേഴ്സ് എന്താണെന്ന് കണ്ടെത്താൻ നിങ്ങൾക്ക് ഓൺലൈനിൽ തിരയാം. ഈ ലേഖനം നിങ്ങൾ കണ്ടെത്തുന്നത് സാധ്യമാണ്. എന്തുകൊണ്ട് 3 മസ്കറ്റിയേഴ്സ്? അത് താഴെ പറയുന്നു: ആളുകൾ, പ്രക്രിയകൾ, ഉൽപ്പന്നങ്ങൾ, അതായത്. PPP - Porthos, Porthos, Porthos. DevOps-ന്റെ 3 മസ്കറ്റിയർമാർ ഇതാ. എന്തുകൊണ്ടാണ് ഇത് പ്രധാനമായതെന്നും അത് എന്താണ് അർത്ഥമാക്കുന്നതെന്നും ഈ ലേഖനം കൂടുതൽ വിശദമായി വിവരിക്കുന്നു.

നിങ്ങൾ ഒരു DevOps സംസ്കാരം നടപ്പിലാക്കാൻ തുടങ്ങുമ്പോൾ, അത് ഇനിപ്പറയുന്ന ക്രമത്തിൽ നടപ്പിലാക്കുന്നത് വളരെ പ്രധാനമാണ്.

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

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

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

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

QA-കൾക്ക് ഏറ്റവും കൂടുതൽ എന്താണ് വേണ്ടത്? അവർ ഹാളിൽ ഉണ്ടോ എന്നറിയില്ല. എനിക്ക് ഒരു QA വേണമെന്ന് പറയാൻ എനിക്ക് ബുദ്ധിമുട്ടാണ്, കാരണം ഞാൻ ഒരിക്കലും ഒരാളായിരുന്നിട്ടില്ല. ആൺകുട്ടികളോട് വിരോധമില്ല, ഞാൻ ഒരിക്കലും ചെയ്യില്ലെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു എന്ന് പറയും. എന്നാൽ അവരുടെ ജോലി അർത്ഥശൂന്യവും ഉപയോഗശൂന്യവുമാണെന്ന് ഞാൻ കരുതുന്നത് കൊണ്ടല്ല, മറിച്ച് ഈ ജോലി കാര്യക്ഷമമായി ചെയ്യാൻ കഴിയുന്ന ഒരു വ്യക്തിയായി ഞാൻ എന്നെ കണക്കാക്കാത്തതിനാൽ ഞാൻ അത് ചെയ്യാൻ പോലും ശ്രമിക്കില്ല. എന്നാൽ ഞാൻ മനസ്സിലാക്കിയതിൽ നിന്ന്, QA ഏറ്റവും ഇഷ്ടപ്പെടാത്തത് രാവിലെ പ്രവർത്തിക്കാൻ പോകുന്നു, നിരന്തരം ചില റിഗ്രഷൻ ടെസ്റ്റുകൾ നടത്തുന്നു, 3 സ്പ്രിന്റുകൾക്ക് മുമ്പ് അവർ ഡെവലപ്പർമാർക്ക് റിപ്പോർട്ട് ചെയ്ത അതേ ബഗുകളിൽ ചവിട്ടി: “നിങ്ങൾ എപ്പോൾ ചെയ്യും , Monsieur D 'Artagnan, ഈ ബഗ് പരിഹരിക്കുക.' മോൺസിയൂർ ഡി ആർടാഗ്നൻ അവനോട് ഉത്തരം നൽകുന്നു: "അതെ, അതെ, അതെ, ഞാൻ ഇതിനകം അത് പരിഹരിച്ചു." ഞാൻ ഒരു ബഗ് പരിഹരിച്ച് വഴിയിൽ 5 ഉണ്ടാക്കിയത് എങ്ങനെ സംഭവിക്കുന്നു.

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

ഒരേ പ്രശ്നങ്ങൾ പരിഹരിക്കാനാണ് അവർ ലക്ഷ്യമിടുന്നതെന്ന് നിങ്ങൾ ആളുകളോട് വിശദീകരിക്കുമ്പോൾ, നിങ്ങൾക്ക് പ്രക്രിയകൾ ഔപചാരികമാക്കുന്നതിലേക്ക് പോകാം. ഇത് വളരെ പ്രധാനപെട്ടതാണ്. എന്തുകൊണ്ട്? കാരണം, "ഔപചാരികവൽക്കരണം" എന്ന് ഞങ്ങൾ പറയുമ്പോൾ, ഒരു തൂവാലയിൽ എവിടെയെങ്കിലും നിങ്ങളുടെ പ്രക്രിയകൾ എങ്ങനെ സംഭവിക്കുന്നുവെന്ന് വിവരിക്കേണ്ടത് പ്രധാനമാണ്. ഉദാഹരണത്തിന്, നിങ്ങൾ ഒരു ക്യുഎ എൻവയോൺമെന്റിലേക്കോ പ്രൊഡക്ഷൻ എൻവയോൺമെന്റിലേക്കോ വിന്യസിക്കുകയാണെങ്കിൽ, ഇത് എല്ലായ്പ്പോഴും ഈ ക്രമത്തിലാണ് സംഭവിക്കുന്നതെന്ന് നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്; ഈ ഘട്ടങ്ങളിൽ ഞങ്ങൾ പ്രവർത്തിപ്പിക്കുന്നു, ഉദാഹരണത്തിന്, ഓട്ടോമാറ്റിക് യൂണിറ്റ് ടെസ്റ്റുകളും യുഐ ടെസ്റ്റുകളും. വിന്യാസത്തിന് ശേഷം, വിന്യാസം നന്നായി നടന്നോ മോശമായോ എന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു. എന്നാൽ നിങ്ങൾ പ്രൊഡക്ഷനിലേക്ക് വിന്യസിക്കുമ്പോൾ വീണ്ടും വീണ്ടും ആവർത്തിക്കേണ്ട പ്രവർത്തനങ്ങളുടെ വ്യക്തമായ ലിസ്റ്റ് നിങ്ങൾക്ക് ഇതിനകം തന്നെയുണ്ട്.

നിങ്ങളുടെ പ്രക്രിയകൾ ഔപചാരികമാക്കുമ്പോൾ മാത്രമേ, ഈ പ്രക്രിയകൾ ഓട്ടോമേറ്റ് ചെയ്യാൻ നിങ്ങളെ സഹായിക്കുന്ന ഉൽപ്പന്നങ്ങൾ തിരഞ്ഞെടുക്കാൻ തുടങ്ങൂ.

നിർഭാഗ്യവശാൽ, ഇത് പലപ്പോഴും വിപരീതമായി സംഭവിക്കുന്നത് ഞാൻ കാണുന്നു. ആരെങ്കിലും "DevOps" എന്ന വാക്ക് കേട്ടാലുടൻ, അവർ ഉടൻ തന്നെ Jenkins ഇൻസ്റ്റാൾ ചെയ്യാൻ നിർദ്ദേശിക്കുന്നു, കാരണം അവർ Jenkins ഇൻസ്റ്റാൾ ചെയ്താലുടൻ അവർക്ക് DevOps ഉണ്ടായിരിക്കുമെന്ന് അവർ വിശ്വസിക്കുന്നു. അവർ Jenkins ഇൻസ്റ്റാൾ ചെയ്തു, Jenkins വെബ്സൈറ്റിലെ "How to" ലേഖനങ്ങൾ വായിച്ചു, ഈ How to ലേഖനങ്ങളിൽ പ്രക്രിയകൾ സ്റ്റഫ് ചെയ്യാൻ ശ്രമിച്ചു, തുടർന്ന് ആളുകളിലേക്ക് വരികയും ആളുകളെ വളച്ചൊടിക്കുകയും ചെയ്തു, നിങ്ങൾ ഇത് ഇങ്ങനെ ചെയ്യണമെന്ന് പുസ്തകം പറയുന്നു, അതിനാൽ ഞങ്ങൾ ഇത് ഈ രീതിയിൽ ചെയ്യുന്നു.

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

നമുക്ക് പൊതുവായി DevOps സമ്പ്രദായങ്ങളെക്കുറിച്ച് സംസാരിക്കാം. അവർ എന്താണ്? എന്താണ് വ്യത്യാസം? അവ എങ്ങനെ പരീക്ഷിക്കാം? എന്തുകൊണ്ടാണ് അവ പ്രധാനമായിരിക്കുന്നത്?

നിങ്ങൾ കേട്ടിരിക്കാവുന്ന ആദ്യത്തെ പരിശീലനത്തെ തുടർച്ചയായ സംയോജനം എന്ന് വിളിക്കുന്നു. ഒരുപക്ഷേ പ്രോജക്റ്റിലുള്ള ആർക്കെങ്കിലും തുടർച്ചയായ സംയോജനം (CI) ഉണ്ടായിരിക്കാം.

ഏറ്റവും വലിയ പ്രശ്നം, മിക്കപ്പോഴും ഞാൻ ഒരു വ്യക്തിയോട് ചോദിക്കുമ്പോൾ: "നിങ്ങൾക്ക് പ്രോജക്റ്റിൽ CI ഉണ്ടോ?" അവൻ പറയുന്നു: "അതെ," പിന്നെ അവൻ എന്താണ് ചെയ്യുന്നതെന്ന് ഞാൻ ചോദിക്കുമ്പോൾ, മുഴുവൻ ഓട്ടോമേഷൻ പ്രക്രിയയും അദ്ദേഹം എന്നോട് വിവരിക്കുന്നു. ഇത് പൂർണ്ണമായും ശരിയല്ല.

വാസ്തവത്തിൽ, വ്യത്യസ്ത ആളുകൾ എഴുതുന്ന കോഡ് ഏതെങ്കിലും തരത്തിലുള്ള സിംഗിൾ കോഡ് ബേസിലേക്ക് സംയോജിപ്പിക്കാൻ മാത്രമാണ് CI യുടെ പരിശീലനം ലക്ഷ്യമിടുന്നത്. അത്രയേയുള്ളൂ.

CI-യ്‌ക്കൊപ്പം, തുടർച്ചയായ വിന്യാസം, റിലീസ് മാനേജ്‌മെന്റ് പോലെയുള്ള മറ്റ് സമ്പ്രദായങ്ങൾ സാധാരണയായി ഉണ്ട്, എന്നാൽ ഞങ്ങൾ അതിനെക്കുറിച്ച് പിന്നീട് സംസാരിക്കും.

വ്യത്യസ്ത ആളുകൾ കോഡ് എഴുതുന്നുവെന്നും ഈ കോഡ് തുടർച്ചയായി ഒരൊറ്റ കോഡ് ബേസിലേക്ക് സംയോജിപ്പിക്കണമെന്നും CI തന്നെ പറയുന്നു.

ഇത് നമുക്ക് എന്താണ് നൽകുന്നത്, എന്തുകൊണ്ട് ഇത് പ്രധാനമാണ്? ഞങ്ങൾക്ക് DotNet ഉണ്ടെങ്കിൽ, അത് നല്ലതാണ്, ഇത് ഒരു കംപൈൽ ചെയ്ത ഭാഷയാണ്, നമുക്ക് ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ കംപൈൽ ചെയ്യാം. ഇത് കംപൈൽ ചെയ്യുകയാണെങ്കിൽ, ഇത് ഇതിനകം ഒരു നല്ല അടയാളമാണ്. ഇത് ഇതുവരെ ഒന്നും അർത്ഥമാക്കുന്നില്ല, പക്ഷേ നമുക്ക് കുറഞ്ഞത് സമാഹരിക്കാൻ കഴിയുന്ന ആദ്യത്തെ നല്ല സൂചനയാണിത്.

അപ്പോൾ നമുക്ക് ചില ടെസ്റ്റുകൾ നടത്താം, അതും ഒരു പ്രത്യേക പരിശീലനമാണ്. ടെസ്റ്റുകൾ എല്ലാം പച്ചയാണ് - ഇത് രണ്ടാമത്തെ നല്ല അടയാളമാണ്. എന്നാൽ വീണ്ടും, ഇത് ഒന്നും അർത്ഥമാക്കുന്നില്ല.

എന്നാൽ നിങ്ങൾ എന്തിനാണ് ഇത് ചെയ്യുന്നത്? ഇന്ന് ഞാൻ സംസാരിക്കുന്ന എല്ലാ രീതികളും ഏകദേശം ഒരേ മൂല്യം വഹിക്കുന്നു, അതായത് ഏകദേശം ഒരേ ആനുകൂല്യങ്ങൾ, ഏകദേശം ഒരേ രീതിയിലാണ് അളക്കുന്നത്.

ആദ്യം, ഡെലിവറി വേഗത്തിലാക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു. ഡെലിവറി വേഗത്തിലാക്കാൻ ഇത് നിങ്ങളെ എങ്ങനെ അനുവദിക്കുന്നു? ഞങ്ങളുടെ കോഡ് ബേസിൽ ചില പുതിയ മാറ്റങ്ങൾ വരുത്തുമ്പോൾ, ഈ കോഡ് ഉപയോഗിച്ച് എന്തെങ്കിലും ചെയ്യാൻ നമുക്ക് ഉടൻ ശ്രമിക്കാം. വ്യാഴാഴ്ച വരുന്നതുവരെ ഞങ്ങൾ കാത്തിരിക്കില്ല, കാരണം വ്യാഴാഴ്ച ഞങ്ങൾ അത് QA പരിസ്ഥിതിയിലേക്ക് വിടുന്നു, ഞങ്ങൾ അത് ഇവിടെയും ഇവിടെയും ചെയ്യുന്നു.

എന്റെ ജീവിതത്തിൽ നിന്നുള്ള ഒരു സങ്കടകരമായ കഥ ഞാൻ നിങ്ങളോട് പറയും. വളരെക്കാലം മുമ്പ്, ഞാൻ ചെറുപ്പവും സുന്ദരനുമായിരുന്നു. ഇപ്പോൾ ഞാൻ ചെറുപ്പവും സുന്ദരിയും മിടുക്കനും എളിമയുള്ളവനുമാണ്. കുറച്ചു കാലം മുമ്പ് ഞാൻ ഒരു പ്രൊജക്റ്റിൽ ആയിരുന്നു. ഏകദേശം 30 ഡെവലപ്പർമാരുടെ ഒരു വലിയ ടീം ഞങ്ങൾക്കുണ്ടായിരുന്നു. ഞങ്ങൾക്ക് ഒരു വലിയ, വലിയ എന്റർപ്രൈസ് പ്രോജക്റ്റ് ഉണ്ടായിരുന്നു, അത് ഏകദേശം 10 വർഷത്തേക്ക് വികസിപ്പിച്ചെടുത്തു. കൂടാതെ ഞങ്ങൾക്ക് വ്യത്യസ്ത ശാഖകളുണ്ടായിരുന്നു. റിപ്പോസിറ്ററിയിൽ ഞങ്ങൾക്ക് ഒരു ശാഖ ഉണ്ടായിരുന്നു, അതിൽ ഡെവലപ്പർമാർ നടന്നു. നിർമ്മാണത്തിലിരിക്കുന്ന കോഡിന്റെ പതിപ്പ് പ്രദർശിപ്പിക്കുന്ന ഒരു ശാഖ ഉണ്ടായിരുന്നു.

ഡെവലപ്പർമാർക്ക് ലഭ്യമായിരുന്ന ശാഖയേക്കാൾ 3 മാസം പിന്നിലായിരുന്നു പ്രൊഡക്ഷൻ ബ്രാഞ്ച്. എന്താണിതിനർത്ഥം? ഇതിനർത്ഥം, ഡെവലപ്പർമാരുടെ തെറ്റ് കാരണം എനിക്ക് എവിടെയെങ്കിലും ഒരു ബഗ് ഉണ്ടായാലുടൻ, അവർ അത് അനുവദിച്ചതിനാലും, QA യുടെ തെറ്റ് കാരണം, അവർ അത് നോക്കിയതിനാലും, ഇതിനർത്ഥം എനിക്ക് ഒരു ലഭിക്കുകയാണെങ്കിൽ പ്രൊഡക്ഷനിനായുള്ള hotfix-നുള്ള ടാസ്‌ക്, തുടർന്ന് 3 മാസം മുമ്പ് എന്റെ കോഡ് മാറ്റങ്ങൾ പിൻവലിക്കണം. എനിക്ക് 3 മാസം മുമ്പ് ഉണ്ടായിരുന്നത് ഓർമ്മിക്കുകയും അത് അവിടെ പരിഹരിക്കാൻ ശ്രമിക്കുകയും വേണം.

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

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

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

ഈ പരിശീലനത്തിന്റെ വിജയവും പരാജയവും നമുക്ക് എങ്ങനെ അളക്കാനാകും? CI പ്രോജക്റ്റിൽ ഞങ്ങൾ നടപ്പിലാക്കിയ കാര്യങ്ങൾ നിങ്ങൾ ബിഗ് ബോസിനോട് റിപ്പോർട്ട് ചെയ്താൽ, അവൻ ബ്ലാ ബ്ലാ ബ്ലാ എന്ന് കേൾക്കുന്നു. ഞങ്ങൾ അത് നടപ്പിലാക്കി, ശരി, പക്ഷേ എന്തുകൊണ്ട്, അത് ഞങ്ങൾക്ക് എന്താണ് കൊണ്ടുവന്നത്, ഞങ്ങൾ അത് എങ്ങനെ അളക്കും, എത്ര കൃത്യമായി അല്ലെങ്കിൽ തെറ്റായി ഞങ്ങൾ അത് നടപ്പിലാക്കുന്നു?

ആദ്യത്തേത്, CI- യ്ക്ക് നന്ദി, ഞങ്ങൾക്ക് കൂടുതൽ കൂടുതൽ തവണ വിന്യസിക്കാൻ കഴിയും, ഞങ്ങളുടെ കോഡ് കൂടുതൽ സുസ്ഥിരമാകാൻ സാധ്യതയുണ്ട്. അതുപോലെ, ഒരു പിശക് കണ്ടെത്താനുള്ള ഞങ്ങളുടെ സമയം കുറയുകയും ഈ പിശക് തിരുത്താനുള്ള സമയം കൃത്യമായി കുറയുകയും ചെയ്യുന്നു, കാരണം സിസ്റ്റത്തിൽ നിന്ന് ഞങ്ങൾക്ക് ഇവിടെ നിന്നും ഇപ്പോളും ഉത്തരം ലഭിക്കുന്നു, ഞങ്ങളുടെ കോഡിന് എന്താണ് തെറ്റ്.

ഞങ്ങൾക്കുള്ള മറ്റൊരു പ്രാക്ടീസ് ഓട്ടോമേഷൻ ടെസ്റ്റിംഗ് പ്രാക്ടീസ് ആണ്, ഇത് മിക്കപ്പോഴും CI പ്രാക്ടീസിനൊപ്പം വരുന്നു. അവർ കൈകോർത്ത് പോകുന്നു.

ഇവിടെ എന്താണ് മനസ്സിലാക്കേണ്ടത്? ഞങ്ങളുടെ പരിശോധനകൾ വ്യത്യസ്തമാണെന്ന് മനസ്സിലാക്കേണ്ടത് പ്രധാനമാണ്. ഓരോ ഓട്ടോമേറ്റഡ് ടെസ്റ്റും അതിന്റേതായ പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ ലക്ഷ്യമിടുന്നു. ഉദാഹരണത്തിന്, ഒരു മൊഡ്യൂൾ പ്രത്യേകം പരിശോധിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്ന യൂണിറ്റ് ടെസ്റ്റുകൾ ഉണ്ട്, അതായത്. ഒരു ശൂന്യതയിൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കും? ഇത് നല്ലതാണ്.

വ്യത്യസ്‌ത മൊഡ്യൂളുകൾ എങ്ങനെ പരസ്പരം സംയോജിപ്പിക്കുന്നുവെന്ന് മനസ്സിലാക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്ന ഇന്റഗ്രേഷൻ ടെസ്റ്റുകളും ഞങ്ങൾക്കുണ്ട്. അതും നല്ലതാണ്.

ഉപഭോക്താവ് നിശ്ചയിച്ചിട്ടുള്ള ചില ആവശ്യകതകൾ UI-യുമായുള്ള പ്രവർത്തനം എത്രത്തോളം നിറവേറ്റുന്നുവെന്ന് പരിശോധിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്ന UI ഓട്ടോമേഷൻ ടെസ്റ്റുകൾ ഞങ്ങൾക്ക് ഉണ്ടായേക്കാം.

നിങ്ങൾ നടത്തുന്ന നിർദ്ദിഷ്ട ടെസ്റ്റുകൾ നിങ്ങൾ എത്ര തവണ പ്രവർത്തിപ്പിക്കുന്നുവെന്നതിനെ ബാധിക്കും. യൂണിറ്റ് ടെസ്റ്റുകൾ സാധാരണയായി ചെറുതും ചെറുതുമാണ്. അവ പതിവായി വിക്ഷേപിക്കാം.

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

ഞാൻ പ്രവർത്തിച്ചുകൊണ്ടിരിക്കുന്ന മറ്റൊരു പ്രോജക്ട് എനിക്കുണ്ട്. ഈ പ്രോജക്റ്റിൽ ഞങ്ങൾക്ക് രണ്ടാഴ്ചത്തെ സ്പ്രിന്റുകൾ ഉണ്ടായിരുന്നു. പ്രോജക്റ്റ് വലുതും സാമ്പത്തിക മേഖലയ്ക്ക് പ്രധാനമാണ്, ഒരു തെറ്റ് വരുത്താൻ കഴിഞ്ഞില്ല. രണ്ടാഴ്ചത്തെ സ്പ്രിന്റിന് ശേഷം, വികസന ചക്രം ഒരു ടെസ്റ്റിംഗ് പ്രക്രിയയ്ക്ക് ശേഷം, അത് മറ്റൊരു 4 ആഴ്ച എടുത്തു. ദുരന്തത്തിന്റെ തോത് സങ്കൽപ്പിക്കാൻ ശ്രമിക്കുക. ഞങ്ങൾ രണ്ടാഴ്ചത്തേക്ക് കോഡ് എഴുതുന്നു, തുടർന്ന് ഞങ്ങൾ അത് ala CodeFreeze ചെയ്യുന്നു, അത് ആപ്ലിക്കേഷന്റെ ഒരു പുതിയ പതിപ്പിലേക്ക് പാക്കേജുചെയ്യുന്നു, കൂടാതെ അത് ടെസ്റ്റർമാർക്ക് കൈമാറും. ടെസ്റ്റർമാർ ഇത് മറ്റൊരു 4 ആഴ്ചത്തേക്ക് പരിശോധിക്കുന്നു, അതായത്. അവർ അത് പരീക്ഷിക്കുമ്പോൾ, അവർക്കായി രണ്ട് പതിപ്പുകൾ കൂടി തയ്യാറാക്കാൻ ഞങ്ങൾക്ക് സമയമുണ്ട്. ഇത് ശരിക്കും സങ്കടകരമായ കേസാണ്.

നിങ്ങൾ കൂടുതൽ ഉൽപ്പാദനക്ഷമതയുള്ളവരാകാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ് സമ്പ്രദായങ്ങൾ നടപ്പിലാക്കുന്നതിൽ അർത്ഥമുണ്ടെന്ന് ഞങ്ങൾ അവരോട് പറഞ്ഞു, കാരണം ഇതാണ് ഇപ്പോൾ നിങ്ങളെ ഇവിടെ വേദനിപ്പിക്കുന്നത്.

തുടർച്ചയായ വിന്യാസം പരിശീലിക്കുക. കൊള്ളാം, നിങ്ങൾ പണിതു കഴിഞ്ഞു. ഇത് ഇതിനകം നല്ലതാണ്. നിങ്ങളുടെ കോഡ് സമാഹരിച്ചു. ഇപ്പോൾ ഈ ബിൽഡ് കുറച്ച് പരിസ്ഥിതിയിൽ വിന്യസിക്കുന്നത് നന്നായിരിക്കും. ഡെവലപ്പർമാർക്കുള്ള ഒരു പരിതസ്ഥിതിയിൽ പറയാം.

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

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

കൂടാതെ, നിങ്ങൾ പരസ്പരം കോഡ് സംയോജിപ്പിക്കുമ്പോൾ, അതായത്. കമാൻഡിന് ഇടയിൽ, യുഐയിൽ ഇത് എങ്ങനെ കാണപ്പെടുന്നുവെന്ന് കാണാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

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

ഞങ്ങളുടെ അടുത്ത പ്രാക്ടീസ് യാന്ത്രിക പുനഃസ്ഥാപിക്കാനുള്ള പരിശീലനമാണ്, അതായത് ആപ്ലിക്കേഷന്റെ മുൻ പതിപ്പിലേക്ക് മടങ്ങുക.

ഡെവലപ്പർമാർക്ക് ഇത് പ്രധാനമായിരിക്കുന്നത് എന്തുകൊണ്ട്? കമ്പ്യൂട്ടറുകൾ വലുതും പ്രോഗ്രാമുകൾ ചെറുതും ആയിരുന്ന വിദൂര, വിദൂര 90 കൾ ഓർക്കുന്നവർ ഇപ്പോഴും ഉണ്ട്. വെബ് ഡെവലപ്‌മെന്റിനുള്ള ഏക മാർഗം പിഎച്ച്പി വഴിയായിരുന്നു. PHP ഒരു മോശം ഭാഷയാണെന്നല്ല, അങ്ങനെയാണെങ്കിലും.

എന്നാൽ പ്രശ്നം മറ്റൊന്നായിരുന്നു. ഞങ്ങളുടെ php സൈറ്റിന്റെ ഒരു പുതിയ പതിപ്പ് ഞങ്ങൾ വിന്യസിച്ചപ്പോൾ, ഞങ്ങൾ അത് എങ്ങനെ വിന്യസിച്ചു? മിക്കപ്പോഴും ഞങ്ങൾ ഫാർ മാനേജർ അല്ലെങ്കിൽ മറ്റെന്തെങ്കിലും തുറക്കുന്നു. ഈ ഫയലുകൾ FTP-യിലേക്ക് അപ്‌ലോഡ് ചെയ്യുകയും ചെയ്തു. ഞങ്ങൾക്ക് ചെറിയ ചെറിയ ബഗ് ഉണ്ടെന്ന് ഞങ്ങൾ പെട്ടെന്ന് മനസ്സിലാക്കി, ഉദാഹരണത്തിന്, ഞങ്ങൾ ഒരു അർദ്ധവിരാമം ഇടാൻ മറന്നു അല്ലെങ്കിൽ ഡാറ്റാബേസിനായി പാസ്‌വേഡ് മാറ്റാൻ മറന്നു, കൂടാതെ ഡാറ്റാബേസിനായി ഒരു പാസ്‌വേഡ് ഉണ്ട്, അത് ലോക്കൽ ഹോസ്റ്റിലാണ്. എഫ്‌ടിപിയിലേക്ക് വേഗത്തിൽ കണക്റ്റുചെയ്യാനും ഫയലുകൾ അവിടെ തന്നെ എഡിറ്റുചെയ്യാനും ഞങ്ങൾ തീരുമാനിക്കുന്നു. ഇത് വെറും തീയാണ്! ഇതാണ് 90 കളിൽ പ്രചാരത്തിലുള്ളത്.

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

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

മുമ്പത്തെ രണ്ട് പരിശീലനങ്ങളും എങ്ങനെയെങ്കിലും സംയോജിപ്പിക്കാൻ നമുക്ക് ശ്രമിക്കാം. റിലീസ് മാനേജ്‌മെന്റ് എന്ന പേരിൽ മൂന്നാമത്തേത് നമുക്ക് ലഭിക്കും.

Continuous Deployment-നെ കുറിച്ച് അതിന്റെ ക്ലാസിക്കൽ രൂപത്തിൽ നമ്മൾ പറയുമ്പോൾ, റിപ്പോസിറ്ററിയിൽ നിന്ന് ഏതെങ്കിലും ബ്രാഞ്ചിൽ നിന്ന് കോഡ് വലിച്ചെടുത്ത് കംപൈൽ ചെയ്ത് വിന്യസിക്കണമെന്ന് ഞങ്ങൾ പറയുന്നു. നമുക്കും ഇതേ ചുറ്റുപാടുണ്ടെങ്കിൽ അത് നല്ലതാണ്. നമുക്ക് നിരവധി പരിതസ്ഥിതികൾ ഉണ്ടെങ്കിൽ, ഒരേ പ്രതിബദ്ധതയിൽ നിന്ന് പോലും ഓരോ തവണയും കോഡ് പിൻവലിക്കണം എന്നാണ് ഇതിനർത്ഥം. ഞങ്ങൾ അത് ഓരോ തവണയും പുറത്തെടുക്കും, ഓരോ തവണയും ഞങ്ങൾ അത് നിർമ്മിക്കുകയും ഒരു പുതിയ അന്തരീക്ഷത്തിലേക്ക് വിന്യസിക്കുകയും ചെയ്യും. ഒന്നാമതായി, ഇത് സമയമാണ്, കാരണം ഒരു പ്രോജക്റ്റ് നിർമ്മിക്കാൻ, നിങ്ങൾക്ക് ഒരു വലിയ ഒന്ന് ഉണ്ടെങ്കിൽ, 90 കളിൽ നിന്ന് വന്നതാണെങ്കിൽ, ഇതിന് കുറച്ച് മണിക്കൂറുകൾ എടുത്തേക്കാം.

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

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

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

ഞങ്ങളുടെ വ്യത്യസ്ത പരിതസ്ഥിതികളിലേക്ക് വിന്യസിക്കാൻ ഞങ്ങൾ തയ്യാറുള്ള ഒരു ശാഖയിൽ ഞങ്ങൾക്ക് എന്തെങ്കിലും പ്രതിബദ്ധത ഉണ്ടായാലുടൻ, ഈ പ്രതിബദ്ധതയിൽ നിന്ന് ഞങ്ങൾ ആപ്ലിക്കേഷനുകൾ ശേഖരിക്കുകയും ഈ ആപ്ലിക്കേഷന് ആവശ്യമായ എല്ലാ കാര്യങ്ങളും ഞങ്ങൾ പാക്ക് ചെയ്യുകയും ചെയ്യുന്നു എന്നതാണ് പ്രധാന ആശയം. ഒരു zip ആർക്കൈവിലേക്ക് മാറ്റി വിശ്വസനീയമായ സ്റ്റോറേജിൽ സംരക്ഷിക്കുക. ഈ സ്റ്റോറേജിൽ നിന്ന് നമുക്ക് എപ്പോൾ വേണമെങ്കിലും ഈ zip ആർക്കൈവ് ലഭിക്കും.

തുടർന്ന് ഞങ്ങൾ അത് എടുത്ത് സ്വയമേവ dev പരിതസ്ഥിതിയിലേക്ക് വിന്യസിക്കുന്നു. ഞങ്ങൾ അവിടെ ഓടുന്നു, എല്ലാം നല്ലതാണെങ്കിൽ, ഞങ്ങൾ സ്റ്റേജിലേക്ക് വിന്യസിക്കുന്നു. എല്ലാം ശരിയാണെങ്കിൽ, ഞങ്ങൾ ഒരേ ആർക്കൈവ് പ്രൊഡക്ഷനിലേക്ക് വിന്യസിക്കുന്നു, ഒരേ ബൈനറികൾ, കൃത്യമായി ഒരു തവണ സമാഹരിച്ചിരിക്കുന്നു.

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

മറ്റൊരു മഹത്തായ ആചാരമുണ്ട്. മുമ്പത്തെ പതിപ്പിലേക്ക് ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ റോൾ ബാക്ക് ചെയ്യുമ്പോൾ, മുമ്പത്തെ പതിപ്പിന്റെ ഇൻഫ്രാസ്ട്രക്ചർ ഞങ്ങൾക്ക് ആവശ്യമാണെന്ന് ഇത് അർത്ഥമാക്കാം എന്ന് നിങ്ങളും ഞാനും എല്ലാവരും മനസ്സിലാക്കുന്നു.

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

കോഡ് സമ്പ്രദായങ്ങളായി ഇൻഫ്രാസ്ട്രക്ചർ ഉപയോഗിക്കുന്നതിലൂടെ, നിങ്ങളുടെ വെർച്വൽ ഇൻഫ്രാസ്ട്രക്ചറിനെ മറ്റൊരു വിഭവമായി കണക്കാക്കാം എന്നതാണ് ആശയം.

ഒരുപക്ഷേ, നിങ്ങളിൽ ആരെങ്കിലും DotNet-ൽ ആപ്ലിക്കേഷനുകൾ വികസിപ്പിക്കുന്നുണ്ടെങ്കിൽ, Entity Framework എന്നൊരു ലൈബ്രറിയെക്കുറിച്ച് നിങ്ങൾ കേട്ടിരിക്കാം. മൈക്രോസോഫ്റ്റ് സജീവമായി മുന്നോട്ട് കൊണ്ടുപോകുന്ന സമീപനങ്ങളിലൊന്നാണ് എന്റിറ്റി ഫ്രെയിംവർക്ക് എന്ന് നിങ്ങൾ കേട്ടിരിക്കാം. ഒരു ഡാറ്റാബേസിൽ പ്രവർത്തിക്കുന്നതിന്, ഇത് കോഡ് ഫസ്റ്റ് എന്ന ഒരു സമീപനമാണ്. നിങ്ങളുടെ ഡാറ്റാബേസ് എങ്ങനെ കാണണമെന്ന് നിങ്ങൾ കോഡിൽ വിവരിക്കുമ്പോഴാണ് ഇത്. തുടർന്ന് നിങ്ങൾ ആപ്ലിക്കേഷൻ വിന്യസിക്കുന്നു. ഇത് ഡാറ്റാബേസുമായി ബന്ധിപ്പിക്കുന്നു, ഏതൊക്കെ പട്ടികകളാണ് ഉള്ളതെന്നും ഏതൊക്കെ ടേബിളുകൾ ഇല്ലെന്നും അത് തന്നെ നിർണ്ണയിക്കുകയും നിങ്ങൾക്ക് ആവശ്യമുള്ളതെല്ലാം സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.

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

നിലവിലുള്ളതും പ്രധാനപ്പെട്ടതും എന്നാൽ കുറച്ച് ആളുകൾ ഉപയോഗിക്കുന്നതുമായ അടുത്ത സമ്പ്രദായം ആപ്ലിക്കേഷൻ പെർഫോമൻസ് മോണിറ്ററിംഗ് ആണ്.

ആപ്ലിക്കേഷൻ പെർഫോമൻസ് മോണിറ്ററിംഗിനെക്കുറിച്ച് ഒരു കാര്യം മാത്രം പറയാൻ ഞാൻ ആഗ്രഹിച്ചു. ഈ പരിശീലനത്തിൽ ഏറ്റവും പ്രധാനപ്പെട്ടത് എന്താണ്? ഒരു അപാര്ട്മെംട് നന്നാക്കുന്നതിന് തുല്യമാണ് ആപ്ലിക്കേഷൻ പെർഫോമൻസ് മോണിറ്ററിംഗ്. ഇതൊരു അന്തിമ അവസ്ഥയല്ല, ഒരു പ്രക്രിയയാണ്. നിങ്ങൾ ഇത് പതിവായി ചെയ്യേണ്ടതുണ്ട്.

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

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

എവിടെയെങ്കിലും ഡ്രോഡൗൺ കുത്തനെ കുറഞ്ഞുവെന്ന് നിങ്ങൾ കണ്ടെത്തുകയാണെങ്കിൽ, അത് കഴിഞ്ഞ രണ്ടാഴ്ചയ്ക്കിടെ ഉണ്ടായ മാറ്റങ്ങൾ കാരണം മാത്രമാണെന്ന് അർത്ഥമാക്കും. ഇത് വളരെ വേഗത്തിൽ പ്രശ്നം തിരിച്ചറിയാനും പരിഹരിക്കാനും നിങ്ങളെ അനുവദിക്കും. വീണ്ടും, ഇത് നിങ്ങൾ എത്രത്തോളം വിജയകരമായി ചെയ്തുവെന്ന് അളക്കാൻ കഴിയുന്ന ഏതാണ്ട് അതേ അളവുകോലുകളാണ്.

കോൺഫിഗറേഷൻ മാനേജ്മെന്റ് പ്രാക്ടീസ് ആണ് ഞങ്ങളുടെ അടുത്ത പ്രാക്ടീസ്. ഇത് ഗൗരവമായി എടുക്കുന്നവർ വളരെ കുറവാണ്. എന്നാൽ എന്നെ വിശ്വസിക്കൂ, ഇത് യഥാർത്ഥത്തിൽ വളരെ ഗുരുതരമായ ഒരു കാര്യമാണ്.

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

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

കോൺഫിഗറേഷൻ മാനേജ്മെന്റ്. വ്യത്യസ്ത പരിതസ്ഥിതികളിൽ നമുക്ക് വ്യത്യസ്ത കോൺഫിഗറേഷനുകൾ ഉണ്ടായിരിക്കാം. ഉദാഹരണത്തിന്, QA, ഡെമോ, പ്രൊഡക്ഷൻ എൻവയോൺമെന്റ് മുതലായവയ്‌ക്കായുള്ള ഡാറ്റാബേസുകൾക്കായി ഞങ്ങൾക്ക് വ്യത്യസ്ത ലോഗിനുകളും പാസ്‌വേഡുകളും ഉണ്ടായിരിക്കാം.

ഈ കോൺഫിഗറേഷൻ ഓട്ടോമേറ്റ് ചെയ്യാനും കഴിയും. ഇത് എല്ലായ്പ്പോഴും ആപ്ലിക്കേഷനിൽ നിന്ന് വേറിട്ടുനിൽക്കണം. എന്തുകൊണ്ട്? നിങ്ങൾ ഒരിക്കൽ ആപ്ലിക്കേഷൻ നിർമ്മിച്ചതിനാൽ, നിങ്ങൾ SQL സെർവറിലേക്ക് അത്തരത്തിലുള്ള ഒരു ഐപി വഴിയോ അല്ലെങ്കിൽ അത്തരം ഒരു ഐപി വഴിയോ കണക്‌റ്റ് ചെയ്‌തിട്ടുണ്ടോ എന്ന് ആപ്ലിക്കേഷൻ ശ്രദ്ധിക്കുന്നില്ല, അത് ഒരേപോലെ പ്രവർത്തിക്കണം. അതിനാൽ, പെട്ടെന്ന് നിങ്ങളിൽ ഒരാൾ ഇപ്പോഴും കോഡിലെ കണക്ഷൻ സ്ട്രിംഗ് ഹാർഡ്കോഡ് ചെയ്യുകയാണെങ്കിൽ, ഞാൻ നിങ്ങളെ കണ്ടെത്തുമെന്നും നിങ്ങൾ എന്നോടൊപ്പം ഒരേ പ്രോജക്റ്റിൽ നിങ്ങളെ കണ്ടെത്തുകയാണെങ്കിൽ നിങ്ങളെ ശിക്ഷിക്കുമെന്നും ഓർക്കുക. ഇത് എല്ലായ്പ്പോഴും ഒരു പ്രത്യേക കോൺഫിഗറേഷനിൽ സ്ഥാപിച്ചിരിക്കുന്നു, ഉദാഹരണത്തിന്, web.config-ൽ.

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

ഞാൻ സംസാരിക്കാൻ ആഗ്രഹിക്കുന്ന അവസാന സമ്പ്രദായം മേഘങ്ങളുമായി വളരെ ബന്ധപ്പെട്ടിരിക്കുന്ന ഒരു പരിശീലനമാണ്. നിങ്ങൾ ക്ലൗഡിൽ പ്രവർത്തിക്കുകയാണെങ്കിൽ അത് പരമാവധി പ്രഭാവം നൽകുന്നു. ഇത് നിങ്ങളുടെ പരിസ്ഥിതിയുടെ സ്വയമേവ നീക്കം ചെയ്യലാണ്.

ഞാൻ പ്രവർത്തിക്കുന്ന ടീമുകളിൽ നിന്ന് ഈ കോൺഫറൻസിൽ നിരവധി ആളുകൾ ഉണ്ടെന്ന് എനിക്കറിയാം. ഒപ്പം ഞാൻ പ്രവർത്തിക്കുന്ന എല്ലാ ടീമുകളുമായും ഞങ്ങൾ ഈ പരിശീലനം ഉപയോഗിക്കുന്നു.

എന്തുകൊണ്ട്? തീർച്ചയായും, ഓരോ ഡവലപ്പർക്കും 24/7 പ്രവർത്തിക്കുന്ന ഒരു വെർച്വൽ മെഷീൻ ഉണ്ടെങ്കിൽ അത് വളരെ മികച്ചതായിരിക്കും. എന്നാൽ ഇത് നിങ്ങൾക്ക് ഒരു വാർത്തയായിരിക്കാം, ഒരുപക്ഷേ നിങ്ങൾ ശ്രദ്ധിച്ചില്ലായിരിക്കാം, പക്ഷേ ഡവലപ്പർ തന്നെ 24/7 പ്രവർത്തിക്കുന്നില്ല. ഒരു ഡവലപ്പർ സാധാരണയായി ഒരു ദിവസം 8 മണിക്കൂർ പ്രവർത്തിക്കുന്നു. അവൻ നേരത്തെ ജോലിക്ക് വന്നാലും, അവൻ ജിമ്മിൽ പോകുന്ന സമയത്ത് ഒരു വലിയ ഉച്ചഭക്ഷണം കഴിക്കുന്നു. ഡെവലപ്പർ യഥാർത്ഥത്തിൽ ഈ ഉറവിടങ്ങൾ ഉപയോഗിക്കുമ്പോൾ അത് ദിവസത്തിൽ 12 മണിക്കൂർ ആയിരിക്കട്ടെ. ഞങ്ങളുടെ നിയമനിർമ്മാണം അനുസരിച്ച്, ഞങ്ങൾക്ക് ആഴ്ചയിൽ 5-ൽ 7 ദിവസങ്ങൾ പ്രവൃത്തി ദിവസമായി കണക്കാക്കുന്നു.

അതനുസരിച്ച്, പ്രവൃത്തിദിവസങ്ങളിൽ ഈ മെഷീൻ 24 മണിക്കൂറും 12 മണിക്കൂറും പ്രവർത്തിക്കരുത്, വാരാന്ത്യങ്ങളിൽ ഈ യന്ത്രം പ്രവർത്തിക്കരുത്. എല്ലാം വളരെ ലളിതമാണെന്ന് തോന്നുന്നു, പക്ഷേ ഇവിടെ എന്താണ് പറയേണ്ടത്? ഈ അടിസ്ഥാന ഷെഡ്യൂളിൽ ഈ ലളിതമായ രീതി നടപ്പിലാക്കുന്നതിലൂടെ, ഈ പരിതസ്ഥിതികൾ പരിപാലിക്കുന്നതിനുള്ള ചെലവ് 70% കുറയ്ക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു, അതായത് നിങ്ങളുടെ dev, QA, ഡെമോ, പരിസ്ഥിതി എന്നിവയുടെ വില നിങ്ങൾ എടുത്ത് അതിനെ 3 കൊണ്ട് ഹരിച്ചു.

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

തുടർച്ചയായ പെർഫോമൻസ് മെഷർമെന്റുള്ള സ്ലൈഡിനെ സംബന്ധിച്ച്, പ്രോജക്റ്റിലെ ഡാറ്റാബേസിൽ 1 റെക്കോർഡുകൾ ഉണ്ടെങ്കിൽ, രണ്ട് മാസത്തിന് ശേഷം ഒരു ദശലക്ഷമുണ്ടെങ്കിൽ നമുക്ക് പ്രകടനത്തെ എങ്ങനെ താരതമ്യം ചെയ്യാം? എന്തുകൊണ്ടാണ് പ്രകടനം അളക്കുന്നതിന്റെ പോയിന്റ് എന്താണെന്ന് എങ്ങനെ മനസ്സിലാക്കാം?

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

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

ഒരു പ്രത്യേക ടെസ്റ്റ് പരിതസ്ഥിതിയിൽ പ്രകടനം അളക്കുന്നതിനെക്കുറിച്ചാണോ നമ്മൾ സംസാരിക്കുന്നത്? അതായത്, ഇത് ഉൽപ്പാദനമല്ലേ?

അതെ, ഇത് ഉൽപ്പാദനമല്ല, ഇതൊരു പരീക്ഷണ പരിതസ്ഥിതിയാണ്, അത് എല്ലായ്പ്പോഴും സമാനമാണ്, അതിനാൽ നിങ്ങൾക്ക് മുമ്പത്തെ അളവുകളുമായി താരതമ്യം ചെയ്യാം.

മനസ്സിലായി നന്ദി!

ചോദ്യങ്ങളൊന്നും ഇല്ലെങ്കിൽ, നമുക്ക് അവസാനിപ്പിക്കാമെന്ന് ഞാൻ കരുതുന്നു. നന്ദി!

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