ഉപഭോക്താവിന്റെ പ്ലാറ്റ്‌ഫോമിൽ ഞങ്ങളുടെ തുടർച്ചയായ വിന്യാസം നടപ്പിലാക്കുന്നു

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

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

ഈ ലേഖനത്തിൽ ഞങ്ങൾ തുടർച്ചയായ വിന്യാസത്തിന്റെ (സിഡി) പ്രക്രിയയുടെ എല്ലാ ഘട്ടങ്ങളെക്കുറിച്ചോ അല്ലെങ്കിൽ ഉപഭോക്താവിന്റെ പ്ലാറ്റ്‌ഫോമിലേക്കുള്ള അപ്‌ഡേറ്റുകളുടെ ഡെലിവറിയെക്കുറിച്ചോ സംസാരിക്കും:

1. ഈ പ്രക്രിയ എങ്ങനെയാണ് ആരംഭിക്കുന്നത്?
2. ഉപഭോക്താവിന്റെ Git ശേഖരവുമായുള്ള സമന്വയം,
3. ബാക്കെൻഡിന്റെയും മുൻഭാഗത്തിന്റെയും അസംബ്ലി,
4. ഒരു പരീക്ഷണ പരിതസ്ഥിതിയിൽ യാന്ത്രിക ആപ്ലിക്കേഷൻ വിന്യാസം,
5. ഉൽപ്പന്നത്തിലേക്കുള്ള യാന്ത്രിക വിന്യാസം.

ഞങ്ങൾ സജ്ജീകരണ വിശദാംശങ്ങൾ വഴിയിൽ പങ്കിടും.

1. സിഡി ആരംഭിക്കുക

ഞങ്ങളുടെ Git റിപ്പോസിറ്ററിയുടെ റിലീസ് ബ്രാഞ്ചിലേക്ക് ഡവലപ്പർ മാറ്റങ്ങൾ വരുത്തിക്കൊണ്ട് തുടർച്ചയായ വിന്യാസം ആരംഭിക്കുന്നു.

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

നിരവധി കാരണങ്ങളാൽ ഞങ്ങൾ ഒരു ശേഖരത്തിലൂടെ ജോലി സംഘടിപ്പിച്ചു:

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

2. ഉപഭോക്താവിന്റെ സോഴ്സ് കോഡിന്റെ Git റിപ്പോസിറ്ററിയുമായി സിൻക്രൊണൈസേഷൻ

വരുത്തിയ മാറ്റങ്ങൾ ഉപഭോക്താവിന്റെ Git റിപ്പോസിറ്ററിയുമായി സ്വയമേവ സമന്വയിപ്പിക്കപ്പെടുന്നു. അവിടെ ആപ്ലിക്കേഷൻ അസംബ്ലി കോൺഫിഗർ ചെയ്‌തു, അത് ബ്രാഞ്ച് അപ്‌ഡേറ്റ് ചെയ്‌തതിന് ശേഷം സമാരംഭിക്കുകയും തുടർച്ചയിലേക്കുള്ള വിന്യാസം നടത്തുകയും ചെയ്യുന്നു. രണ്ട് പ്രക്രിയകളും അവയുടെ പരിതസ്ഥിതിയിൽ ഒരു Git ശേഖരത്തിൽ നിന്നാണ് ഉത്ഭവിക്കുന്നത്.

ഞങ്ങൾക്ക് ഉപഭോക്താവിന്റെ ശേഖരവുമായി നേരിട്ട് പ്രവർത്തിക്കാൻ കഴിയില്ല, കാരണം വികസനത്തിനും പരിശോധനയ്ക്കും ഞങ്ങളുടെ സ്വന്തം പരിതസ്ഥിതികൾ ആവശ്യമാണ്. ഈ ആവശ്യങ്ങൾക്കായി ഞങ്ങൾ ഞങ്ങളുടെ Git റിപ്പോസിറ്ററി ഉപയോഗിക്കുന്നു - അത് അവരുടെ Git റിപ്പോസിറ്ററിയുമായി സമന്വയിപ്പിച്ചിരിക്കുന്നു. ഞങ്ങളുടെ ശേഖരണത്തിന്റെ ഉചിതമായ ശാഖയിലേക്ക് ഒരു ഡെവലപ്പർ പോസ്‌റ്റ് ചെയ്‌താൽ, GitLab ഉടൻ തന്നെ ഈ മാറ്റങ്ങൾ ഉപഭോക്താവിലേക്ക് എത്തിക്കുന്നു.

