DevOps LEGO: ഞങ്ങൾ എങ്ങനെയാണ് പൈപ്പ് ലൈൻ ക്യൂബുകളായി സ്ഥാപിച്ചത്

ഒരിക്കൽ ഞങ്ങൾ ഒരു ഇലക്ട്രോണിക് ഡോക്യുമെന്റ് മാനേജ്മെന്റ് സിസ്റ്റം ഒരു ഉപഭോക്താവിന് ഒരു സൗകര്യത്തിൽ വിതരണം ചെയ്തു. പിന്നെ മറ്റൊരു വസ്തുവിലേക്ക്. ഒപ്പം ഒന്ന് കൂടി. നാലാമത്തേതും അഞ്ചാമത്തേതും. ഞങ്ങൾ 10 വിതരണം ചെയ്ത വസ്തുക്കളിൽ എത്തിച്ചേർന്നു. അത് ശക്തമായിരുന്നു... പ്രത്യേകിച്ചും ഞങ്ങൾ മാറ്റങ്ങൾ എത്തിക്കുന്ന ഘട്ടത്തിൽ എത്തിയപ്പോൾ. പ്രൊഡക്ഷൻ സർക്യൂട്ടിലേക്കുള്ള ഡെലിവറിയുടെ ഭാഗമായി, ടെസ്റ്റിംഗ് സിസ്റ്റത്തിന്റെ 5 സാഹചര്യങ്ങൾക്ക് ആത്യന്തികമായി 10 മണിക്കൂറും 6-7 ജീവനക്കാരും ആവശ്യമാണ്. അത്തരം ചെലവുകൾ കഴിയുന്നത്ര അപൂർവ്വമായി ഡെലിവറികൾ നടത്താൻ ഞങ്ങളെ നിർബന്ധിച്ചു. മൂന്ന് വർഷത്തെ പ്രവർത്തനത്തിന് ശേഷം, ഞങ്ങൾക്ക് അത് സഹിക്കാൻ കഴിഞ്ഞില്ല, കൂടാതെ ഒരു നുള്ള് DevOps ഉപയോഗിച്ച് പ്രോജക്റ്റ് മസാലയാക്കാൻ തീരുമാനിച്ചു.

ഇപ്പോൾ എല്ലാ പരിശോധനകളും 3 മണിക്കൂറിനുള്ളിൽ നടക്കുന്നു, 3 ആളുകൾ അതിൽ പങ്കെടുക്കുന്നു: ഒരു എഞ്ചിനീയറും രണ്ട് ടെസ്റ്റർമാരും. മെച്ചപ്പെടുത്തലുകൾ അക്കങ്ങളിൽ വ്യക്തമായി പ്രകടിപ്പിക്കുകയും വളരെ പ്രിയപ്പെട്ട ടിടിഎമ്മിൽ കുറവുണ്ടാക്കുകയും ചെയ്യുന്നു. ഞങ്ങളുടെ അനുഭവത്തിൽ, DevOps-നെ കുറിച്ച് അറിയാവുന്നവരേക്കാൾ കൂടുതൽ ഉപഭോക്താക്കൾ അതിൽ നിന്ന് പ്രയോജനം നേടുന്നു. അതിനാൽ, DevOps-നെ ആളുകളിലേക്ക് അടുപ്പിക്കുന്നതിന്, ഞങ്ങൾ ഒരു ലളിതമായ കൺസ്ട്രക്റ്റർ വികസിപ്പിച്ചെടുത്തിട്ടുണ്ട്, ഈ പോസ്റ്റിൽ കൂടുതൽ വിശദമായി ഞങ്ങൾ സംസാരിക്കും.

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

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

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

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

അതിനാൽ, ഞങ്ങൾക്ക് ഒരു വശത്ത് ഒരു കൂട്ടം പ്രശ്‌നങ്ങളുണ്ട്, മറുവശത്ത് ഞങ്ങൾക്ക് DevOps അറിവും പരിശീലനങ്ങളും ഉപകരണങ്ങളും ഉണ്ട്. എന്തുകൊണ്ട് എല്ലാവരുമായും അനുഭവം പങ്കുവെച്ചുകൂടാ?

ഒരു DevOps കൺസ്ട്രക്റ്റർ സൃഷ്ടിക്കുന്നു

എജൈലിന് അതിന്റേതായ പ്രകടനപത്രികയുണ്ട്. ഐടിഐഎല്ലിന് അതിന്റേതായ രീതിശാസ്ത്രമുണ്ട്. DevOps ഭാഗ്യം കുറവാണ് - ഇത് ഇതുവരെ ടെംപ്ലേറ്റുകളും മാനദണ്ഡങ്ങളും നേടിയിട്ടില്ല. എങ്കിലും ചിലത് ശ്രമിക്കുന്നു കമ്പനികളുടെ വികസനത്തിന്റെയും പ്രവർത്തന രീതികളുടെയും വിലയിരുത്തലിനെ അടിസ്ഥാനമാക്കി അവരുടെ പക്വത നിർണ്ണയിക്കുക.

ഭാഗ്യവശാൽ, 2014 ൽ അറിയപ്പെടുന്ന കമ്പനി ഗാർട്ട്നർ ശേഖരിച്ചു പ്രധാന DevOps രീതികളും അവ തമ്മിലുള്ള ബന്ധങ്ങളും വിശകലനം ചെയ്തു. ഇതിനെ അടിസ്ഥാനമാക്കി, ഞാൻ ഒരു ഇൻഫോഗ്രാഫിക് പുറത്തിറക്കി:

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

പ്രക്രിയകൾ

കുപ്രസിദ്ധമായ EDMS പ്രോജക്റ്റിൽ, ഓരോ 10 ഒബ്ജക്റ്റുകളിലും ഒരേ സ്കീം അനുസരിച്ച് സാങ്കേതിക ഡോക്യുമെന്റേഷൻ മാനേജ്മെന്റ് സിസ്റ്റം വിന്യസിച്ചു. ഇൻസ്റ്റാളേഷനിൽ 4 സെർവറുകൾ ഉൾപ്പെടുന്നു: ഡാറ്റാബേസ് സെർവർ, ആപ്ലിക്കേഷൻ സെർവർ, ഫുൾ-ടെക്‌സ്റ്റ് ഇൻഡെക്‌സിംഗ്, ഉള്ളടക്ക മാനേജ്‌മെന്റ്. ഇൻസ്റ്റാളേഷനിൽ, അവ ഒരൊറ്റ നോഡിനുള്ളിൽ പ്രവർത്തിക്കുകയും സൗകര്യങ്ങളിലെ ഡാറ്റാ സെന്ററിൽ സ്ഥിതിചെയ്യുകയും ചെയ്യുന്നു. എല്ലാ വസ്തുക്കളും ഇൻഫ്രാസ്ട്രക്ചറിൽ അല്പം വ്യത്യാസപ്പെട്ടിരിക്കുന്നു, എന്നാൽ ഇത് ആഗോള ഇടപെടലിൽ ഇടപെടുന്നില്ല.

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

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

സംസ്കാരം

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

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

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

ജനം

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

സാങ്കേതികവിദ്യയുടെ

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

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

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

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

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

തുടർച്ചയായ ഡെലിവറി, നിരീക്ഷണം

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

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

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

ആർക്കാണ് നമ്മുടെ ആവശ്യം DevOps ഡിസൈനർ?

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

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

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

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