Bagikan melalui

Pilih opsi alur kerja Fabric CI/CD terbaik untuk Anda

  • Artikel

Tujuan dari artikel ini adalah untuk menyajikan pengembang Fabric dengan opsi yang berbeda untuk membangun proses CI/CD di Fabric, berdasarkan skenario pelanggan umum. Artikel ini lebih berfokus pada penyebaran berkelanjutan (CD) dari proses CI/CD. Untuk diskusi tentang bagian integrasi berkelanjutan (CI), lihat Mengelola cabang Git.

Meskipun artikel ini menguraikan beberapa opsi yang berbeda, banyak organisasi mengambil pendekatan hibrid.

Prasyarat

Untuk mengakses fitur alur penyebaran, Anda harus memenuhi kondisi berikut:

Proses pengembangan

Proses pengembangan sama dalam semua skenario penyebaran, dan independen dari cara merilis pembaruan baru ke dalam produksi. Ketika pengembang bekerja dengan kontrol sumber, mereka perlu bekerja di lingkungan yang terisolasi. Di Fabric, lingkungan tersebut dapat menjadi IDE di komputer lokal Anda (seperti Power BI Desktop, atau VS Code), atau ruang kerja yang berbeda di Fabric. Anda dapat menemukan informasi tentang berbagai pertimbangan untuk proses pengembangan di Mengelola cabang Git

Diagram memperlihatkan cara kerja proses pengembangan.

Proses rilis

Proses rilis dimulai setelah pembaruan baru selesai dan permintaan pull (PR) digabungkan ke cabang bersama tim (seperti Utama, Dev, dll.). Dari titik ini, ada berbagai opsi untuk membangun proses rilis di Fabric.

Opsi 1 - Penyebaran berbasis Git

Diagram memperlihatkan cara kerja penyebaran berbasis Git.

Dengan opsi ini, semua penyebaran berasal dari repositori Git. Setiap tahap dalam alur rilis memiliki cabang utama khusus (dalam diagram, tahapan ini adalah Dev, Test, dan Prod), yang memberi umpan ruang kerja yang sesuai di Fabric.

Setelah PR ke cabang Dev disetujui dan digabungkan:

  1. Alur rilis dipicu untuk memperbarui konten ruang kerja Dev . Proses ini juga dapat mencakup alur Build untuk menjalankan pengujian unit, tetapi pengunggahan file aktual dilakukan langsung dari repositori ke ruang kerja, menggunakan Fabric Git API. Anda mungkin perlu memanggil FABRIC API lain untuk operasi pasca-penyebaran yang mengatur konfigurasi tertentu untuk ruang kerja ini, atau menyerap data.
  2. PR kemudian dibuat ke cabang Uji . Dalam kebanyakan kasus, PR dibuat menggunakan cabang rilis yang dapat ceri memilih konten untuk pindah ke tahap berikutnya. PR harus menyertakan proses peninjauan dan persetujuan yang sama seperti yang lain dalam tim atau organisasi Anda.
  3. Alur Build dan rilis lainnya dipicu untuk memperbarui ruang kerja Uji, menggunakan proses yang mirip dengan yang dijelaskan pada langkah pertama.
  4. PR dibuat ke cabang Prod , menggunakan proses yang mirip dengan yang dijelaskan di langkah #2.
  5. Alur Build dan rilis lainnya dipicu untuk memperbarui ruang kerja Prod, menggunakan proses yang mirip dengan yang dijelaskan pada langkah pertama.

Kapan Anda harus mempertimbangkan untuk menggunakan opsi #1?

  • Ketika Anda ingin menggunakan repositori Git Anda sebagai sumber kebenaran tunggal, dan asal semua penyebaran.
  • Saat tim Anda mengikuti Gitflow sebagai strategi percabangan, termasuk beberapa cabang utama.
  • Unggahan dari repositori langsung masuk ke ruang kerja, karena kita tidak memerlukan lingkungan build untuk mengubah file sebelum penyebaran. Anda dapat mengubah ini dengan memanggil API atau menjalankan item di ruang kerja setelah penyebaran.

Opsi 2 - Penyebaran berbasis Git menggunakan lingkungan Build

Diagram memperlihatkan alur penyebaran berbasis Git menggunakan lingkungan build.

Dengan opsi ini, semua penyebaran berasal dari cabang repositori Git (Utama) yang sama. Setiap tahap dalam alur rilis memiliki alur build dan Rilis khusus. Alur ini mungkin menggunakan lingkungan Build untuk menjalankan pengujian unit dan skrip yang mengubah beberapa definisi dalam item sebelum diunggah ke ruang kerja. Misalnya, Anda mungkin ingin mengubah koneksi sumber data, koneksi antara item di ruang kerja, atau nilai parameter untuk menyesuaikan konfigurasi untuk tahap yang tepat.