ഇതിനുശേഷം നിങ്ങൾ അസംബ്ലി നടത്തേണ്ടതുണ്ട്. ഇത് നിരവധി ഘട്ടങ്ങൾ ഉൾക്കൊള്ളുന്നു: ബാക്കെൻഡ്, ഫ്രണ്ട്എൻഡ് അസംബ്ലി, ടെസ്റ്റിംഗ്, പ്രൊഡക്ഷനിലേക്കുള്ള ഡെലിവറി.

3. ബാക്കെൻഡും ഫ്രണ്ട്‌എൻഡും കൂട്ടിച്ചേർക്കുന്നു

GitLab റണ്ണർ സിസ്റ്റത്തിൽ നിർവ്വഹിക്കുന്ന രണ്ട് സമാന്തര ജോലികളാണ് ബാക്കെൻഡും ഫ്രണ്ട്‌എൻഡും നിർമ്മിക്കുന്നത്. അതിന്റെ യഥാർത്ഥ അസംബ്ലി കോൺഫിഗറേഷൻ അതേ ശേഖരത്തിലാണ് സ്ഥിതി ചെയ്യുന്നത്.

GitLab-ൽ നിർമ്മിക്കുന്നതിനായി YAML സ്ക്രിപ്റ്റ് എഴുതുന്നതിനുള്ള ട്യൂട്ടോറിയൽ.

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

ഡോക്കറിൽ പ്രസിദ്ധീകരിക്കുന്ന റിലീസ് പതിപ്പുമായി ഞങ്ങളുടെ ചിത്രങ്ങളുടെ പതിപ്പുകൾ ഞങ്ങൾ സമന്വയിപ്പിക്കുന്നു. സുഗമമായ പ്രവർത്തനത്തിനായി ഞങ്ങൾ നിരവധി ക്രമീകരണങ്ങൾ വരുത്തിയിട്ടുണ്ട്:

1. ടെസ്റ്റ് പരിതസ്ഥിതിക്കും ഉൽപ്പാദന അന്തരീക്ഷത്തിനും ഇടയിൽ കണ്ടെയ്നറുകൾ പുനർനിർമ്മിക്കുന്നില്ല. ഞങ്ങൾ പാരാമീട്രൈസേഷനുകൾ ഉണ്ടാക്കിയതിനാൽ, ഒരേ കണ്ടെയ്‌നറിന് എല്ലാ ക്രമീകരണങ്ങളിലും പരിസ്ഥിതി വേരിയബിളുകളിലും സേവനങ്ങളിലും പരീക്ഷണ പരിതസ്ഥിതിയിലും ഉൽപ്പാദനത്തിലും പുനർനിർമ്മിക്കാതെ പ്രവർത്തിക്കാനാകും.

2. ഹെൽം വഴി ഒരു ആപ്ലിക്കേഷൻ അപ്ഡേറ്റ് ചെയ്യുന്നതിന്, നിങ്ങൾ അതിന്റെ പതിപ്പ് വ്യക്തമാക്കണം. ഞങ്ങൾ ബാക്കെൻഡ്, ഫ്രണ്ട്‌എൻഡ്, ആപ്ലിക്കേഷൻ അപ്‌ഡേറ്റ് എന്നിവ നിർമ്മിക്കുന്നു - ഇവ മൂന്ന് വ്യത്യസ്ത ജോലികളാണ്, അതിനാൽ എല്ലായിടത്തും ആപ്ലിക്കേഷന്റെ ഒരേ പതിപ്പ് ഉപയോഗിക്കുന്നത് പ്രധാനമാണ്. ഈ ടാസ്ക്കിനായി, ഞങ്ങളുടെ K8S ക്ലസ്റ്റർ കോൺഫിഗറേഷനും ആപ്ലിക്കേഷനുകളും ഒരേ Git റിപ്പോസിറ്ററിയിലായതിനാൽ Git ചരിത്രത്തിൽ നിന്നുള്ള ഡാറ്റ ഞങ്ങൾ ഉപയോഗിക്കുന്നു.

കമാൻഡ് എക്സിക്യൂഷൻ ഫലങ്ങളിൽ നിന്ന് നമുക്ക് ആപ്ലിക്കേഷൻ പതിപ്പ് ലഭിക്കും
git describe --tags --abbrev=7.

