GitLab-ൽ ഞങ്ങൾ എങ്ങനെയാണ് സോഫ്റ്റ്‌വെയർ പാച്ചുകൾ റിലീസ് ചെയ്യുന്നത്

GitLab-ൽ, ഞങ്ങൾ സോഫ്റ്റ്‌വെയർ പാച്ചുകൾ രണ്ട് തരത്തിലാണ് കൈകാര്യം ചെയ്യുന്നത്: മാനുവലായും ഓട്ടോമാറ്റിക്കായും. റിലീസ് മാനേജർ gitlab.com-ലേക്ക് ഓട്ടോമേറ്റഡ് ഡിപ്ലോയ്‌മെന്റ് വഴി പ്രധാനപ്പെട്ട അപ്‌ഡേറ്റുകൾ എങ്ങനെ സൃഷ്ടിക്കുകയും നൽകുകയും ചെയ്യുന്നു എന്നതിനെക്കുറിച്ച് കൂടുതലറിയാൻ വായിക്കുക, അതുപോലെ തന്നെ സ്വന്തം ഇൻസ്റ്റാളേഷനുകളിൽ പ്രവർത്തിക്കുന്ന ഉപയോക്താക്കൾക്കുള്ള പാച്ചുകളും.

നിങ്ങളുടെ സ്മാർട്ട് വാച്ചിൽ ഒരു ഓർമ്മപ്പെടുത്തൽ സജ്ജീകരിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു: എല്ലാ മാസവും 22-ാം തീയതി, സ്വന്തം ഉപകരണങ്ങളിൽ GitLab-ൽ പ്രവർത്തിക്കുന്ന ഉപയോക്താക്കൾക്ക് ഞങ്ങളുടെ ഉൽപ്പന്നത്തിന്റെ ഏറ്റവും പുതിയ പതിപ്പിലേക്കുള്ള അപ്‌ഡേറ്റുകൾ കാണാൻ കഴിയും. പ്രതിമാസ പതിപ്പിൽ പുതിയ സവിശേഷതകൾ, നിലവിലുള്ളവയിലെ മെച്ചപ്പെടുത്തലുകൾ എന്നിവ ഉൾപ്പെടുന്നു, കൂടാതെ പലപ്പോഴും ഉപകരണങ്ങൾക്കോ ​​ലയനങ്ങൾക്കോ ​​വേണ്ടിയുള്ള കമ്മ്യൂണിറ്റി സമർപ്പിച്ച ഫീച്ചർ അഭ്യർത്ഥനകളുടെ അന്തിമ ഫലങ്ങൾ ഉൾപ്പെടുന്നു.

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

«GitLab.com-ലേക്ക് മാറ്റുന്നതിനുമുമ്പ്, ഡെവലപ്പർമാർ ചെയ്തതെല്ലാം എല്ലാ പരിതസ്ഥിതികളിലേക്കും എല്ലാ ദിവസവും വിന്യസിച്ചിട്ടുണ്ടെന്ന് ഞങ്ങൾ ഉറപ്പാക്കുന്നു.", വിശദീകരിക്കുന്നു മാരിൻ ജാൻകോവ്കി, ഇൻഫ്രാസ്ട്രക്ചർ വകുപ്പിന്റെ സീനിയർ ടെക്നിക്കൽ മാനേജർ.നിങ്ങളുടെ ഇൻസ്റ്റാളേഷനുകൾക്കുള്ള റിലീസുകളെ gitlab.com ഡിപ്ലോയ്‌മെന്റുകൾക്കുള്ള സ്‌നാപ്പ്‌ഷോട്ടുകളായി കരുതുക, ഇതിനായി ഒരു പാക്കേജ് സൃഷ്ടിക്കുന്നതിനുള്ള പ്രത്യേക ഘട്ടങ്ങൾ ഞങ്ങൾ ചേർത്തിട്ടുണ്ട്, അതുവഴി ഞങ്ങളുടെ ഉപയോക്താക്കൾക്ക് അവരുടെ സ്വന്തം സിസ്റ്റങ്ങളിൽ ഇൻസ്റ്റാളേഷനായി ഇത് ഉപയോഗിക്കാൻ കഴിയും.".

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

റിലീസുകൾ സൃഷ്ടിക്കുന്നതിൽ ഉൾപ്പെട്ടിരിക്കുന്ന മിക്ക പ്രക്രിയകളും ഓട്ടോമേറ്റ് ചെയ്യാൻ ഡെലിവറി ടീം കഠിനമായി പരിശ്രമിക്കുന്നു. എം.ടി.ടി.പി. (ഉൽപാദനത്തിലേക്കുള്ള ശരാശരി സമയം), ഒരു ഡെവലപ്പർ ഒരു പുൾ അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുന്ന സമയം മുതൽ അത് gitlab.com-ലേക്ക് വിന്യസിക്കുന്നതുവരെയുള്ള സമയം.

