𝗠𝗶𝗰𝗿𝗼𝘀𝗼𝗳𝘁 𝗙𝗮𝗯𝗿𝗶𝗰 𝗖𝗜/𝗖𝗗: 𝗧𝗵𝗲 𝗗𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁 𝗚𝗮𝗽
Deployment anda selesai dengan jayanya. Pipeline Azure DevOps anda lulus. Workspace production kelihatan sempurna.
Kemudian, pagi Isnin tiba.
Proses refresh model semantik gagal. Partition Lakehouse rosak. Laporan mengalami timeout bagi setiap pengguna.
Inilah sisi Microsoft Fabric CI/CD yang sering diabaikan oleh kebanyakan tutorial.
Kebanyakan sumber bahasa Inggeris menunjukkan tetapan "hello world". Mereka menunjukkan cara untuk menyelaraskan (sync) item. Mereka tidak menunjukkan cara untuk menjalankan persekitaran production yang sebenar.
Saya telah mengkaji dokumentasi daripada komuniti pembangun Jepun di Qiita. Mereka telah mengenal pasti masalah sebenar dengan deployment Fabric yang sedia untuk production.
Fabric menganggap segalanya sebagai item. Ini termasuk model semantik, lakehouse, pipeline, laporan, dan notebook. Matlamatnya adalah untuk menganggap item-item ini sebagai kod.
Aliran kerja standard adalah seperti berikut:
- Source control: Eksport item sebagai definisi JSON dalam repo anda.
- Build stage: Sahkan konfigurasi dan kebergantungan (dependencies).
- Release stage: Deploy ke workspace sasaran menggunakan parameter persekitaran.
Tetapi aliran kerja ringkas ini gagal pada skala besar. Berikut adalah sebabnya:
Ralat kebergantungan (Dependency errors) Tutorial menyatakan anda boleh melakukan deployment item dalam sebarang urutan. Ini tidak benar. Model semantik bergantung pada lakehouse. Jika anda melakukan deployment model sebelum kemas kini lakehouse, proses refresh akan gagal.
Had API (API limits) Tutorial mencadangkan satu pipeline untuk segalanya. Workspace yang besar akan mencapai had kadar (rate limits) API Fabric semasa deployment serentak. Anda memerlukan logik untuk memperlahankan proses tersebut.
Perbezaan kapasiti (Capacity differences) Sesuatu model mungkin berfungsi dalam persekitaran ujian tetapi gagal dalam production. Workspace production selalunya mempunyai tahap kapasiti dan sekatan ciri yang berbeza.
Jika anda ingin beralih daripada tutorial kepada tetapan production yang sebenar, ikuti peraturan ini:
- Gunakan deployment berurutan (sequential deployment). Tentukan urutan item berdasarkan kebergantungan mereka.
- Laksanakan penguncian workspace (workspace locking). Halang dua pipeline daripada berjalan pada masa yang sama. Ini mengelakkan kerosakan workspace.
- Simpan workspace sandaran (backup). Gunakan ia sebagai sasaran rollback jika deployment gagal.
- Gunakan parameter peka-kapasiti (capacity-aware parameters). Uji tetapan anda terhadap kapasiti production sebenar anda.
Alatan sudah tersedia. Corak ini berfungsi. Anda hanya perlu bersedia untuk kegagalan yang sering ditinggalkan oleh tutorial.
Adakah pasukan anda pernah mengalami kegagalan deployment yang tidak dinyatakan dalam tutorial? Apakah lagi yang patut ada dalam senarai semak production?
Microsoft Fabric CI/CD: Jurang Deployment yang Tiada Sesiapa Bincangkan
Microsoft Fabric menjanjikan revolusi dalam pengurusan data, tetapi apabila kita bercakap tentang CI/CD (Continuous Integration/Continuous Deployment), terdapat satu jurang besar yang jarang dibincangkan oleh komuniti.
Dua Tonggak CI/CD dalam Microsoft Fabric
Buat masa ini, Microsoft Fabric menawarkan dua mekanisme utama untuk menguruskan kitaran hayat item:
1. Integrasi Git (Tahap Workspace)
Integrasi Git membolehkan anda menyambungkan workspace Fabric anda terus ke repositori Git (seperti Azure DevOps atau GitHub). Ini membolehkan item seperti Notebook, Lakehouse, dan Report diselaraskan sebagai fail dalam repositori, membolehkan kawalan versi (version control) dilakukan pada tahap workspace.
2. Pipeline Deployment (Tahap Item)
Pipeline Deployment pula membolehkan anda memindahkan item secara khusus dari satu workspace (contohnya, Dev) ke workspace lain (contohnya, Test atau Prod). Ini adalah pendekatan berasaskan item yang direka untuk memudahkan pergerakan aset melalui pelbagai persekitaran.
Jurang yang Wujud: Percanggahan Tahap
Di sinilah masalahnya bermula. Walaupun kedua-dua ciri ini sangat berguna, mereka beroperasi pada tahap yang berbeza dan tidak "bercakap" antara satu sama lain:
- Integrasi Git adalah bersifat workspace-centric (berpusatkan workspace).
- Pipeline Deployment adalah bersifat item-centric (berpusatkan item).
Apabila anda menggunakan Integrasi Git dalam workspace 'Dev', anda sedang menguruskan keseluruhan workspace melalui Git. Namun, apabila anda menggunakan Pipeline Deployment untuk memindahkan item dari 'Dev' ke 'Prod', anda sebenarnya memintas proses Git untuk persekitaran 'Prod'.
Ini mewujudkan satu situasi di mana workspace 'Prod' anda mungkin tidak mempunyai integrasi Git yang selari dengan 'Dev'. Akibatnya, anda kehilangan "Single Source of Truth" (Sumber Kebenaran Tunggal) yang sepatutnya menjadi teras kepada amalan DevOps yang baik.
Mengapa Ini Menjadi Isu Besar?
- Ketidakkonsistenan Persekitaran: Jika anda memindahkan item melalui Pipeline Deployment ke workspace 'Prod' yang tidak mempunyai integrasi Git, anda tidak mempunyai cara mudah untuk menyelaraskan semula (sync) perubahan tersebut kembali ke repositori Git tanpa risiko konflik.
- Pengurusan Konfigurasi yang Sukar: Item seperti Semantic Model memerlukan konfigurasi yang berbeza antara persekitaran Dev dan Prod (seperti sambungan data). Menguruskan perbezaan ini melalui Git dan Pipeline secara serentak memerlukan usaha manual yang tinggi.
- Ketiadaan Aliran Kerja Bersepadu: Buat masa ini, tiada aliran kerja "out-of-the-box" yang menggabungkan kekuatan Integrasi Git (untuk kawalan versi) dengan Pipeline Deployment (untuk penghantaran item) secara lancar dan automatik.
Kesimpulan
Jurang antara integrasi Git dan pipeline deployment dalam Microsoft Fabric bermakna pembangun tidak boleh hanya bergantung kepada ciri sedia ada untuk mencapai automasi CI/CD yang lengkap. Untuk merapatkan jurang ini, organisasi perlu membina proses tambahan, mungkin menggunakan API atau skrip automasi, untuk memastikan persekitaran produksi sentiasa selari dengan repositori Git anda.
Optional learning community: https://t.me/GyaanSetuAi