4. ടെസ്റ്റ് എൻവയോൺമെന്റിലേക്കുള്ള (UAT) എല്ലാ മാറ്റങ്ങളുടെയും യാന്ത്രിക വിന്യാസം

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

ക്ലസ്റ്റർ അപ്ഡേറ്റ് ഉപയോഗിച്ചു തുടങ്ങിയിരിക്കുന്നു ഹെൽം അപ്ഡേറ്റ്. തൽഫലമായി, എന്തെങ്കിലും പ്ലാൻ അനുസരിച്ച് നടന്നില്ലെങ്കിൽ, ഹെൽം അതിന്റെ എല്ലാ മാറ്റങ്ങളും സ്വയമേവ സ്വതന്ത്രമായി പിൻവലിക്കും. അവന്റെ ജോലി നിയന്ത്രിക്കേണ്ട ആവശ്യമില്ല.

അസംബ്ലിയ്‌ക്കൊപ്പം ഞങ്ങൾ K8S ക്ലസ്റ്റർ കോൺഫിഗറേഷനും നൽകുന്നു. അതിനാൽ, അടുത്ത ഘട്ടം ഇത് അപ്‌ഡേറ്റ് ചെയ്യുകയാണ്: കോൺഫിഗറേഷൻ മാപ്പുകൾ, വിന്യാസങ്ങൾ, സേവനങ്ങൾ, രഹസ്യങ്ങൾ, ഞങ്ങൾ മാറ്റിയ മറ്റേതെങ്കിലും കെ8എസ് കോൺഫിഗറേഷനുകൾ.

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

5. ഉൽപ്പന്നത്തിലേക്കുള്ള എല്ലാ മാറ്റങ്ങളുടെയും യാന്ത്രിക വിന്യാസം

പ്രൊഡക്ഷൻ എൻവയോൺമെന്റിലേക്ക് ഒരു അപ്‌ഡേറ്റ് വിന്യസിക്കാൻ, നിങ്ങൾ GitLab-ലെ ഒരു ബട്ടണിൽ ക്ലിക്ക് ചെയ്താൽ മതി - കണ്ടെയ്‌നറുകൾ ഉടനടി പ്രൊഡക്ഷൻ എൻവയോൺമെന്റിലേക്ക് ഡെലിവർ ചെയ്യപ്പെടും.

ഒരേ ആപ്ലിക്കേഷന് പുനർനിർമ്മാണം കൂടാതെ വ്യത്യസ്ത പരിതസ്ഥിതികളിൽ-ടെസ്റ്റിലും പ്രൊഡക്ഷനിലും പ്രവർത്തിക്കാനാകും. ആപ്ലിക്കേഷനിൽ ഒന്നും മാറ്റാതെ ഞങ്ങൾ ഒരേ പുരാവസ്തുക്കൾ ഉപയോഗിക്കുന്നു, കൂടാതെ ഞങ്ങൾ പരാമീറ്ററുകൾ ബാഹ്യമായി സജ്ജമാക്കുകയും ചെയ്യുന്നു.

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

പരിസ്ഥിതിയെ ആശ്രയിക്കുന്ന എല്ലാ ഉപയോഗിച്ച സേവനങ്ങളും വേരിയബിളുകളും പാരാമീറ്റർ ചെയ്യുകയും ഹെൽമിനായുള്ള എൻവയോൺമെന്റ് പാരാമീറ്ററുകളുടെ വിവരണ-കോൺഫിഗറേഷനുകളിലേക്കും അവയെ വിവർത്തനം ചെയ്യുക എന്നതായിരുന്നു ഏറ്റവും ബുദ്ധിമുട്ടുള്ള കാര്യം.

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

APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}

.Values.global.env - ഈ വേരിയബിൾ പരിസ്ഥിതിയുടെ പേര് (പ്രൊഡ്, സ്റ്റേജ്, യുഎടി) സംഭരിക്കുന്നു.
.Values.app.properties.app_external_domain – ഈ വേരിയബിളിൽ നമ്മൾ .Values.yaml ഫയലിൽ ആവശ്യമുള്ള ഡൊമെയ്ൻ സജ്ജമാക്കുന്നു

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