«ഒരു കമ്പനി എന്ന നിലയിൽ നമുക്ക് വേഗത്തിൽ മുന്നേറാൻ കഴിയുമെന്ന് ഉറപ്പാക്കുക, അല്ലെങ്കിൽ കുറഞ്ഞത് ഡെലിവറി ആളുകളുടെ ജോലികൾ വേഗത്തിലാക്കുക എന്നതാണ് ഡെലിവറി ടീമിന്റെ ലക്ഷ്യം, അല്ലേ?? ", മാരിൻ പറയുന്നു.

സൈക്കിൾ സമയം കുറയ്ക്കുന്നതിനും വിന്യാസങ്ങൾ വേഗത്തിലാക്കുന്നതിനുമുള്ള ഡെലിവറി ടീമിന്റെ ശ്രമങ്ങളിൽ നിന്ന് gitlab.com ഉപഭോക്താക്കൾക്കും അവരുടെ ഇൻസ്റ്റാളേഷനുകളുടെ ഉപയോക്താക്കൾക്കും പ്രയോജനം ലഭിക്കുന്നു. ഈ ലേഖനത്തിൽ, ഈ രണ്ട് സമീപനങ്ങൾ തമ്മിലുള്ള സമാനതകളും വ്യത്യാസങ്ങളും ഞങ്ങൾ വിശദീകരിക്കും. റിലീസുകൾസ്വന്തം സിസ്റ്റങ്ങളിൽ പ്രവർത്തിക്കുന്ന ഉപയോക്താക്കൾക്കായി ഞങ്ങളുടെ ഡെലിവറി ടീം എങ്ങനെ പാച്ചുകൾ തയ്യാറാക്കുന്നു, ഓട്ടോമേറ്റഡ് ഡിപ്ലോയ്‌മെന്റുകൾ ഉപയോഗിച്ച് gitlab.com-നെ എങ്ങനെ കാലികമായി നിലനിർത്തുന്നു എന്നിവ ഞങ്ങൾ വിവരിക്കും.

ഒരു റിലീസ് മാനേജർ എന്താണ് ചെയ്യുന്നത്?

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

ഓൺ-പ്രിമൈസ് റിലീസുകളും gitlab.com റിലീസുകളും സമാനമായ വർക്ക്ഫ്ലോകളാണ് ഉപയോഗിക്കുന്നതെങ്കിലും വ്യത്യസ്ത സമയങ്ങളിൽ പ്രവർത്തിക്കുന്നുവെന്ന് മാരിൻ വിശദീകരിക്കുന്നു.

ഒന്നാമതായി, റിലീസ് തരം പരിഗണിക്കാതെ തന്നെ, റിലീസ് മാനേജർ, gitlab.com-ൽ ആപ്ലിക്കേഷൻ ലോഞ്ച് ചെയ്യുന്ന നിമിഷം മുതൽ GitLab-ന്റെ ലഭ്യതയും സുരക്ഷയും ഉറപ്പാക്കുന്നു, അതുപോലെ തന്നെ സമാനമായ പ്രശ്നങ്ങൾ ഉപഭോക്തൃ ഇൻഫ്രാസ്ട്രക്ചറിൽ അവരുടെ കഴിവുകൾ ഉപയോഗിച്ച് എത്തുന്നില്ലെന്ന് ഉറപ്പാക്കുന്നു.

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

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

തിരുത്തലുകളെക്കുറിച്ചുള്ള എല്ലാം

തിരുത്തലുകൾ എന്തൊക്കെയാണ്, അവ നമുക്ക് ആവശ്യമായി വരുന്നത് എന്തുകൊണ്ട്?

ബഗിന്റെ തീവ്രതയനുസരിച്ച് ഒരു പരിഹാരം പുറത്തിറക്കാൻ റിലീസ് മാനേജർ തീരുമാനിക്കുന്നു.

