𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗙𝗮𝗯𝗿𝗶𝗰 𝗖𝗜/𝗖𝗗: 𝗧𝗵𝗲 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗚𝗮𝗽
ನಿಮ್ಮ ನಿಯೋಜನೆ (deployment) ಯಶಸ್ವಿಯಾಗಿ ಮುಕ್ತಾಯಗೊಳ್ಳುತ್ತದೆ. ನಿಮ್ಮ Azure DevOps ಪೈಪ್ಲೈನ್ ಪಾಸಾಗುತ್ತದೆ. ಪ್ರೊಡಕ್ಷನ್ ವರ್ಕ್ಸ್ಪೇಸ್ ಪರಿಪೂರ್ಣವಾಗಿ ಕಾಣುತ್ತದೆ.
ನಂತರ ಸೋಮವಾರದ ಬೆಳಿಗ್ಗೆ ಎದುರಾಗುತ್ತದೆ.
ಸೆಮ್ಯಾಂಟಿಕ್ ಮಾಡೆಲ್ ರಿಫ್ರೆಶ್ (semantic model refresh) ವಿಫಲವಾಗುತ್ತದೆ. ಲೇಕ್ಹೌಸ್ ಪಾರ್ಟಿಷನ್ಗಳು (Lakehouse partitions) ಹಾನಿಗೊಳಗಾಗುತ್ತವೆ. ಪ್ರತಿಯೊಬ್ಬ ಬಳಕೆದಾರರಿಗೂ ವರದಿಗಳು ಟೈಮ್ಔಟ್ (timeout) ಆಗುತ್ತವೆ.
ಇದು Microsoft Fabric CI/CD ನ ಅಂತಹ ಒಂದು ಮುಖ, ಇದನ್ನು ಹೆಚ್ಚಿನ ಟ್ಯುಟೋರಿಯಲ್ಗಳು ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ.
ಹೆಚ್ಚಿನ ಇಂಗ್ಲಿಷ್ ಸಂಪನ್ಮೂಲಗಳು ಕೇವಲ "hello world" ಸೆಟಪ್ ಅನ್ನು ತೋರಿಸುತ್ತವೆ. ಐಟಂಗಳನ್ನು ಹೇಗೆ ಸಿಂಕ್ ಮಾಡಬೇಕೆಂದು ಅವು ತೋರಿಸುತ್ತವೆ. ಆದರೆ ನೈಜ ಪ್ರೊಡಕ್ಷನ್ ಪರಿಸರವನ್ನು (production environment) ಹೇಗೆ ನಿರ್ವಹಿಸಬೇಕೆಂದು ಅವು ತೋರಿಸುವುದಿಲ್ಲ.
ನಾನು Qiita ನಲ್ಲಿರುವ ಜಪಾನೀಸ್ ಡೆವಲಪರ್ ಸಮುದಾಯದ ದಾಖಲೆಗಳನ್ನು (documentation) ಅಧ್ಯಯನ ಮಾಡಿದೆ. ಪ್ರೊಡಕ್ಷನ್-ರೆಡಿ Fabric ನಿಯೋಜನೆಗಳಲ್ಲಿನ ನೈಜ ಸಮಸ್ಯೆಗಳನ್ನು ಅವರು ಪತ್ತೆಹಚ್ಚಿದ್ದಾರೆ.
Fabric ಎಲ್ಲವನ್ನೂ 'ಐಟಂಗಳು' (items) ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ. ಇವುಗಳಲ್ಲಿ ಸೆಮ್ಯಾಂಟಿಕ್ ಮಾಡೆಲ್ಗಳು, ಲೇಕ್ಹೌಸ್ಗಳು, ಪೈಪ್ಲೈನ್ಗಳು, ವರದಿಗಳು ಮತ್ತು ನೋಟ್ಬುಕ್ಗಳು ಸೇರಿವೆ. ಈ ಐಟಂಗಳನ್ನು ಕೋಡ್ (code) ಎಂದು ಪರಿಗಣಿಸುವುದು ಇದರ ಗುರಿಯಾಗಿದೆ.
ಪ್ರಮಾಣಿತ ವರ್ಕ್ಫ್ಲೋ (standard workflow) ಈ ರೀತಿ ಇರುತ್ತದೆ:
- ಸೋರ್ಸ್ ಕಂಟ್ರೋಲ್ (Source control): ನಿಮ್ಮ ರೆಪೋದಲ್ಲಿ (repo) ಐಟಂಗಳನ್ನು JSON ವ್ಯಾಖ್ಯಾನಗಳಾಗಿ (definitions) ಎಕ್ಸ್ಪೋರ್ಟ್ ಮಾಡಿ.
- ಬಿಲ್ಡ್ ಹಂತ (Build stage): ಕಾನ್ಫಿಗರೇಶನ್ಗಳು ಮತ್ತು ಅವಲಂಬನೆಗಳನ್ನು (dependencies) ದೃಢೀಕರಿಸಿ.
- ರಿಲೀಸ್ ಹಂತ (Release stage): ಎನ್ವಿರಾನ್ಮೆಂಟ್ ಪ್ಯಾರಾಮೀಟರ್ಗಳನ್ನು ಬಳಸಿ ಟಾರ್ಗೆಟ್ ವರ್ಕ್ಸ್ಪೇಸ್ಗಳಿಗೆ ನಿಯೋಜಿಸಿ (deploy).
ಆದರೆ ಈ ಸರಳ ವರ್ಕ್ಫ್ಲೋ ದೊಡ್ಡ ಮಟ್ಟದ ಬಳಕೆಯಲ್ಲಿ (at scale) ವಿಫಲವಾಗುತ್ತದೆ. ಅದಕ್ಕೆ ಕಾರಣಗಳು ಇಲ್ಲಿವೆ:
ಅವಲಂಬನೆ ದೋಷಗಳು (Dependency errors) ಐಟಂಗಳನ್ನು ಯಾವುದೇ ಕ್ರಮದಲ್ಲಿ ನಿಯೋಜಿಸಬಹುದು ಎಂದು ಟ್ಯುಟೋರಿಯಲ್ಗಳು ಹೇಳುತ್ತವೆ. ಇದು ತಪ್ಪು. ಸೆಮ್ಯಾಂಟಿಕ್ ಮಾಡೆಲ್ ಒಂದು ಲೇಕ್ಹೌಸ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ. ಲೇಕ್ಹೌಸ್ ಅಪ್ಡೇಟ್ ಆಗುವ ಮೊದಲೇ ನೀವು ಮಾಡೆಲ್ ಅನ್ನು ನಿಯೋಜಿಸಿದರೆ, ರಿಫ್ರೆಶ್ ವಿಫಲವಾಗುತ್ತದೆ.
API ಮಿತಿಗಳು (API limits) ಎಲ್ಲದಕ್ಕೂ ಒಂದೇ ಪೈಪ್ಲೈನ್ ಬಳಸಲು ಟ್ಯುಟೋರಿಯಲ್ಗಳು ಸೂಚಿಸುತ್ತವೆ. ದೊಡ್ಡ ವರ್ಕ್ಸ್ಪೇಸ್ಗಳು ಏಕಕಾಲಿಕ ನಿಯೋಜನೆಗಳ ಸಮಯದಲ್ಲಿ Fabric API ದರ ಮಿತಿಗಳನ್ನು (rate limits) ತಲುಪುತ್ತವೆ. ಪ್ರಕ್ರಿಯೆಯನ್ನು ನಿಧಾನಗೊಳಿಸಲು ನಿಮಗೆ ತರ್ಕದ (logic) ಅಗತ್ಯವಿದೆ.
ಸಾಮರ್ಥ್ಯದ ವ್ಯತ್ಯಾಸಗಳು (Capacity differences) ಒಂದು ಮಾಡೆಲ್ ಟೆಸ್ಟ್ ಎನ್ವಿರಾನ್ಮೆಂಟ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಬಹುದು ಆದರೆ ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು. ಪ್ರೊಡಕ್ಷನ್ ವರ್ಕ್ಸ್ಪೇಸ್ಗಳು ಹೆಚ್ಚಾಗಿ ವಿಭಿನ್ನ ಸಾಮರ್ಥ್ಯದ ಹಂತಗಳು (capacity tiers) ಮತ್ತು ವೈಶಿಷ್ಟ್ಯದ ನಿರ್ಬಂಧಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ.
ನೀವು ಟ್ಯುಟೋರಿಯಲ್ನಿಂದ ನೈಜ ಪ್ರೊಡಕ್ಷನ್ ಸೆಟಪ್ಗೆ ಹೋಗಲು ಬಯಸಿದರೆ, ಈ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸಿ:
- ಸೀಕ್ವೆನ್ಷಿಯಲ್ ನಿಯೋಜನೆಯನ್ನು (sequential deployment) ಬಳಸಿ. ಅವುಗಳ ಅವಲಂಬನೆಗಳ ಆಧಾರದ ಮೇಲೆ ಐಟಂಗಳ ಕ್ರಮವನ್ನು ನಿರ್ಧರಿಸಿ.
- ವರ್ಕ್ಸ್ಪೇಸ್ ಲಾಕಿಂಗ್ ಅನ್ನು ಜಾರಿಗೆ ತರండి. ಎರಡು ಪೈಪ್ಲೈನ್ಗಳು ಏಕಕಾಲದಲ್ಲಿ ಚಲಿಸದಂತೆ ತಡೆಯಿರಿ. ಇದು ವರ್ಕ್ಸ್ಪೇಸ್ ದೋಷಗಳಿಗೆ (corruption) ಕಾರಣವಾಗುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ.
- ಬ್ಯಾಕಪ್ ವರ್ಕ್ಸ್ಪೇಸ್ ಇಟ್ಟುಕೊಳ್ಳಿ. ನಿಯೋಜನೆ ವಿಫಲವಾದರೆ ಅದನ್ನು ರೋಲ್ಬ್ಯಾಕ್ (rollback) ಗುರಿಯಾಗಿ ಬಳಸಿ.
- ಸಾಮರ್ಥ್ಯಕ್ಕೆ ಅನುಗುಣವಾದ ಪ್ಯಾರಾಮೀಟರ್ಗಳನ್ನು ಬಳಸಿ. ನಿಮ್ಮ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ನಿಮ್ಮ ನೈಜ ಪ್ರೊಡಕ್ಷನ್ ಸಾಮರ್ಥ್ಯದೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ.
ಉಪಕರಣಗಳು ಲಭ್ಯವಿವೆ. ಈ ಮಾದರಿಯು ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಟ್ಯುಟೋರಿಯಲ್ಗಳು ಬಿಟ್ಟುಹೋಗುವ ವೈಫಲ್ಯಗಳಿಗೆ ನೀವು ಸಿದ್ಧರಾಗಬೇಕಷ್ಟೇ.
ಟ್ಯುಟೋರಿಯಲ್ಗಳು ಉಲ್ಲೇಖಿಸದ ನಿಯೋಜನಾ ವೈಫಲ್ಯಗಳನ್ನು ನಿಮ್ಮ ತಂಡ ಎದುರಿಸಿದೆಯೇ? ಪ್ರೊಡಕ್ಷನ್ ಚೆಕ್ಲಿಸ್ಟ್ನಲ್ಲಿ ಇನ್ನು ಏನೇನಿರಬೇಕು?
Microsoft Fabric CI/CD: The Deployment Gap Nobody Talks About
Microsoft Fabric ಒಂದು ಶಕ್ತಿಯುತವಾದ ಏಕೀಕೃತ ವಿಶ್ಲೇಷಣಾ ಪ್ಲಾಟ್ಫಾರ್ಮ್ (unified analytics platform). ಇದು ಡೇಟಾ ಎಂಜಿನಿಯರಿಂಗ್, ಡೇಟಾ ಸೈನ್ಸ್ ಮತ್ತು ರಿಯಲ್-ಟೈಮ್ ಅನಾಲಿಟಿಕ್ಸ್ ಅನ್ನು ಒಂದೇ ಸೂರಿನಡಿ ತರುತ್ತದೆ. ಆದರೆ ಸಂಸ್ಥೆಗಳು ತಮ್ಮ ಪ್ರಯೋಗಗಳನ್ನು (experimentation) ಉತ್ಪಾದನಾ ಹಂತಕ್ಕೆ (production) ಸಾಗಿಸುತ್ತಿದ್ದಂತೆ, ಒಂದು ನಿರ್ಣಾಯಕ ಪ್ರಶ್ನೆ ಎದುರಾಗುತ್ತದೆ: ನಾವು ಬಲವಾದ CI/CD (Continuous Integration/Continuous Deployment) ಅನ್ನು ಹೇಗೆ ಜಾರಿಗೆ ತರಬಹುದು?
Fabric ನಲ್ಲಿ CI/CD ನ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿ
Microsoft Fabric ಪ್ರಸ್ತುತ ನಿಯೋಜನೆಗಳನ್ನು (deployments) ನಿರ್ವಹಿಸಲು ಎರಡು ಪ್ರಮುಖ ವಿಧಾನಗಳನ್ನು ನೀಡುತ್ತದೆ:
- Git Integration: ಇದು ನಿಮ್ಮ Fabric ವರ್ಕ್ಸ್ಪೇಸ್ಗಳನ್ನು Git ರೆಪೊಸಿಟರಿಗಳೊಂದಿಗೆ ಜೋಡಿಸಲು ಅನುಮತಿಸುತ್ತದೆ.
- Deployment Pipelines: ಇದು ವಿವಿಧ ಪರಿಸರಗಳ (environments) ನಡುವೆ ಕಂಟೆಂಟ್ ಅನ್ನು ವರ್ಗಾಯಿಸಲು ಬಳಸುವ ಒಂದು ಅಂತರ್ಗತ ಸಾಧನವಾಗಿದೆ.
ಆದಾಗ್ಯೂ, ಈ ಎರಡೂ ವಿಧಾನಗಳು ಪರಿಪೂರ್ಣವಾಗಿಲ್ಲ ಮತ್ತು ಅವುಗಳ ನಡುವೆ ಒಂದು ದೊಡ್ಡ ಅಂತರವಿದೆ.
Git Integration ಅಂತರ (The Git Integration Gap)
Git integration ಒಂದು ದೊಡ್ಡ ಪ್ರಗತಿಯಾಗಿದ್ದರೂ, ಇದು ಸಂಪೂರ್ಣ ಪರಿಹಾರವಲ್ಲ. ಪ್ರಸ್ತುತ ಎಲ್ಲಾ Fabric ಐಟಂಗಳು Git integration ನಿಂದ ಬೆಂಬಲಿತವಾಗಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಕೆಲವು ಐಟಂಗಳು Git ಮೂಲಕ ಸಿಂಕ್ ಆಗಬಹುದು, ಆದರೆ ಇತರವುಗಳು ಅಥವಾ ಕೆಲವು ನಿರ್ದಿಷ್ಟ ಕಾನ್ಫಿಗರೇಶನ್ಗಳು ಇನ್ನೂ ಬೆಂಬಲಿತವಾಗಿಲ್ಲ.
ಇದರರ್ಥ, ನೀವು ಎಲ್ಲವನ್ನೂ ಕೋಡ್ ರೂಪದಲ್ಲಿ ರೆಪೊಸಿಟರಿಗೆ (repository) ಸಿಂಕ್ ಮಾಡಿ, ಅಲ್ಲಿಂದ ಸುಗಮವಾಗಿ ನಿಯೋಜಿಸಲು (seamless deployment) ನಿರೀಕ್ಷಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ಅಭಿವೃದ್ಧಿ ತಂಡಗಳಿಗೆ (development teams) ಹೆಚ್ಚಿನ ಕೆಲಸದ ಹೊರೆಯನ್ನು ನೀಡುತ್ತದೆ.
Deployment Pipeline ಮಿತಿಗಳು
Deployment pipelines ಗಳನ್ನು ವರ್ಕ್ಸ್ಪೇಸ್ಗಳ ನಡುವೆ ಕಂಟೆಂಟ್ ಅನ್ನು ವರ್ಗಾಯಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಆದರೆ, ಸಾಂಪ್ರದಾಯಿಕ DevOps ಪದ್ಧತಿಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಇವು ಹೆಚ್ಚಾಗಿ ಒಂದು "ಬ್ಲಾಕ್ ಬಾಕ್ಸ್" (black box) ನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ.
ಸಾಂಪ್ರದಾಯಿಕ ಸಾಫ್ಟ್ವೇರ್ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ, ನೀವು ಕೋಡ್ನ ಪ್ರತಿಯೊಂದು ಸಣ್ಣ ಬದಲಾವಣೆಯನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು. ಆದರೆ Fabric ನ ಪೈಪ್ಲೈನ್ಗಳಲ್ಲಿ, ಅಡಿಯಲ್ಲಿರುವ ಕೋಡ್ ಮತ್ತು ಸೂಕ್ಷ್ಮ ಬದಲಾವಣೆಗಳ (granular changes) ಮೇಲೆ ನಿಮಗೆ ಅಷ್ಟೊಂದು ನಿಯಂತ್ರಣವಿರುವುದಿಲ್ಲ. ಇದು "Infrastructure as Code" (IaC) ತತ್ವಗಳಿಗೆ ವಿರುದ್ಧವಾಗಿದೆ.
"ಅಂತರ" (The Gap) ಎಂದರೇನು?
ಈ ಅಂತರವು ಮುಖ್ಯವಾಗಿ ಎರಡು ಕಾರಣಗಳಿಂದ ಉಂಟಾಗುತ್ತದೆ:
- ಸಂಪರ್ಕದ ಕೊರತೆ: ડેವಲಪರ್ ಬಳಸುವ ಸ್ಥಳೀಯ ಪರಿಸರ (local environment) ಅಥವಾ Git ರೆಪೊಸಿಟರಿ ಮತ್ತು Fabric ಸೇವೆಯ ಆಂತರಿಕ ಸ್ಥಿತಿಯ ನಡುವೆ ನೇರವಾದ ಮತ್ತು ಸಂಪೂರ್ಣವಾದ ಸಂಪರ್ಕವಿಲ್ಲ.
- ಆವೃತ್ತಿ ನಿಯಂತ್ರಣದ ಸಮಸ್ಯೆ (Versioning Issues): ನೀವು ಪೈಪ್ಲೈನ್ ಮೂಲಕ ನಿಯೋಜಿಸಿದಾಗ, Git ನಲ್ಲಿ ನೀವು ನೋಡುವ ಕೋಡ್ನ ನಿಖರವಾದ ಆವೃತ್ತಿಯನ್ನು (exact version) ನೀವು ಯಾವಾಗಲೂ ನಿಯೋಜಿಸುವುದಿಲ್ಲ. ಇದು ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ (production environment) ಅನಿರೀಕ್ಷಿತ ತಪ್ಪುಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.
ಈ ಅಂತರವನ್ನು ಹೇಗೆ ತುಂಬುವುದು?
ನಿಜವಾದ, ವೃತ್ತಿಪರ CI/CD ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸಾಧಿಸಲು, ತಂಡಗಳು ಕೇವಲ ಅಂತರ್ಗತ (built-in) ಸಾಧನಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗದೆ ಹೆಚ್ಚಿನದನ್ನು ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಇದಕ್ಕೆ ಈ ಕೆಳಗಿನವುಗಳು ಅಗತ್ಯವಾಗಿವೆ:
- Fabric REST APIs ಬಳಕೆ: ಐಟಂಗಳನ್ನು ರಚಿಸಲು, ಅಪ್ಡೇಟ್ ಮಾಡಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು API ಗಳನ್ನು ಬಳಸುವ ಮೂಲಕ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವುದು.
- PowerShell ಮತ್ತು SDKಗಳು: ನಿಯೋಜನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಮತ್ತು ಹೆಚ್ಚಿನ ನಿಯಂತ್ರಣ ಪಡೆಯಲು PowerShell ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳುವುದು.
- Custom Deployment Scripts: Git ಮತ್ತು Fabric ವರ್ಕ್ಸ್ಪೇಸ್ಗಳ ನಡುವೆ ಸೇತುವೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಕಸ್ಟಮ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು.
ತೀರ್ಮಾನ
Microsoft Fabric ನಲ್ಲಿನ ನಿಯೋಜನೆಯ ಅಂತರವು (deployment gap) ನಿಜವಾಗಿಯೂ ಇದೆ, ಆದರೆ ಇದನ್ನು ಎದುರಿಸಲಾಗದ್ದು ಅಲ್ಲ. ಸಂಸ್ಥೆಗಳು ಕೇವಲ ಸರಳ ಪರಿಹಾರಗಳನ್ನು ಹುಡುಕುವ ಬದಲು, APIಗಳು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವಿಕೆಯ (automation) ಮೂಲಕ ಹೆಚ್ಚು ಬಲವಾದ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ DevOps ವರ್ಕ್ಫ್ಲೋವನ್ನು ನಿರ್ಮಿಸಬೇಕಾಗುತ್ತದೆ.
Optional learning community: https://t.me/GyaanSetuAi