താരതമ്യേന അടുത്തിടെ, കോൺഫിഗറേഷൻ മാപ്പുകളിൽ പ്രവർത്തിക്കുന്നത് ഉൾപ്പെടെ സ്പ്രിംഗ് ക്ലൗഡിൽ K8S പിന്തുണ പ്രത്യക്ഷപ്പെട്ടു: സ്പ്രിംഗ് ക്ലൗഡ് കുബെർനെറ്റസ്. പ്രോജക്റ്റ് സജീവമായി വികസിപ്പിക്കുകയും സമൂലമായി മാറുകയും ചെയ്യുമ്പോൾ, ഞങ്ങൾക്ക് അത് ഉൽപാദനത്തിൽ ഉപയോഗിക്കാൻ കഴിയില്ല. എന്നാൽ ഞങ്ങൾ അതിന്റെ അവസ്ഥ സജീവമായി നിരീക്ഷിക്കുകയും DEV കോൺഫിഗറേഷനുകളിൽ ഉപയോഗിക്കുകയും ചെയ്യുന്നു. അത് സ്ഥിരത കൈവരിക്കുമ്പോൾ, പരിസ്ഥിതി വേരിയബിളുകൾ ഉപയോഗിക്കുന്നതിൽ നിന്ന് ഞങ്ങൾ അതിലേക്ക് മാറും.

ആകെ

അതിനാൽ, തുടർച്ചയായ വിന്യാസം ക്രമീകരിച്ച് പ്രവർത്തിക്കുന്നു. എല്ലാ അപ്‌ഡേറ്റുകളും ഒരു കീസ്ട്രോക്ക് ഉപയോഗിച്ചാണ് സംഭവിക്കുന്നത്. ഉൽപ്പന്ന പരിതസ്ഥിതിയിൽ മാറ്റങ്ങൾ വരുത്തുന്നത് യാന്ത്രികമാണ്. കൂടാതെ, പ്രധാനമായി, അപ്‌ഡേറ്റുകൾ സിസ്റ്റത്തെ തടയുന്നില്ല.

ഭാവി പദ്ധതികൾ: ഓട്ടോമാറ്റിക് ഡാറ്റാബേസ് മൈഗ്രേഷൻ

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

അതിനാൽ, നമുക്ക് കോളത്തിന്റെ പേരോ മറ്റ് ഡാറ്റയോ മാറ്റാൻ കഴിയില്ല. എന്നാൽ നമുക്ക് ഒരു പുതിയ കോളം സൃഷ്‌ടിക്കാനും പഴയ കോളത്തിൽ നിന്ന് ഡാറ്റ അതിലേക്ക് പകർത്താനും ട്രിഗറുകൾ എഴുതാനും കഴിയും, ഡാറ്റ അപ്‌ഡേറ്റ് ചെയ്യുമ്പോൾ, അത് ഒരേസമയം മറ്റൊരു കോളത്തിൽ പകർത്തി അപ്‌ഡേറ്റ് ചെയ്യും. ആപ്ലിക്കേഷന്റെ പുതിയ പതിപ്പ് വിജയകരമായി വിന്യസിച്ചതിന് ശേഷം, ലോഞ്ച് സപ്പോർട്ട് കാലയളവിന് ശേഷം, ഞങ്ങൾക്ക് പഴയ കോളവും അനാവശ്യമായ ട്രിഗറും ഇല്ലാതാക്കാൻ കഴിയും.

ആപ്ലിക്കേഷന്റെ പുതിയ പതിപ്പ് ശരിയായി പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, ഡാറ്റാബേസിന്റെ മുൻ പതിപ്പ് ഉൾപ്പെടെ, ഞങ്ങൾക്ക് മുമ്പത്തെ പതിപ്പിലേക്ക് മടങ്ങാം. ചുരുക്കത്തിൽ, ആപ്ലിക്കേഷന്റെ നിരവധി പതിപ്പുകൾക്കൊപ്പം ഒരേസമയം പ്രവർത്തിക്കാൻ ഞങ്ങളുടെ മാറ്റങ്ങൾ നിങ്ങളെ അനുവദിക്കും.

K8S ജോബ് വഴി ഡാറ്റാബേസ് മൈഗ്രേഷൻ ഓട്ടോമേറ്റ് ചെയ്യാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു, അത് CD പ്രോസസ്സിലേക്ക് സംയോജിപ്പിക്കുന്നു. ഞങ്ങൾ തീർച്ചയായും ഈ അനുഭവം ഹബ്രെയിൽ പങ്കിടും.

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