പിശകുകൾ അവയുടെ തീവ്രതയെ ആശ്രയിച്ച് വ്യത്യാസപ്പെടുന്നു. ഉദാഹരണത്തിന്, S4 അല്ലെങ്കിൽ S3 പിശകുകൾ സ്റ്റൈലിസ്റ്റിക് ആകാം, തെറ്റായി ക്രമീകരിച്ച പിക്സൽ അല്ലെങ്കിൽ ഐക്കൺ പോലെ. ഇത് അത്ര പ്രധാനമല്ലെങ്കിലും, ഇത് ആരുടെയും വർക്ക്ഫ്ലോയെ കാര്യമായി ബാധിക്കുന്നില്ല, അതായത് അത്തരം S3 അല്ലെങ്കിൽ S4 പിശകുകൾക്ക് ഒരു പരിഹാരം സൃഷ്ടിക്കപ്പെടാനുള്ള സാധ്യത കുറവാണ്, മാരിൻ വിശദീകരിക്കുന്നു.

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

ഒരു S1 അല്ലെങ്കിൽ S2 ദുർബലതയ്ക്കുള്ള പരിഹാരം തയ്യാറായിക്കഴിഞ്ഞാൽ, റിലീസ് മാനേജർ പരിഹാരത്തിന്റെ റിലീസ് ട്രിഗർ ചെയ്യുന്നു.

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

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

ഒരു റിലീസ് മാനേജർ എങ്ങനെയാണ് പരിഹാരങ്ങൾ സൃഷ്ടിക്കുന്നത്

ഹോട്ട്ഫിക്സുകൾ സൃഷ്ടിക്കാൻ ഞങ്ങൾ GitLab CI-യും ഞങ്ങളുടെ ChatOps പോലുള്ള മറ്റ് സവിശേഷതകളും ഉപയോഗിക്കുന്നു. ഞങ്ങളുടെ ആന്തരിക ചാനലിൽ ChatOps ടീമിനെ സജീവമാക്കിക്കൊണ്ടാണ് റിലീസ് മാനേജർ ഹോട്ട്ഫിക്സ് റിലീസ് ആരംഭിക്കുന്നത്. #releases സ്ലാക്കിൽ.

/chatops run release prepare 12.10.1

സ്ലാക്കിൽ വിവിധ ഇവന്റുകൾ ട്രിഗർ ചെയ്യുന്നതിനായി ചാറ്റ്ഓപ്‌സ് പ്രവർത്തിക്കുന്നു, തുടർന്ന് അവ GitLab പ്രോസസ്സ് ചെയ്യുകയും നടപ്പിലാക്കുകയും ചെയ്യുന്നു. ഉദാഹരണത്തിന്, പാച്ച് റിലീസുകളുടെ വിവിധ വശങ്ങൾ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനായി ഡെലിവറി ടീം ചാറ്റ്ഓപ്‌സ് കോൺഫിഗർ ചെയ്‌തു.

റിലീസ് മാനേജർ സ്ലാക്കിൽ ഒരു ചാറ്റ്ഓപ്സ് കമാൻഡ് ആരംഭിച്ചുകഴിഞ്ഞാൽ, ബാക്കി ജോലികൾ CICD ഉപയോഗിച്ച് GitLab-ൽ യാന്ത്രികമായി നടക്കും. റിലീസ് പ്രക്രിയയിൽ, സ്ലാക്കിലെ ചാറ്റ്ഓപ്സും GitLab-ഉം തമ്മിൽ ടു-വേ ആശയവിനിമയം സംഭവിക്കുന്നു, കാരണം റിലീസ് മാനേജർ ചില പ്രധാന ഘട്ടങ്ങൾ ആരംഭിക്കുന്നു.

GitLab-നുള്ള ഒരു പരിഹാരം തയ്യാറാക്കുന്നതിനുള്ള സാങ്കേതിക പ്രക്രിയ താഴെയുള്ള വീഡിയോ കാണിക്കുന്നു.

gitlab.com-ന്റെ ഓട്ടോമേറ്റഡ് ഡിപ്ലോയ്‌മെന്റ് എങ്ങനെ പ്രവർത്തിക്കുന്നു

gitlab.com അപ്ഡേറ്റ് ചെയ്യാൻ ഉപയോഗിക്കുന്ന പ്രക്രിയയും ഉപകരണങ്ങളും പാച്ചിംഗിന് ഉപയോഗിക്കുന്നവയ്ക്ക് സമാനമാണ്. റിലീസ് മാനേജരുടെ വീക്ഷണകോണിൽ നിന്ന് നോക്കുമ്പോൾ gitlab.com അപ്ഡേറ്റ് ചെയ്യുന്നതിന് കുറഞ്ഞ മാനുവൽ ജോലി മാത്രമേ ആവശ്യമുള്ളൂ.

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

