DevOps - VTB അനുഭവം ഉപയോഗിച്ച് ഒരു സമ്പൂർണ്ണ ഇൻഹൗസ് വികസനം എങ്ങനെ നിർമ്മിക്കാം

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

 

ആമുഖം: DevOps ഒരു തത്വശാസ്ത്രമാണ്

കഴിഞ്ഞ ഒരു വർഷമായി, VTB-യിൽ DevOps പ്രാക്ടീസുകളുടെ ആന്തരിക വികസനവും നടപ്പിലാക്കലും സംഘടിപ്പിക്കുന്നതിന് ഞങ്ങൾ വളരെയധികം പ്രവർത്തനങ്ങൾ നടത്തി:

• 12 സിസ്റ്റങ്ങൾക്കായി ഞങ്ങൾ ആന്തരിക വികസന പ്രക്രിയകൾ നിർമ്മിച്ചു;
• ഞങ്ങൾ 15 പൈപ്പ് ലൈനുകൾ ആരംഭിച്ചു, അതിൽ നാലെണ്ണം ഉൽപാദനത്തിലേക്ക് കൊണ്ടുവന്നു;
• ഓട്ടോമേറ്റഡ് 1445 ടെസ്റ്റ് സാഹചര്യങ്ങൾ;
• ഇൻ-ഹൗസ് ടീമുകൾ തയ്യാറാക്കിയ നിരവധി റിലീസുകൾ ഞങ്ങൾ വിജയകരമായി നടപ്പിലാക്കി.

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

ആദ്യം, നടപ്പിലാക്കൽ അൽഗോരിതം ലളിതവും വ്യക്തവുമാണെന്ന് തോന്നി:

• ഞങ്ങൾ പ്രാരംഭ വികസന വൈദഗ്ധ്യം വികസിപ്പിക്കുകയും കോഡ് ടീമിൽ നിന്ന് സ്വീകാര്യമായ നിലവാരം കൈവരിക്കുകയും ചെയ്യുന്നു;
• കഴിയുന്നത്ര നിലവിലുള്ള പ്രക്രിയകളിലേക്ക് ഞങ്ങൾ സംയോജിപ്പിക്കുന്നു;
• വ്യക്തമായ ഘട്ടങ്ങൾക്കിടയിൽ കോഡ് കൈമാറാൻ, ഞങ്ങൾ ഒരു പൈപ്പ്ലൈൻ മുറിച്ച് അതിന്റെ അറ്റങ്ങളിലൊന്ന് തുടർച്ചയിലേക്ക് തള്ളുന്നു.

ഈ സമയത്ത്, ആവശ്യമായ വലുപ്പത്തിലുള്ള വികസന സംഘം കഴിവുകൾ വികസിപ്പിക്കുകയും സ്വീകാര്യമായ തലത്തിലേക്ക് റിലീസുകളിലേക്കുള്ള സംഭാവനയുടെ പങ്ക് വർദ്ധിപ്പിക്കുകയും വേണം. അത്രയേയുള്ളൂ, പൂർത്തിയാക്കിയ ടാസ്ക് നമുക്ക് പരിഗണിക്കാം.

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

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

ഇൻഹൗസ് വികസനം എവിടെ തുടങ്ങും? 

പ്രവർത്തിക്കാൻ ഏറ്റവും സൗഹൃദപരമായ സംവിധാനമായിരുന്നില്ല അത്. വാസ്തുവിദ്യാപരമായി, ഇത് ഒരു വലിയ നോൺ-റിലേഷണൽ DBMS ആയിരുന്നു, അതിൽ പല പ്രത്യേക എക്സിക്യൂട്ടബിൾ ഒബ്ജക്റ്റുകൾ (സ്ക്രിപ്റ്റുകൾ, നടപടിക്രമങ്ങൾ, ബാച്ചുകൾ മുതലായവ) അടങ്ങിയിരിക്കുന്നു, അവ ആവശ്യാനുസരണം വിളിക്കുകയും ഒരു ബ്ലാക്ക് ബോക്സിന്റെ തത്വത്തിൽ പ്രവർത്തിക്കുകയും ചെയ്തു: ഇതിന് ഒരു അഭ്യർത്ഥനയും പ്രശ്നങ്ങളും ലഭിക്കുന്നു. ഒരു പ്രതികരണം. ശ്രദ്ധിക്കേണ്ട മറ്റ് ബുദ്ധിമുട്ടുകൾ ഉൾപ്പെടുന്നു:

• വിദേശ ഭാഷ (MUMPS);
• കൺസോൾ ഇന്റർഫേസ്;
• ജനപ്രിയ ഓട്ടോമേഷൻ ഉപകരണങ്ങളും ചട്ടക്കൂടുകളുമായുള്ള സംയോജനത്തിന്റെ അഭാവം;
• പതിനായിരക്കണക്കിന് ടെറാബൈറ്റുകളിൽ ഡാറ്റ വോളിയം;
• മണിക്കൂറിൽ 2 ദശലക്ഷത്തിലധികം പ്രവർത്തനങ്ങളുടെ ലോഡ്;
• പ്രാധാന്യം - ബിസിനസ്-നിർണ്ണായക.

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

