𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗙𝗮𝗯𝗿𝗶𝗰 𝗖𝗜/𝗖𝗗: 𝗧𝗵𝗲 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗚𝗮𝗽

നിങ്ങളുടെ ഡിപ്ലോയ്മെന്റ് വിജയകരമായി പൂർത്തിയാകുന്നു. നിങ്ങളുടെ Azure DevOps പൈപ്പ്‌ലൈൻ പാസായി. പ്രൊഡക്ഷൻ വർക്ക്‌സ്‌പേസ് തികച്ചും കൃത്യമായി കാണപ്പെടുന്നു.

എന്നാൽ തിങ്കളാഴ്ച രാവിലെ ആ പ്രശ്നം വരുന്നു.

സെമാന്റിക് മോഡൽ റിഫ്രഷ് പരാജയപ്പെടുന്നു. Lakehouse പാർട്ടീഷനുകൾ തകരാറിലാകുന്നു. ഓരോ ഉപയോക്താവിനും റിപ്പോർട്ടുകൾ ടൈം ഔട്ട് ആകുന്നു.

മിക്ക ട്യൂട്ടോറിയലുകളും അവഗണിക്കുന്ന Microsoft Fabric CI/CD-യുടെ ഒരു വശമാണിത്.

മിക്ക ഇംഗ്ലീഷ് റിസോഴ്‌സുകളും ഒരു "hello world" സെറ്റപ്പ് മാത്രമാണ് കാണിക്കുന്നത്. ഐറ്റങ്ങൾ എങ്ങനെ സിങ്ക് ചെയ്യാം എന്ന് അവ കാണിച്ചുതരുന്നു. എന്നാൽ ഒരു യഥാർത്ഥ പ്രൊഡക്ഷൻ എൻവയോൺമെന്റ് എങ്ങനെ പ്രവർത്തിപ്പിക്കാം എന്ന് അവ കാണിച്ചുതരുന്നില്ല.

Qiita-യിലെ ജാപ്പനീസ് ഡെവലപ്പർ കമ്മ്യൂണിറ്റിയുടെ ഡോക്യുമെന്റേഷൻ ഞാൻ പഠിച്ചു. പ്രൊഡക്ഷൻ റെഡി ആയ Fabric ഡിപ്ലോയ്മെന്റുകളിലെ യഥാർത്ഥ പ്രശ്നങ്ങൾ അവർ കണ്ടെത്തിയിട്ടുണ്ട്.

Fabric എല്ലാറ്റിനെയും ഐറ്റങ്ങൾ (items) ആയിട്ടാണ് പരിഗണിക്കുന്നത്. ഇതിൽ semantic models, lakehouses, pipelines, reports, notebooks എന്നിവ ഉൾപ്പെടുന്നു. ഈ ഐറ്റങ്ങളെ കോഡ് ആയി പരിഗണിക്കുക എന്നതാണ് ഇതിന്റെ ലക്ഷ്യം.

സാധാരണ വർക്ക്ഫ്ലോ ഇപ്രകാരമാണ്:

  • Source control: നിങ്ങളുടെ റെപ്പോയിൽ (repo) ഐറ്റങ്ങളെ JSON ഡെഫനിഷനുകളായി എക്‌സ്‌പോർട്ട് ചെയ്യുക.
  • Build stage: കോൺഫിഗറേഷനുകളും ഡിപെൻഡൻസികളും പരിശോധിക്കുക (Validate).
  • Release stage: എൻവയോൺമെന്റ് പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് ടാർഗെറ്റ് വർക്ക്‌സ്‌പേസുകളിലേക്ക് ഡിപ്ലോയ് ചെയ്യുക.