"അതിനാൽ gitlab.com ന് മുമ്പ് വ്യത്യസ്ത പരിതസ്ഥിതികളിൽ പ്രവർത്തിക്കുന്ന ധാരാളം വിന്യാസങ്ങൾ ഞങ്ങളുടെ പക്കലുണ്ട്, ആ പരിതസ്ഥിതികൾ നല്ല നിലയിലാകുകയും പരിശോധന നല്ല ഫലങ്ങൾ കാണിക്കുകയും ചെയ്തുകഴിഞ്ഞാൽ, റിലീസ് മാനേജർ gitlab.com വിന്യാസ പ്രവർത്തനങ്ങൾ ആരംഭിക്കുന്നു," മാരിൻ പറയുന്നു.

gitlab.com-ൽ റിലീസ് മാനേജർ പ്രൊഡക്ഷൻ എൻവയോൺമെന്റ് സ്വമേധയാ വിന്യാസം ആരംഭിക്കുന്നതുവരെ, gitlab.com അപ്‌ഡേറ്റുകളെ പിന്തുണയ്ക്കുന്നതിനുള്ള CICD സാങ്കേതികവിദ്യ മുഴുവൻ പ്രക്രിയയും ഓട്ടോമേറ്റ് ചെയ്യുന്നു.

താഴെയുള്ള വീഡിയോയിൽ, മാരിൻ gitlab.com അപ്‌ഡേറ്റ് പ്രക്രിയയെക്കുറിച്ച് വിശദമായി വിവരിക്കുന്നു.

ഡെലിവറി ടീം വേറെ എന്താണ് ചെയ്യുന്നത്?

gitlab.com അപ്‌ഡേറ്റ് പ്രക്രിയയും പരിസരത്തുള്ള ഉപഭോക്താക്കൾക്ക് പാച്ചുകൾ പുറത്തിറക്കുന്നതും തമ്മിലുള്ള പ്രധാന വ്യത്യാസം, രണ്ടാമത്തെ പ്രക്രിയയ്ക്ക് റിലീസ് മാനേജരിൽ നിന്ന് കൂടുതൽ സമയവും മാനുവൽ ജോലിയും ആവശ്യമാണ് എന്നതാണ്.

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

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

gitlab.com-നെ കുബേർനെറ്റ്സ് അധിഷ്ഠിത ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് മാറ്റുന്നതിലും ഡെലിവറി ടീം പ്രവർത്തിക്കുന്നു.

എഡിറ്റർ എൻ.ബിനിങ്ങൾ കുബേർനെറ്റസിനെക്കുറിച്ച് കേട്ടിട്ടുണ്ടെങ്കിൽ (എനിക്ക് ഉറപ്പുണ്ട്), പക്ഷേ ഇതുവരെ അത് പരീക്ഷിച്ചിട്ടില്ലെങ്കിൽ, ഓൺലൈൻ തീവ്രതകളിൽ പങ്കെടുക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു. കുബെർനെറ്റസ് ബേസ്സെപ്റ്റംബർ 28-30 തീയതികളിൽ നടക്കുന്ന, കൂടാതെ കുബെർനെറ്റസ് മെഗാഒക്ടോബർ 14–16 തീയതികളിൽ നടക്കും. ഇത് നിങ്ങളെ ആത്മവിശ്വാസത്തോടെ നാവിഗേറ്റ് ചെയ്യാനും സാങ്കേതികവിദ്യയുമായി പ്രവർത്തിക്കാനും അനുവദിക്കും.

ഇവ ഒരേ ലക്ഷ്യം പങ്കിടുന്ന രണ്ട് സമീപനങ്ങളാണ്: gitlab.com ലും സ്വന്തം സ്ഥലത്തെ ഉപഭോക്താക്കൾക്കും വേഗത്തിൽ അപ്‌ഡേറ്റുകൾ എത്തിക്കുക.

ഞങ്ങൾക്ക് എന്തെങ്കിലും ആശയങ്ങളോ ശുപാർശകളോ ഉണ്ടോ?

GitLab-ന്റെ വികസനത്തിന് ആർക്കും സംഭാവന നൽകാം, ഞങ്ങളുടെ വായനക്കാരുടെ ഫീഡ്‌ബാക്ക് ഞങ്ങൾ സ്വാഗതം ചെയ്യുന്നു. ഞങ്ങളുടെ ഡെലിവറി ടീമിനായി നിങ്ങൾക്ക് ആശയങ്ങൾ ഉണ്ടെങ്കിൽ, ദയവായി അവ പങ്കിടാൻ മടിക്കരുത്. ഒരു അഭ്യർത്ഥന സൃഷ്ടിക്കുക നോട്ടീസ് സഹിതം team: Delivery.

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