• കോഡ് സൃഷ്ടിക്കുന്നതിന്റെ ഡോക്യുമെന്റേഷനും അടിസ്ഥാനകാര്യങ്ങളും പഠിച്ചു;
• വെണ്ടറിൽ നിന്ന് ലഭിച്ച വികസനത്തെക്കുറിച്ചുള്ള ഹ്രസ്വ കോഴ്‌സ് ഞങ്ങൾ പഠിച്ചു;
• പ്രാരംഭ വികസന കഴിവുകളിൽ വൈദഗ്ദ്ധ്യം;
• പുതിയ ടീം അംഗങ്ങൾക്കായി ഞങ്ങൾ ഒരു പരിശീലന മാനുവൽ സമാഹരിച്ചു;
• "കോംബാറ്റ്" മോഡിൽ ടീമിനെ ഉൾപ്പെടുത്താൻ ഞങ്ങൾ സമ്മതിച്ചു;
• കോഡ് ഗുണനിലവാര നിയന്ത്രണത്തിൽ പ്രശ്നം പരിഹരിച്ചു;
• ഞങ്ങൾ വികസനത്തിനായി ഒരു നിലപാട് സംഘടിപ്പിച്ചു.

വൈദഗ്ധ്യം വികസിപ്പിക്കുന്നതിനും സിസ്റ്റത്തിൽ മുഴുകുന്നതിനും ഞങ്ങൾ മൂന്ന് മാസം ചെലവഴിച്ചു, 2019 ന്റെ തുടക്കം മുതൽ, ഇൻഹൗസ് വികസനം ശോഭനമായ ഭാവിയിലേക്കുള്ള അതിന്റെ ചലനം ആരംഭിച്ചു, ചിലപ്പോൾ പ്രയാസത്തോടെ, എന്നാൽ ആത്മവിശ്വാസത്തോടെയും ലക്ഷ്യബോധത്തോടെയും.

റിപ്പോസിറ്ററി മൈഗ്രേഷനും ഓട്ടോടെസ്റ്റുകളും

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

റിപ്പോസിറ്ററിയുടെ മൈഗ്രേഷൻ ആവർത്തിച്ച് മാറ്റിവച്ചു; മുൻനിരയിലെ സഹപ്രവർത്തകരുടെ സഹായത്തോടെ ഏപ്രിലിൽ മാത്രമാണ് ഇത് പൂർത്തിയാക്കിയത്. Git Flow ഉപയോഗിച്ച്, ഒരു തുടക്കത്തിനായി കാര്യങ്ങൾ ലളിതമായി നിലനിർത്താൻ ഞങ്ങൾ തീരുമാനിച്ചു, ഹോട്ട്ഫിക്സ്, വികസിപ്പിക്കൽ, റിലീസ് എന്നിവ ഉപയോഗിച്ച് ക്ലാസിക് സ്കീമിൽ സ്ഥിരതാമസമാക്കി. അവർ മാസ്റ്ററെ (പ്രോഡ് പോലെ) ഉപേക്ഷിക്കാൻ തീരുമാനിച്ചു. എന്തുകൊണ്ടാണ് ഈ ഓപ്ഷൻ ഞങ്ങൾക്ക് അനുയോജ്യമെന്ന് ഞങ്ങൾ ചുവടെ വിശദീകരിക്കും. രണ്ട് ടീമുകൾക്ക് പൊതുവായുള്ള വെണ്ടറുടെ ഒരു ബാഹ്യ ശേഖരം ഒരു തൊഴിലാളിയായി ഉപയോഗിച്ചു. ഇത് ഒരു ഷെഡ്യൂൾ അനുസരിച്ച് ആന്തരിക ശേഖരവുമായി സമന്വയിപ്പിച്ചു. ഇപ്പോൾ Git, Gitlab എന്നിവ ഉപയോഗിച്ച് പ്രക്രിയകൾ ഓട്ടോമേറ്റ് ചെയ്യാൻ സാധിച്ചു.

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

അത് എങ്ങനെയായിരുന്നു: ഓട്ടോമേഷന് മുമ്പുള്ള മോഡൽ

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

സ്വതന്ത്ര വസ്തുക്കളായ വ്യക്തിഗത ഡെലിവറികളുടെ തലത്തിലാണ് അസംബ്ലി നടത്തിയത്. ഏത് മാറ്റവും ഒരു പുതിയ ഡെലിവറി ആണ്. മറ്റ് കാര്യങ്ങളിൽ, പ്രധാന റിലീസ് കോമ്പോസിഷന്റെ 60-70 പാക്കേജുകളിലേക്ക് 10-15 സാങ്കേതിക പതിപ്പുകൾ ചേർത്തു - റിലീസിൽ നിന്ന് എന്തെങ്കിലും ചേർക്കുമ്പോഴോ ഒഴിവാക്കുമ്പോഴോ ലഭിച്ച പതിപ്പുകൾ, റിലീസുകൾക്ക് പുറത്തുള്ള വിൽപ്പനയിലെ മാറ്റങ്ങൾ പ്രതിഫലിപ്പിക്കുന്നു.

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

