Praktik terbaik manajemen siklus hidup
Artikel ini menyediakan panduan untuk pembuat data & analitik yang mengelola konten mereka sepanjang siklus hidupnya di Microsoft Fabric. Artikel ini berfokus pada penggunaan integrasi Git untuk kontrol sumber dan alur penyebaran sebagai alat rilis . Untuk panduan umum tentang penerbitan konten Perusahaan, penerbitan konten Perusahaan.
Penting
Fitur ini dalam pratinjau.
Artikel ini dibagi menjadi empat bagian:
Persiapan konten - Siapkan konten Anda untuk manajemen siklus hidup.
Pengembangan - Pelajari tentang cara terbaik untuk membuat konten dalam tahap pengembangan alur penyebaran.
Uji - Pahami cara menggunakan tahap pengujian alur penyebaran untuk menguji lingkungan Anda.
Produksi - Gunakan tahap produksi alur penyebaran untuk membuat konten Anda tersedia untuk dikonsumsi.
Persiapan konten
Untuk mempersiapkan konten Anda dengan sebaik-baiknya untuk manajemen yang sedang berlangsung sepanjang siklus hidupnya, tinjau informasi di bagian ini sebelum Anda:
Rilis konten ke produksi.
Mulai gunakan alur penyebaran untuk ruang kerja tertentu.
Memisahkan pengembangan antar tim
Tim yang berbeda dalam organisasi biasanya memiliki keahlian, kepemilikan, dan metode kerja yang berbeda, bahkan ketika mengerjakan proyek yang sama. Penting untuk menetapkan batasan sambil memberi setiap tim kemerdekaan mereka untuk bekerja seperti yang mereka suka. Pertimbangkan untuk memiliki ruang kerja terpisah untuk tim yang berbeda. Dengan ruang kerja terpisah, setiap tim dapat memiliki izin yang berbeda, bekerja dengan repositori kontrol sumber yang berbeda, dan mengirim konten ke produksi dalam irama yang berbeda. Sebagian besar item dapat menyambungkan dan menggunakan data di seluruh ruang kerja, sehingga tidak memblokir kolaborasi pada data dan proyek yang sama.
Merencanakan model izin Anda
Integrasi Git dan alur penyebaran memerlukan izin yang berbeda dari sekadar izin ruang kerja. Baca tentang persyaratan izin untuk integrasi Git dan alur penyebaran.
Untuk menerapkan alur kerja yang aman dan mudah, rencanakan siapa yang mendapatkan akses ke setiap bagian lingkungan yang digunakan, baik repositori Git maupun tahap dev/test/prod dalam alur. Beberapa pertimbangan yang perlu dipertimbangkan adalah:
Siapa harus memiliki akses ke kode sumber di repositori Git?
Operasi mana yang harus dapat dilakukan pengguna dengan akses alur di setiap tahap?
Siapa meninjau konten dalam tahap pengujian?
Haruskah peninjau tahap pengujian memiliki akses ke alur?
Siapa harus mengawasi penyebaran ke tahap produksi?
Ruang kerja mana yang Anda tetapkan ke alur, atau menyambungkan ke git?
Cabang mana yang Anda sambungkan ke ruang kerja? Apa kebijakan yang ditentukan untuk cabang tersebut?
Apakah ruang kerja dibagikan oleh beberapa anggota tim? Haruskah mereka membuat perubahan langsung di ruang kerja, atau hanya melalui permintaan Pull?
Tahap mana yang Anda tetapkan untuk ruang kerja Anda?
Apakah Anda perlu membuat perubahan pada izin ruang kerja yang Anda tetapkan?
Sambungkan tahapan yang berbeda ke database yang berbeda
Database produksi harus selalu stabil dan tersedia. Yang terbaik adalah tidak membebaninya dengan kueri yang dihasilkan oleh pembuat BI untuk model semantik pengembangan atau pengujian mereka. Bangun database terpisah untuk pengembangan dan pengujian untuk melindungi data produksi dan tidak membebani database pengembangan dengan seluruh volume data produksi.
Menggunakan parameter untuk konfigurasi yang akan berubah antar tahap
Jika memungkinkan, tambahkan parameter ke definisi apa pun yang mungkin berubah antara tahap dev/test/prod. Menggunakan parameter membantu Anda mengubah definisi dengan mudah saat Anda memindahkan perubahan ke produksi. Meskipun masih belum ada cara terpadu untuk mengelola parameter di Fabric, sebaiknya gunakan pada item yang mendukung semua jenis parameterisasi.
Parameter memiliki kegunaan yang berbeda, seperti menentukan koneksi ke sumber data, atau ke item internal di Fabric. Mereka juga dapat digunakan untuk membuat perubahan pada kueri, filter, dan teks yang ditampilkan kepada pengguna.
Dalam alur penyebaran, Anda dapat mengonfigurasi aturan parameter untuk mengatur nilai yang berbeda untuk setiap tahap penyebaran.
Pengembangan
Bagian ini menyediakan panduan untuk bekerja dengan alur penyebaran dan menggunakan kecocokan untuk tahap pengembangan Anda.
Mencadangkan pekerjaan Anda ke repositori Git
Dengan integrasi Git, setiap pengembang dapat mencadangkan pekerjaan mereka dengan menerapkannya ke Git. Untuk mencadangkan pekerjaan Anda dengan benar di Fabric, berikut adalah beberapa aturan dasar:
Pastikan Anda memiliki lingkungan terisolasi untuk bekerja, sehingga orang lain tidak mengambil alih pekerjaan Anda sebelum diterapkan. Ini berarti bekerja di alat Desktop (seperti Visual Studio Code, Power BI Desktop atau lainnya), atau di ruang kerja terpisah yang tidak dapat diakses pengguna lain.
Terapkan ke cabang yang Anda buat dan tidak ada pengembang lain yang menggunakan. Jika Anda menggunakan ruang kerja sebagai lingkungan penulisan, baca tentang bekerja dengan cabang.
Terapkan perubahan bersama-sama yang harus disebarkan bersama-sama. Saran ini berlaku untuk satu item, atau beberapa item yang terkait dengan perubahan yang sama. Menerapkan semua perubahan terkait bersama-sama dapat membantu Anda nanti saat menyebarkan ke tahap lain, membuat permintaan pull, atau mengembalikan perubahan kembali.
Penerapan besar mungkin mencapai batas ukuran penerapan maks. Perhatikan jumlah item yang Anda terapkan bersama-sama, atau ukuran umum item. Misalnya, laporan dapat tumbuh besar saat menambahkan gambar besar. Ini adalah praktik buruk untuk menyimpan item berukuran besar dalam sistem kontrol sumber, bahkan jika berfungsi. Pertimbangkan cara untuk mengurangi ukuran item Anda jika memiliki banyak sumber daya statis, seperti gambar.
Menggulung balik perubahan
Setelah Anda mencadangkan pekerjaan, mungkin ada kasus di mana Anda ingin kembali ke versi sebelumnya dan memulihkannya di ruang kerja. Ada beberapa cara untuk kembali ke versi sebelumnya:
Tombol Batalkan: Operasi Batalkan adalah cara yang mudah dan cepat untuk mengembalikan perubahan langsung yang Anda buat, selama belum dilakukan. Anda juga dapat membatalkan setiap item secara terpisah. Baca selengkapnya tentang operasi batalkan.
Kembali ke penerapan yang lebih lama: Tidak ada cara langsung untuk kembali ke penerapan sebelumnya di UI. Opsi terbaik adalah mempromosikan penerapan yang lebih lama menjadi HEAD menggunakan git revert atau git reset. Melakukan ini menunjukkan bahwa ada pembaruan di panel kontrol sumber, dan Anda bisa memperbarui ruang kerja dengan penerapan baru tersebut.
Karena data tidak disimpan di Git, perlu diingat bahwa mengembalikan item data ke versi yang lebih lama mungkin merusak data yang ada dan mungkin mengharuskan Anda untuk menghilangkan data atau operasi mungkin gagal. Periksa terlebih dahulu sebelum mengembalikan perubahan.
Bekerja dengan ruang kerja 'privat'
Saat Anda ingin bekerja dalam isolasi, gunakan ruang kerja terpisah sebagai lingkungan yang terisolasi. Baca selengkapnya tentang mengisolasi lingkungan kerja Anda dalam bekerja dengan cabang. Untuk alur kerja yang optimal bagi Anda dan tim, pertimbangkan poin-poin berikut:
Menyiapkan ruang kerja: Sebelum memulai, pastikan Anda dapat membuat ruang kerja baru (jika Anda belum memilikinya), yang dapat Anda tetapkan ke kapasitas Fabric, dan Anda memiliki akses ke data untuk bekerja di ruang kerja Anda.
Membuat cabang baru: Buat cabang baru dari cabang utama , sehingga Anda memiliki versi terbaru dari konten Anda. Pastikan juga Anda terhubung ke folder yang benar di cabang, sehingga Anda dapat menarik konten yang tepat ke ruang kerja.
Perubahan kecil dan sering: Ini adalah praktik terbaik Git untuk membuat perubahan inkremental kecil yang mudah digabungkan dan cenderung tidak mengalami konflik. Jika itu tidak memungkinkan, pastikan untuk memperbarui cabang Anda dari utama sehingga Anda dapat mengatasi konflik sendiri terlebih dahulu.
Perubahan konfigurasi: Jika perlu, ubah konfigurasi di ruang kerja Anda untuk membantu Anda bekerja lebih produktif. Beberapa perubahan dapat mencakup koneksi antara item, atau ke sumber data yang berbeda atau perubahan pada parameter pada item tertentu. Ingatlah bahwa apa pun yang Anda lakukan menjadi bagian dari penerapan dan secara tidak sengaja dapat digabungkan ke cabang utama.
Menggunakan alat Klien untuk mengedit pekerjaan Anda
Untuk item dan alat yang mendukungnya, mungkin lebih mudah untuk bekerja dengan alat klien untuk penulisan, seperti Power BI Desktop untuk model dan laporan semantik, VSCode untuk Notebooks dll. Alat-alat ini dapat menjadi lingkungan pengembangan lokal Anda. Setelah Anda menyelesaikan pekerjaan, dorong perubahan ke repositori jarak jauh, dan sinkronkan ruang kerja untuk mengunggah perubahan. Pastikan Anda bekerja dengan struktur item yang didukung yang Sedang Anda tulis. Jika Anda tidak yakin, pertama-tama kloning repositori dengan konten yang sudah disinkronkan ke ruang kerja, lalu mulai penulisan dari sana, tempat struktur sudah ada.
Mengelola ruang kerja dan cabang
Karena ruang kerja hanya dapat dihubungkan ke satu cabang pada satu waktu, disarankan untuk memperlakukan ini sebagai pemetaan 1:1. Namun, untuk mengurangi jumlah ruang kerja yang diperlukannya, pertimbangkan opsi ini:
Jika pengembang menyiapkan ruang kerja privat dengan semua konfigurasi yang diperlukan, mereka dapat terus menggunakan ruang kerja tersebut untuk cabang mendatang yang mereka buat. Ketika sprint selesai, perubahan Anda digabungkan dan Anda memulai tugas baru baru, cukup alihkan koneksi ke cabang baru di ruang kerja yang sama. Anda juga dapat melakukan ini jika Anda tiba-tiba perlu memperbaiki bug di tengah sprint. Anggap saja sebagai direktori kerja di web.
Pengembang yang menggunakan alat klien (seperti Visual Studio Code, Power BI Desktop, atau lainnya), tidak selalu memerlukan ruang kerja. Mereka dapat membuat cabang dan menerapkan perubahan pada cabang tersebut secara lokal, mendorong mereka ke repositori jarak jauh dan membuat permintaan pull ke cabang utama, semuanya tanpa ruang kerja. Ruang kerja hanya diperlukan sebagai lingkungan pengujian untuk memeriksa bahwa semuanya berfungsi dalam skenario kehidupan nyata. Terserah Anda untuk memutuskan kapan itu harus terjadi.
Menduplikasi item di repositori Git
Untuk menduplikasi item di repositori Git:
- Salin seluruh direktori item.
- Ubah logicalId menjadi sesuatu yang unik untuk ruang kerja yang tersambung tersebut.
- Ubah nama tampilan untuk membedakannya dari item asli dan untuk menghindari kesalahan nama tampilan duplikat.
- Jika perlu, perbarui logicalId dan/atau nama tampilan dalam dependensi apa pun.
Uji
Bagian ini menyediakan panduan untuk bekerja dengan tahap pengujian alur penyebaran.
Mensimulasikan ke lingkungan produksi Anda
Penting untuk melihat bagaimana perubahan yang Anda usulkan akan memengaruhi tahap produksi. Tahap pengujian alur penyebaran memungkinkan Anda mensimulasikan lingkungan produksi nyata untuk tujuan pengujian. Atau, Anda dapat mensimulasikan ini dengan menghubungkan Git ke ruang kerja lain.
Pastikan bahwa ketiga faktor ini ditangani di lingkungan pengujian Anda:
Volume data
Volume penggunaan
Kapasitas serupa seperti dalam produksi
Saat pengujian, Anda dapat menggunakan kapasitas yang sama dengan tahap produksi. Namun, menggunakan kapasitas yang sama dapat membuat produksi tidak stabil selama pengujian beban. Untuk menghindari produksi yang tidak stabil, uji menggunakan kapasitas berbeda yang mirip dalam sumber daya dengan kapasitas produksi. Untuk menghindari biaya tambahan, gunakan kapasitas di mana Anda hanya dapat membayar untuk waktu pengujian.
Menggunakan aturan penyebaran dengan sumber data kehidupan nyata
Jika Anda menggunakan tahap pengujian untuk mensimulasikan penggunaan data kehidupan nyata, yang terbaik adalah memisahkan sumber data pengembangan dan pengujian. Database pengembangan harus relatif kecil, dan database pengujian harus semirip mungkin dengan database produksi. Gunakan aturan sumber data untuk mengalihkan sumber data dalam tahap pengujian atau membuat parameter koneksi jika tidak bekerja melalui alur penyebaran.
Memeriksa item terkait
Perubahan yang Anda buat juga dapat memengaruhi item dependen. Selama pengujian, verifikasi bahwa perubahan Anda tidak memengaruhi atau memutus performa item yang ada, yang dapat bergantung pada yang diperbarui.
Anda dapat dengan mudah menemukan item terkait dengan menggunakan analisis dampak.
Memperbarui item data
Item data adalah item yang menyimpan data. Definisi item di Git menentukan bagaimana data disimpan. Saat memperbarui item di ruang kerja, kami mengimpor definisinya ke ruang kerja dan menerapkannya pada data yang ada. Operasi memperbarui item data sama untuk Git dan alur penyebaran.
Karena item yang berbeda memiliki kemampuan yang berbeda dalam hal menyimpan data ketika perubahan pada definisi diterapkan, berhati-hatilah saat menerapkan perubahan. Beberapa praktik yang dapat membantu Anda menerapkan perubahan dengan cara yang paling aman:
Ketahui terlebih dahulu apa itu perubahan dan apa dampaknya pada data yang ada. Gunakan pesan penerapan untuk menjelaskan perubahan yang dibuat.
Untuk melihat bagaimana item tersebut menangani perubahan dengan data pengujian, unggah perubahan terlebih dahulu ke lingkungan pengembangan atau pengujian.
Jika semuanya berjalan dengan baik, disarankan untuk juga memeriksanya pada lingkungan penahapan, dengan data kehidupan nyata (atau sedekat mungkin), untuk meminimalkan perilaku tak terduga dalam produksi.
Pertimbangkan waktu terbaik saat memperbarui lingkungan Prod untuk meminimalkan kerusakan yang mungkin disebabkan oleh pengguna bisnis Anda yang menggunakan data.
Setelah penyebaran, pengujian pasca-penyebaran di Prod untuk memverifikasi bahwa semuanya berfungsi seperti yang diharapkan.
Beberapa perubahan akan selalu dianggap melanggar perubahan. Mudah-mudahan, langkah-langkah sebelumnya akan membantu Anda melacaknya sebelum produksi. Buat rencana tentang cara menerapkan perubahan di Prod dan memulihkan data untuk kembali ke status normal dan meminimalkan waktu henti bagi pengguna bisnis.
Menguji aplikasi Anda
Jika Anda mendistribusikan konten kepada pelanggan melalui aplikasi, tinjau versi baru aplikasi sebelum dalam produksi. Karena setiap tahap alur penyebaran memiliki ruang kerjanya sendiri, Anda dapat dengan mudah menerbitkan dan memperbarui aplikasi untuk tahap pengembangan dan pengujian. Menerbitkan dan memperbarui aplikasi memungkinkan Anda menguji aplikasi dari sudut pandang pengguna akhir.
Penting
Proses penyebaran tidak termasuk memperbarui konten atau pengaturan aplikasi. Untuk menerapkan perubahan pada konten atau pengaturan, perbarui aplikasi secara manual di tahap alur yang diperlukan.
Produksi
Bagian ini menyediakan panduan untuk tahap produksi alur penyebaran.
Mengelola siapa yang dapat menyebarkan ke produksi
Karena penyebaran ke produksi harus ditangani dengan hati-hati, adalah praktik yang baik untuk membiarkan hanya orang tertentu yang mengelola operasi sensitif ini. Namun, Anda mungkin ingin semua pembuat BI untuk ruang kerja tertentu memiliki akses ke alur. Gunakan izin ruang kerja produksi untuk mengelola izin akses. Pengguna lain dapat memiliki peran penampil ruang kerja produksi untuk melihat konten di ruang kerja tetapi tidak membuat perubahan dari Git atau alur penyebaran.
Selain itu, batasi akses ke repositori atau alur hanya dengan mengaktifkan izin kepada pengguna yang merupakan bagian dari proses pembuatan konten.
Menetapkan aturan untuk memastikan ketersediaan tahap produksi
Aturan penyebaran adalah cara yang ampuh untuk memastikan data dalam produksi selalu terhubung dan tersedia untuk pengguna. Dengan diterapkannya aturan penyebaran, penyebaran dapat berjalan saat Anda memiliki jaminan bahwa pelanggan dapat melihat informasi yang relevan tanpa gangguan.
Pastikan Anda menetapkan aturan penyebaran produksi untuk sumber data dan parameter yang ditentukan dalam model semantik.
Memperbarui aplikasi produksi
Penyebaran dalam alur melalui UI memperbarui konten ruang kerja. Untuk memperbarui aplikasi terkait, gunakan API alur penyebaran. Tidak dimungkinkan untuk memperbarui aplikasi melalui UI. Jika Anda menggunakan aplikasi untuk distribusi konten, jangan lupa untuk memperbarui aplikasi setelah menyebarkan ke produksi sehingga pengguna akhir segera dapat menggunakan versi terbaru.
Menyebarkan ke dalam produksi menggunakan cabang Git
Karena repositori berfungsi sebagai 'sumber kebenaran tunggal', beberapa tim mungkin ingin menyebarkan pembaruan ke berbagai tahap langsung dari Git. Ini dimungkinkan dengan integrasi Git, dengan beberapa pertimbangan:
Sebaiknya gunakan cabang rilis. Anda perlu terus mengubah koneksi ruang kerja ke cabang rilis baru sebelum setiap penyebaran.
Jika alur build atau rilis mengharuskan Anda mengubah kode sumber, atau menjalankan skrip di lingkungan build sebelum penyebaran ke ruang kerja, maka menyambungkan ruang kerja ke Git tidak akan membantu Anda.
Setelah menyebarkan ke setiap tahap, pastikan untuk mengubah semua konfigurasi khusus untuk tahap tersebut.
Perbaikan cepat pada konten
Terkadang ada masalah dalam produksi yang memerlukan perbaikan cepat. Menyebarkan perbaikan tanpa mengujinya terlebih dahulu adalah praktik yang buruk. Oleh karena itu, selalu terapkan perbaikan dalam tahap pengembangan dan dorong ke tahap alur penyebaran lainnya. Menyebarkan ke tahap pengembangan memungkinkan Anda memeriksa apakah perbaikan berfungsi sebelum menyebarkannya ke produksi. Penyebaran di seluruh alur hanya membutuhkan waktu beberapa menit.
Jika Anda menggunakan penyebaran dari Git, sebaiknya ikuti praktik yang dijelaskan dalam Mengadopsi strategi pencabangan Git.
Konten terkait
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk