𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗙𝗮𝗯𝗿𝗶𝗰 𝗖𝗜/𝗖𝗗: 𝗧𝗵𝗲 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗚𝗮𝗽
உங்கள் deployment வெற்றிகரமாக முடிகிறது. உங்கள் Azure DevOps pipeline தேர்ச்சி பெறுகிறது. Production workspace பார்க்க மிகச்சரியாகத் தெரிகிறது.
பிறகு திங்கட்கிழமை காலை வருகிறது.
Semantic model refresh தோல்வியடைகிறது. Lakehouse partitions உடைந்துள்ளன. ஒவ்வொரு பயனருக்கும் reports timeout ஆகின்றன.
இதுதான் பெரும்பாலான பயிற்சிகள் (tutorials) புறக்கணிக்கும் Microsoft Fabric CI/CD-ன் ஒரு பக்கம்.
பெரும்பாலான ஆங்கில ஆதாரங்கள் ஒரு "hello world" அமைப்பைக் காட்டுகின்றன. அவை உருப்படிகளை (items) எவ்வாறு sync செய்வது என்பதைக் காட்டுகின்றன. ஆனால் ஒரு உண்மையான production environment-ஐ எவ்வாறு இயக்குவது என்பதைக் காட்டுவதில்லை.
நான் Qiita தளத்தில் உள்ள ஜப்பானிய டெவலப்பர் சமூகத்தின் ஆவணங்களைப் படித்தேன். Production-ready Fabric deployments-ல் உள்ள உண்மையான சிக்கல்களை அவர்கள் கண்டறிந்துள்ளனர்.
Fabric அனைத்தையும் 'items' ஆகக் கருதுகிறது. இதில் semantic models, lakehouses, pipelines, reports மற்றும் notebooks ஆகியவை அடங்கும். இந்த items-களை code ஆகக் கருதுவதே இதன் இலக்காகும்.
நிலையான workflow இவ்வாறு அமையும்:
- Source control: உங்கள் repo-வில் items-களை JSON definitions ஆக export செய்யவும்.
- Build stage: Configurations மற்றும் dependencies-களைச் சரிபார்க்கவும் (validate).
- Release stage: Environment parameters பயன்படுத்தி target workspaces-க்கு deploy செய்யவும்.
ஆனால் இந்த எளிய workflow பெரிய அளவில் (at scale) தோல்வியடைகிறது. அதற்கான காரணங்கள் இதோ:
Dependency பிழைகள் உருப்படிகளை எந்த வரிசையிலும் deploy செய்யலாம் என்று பயிற்சிகள் கூறுகின்றன. இது தவறு. ஒரு semantic model, ஒரு lakehouse-ஐச் சார்ந்துள்ளது. Lakehouse புதுப்பிக்கப்படுவதற்கு முன்பே நீங்கள் model-ஐ deploy செய்தால், refresh தோல்வியடையும்.
API வரம்புகள் (limits) அனைத்திற்கும் ஒரு pipeline போதுமானது என்று பயிற்சிகள் பரிந்துரைக்கின்றன. பெரிய workspaces, ஒரே நேரத்தில் நடக்கும் deployments-ன் போது Fabric API rate limits-ஐ எட்டுகின்றன. இந்தச் செயல்முறையை மெதுவாக்கத் தேவையான logic உங்களுக்குத் தேவை.
Capacity வேறுபாடுகள் ஒரு model test environment-ல் வேலை செய்யலாம், ஆனால் production-ல் தோல்வியடையலாம். Production workspaces பெரும்பாலும் வெவ்வேறு capacity tiers மற்றும் feature கட்டுப்பாடுகளைக் கொண்டிருக்கும்.
நீங்கள் ஒரு பயிற்சியிலிருந்து (tutorial) உண்மையான production setup-க்கு மாற விரும்பினால், இந்த விதிகளைப் பின்பற்றுங்கள்:
- Sequential deployment-ஐப் பயன்படுத்தவும். அவற்றின் dependencies-ன் அடிப்படையில் items-களின் வரிசையை வரையறுக்கவும்.
- Workspace locking-ஐச் செயல்படுத்தவும். இரண்டு pipelines ஒரே நேரத்தில் இயங்குவதைத் தடுக்கவும். இது workspace corruption-ஐத் தடுக்கும்.
- ஒரு backup workspace-ஐ வைத்திருக்கவும். Deployment தோல்வியடைந்தால் அதை rollback target ஆகப் பயன்படுத்தவும்.
- Capacity-aware parameters-களைப் பயன்படுத்தவும். உங்கள் settings-களை உண்மையான production capacity-க்கு எதிராகச் சோதிக்கவும்.
கருவிகள் உள்ளன. இந்த முறை (pattern) வேலை செய்கிறது. பயிற்சிகள் விடுபடும் தோல்விகளுக்கு நீங்கள் தயாராக இருந்தால் போதும்.
பயிற்சிகளில் குறிப்பிடப்படாத deployment தோல்விகளை உங்கள் குழு எதிர்கொண்டிருக்கிறதா? ஒரு production checklist-ல் வேறு என்ன இருக்க வேண்டும்?
Microsoft Fabric CI/CD: யாரும் பேசாத அந்த Deployment இடைவெளி
Microsoft Fabric என்பது தரவுப் பொறியியல் (data engineering), தரவு அறிவியல் (data science) மற்றும் பகுப்பாய்வு (analytics) ஆகியவற்றிற்கான ஒரு சக்திவாய்ந்த தளமாகும். இது ஒரு ஒருங்கிணைந்த அனுபவத்தை (unified experience) வழங்குகிறது. ஆனால், நிறுவனங்கள் ஒரு முன்னோட்டத் திட்டத்திலிருந்து (pilot) உற்பத்தி நிலைக்கு (production) மாறும்போது, ஒரு முக்கியமான கேள்வி எழுகிறது: Fabric-இல் CI/CD (Continuous Integration/Continuous Deployment) வாழ்க்கைச் சுழற்சி எவ்வளவு வலுவானது?
Git ஒருங்கிணைப்பின் தற்போதைய நிலை
Git ஒருங்கிணைப்பை அறிமுகப்படுத்துவதன் மூலம் Microsoft குறிப்பிடத்தக்க முன்னேற்றங்களைச் செய்துள்ளது. இது டெவலப்பர்கள் தங்கள் Fabric workspaces-களை Azure DevOps அல்லது GitHub repository-உடன் இணைக்க அனுமதிக்கிறது. இது பதிப்பு கட்டுப்பாட்டை (version control) சாத்தியமாக்குகிறது, இது நவீன மென்பொருள் மேம்பாட்டு வாழ்க்கைச் சுழற்சியின் அடிப்படைத் தேவையாகும்.
இருப்பினும், Fabric-இல் உள்ள Git ஒருங்கிணைப்பு என்பது "set it and forget it" (அமைத்துவிட்டு மறந்துவிடலாம்) போன்ற ஒரு தீர்வு அல்ல. இது முதன்மையாக Fabric items-களின் metadata-வை repository-க்குத் தயார் செய்து அனுப்புவதில் கவனம் செலுத்துகிறது. இது ஒரு பெரிய முன்னேற்றம் என்றாலும், இது முழுமையான deployment புதிரைத் தீர்க்கவில்லை.
Deployment Pipeline சிக்கல்கள்
மேம்பாடு (development) மற்றும் உற்பத்தி (production) ஆகியவற்றுக்கு இடையிலான இடைவெளியைக் குறைக்க, Microsoft Deployment Pipelines-ஐ அறிமுகப்படுத்தியது. இந்த pipelines மூலம் நீங்கள் ஒரு workspace-லிருந்து மற்றொரு workspace-க்கு (உதாரணமாக, Development -> Test -> Production ஆகிய நிலைகள் வழியாக) உள்ளடக்கத்தை நகர்த்த முடியும்.
ஆனால், இங்கிருந்துதான் அந்த "இடைவெளி" (gap) தெரியத் தொடங்குகிறது.
1. வரையறுக்கப்பட்ட Item ஆதரவு (Limited Item Support)
Microsoft Fabric-இல் உள்ள அனைத்து items-களும் தற்போது Deployment Pipelines மூலம் ஆதரிக்கப்படுவதில்லை. உங்கள் தீர்வு ஆதரிக்கப்படாத குறிப்பிட்ட items-களை பெரிதும் நம்பியிருந்தால், உங்கள் தானியங்கி pipeline செயலிழந்துவிடும். இது டெவலப்பர்களை மீண்டும் கைமுறை (manual) deployment செயல்முறைகளுக்குத் தள்ளுகிறது.
2. சார்புநிலை சிக்கல்கள் (The Dependency Nightmare)
ஒரு சிக்கலான தரவுச் சூழலில் (data ecosystem), items பெரும்பாலும் தனித்து இருப்பதில்லை. ஒரு Notebook ஒரு குறிப்பிட்ட Lakehouse-ஐச் சார்ந்திருக்கலாம், அது மீண்டும் ஒரு குறிப்பிட்ட Data Factory pipeline-ஐச் சார்ந்திருக்கலாம். ஒரு item-ஐ அதன் சார்புநிலைகளுடன் (dependencies) நகர்த்தாமல் அல்லது தவறான வரிசையில் நகர்த்தும்போது, சூழல்கள் (environments) உடைந்து போகக்கூடும். Fabric-இன் தற்போதைய deployment வழிமுறைகள் இத்தகைய சிக்கலான சார்புநிலைகளைத் தடையின்றி கையாள்வதில் சிரமப்படுகின்றன.
3. கட்டமைப்பு மேலாண்மை (Configuration Management)
ஒவ்வொரு சூழலுக்கும் (Dev, Test, Prod) வழக்கமாக வெவ்வேறு கட்டமைப்புகள் தேவைப்படும்—வெவ்வேறு connection strings, வெவ்வேறு storage paths அல்லது வெவ்வேறு பாதுகாப்பு அமைப்புகள். ஒரு deployment-இன் போது இந்த சூழல் சார்ந்த அளவுருக்களை (environment-specific parameters) நிர்வகிப்பது Fabric-இல் இன்னும் ஒரு கைமுறை அல்லது பகுதி-தானியங்கி (semi-automated) தலைவலியாகவே உள்ளது.
இடைவெளி: தானியங்கி முறை எங்கு முடிகிறது?
"Deployment Gap" என்பது உங்கள் குறியீடு (code) Git-இல் இருப்பதற்கும், அது உற்பத்தியில் (Production) சரியாக இயங்குவதற்கும் இடைப்பட்ட இடமாகும்.
தற்போதைய பணிப்பாய்வு (workflow) இவ்வாறு உள்ளது:
- Workspace A-இல் மேம்பாடு செய்தல்.
- Git-இல் commit செய்தல்.
- மற்றொரு branch/workspace-க்கு இழுத்தல் (pull).
- Test/Prod நிலைகளுக்கு நகர்த்த Deployment Pipelines-ஐப் பயன்படுத்துதல்.
- இடைவெளி: உடைந்த சார்புநிலைகளைச் சரிசெய்தல், connection strings-களைப் புதுப்பித்தல் மற்றும் அனைத்தும் எதிர்பார்த்தபடி செயல்படுகிறதா என்பதைச் சரிபார்த்தல் போன்ற கைமுறை வேலைகள்.
இந்த கைமுறைத் தலையீடு "Continuous Deployment"-இன் நோக்கத்தையே சிதைக்கிறது.
இந்த இடைவெளியை எவ்வாறு கையாள்வது?
Microsoft இந்த இடைவெளியை மூடும் வரை, பொறியாளர்கள் முன்கூட்டியே செயல்பட வேண்டும். சில உத்திகள் பின்வருமாறு:
- Fabric REST APIs பயன்படுத்துதல்: APIs மூலம் deployment மற்றும் configuration படிகளைத் தானியக்கமாக்குதல்.
- Azure DevOps Pipelines: Fabric APIs-களைத் தூண்டும் (trigger) வகையில் Azure DevOps-இல் தனிப்பயன் pipelines-களை உருவாக்குதல்.
- கடுமையான சோதனை (Rigorous Testing): சார்புநிலை சிக்கல்களை ஆரம்பத்திலேயே கண்டறிய 'Test' நிலையில் தீவிரமான சோதனைகளைச் செயல்படுத்துதல்.
முடிவுரை
Microsoft Fabric ஒரு அற்புதமான தளம், ஆனால் அதன் DevOps முதிர்ச்சி இன்னும் வளர வேண்டியுள்ளது. Deployment இடைவெளி என்பது நிஜமானது, மேலும் இது தரவுப் பொறியாளர்களிடமிருந்து கவனமான திட்டமிடலையும் கூடுதல் முயற்சியையும் கோருகிறது. தளம் வளர்ச்சியடையும் போது, நாம் ஒரு தடையற்ற, முழுமையான CI/CD அனுபவத்தை எதிர்பார்க்கலாம்.