Setelah PR ke cabang dev disetujui dan digabungkan:

  1. Alur build dipicu untuk memutar lingkungan Build baru dan menjalankan pengujian unit untuk tahap pengembangan. Kemudian, alur rilis dipicu untuk mengunggah konten ke lingkungan Build, menjalankan skrip untuk mengubah beberapa konfigurasi, menyesuaikan konfigurasi ke tahap dev, dan menggunakan API definisi item Pembaruan Fabric untuk mengunggah file ke Ruang Kerja.
  2. Ketika proses ini selesai, termasuk menyerap data dan persetujuan dari manajer rilis, alur build dan rilis berikutnya untuk tahap pengujian dapat dibuat. Tahapan ini dibuat dalam proses yang mirip dengan yang dijelaskan pada langkah pertama. Untuk tahap pengujian , pengujian otomatis atau manual lainnya mungkin diperlukan setelah penyebaran, untuk memvalidasi perubahan siap dirilis ke tahap Prod .
  3. Ketika semua pengujian otomatis dan manual selesai, manajer rilis dapat menyetujui dan memulai alur build dan rilis ke tahap Prod . Karena tahap Prod biasanya memiliki konfigurasi yang berbeda dari tahap pengujian/Dev, penting untuk juga menguji perubahan setelah penyebaran. Selain itu, penyebaran harus memicu penyerapan data lagi, berdasarkan perubahan, untuk meminimalkan potensi non ketersediaan kepada konsumen.

Kapan Anda harus mempertimbangkan untuk menggunakan opsi #2?

  • Ketika Anda ingin menggunakan Git sebagai sumber kebenaran tunggal Anda, dan asal semua penyebaran.
  • Saat tim Anda mengikuti alur kerja berbasis Trunk sebagai strategi percabangannya.
  • Anda memerlukan lingkungan build (dengan skrip kustom) untuk mengubah atribut khusus ruang kerja, seperti connectionId dan lakehouseId, sebelum penyebaran.
  • Anda memerlukan alur rilis (skrip kustom) untuk mengambil konten item dari git dan memanggil Fabric Item API yang sesuai untuk membuat, memperbarui, atau menghapus Item Fabric yang dimodifikasi.

Opsi 3 - Menyebarkan menggunakan alur penyebaran Fabric

Diagram memperlihatkan alur penyebaran berbasis Git menggunakan alur penyebaran.

Dengan opsi ini, Git hanya terhubung sampai tahap dev . Dari tahap pengembangan, penyebaran terjadi langsung di antara ruang kerja Dev/Test/Prod, menggunakan alur penyebaran Fabric. Meskipun alat itu sendiri bersifat internal untuk Fabric, pengembang dapat menggunakan API alur penyebaran untuk mengatur penyebaran sebagai bagian dari alur rilis Azure mereka, atau alur kerja GitHub. API ini memungkinkan tim untuk membangun proses build dan rilis serupa seperti di opsi lain, dengan menggunakan pengujian otomatis (yang dapat dilakukan di ruang kerja itu sendiri, atau sebelum tahap dev), persetujuan dll.

Setelah PR ke cabang utama disetujui dan digabungkan:

  1. Alur build dipicu yang mengunggah perubahan ke tahap pengembangan menggunakan Fabric Git API. Jika perlu, alur dapat memicu API lain untuk memulai operasi/pengujian pasca-penyebaran di tahap dev .
  2. Setelah penyebaran dev selesai, alur rilis dimulai untuk menyebarkan perubahan dari tahap dev ke tahap pengujian. Pengujian otomatis dan manual harus dilakukan setelah penyebaran, untuk memastikan bahwa perubahan diuji dengan baik sebelum mencapai produksi.
  3. Setelah pengujian selesai dan manajer rilis menyetujui penyebaran ke tahap Prod , rilis ke Prod dimulai dan menyelesaikan penyebaran.

Kapan Anda harus mempertimbangkan untuk menggunakan opsi #3?

  • Saat Anda menggunakan kontrol sumber hanya untuk tujuan pengembangan, dan lebih suka menyebarkan perubahan langsung di antara tahap alur rilis.
  • Saat aturan penyebaran, pengikatan otomatis dan API lain yang tersedia cukup untuk mengelola konfigurasi antara tahap alur rilis.
  • Ketika Anda ingin menggunakan fungsionalitas lain dari alur penyebaran Fabric, seperti melihat perubahan fabric, riwayat penyebaran, dll.
  • Pertimbangkan juga bahwa penyebaran dalam alur penyebaran Fabric memiliki struktur linier, dan memerlukan izin lain untuk membuat dan mengelola alur.