എന്നാൽ ഈ ലളിതമായ വർക്ക്ഫ്ലോ വലിയ തോതിലുള്ള ഉപയോഗങ്ങളിൽ (at scale) പരാജയപ്പെടുന്നു. അതിന്റെ കാരണങ്ങൾ താഴെ പറയുന്നവയാണ്:

  1. ഡിപെൻഡൻസി പിശകുകൾ (Dependency errors) ഐറ്റങ്ങൾ ഏത് ക്രമത്തിലും ഡിപ്ലോയ് ചെയ്യാമെന്ന് ട്യൂട്ടോറിയലുകൾ പറയുന്നു. ഇത് തെറ്റാണ്. ഒരു semantic model ഒരു lakehouse-നെ ആശ്രയിച്ചിരിക്കുന്നു. Lakehouse അപ്‌ഡേറ്റ് ചെയ്യുന്നതിന് മുമ്പ് നിങ്ങൾ മോഡൽ ഡിപ്ലോയ് ചെയ്താൽ, റിഫ്രഷ് പരാജയപ്പെടും.

  2. API പരിധികൾ (API limits) എല്ലാത്തിനും ഒരു പൈപ്പ്‌ലൈൻ മതി എന്ന് ട്യൂട്ടോറിയലുകൾ നിർദ്ദേശിക്കുന്നു. വലിയ വർക്ക്‌സ്‌പേസുകളിൽ ഒരേസമയം ഡിപ്ലോയ്മെന്റുകൾ നടക്കുമ്പോൾ Fabric API റേറ്റ് ലിമിറ്റുകൾ (rate limits) നേരിടേണ്ടി വരും. പ്രക്രിയയുടെ വേഗത കുറയ്ക്കുന്നതിനുള്ള ലോജിക് നിങ്ങൾക്ക് ആവശ്യമാണ്.

  3. കപ്പാസിറ്റി വ്യത്യാസങ്ങൾ (Capacity differences) ഒരു മോഡൽ ടെസ്റ്റ് എൻവയോൺമെന്റിൽ പ്രവർത്തിച്ചേക്കാം, എന്നാൽ പ്രൊഡക്ഷനിൽ പരാജയപ്പെട്ടേക്കാം. പ്രൊഡക്ഷൻ വർക്ക്‌സ്‌പേസുകൾ പലപ്പോഴും വ്യത്യസ്ത കപ്പാസിറ്റി ടയറുകളും (capacity tiers) ഫീച്ചർ നിയന്ത്രണങ്ങളും కలిగిയിരിക്കും.

ഒരു ട്യൂട്ടോറിയലിൽ നിന്ന് യഥാർത്ഥ പ്രൊഡക്ഷൻ സെറ്റപ്പിലേക്ക് മാറാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഈ നിയമങ്ങൾ പാലിക്കുക:

  • സീക്വൻഷ്യൽ ഡിപ്ലോയ്മെന്റ് (Sequential deployment) ഉപയോഗിക്കുക. ഐറ്റങ്ങളുടെ ഡിപെൻഡൻസികൾ അടിസ്ഥാനമാക്കി അവയുടെ ക്രമം നിശ്ചയിക്കുക.
  • വർക്ക്‌സ്‌പേസ് ലോക്കിംഗ് (Workspace locking) നടപ്പിലാക്കുക. രണ്ട് പൈപ്പ്‌ലൈനുകൾ ഒരേസമയം പ്രവർത്തിക്കുന്നത് തടയുക. ഇത് വർക്ക്‌സ്‌പേസ് കറപ്ഷൻ ഒഴിവാക്കാൻ സഹായിക്കും.
  • ഒരു ബാക്കപ്പ് വർക്ക്‌സ്‌പേസ് സൂക്ഷിക്കുക. ഡിപ്ലോയ്മെന്റ് പരാജയപ്പെട്ടാൽ റോളബാക്ക് (rollback) ചെയ്യാൻ ഇത് ഉപയോഗിക്കുക.
  • കപ്പാസിറ്റി അറിവുള്ള പാരാമീറ്ററുകൾ (capacity-aware parameters) ഉപയോഗിക്കുക. നിങ്ങളുടെ യഥാർത്ഥ പ്രൊഡക്ഷൻ കപ്പാസിറ്റിയുമായി നിങ്ങളുടെ സെറ്റിംഗുകൾ പരീക്ഷിച്ചു നോക്കുക.

ആവശ്യമായ ടൂളുകൾ ലഭ്യമാണ്. ഈ രീതി ഫലപ്രദവുമാണ്. ട്യൂട്ടോറിയലുകൾ ഒഴിവാക്കുന്ന പരാജയങ്ങൾക്കായി നിങ്ങൾ തയ്യാറെടുക്കുക മാത്രം ചെയ്താൽ മതി.

ട്യൂട്ടോറിയലുകളിൽ സൂചിപ്പിക്കാത്ത ഡിപ്ലോയ്മെന്റ് പരാജയങ്ങൾ നിങ്ങളുടെ ടീം നേരിട്ടിട്ടുണ്ടോ? ഒരു പ്രൊഡക്ഷൻ ചെക്ക്‌ലിസ്റ്റിൽ വേറെ എന്തൊക്കെ ഉൾപ്പെടുത്തണം?

Source: https://dev.to/xu_xu_b2179aa8fc958d531d1/microsoft-fabric-cicd-the-deployment-gap-nobody-talks-about-2b44

Optional learning community: https://t.me/GyaanSetuAi