കോഡിന്റെ ആവശ്യമായ പതിപ്പ് ലഭിക്കുന്നതിന്, ഇൻസ്റ്റാളേഷൻ ക്രമം കർശനമായി പാലിക്കേണ്ടത് ആവശ്യമാണ്, ഈ സമയത്ത് ഒബ്‌ജക്റ്റുകൾ ശാരീരികമായി നിരവധി തവണ, ചില 10-12 തവണ മാറ്റിയെഴുതി.

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

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

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

ആദ്യ അപ്‌ഡേറ്റുകൾ: അസംബ്ലിയും ഡെലിവറിയും നടത്തുക

ഈ വഴിയിലൂടെ ഒരു പൈപ്പിലൂടെ കോഡ് കൈമാറിക്കൊണ്ട് ഓട്ടോമേഷൻ ആരംഭിച്ചു:

• സംഭരണത്തിൽ നിന്ന് പൂർത്തിയായ ഡെലിവറി എടുക്കുക;
• ഒരു സമർപ്പിത പരിതസ്ഥിതിയിൽ ഇത് ഇൻസ്റ്റാൾ ചെയ്യുക;
• ഓട്ടോടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുക;
• ഇൻസ്റ്റാളേഷൻ ഫലം വിലയിരുത്തുക;
• ടെസ്റ്റിംഗ് കമാൻഡിന്റെ വശത്തുള്ള ഇനിപ്പറയുന്ന പൈപ്പ്ലൈനിൽ വിളിക്കുക.

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

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

ഇതിനുശേഷം, കോഡ് പരിശോധിക്കുകയും കൈമാറുകയും ചെയ്യുന്നതിനും പൈപ്പ് സമാരംഭിക്കുന്നതിനും ഞങ്ങളുടെ വശത്ത് കൂട്ടിച്ചേർക്കുന്നതിനും ഇതിനകം നിലവിലുള്ള നടപടികൾ ഉണ്ടായിരുന്നു.

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

അന്തിമ പരിഹാരം: ക്യുമുലേറ്റീവ് ഇൻസ്റ്റലേഷൻ പാക്കേജുകൾ 

വെണ്ടറുടെ നിർദ്ദേശങ്ങൾ സ്‌ക്രിപ്റ്റ് ചെയ്യുന്നത് വളരെ ഓട്ടോമേഷൻ ആണെന്ന് ഞങ്ങൾ നന്നായി മനസ്സിലാക്കി; ഞങ്ങൾ ഈ പ്രക്രിയയെക്കുറിച്ച് തന്നെ പുനർവിചിന്തനം ചെയ്യേണ്ടതുണ്ട്. പരിഹാരം വ്യക്തമായിരുന്നു - ആവശ്യമായ പതിപ്പുകളുടെ എല്ലാ ഒബ്ജക്റ്റുകളും ഉപയോഗിച്ച് റിലീസ് ബ്രാഞ്ചിൽ നിന്ന് ഒരു ക്യുമുലേറ്റീവ് സപ്ലൈ ശേഖരിക്കുക.

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

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

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

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

ഒരു അധിക വെല്ലുവിളി എന്നത് കണക്കിലെടുക്കേണ്ട ധാരാളം നോൺ-റിലീസുകൾ ആയിരുന്നു. എന്നാൽ പ്രോഡ് പോലുള്ള ശാഖയും റീബേസും ആയതോടെ ചുമതല സുതാര്യമായി.

ആദ്യമായി, വേഗത്തിലും പിശകുകളില്ലാതെയും

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

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

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

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

ഫലങ്ങളും നിഗമനങ്ങളും

ഒരു വർഷത്തിനുള്ളിൽ ഞങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിഞ്ഞു:

• ഒരു വിദേശ സംവിധാനം ഉപയോഗിച്ച് പൂർണ്ണമായ ആന്തരിക വികസനം നിർമ്മിക്കുക;
• നിർണായകമായ വെണ്ടർ ആശ്രിതത്വം ഇല്ലാതാക്കുക;
• വളരെ സൗഹൃദപരമല്ലാത്ത പാരമ്പര്യത്തിനായി CI/CD സമാരംഭിക്കുക;
• നടപ്പാക്കൽ പ്രക്രിയകൾ ഒരു പുതിയ സാങ്കേതിക തലത്തിലേക്ക് ഉയർത്തുക;
• വിന്യാസ സമയം ഗണ്യമായി കുറയ്ക്കുക;
• നടപ്പാക്കൽ പിശകുകളുടെ എണ്ണം ഗണ്യമായി കുറയ്ക്കുക;
• ഒരു മുൻനിര വികസന വിദഗ്ധനായി സ്വയം ആത്മവിശ്വാസത്തോടെ പ്രഖ്യാപിക്കുക.

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

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