Opsi 4 - CI/CD untuk ISV dalam Fabric (mengelola beberapa pelanggan/solusi)

Diagram memperlihatkan alur penyebaran berbasis Git untuk ISV.

Opsi ini berbeda dari yang lain. Ini paling relevan untuk Vendor Perangkat Lunak Independen (ISV) yang membangun aplikasi SaaS untuk pelanggan mereka di atas Fabric. ISV biasanya memiliki ruang kerja terpisah untuk setiap pelanggan dan dapat memiliki sebanyak beberapa ratus atau ribuan ruang kerja. Ketika struktur analitik yang diberikan kepada setiap pelanggan serupa dan di luar kotak, kami sarankan memiliki proses pengembangan dan pengujian terpusat yang memisahkan ke setiap pelanggan hanya dalam tahap Prod .

Opsi ini didasarkan pada opsi #2. Setelah PR ke utama disetujui dan digabungkan:

  1. Alur build dipicu untuk memutar lingkungan Build baru dan menjalankan pengujian unit untuk tahap pengembangan. Ketika pengujian selesai, alur rilis dipicu. Alur ini dapat mengunggah konten ke lingkungan Build, menjalankan skrip untuk mengubah beberapa konfigurasi, menyesuaikan konfigurasi ke tahap pengembangan, lalu menggunakan API definisi item Pembaruan Fabric untuk mengunggah file ke Ruang Kerja.
  2. Setelah proses ini selesai, termasuk menyerap data dan persetujuan dari manajer rilis, alur build dan rilis berikutnya untuk tahap pengujian dapat dimulai. Proses ini mirip dengan yang dijelaskan pada langkah pertama. Untuk tahap pengujian , pengujian otomatis atau manual lainnya mungkin diperlukan setelah penyebaran, untuk memvalidasi perubahan siap dirilis ke tahap Prod dalam kualitas tinggi.
  3. Setelah semua pengujian lulus dan proses persetujuan selesai, penyebaran ke pelanggan Prod dapat dimulai. Setiap pelanggan memiliki rilis sendiri dengan parameternya sendiri, sehingga konfigurasi spesifik dan koneksi datanya dapat berlangsung di ruang kerja pelanggan yang relevan. Perubahan konfigurasi dapat terjadi melalui skrip di lingkungan build , atau menggunakan API pasca penyebaran. Semua rilis dapat terjadi secara paralel karena tidak terkait atau bergantung satu sama lain.

Kapan Anda harus mempertimbangkan untuk menggunakan opsi #4?

  • Anda adalah aplikasi bangunan ISV di atas Fabric.
  • Anda menggunakan ruang kerja yang berbeda untuk setiap pelanggan untuk mengelola multi-penyewaan aplikasi Anda
  • Untuk pemisahan lebih lanjut, atau untuk pengujian tertentu untuk pelanggan yang berbeda, Anda mungkin ingin memiliki multi-penyewaan pada tahap pengembangan atau pengujian sebelumnya. Dalam hal ini, pertimbangkan bahwa dengan multi-penyewaan jumlah ruang kerja yang diperlukan tumbuh secara signifikan.

Ringkasan

Artikel ini merangkum opsi CI/CD utama untuk tim yang ingin membangun proses CI/CD otomatis di Fabric. Meskipun kami menguraikan empat opsi, batasan kehidupan nyata dan arsitektur solusi mungkin meminjamkan diri mereka ke opsi hibrid, atau yang benar-benar berbeda. Anda dapat menggunakan artikel ini untuk memandu Anda melalui berbagai opsi dan cara membuatnya, tetapi Anda tidak dipaksa untuk memilih hanya salah satu opsi.

Beberapa skenario atau item tertentu mungkin memiliki batasan yang dapat mencegah Anda mengadopsi salah satu skenario ini.

Hal yang sama berlaku untuk perkakas. Meskipun kami menyebutkan alat yang berbeda di sini, Anda dapat memilih alat lain yang dapat menyediakan tingkat fungsionalitas yang sama. Pertimbangkan bahwa Fabric memiliki integrasi yang lebih baik dengan beberapa alat, jadi memilih yang lain menghasilkan lebih banyak batasan yang membutuhkan solusi yang berbeda.

Konten terkait