Skenario penggunaan Power BI: Penerbitan konten perusahaan

Catatan

Artikel ini merupakan bagian dari rangkaian artikel Perencanaan implementasi Power BI. Seri ini berfokus terutama pada beban kerja Power BI dalam Microsoft Fabric. Untuk pengantar rangkaian ini, lihat Perencanaan implementasi Power BI.

Ketika pembuat konten berkolaborasi untuk memberikan solusi analitis yang penting bagi organisasi, mereka harus memastikan pengiriman konten yang tepat waktu dan andal kepada konsumen. Tim teknis mengatasi tantangan ini dengan menggunakan proses yang disebut DevOps. DevOps memungkinkan tim untuk mengotomatiskan dan menskalakan proses dengan mengadopsi praktik yang meningkatkan dan mempercepat pengiriman.

Catatan

Tim data yang mengatasi tantangan yang sama mungkin juga mempraktikkan DataOps. DataOps dibangun berdasarkan prinsip DevOps, tetapi DataOps menyertakan praktik tambahan khusus untuk manajemen data, seperti jaminan dan tata kelola kualitas data. Kami merujuk ke DevOps dalam artikel ini, tetapi ketahuilah bahwa prinsip-prinsip yang mendasarinya juga dapat berlaku untuk DataOps.

Pembuat konten dan konsumen mendapat manfaat dari beberapa keuntungan saat mengadopsi praktik DevOps untuk menerbitkan konten Power BI. Poin-poin berikut adalah gambaran umum tingkat tinggi tentang cara kerja proses ini.

1. Mengembangkan konten dan menerapkan pekerjaan ke repositori jarak jauh: Pembuat konten mengembangkan solusi mereka di komputer mereka sendiri. Mereka menerapkan dan menyimpan pekerjaan mereka ke repositori jarak jauh secara berkala selama pengembangan. Repositori jarak jauh berisi versi terbaru solusi, dan dapat diakses oleh seluruh tim pengembangan.
2. Berkolaborasi dan mengelola perubahan konten dengan menggunakan kontrol versi: Pembuat konten lain dapat membuat revisi solusi dengan membuat cabang. Cabang adalah salinan repositori jarak jauh. Ketika revisi ini siap dan disetujui, cabang digabungkan dengan versi terbaru solusi. Semua revisi solusi dilacak. Proses ini dikenal sebagai kontrol versi (atau kontrol sumber).
3. Menyebarkan dan mempromosikan konten dengan menggunakan alur: Dalam skenario penggunaan penerbitan konten layanan mandiri, konten dipromosikan (atau disebarkan) melalui ruang kerja pengembangan, pengujian, dan produksi dengan menggunakan alur penyebaran Power BI. Alur penyebaran Power BI dapat mempromosikan konten ke ruang kerja Power BI Premium secara manual menggunakan antarmuka pengguna, atau secara terprogram menggunakan REST API. Sebaliknya, penerbitan konten perusahaan (fokus skenario penggunaan ini) mempromosikan konten dengan menggunakan Azure Pipelines. Azure Pipelines adalah layanan Azure DevOps yang mengotomatiskan pengujian, manajemen, dan penyebaran konten dengan menggunakan serangkaian langkah terprogram yang disesuaikan. Dalam skenario penggunaan penerbitan konten perusahaan, alur ini juga dapat disebut sebagai alur integrasi dan penyebaran berkelanjutan (atau CI/CD). Alur ini sering dan otomatis mengintegrasikan perubahan dan menyederhanakan penerbitan konten.

Penting

Terkadang artikel ini mengacu pada Power BI Premium atau langganan kapasitasnya (SKU P). Ketahuilah bahwa Microsoft saat ini mengonsolidasikan opsi pembelian dan menghentikan SKU Power BI Premium per kapasitas. Pelanggan baru dan yang sudah ada harus mempertimbangkan untuk membeli langganan kapasitas Fabric (F SKU) sebagai gantinya.

Untuk informasi selengkapnya, lihat Pembaruan penting yang masuk ke lisensi Power BI Premium dan Tanya Jawab Umum Power BI Premium.

DevOps mendukung pendekatan yang matang dan sistematis untuk manajemen dan publikasi konten. Ini memungkinkan pembuat konten untuk berkolaborasi pada solusi, dan memastikan pengiriman konten yang cepat dan andal kepada konsumen. Saat Anda mematuhi praktik DevOps, Anda mendapat manfaat dari alur kerja yang disederhanakan, lebih sedikit kesalahan, dan pengalaman yang ditingkatkan untuk pembuat konten dan konsumen konten.

Anda menyiapkan dan mengelola praktik DevOps untuk solusi Power BI Anda dengan menggunakan Azure DevOps. Dalam skenario perusahaan, Anda dapat mengotomatiskan publikasi konten dengan Azure DevOps dan REST API Power BI dengan tiga cara berbeda.

• REST API Power BI dengan alur penyebaran Power BI: Anda dapat mengimpor konten ke ruang kerja pengembangan dan menggunakan alur penyebaran untuk menyebarkan konten melalui ruang kerja pengujian dan produksi. Anda masih mengontrol penyebaran dari Azure DevOps, dan menggunakan REST API Power BI untuk mengelola alur penyebaran alih-alih item konten individual. Selain itu, Anda menggunakan titik akhir XMLA untuk menyebarkan metadata model data alih-alih file Power BI Desktop (.pbix) dengan Azure DevOps. Metadata ini memungkinkan Anda melacak perubahan tingkat objek dengan menggunakan kontrol versi. Meskipun lebih kuat dan lebih mudah dipertahankan, pendekatan ini memang memerlukan lisensi Premium dan upaya pembuatan skrip sedang untuk menyiapkan impor dan penyebaran konten dengan REST API Power BI. Gunakan pendekatan ini saat Anda ingin menyederhanakan manajemen siklus hidup konten dengan alur penyebaran, dan Anda memiliki lisensi Premium. Titik akhir XMLA dan alur penyebaran Power BI adalah fitur Premium.
• REST API Power BI: Anda juga dapat mengimpor konten ke ruang kerja pengembangan, pengujian, dan produksi dengan menggunakan Azure DevOps dan hanya REST API Power BI. Pendekatan ini tidak memerlukan lisensi Premium, tetapi melibatkan upaya dan penyiapan pembuatan skrip yang tinggi, karena penyebaran dikelola di luar Power BI. Gunakan pendekatan ini saat Anda ingin menyebarkan konten Power BI secara terpusat dari Azure DevOps, atau saat Anda tidak memiliki lisensi Premium. Untuk perbandingan visual antara dua pendekatan pertama, lihat diagram alur rilis mendekati alur.
• Alat otomatisasi Power BI dengan alur penyebaran Power BI: Anda bisa menggunakan alat otomatisasi Power BI ekstensi Azure DevOps untuk mengelola alur penyebaran alih-alih REST API Power BI. Pendekatan ini adalah alternatif untuk opsi pertama, yang menggunakan REST API Power BI dengan alur penyebaran Power BI. Ekstensi alat otomatisasi Power BI adalah alat sumber terbuka. Ini membantu Anda mengelola dan menerbitkan konten dari Azure DevOps tanpa perlu menulis skrip PowerShell. Gunakan pendekatan ini saat Anda ingin mengelola alur penyebaran dari Azure DevOps dengan upaya pembuatan skrip minimal, dan Anda memiliki kapasitas Premium.

Artikel ini berfokus pada opsi pertama, yang menggunakan REST API Power BI dengan alur penyebaran Power BI. Ini menjelaskan bagaimana Anda dapat menggunakan Azure DevOps untuk menyiapkan praktik DevOps. Ini juga menjelaskan bagaimana Anda dapat menggunakan Azure Repos untuk repositori jarak jauh Anda dan mengotomatiskan pengujian, integrasi, dan pengiriman konten dengan Azure Pipelines. Azure DevOps bukan satu-satunya cara untuk menyiapkan penerbitan konten perusahaan, tetapi integrasi sederhana dengan Power BI menjadikannya pilihan yang baik.

Catatan

Skenario penggunaan ini adalah salah satu skenario manajemen konten dan penyebaran . Singkatnya, beberapa aspek yang dijelaskan dalam topik kolaborasi konten dan skenario pengiriman tidak dibahas dalam artikel ini. Untuk cakupan lengkap, baca artikel tersebut terlebih dahulu.

Tip

Microsoft Fabric menyediakan opsi lain untuk penerbitan konten perusahaan dengan menggunakan integrasi Fabric Git. Integrasi Git memungkinkan Anda menautkan ruang kerja Fabric ke cabang di repositori jarak jauh Azure Repos Anda. Konten yang disimpan ke cabang tersebut akan disinkronkan ke ruang kerja secara otomatis, seolah-olah konten tersebut diterbitkan ke ruang kerja. Sebaliknya, pembuat konten dapat menerapkan dan mendorong perubahan dari ruang kerja Fabric ke repositori jarak jauh.

Integrasi Git dapat menyederhanakan kolaborasi dan penerbitan konten, tetapi memerlukan lebih banyak perencanaan tentang bagaimana Anda akan menggunakan ruang kerja Fabric dan apa strategi pencabangan Anda. Untuk informasi selengkapnya tentang cara menyiapkan dan menggunakan integrasi Fabric Git, lihat Mulai menggunakan integrasi Git atau Tutorial: Manajemen siklus hidup end to end.

Diagram skenario

Diagram berikut menggambarkan gambaran umum tingkat tinggi tentang tindakan pengguna dan komponen Power BI yang paling umum yang mendukung penerbitan konten perusahaan. Fokusnya adalah pada penggunaan Azure DevOps untuk mengelola dan menerbitkan konten secara terprogram dalam skala besar melalui ruang kerja pengembangan, pengujian, dan produksi di layanan Power BI.

Tip

Kami mendorong Anda untuk mengunduh diagram skenario jika Anda ingin menyematkannya dalam presentasi, dokumentasi, atau posting blog Anda—atau mencetaknya sebagai poster dinding. Karena ini adalah gambar Scalable Vector Graphics (SVG), Anda dapat meningkatkan atau menurunkan skalanya tanpa kehilangan kualitas.

Diagram skenario menggambarkan tindakan, proses, dan fitur pengguna berikut.

Benda	Keterangan
	Pembuat konten mengembangkan model data dengan menggunakan Power BI Desktop atau Editor Tabular, dan mereka mengembangkan laporan dengan menggunakan Power BI Desktop. Pembuat konten menyimpan pekerjaan mereka ke repositori lokal selama pengembangan.
	Pembuat konten dapat mengkloning repositori jarak jauh untuk mendapatkan salinan lokal konten tersebut.
	Beberapa sumber data mungkin memerlukan gateway data lokal atau gateway VNet untuk refresh data, seperti yang berada dalam jaringan organisasi privat.
	Pembuat konten secara teratur menerapkan dan mendorong perubahan mereka ke repositori jarak jauh selama pengembangan dengan menggunakan klien Git seperti Visual Studio Code. Dalam diagram, repositori jarak jauh adalah Azure Repos.
	Pembuat konten lain menggunakan Azure Repos untuk melacak perubahan dengan kontrol versi. Mereka berkolaborasi dengan melakukan perubahan menjadi cabang terpisah.
	Perubahan pada konten di repositori jarak jauh memicu Azure Pipelines. Alur validasi adalah alur pertama yang dipicu. Alur validasi melakukan pengujian otomatis untuk memvalidasi konten sebelum diterbitkan.
	Konten yang melewati alur validasi memicu alur build berikutnya. Alur build menyiapkan konten untuk penerbitan ke layanan Power BI. Proses hingga titik ini biasanya disebut sebagai integrasi berkelanjutan (CI).
	Konten diterbitkan dan disebarkan dengan menggunakan alur rilis. Alur rilis menggunakan REST API Power BI atau titik akhir XMLA ruang kerja untuk mengimpor konten secara terprogram ke layanan Power BI. Penyebaran dengan menggunakan alur rilis biasanya disebut sebagai penyebaran berkelanjutan (CD).
	Manajer rilis mengontrol penyebaran untuk menguji dan produksi ruang kerja dengan menggunakan persetujuan rilis Azure Pipelines. Dalam penerbitan konten perusahaan, manajer rilis biasanya merencanakan dan mengoordinasikan rilis konten untuk lingkungan pengujian dan produksi. Mereka berkoordinasi dan berkomunikasi dengan pembuat konten, pemangku kepentingan, dan pengguna.
	Alur rilis menerbitkan konten ke ruang kerja pengembangan, atau mempromosikan konten dari pengembangan ke ruang kerja pengujian, atau menguji ke ruang kerja produksi.
	Pembuat konten yang bekerja di ruang kerja yang memiliki mode lisensi kapasitas Fabric dapat menggunakan integrasi Git. Dengan integrasi Git, pembuat konten dapat bekerja di ruang kerja privat selama pengembangan. Pembuat konten menyinkronkan cabang jarak jauh (biasanya cabang fitur tertentu atau cabang bug) dari Azure Repos ke ruang kerja privat mereka. Perubahan konten disinkronkan antara cabang jarak jauh di Azure Repos dan ruang kerja. Dalam skenario ini, pembuat konten tidak perlu menggunakan Azure Pipelines untuk menerbitkan konten. Pembuat konten juga dapat secara teratur menerapkan dan mendorong perubahan dari ruang kerja setelah penerbitan. Setelah siap, pembuat konten dapat membuat permintaan pull (PR) untuk menggabungkan perubahannya ke cabang utama.
	Saat menggunakan integrasi Git, ruang kerja pengembangan disinkronkan dengan cabang utama untuk mendapatkan versi konten terbaru. Konten ini mencakup semua perubahan dari permintaan pull yang ditinjau, disetujui, dan digabungkan oleh manajer rilis.
	Ruang kerja diatur ke kapasitas Fabric, kapasitas Premium, Premium per pengguna, atau mode lisensi Tersemat, untuk memungkinkan penggunaan alur penyebaran Power BI dan titik akhir baca/tulis XMLA.
	Administrator alur penyebaran menyiapkan alur penyebaran Power BI dengan tiga tahap: pengembangan, pengujian, dan produksi. Setiap tahap selaras dengan ruang kerja terpisah di layanan Power BI. Pengaturan penyebaran dan akses diatur untuk alur penyebaran.
	Ruang kerja pengembangan berisi versi terbaru konten termasuk semua perubahan yang disetujui dan digabungkan. Setelah disetujui, alur rilis menyebarkan konten dari pengembangan ke ruang kerja pengujian.
	Peninjau dalam ruang kerja pengujian melakukan pengujian dan jaminan kualitas pada konten. Setelah disetujui, alur rilis menyebarkan konten dari pengujian ke ruang kerja produksi. Saat menggunakan integrasi Git dengan alur penyebaran, ruang kerja pengujian tidak disinkronkan dengan cabang apa pun.
	Setelah alur penyebaran selesai penyebaran, pembuat konten secara manual melakukan aktivitas pasca-penyebaran. Aktivitas dapat mencakup penyiapan refresh data terjadwal atau memperbarui aplikasi Power BI untuk ruang kerja produksi. Saat menggunakan integrasi Git dengan alur penyebaran, ruang kerja produksi tidak disinkronkan dengan cabang apa pun.
	Penampil konten mengakses konten dengan menggunakan ruang kerja produksi atau aplikasi Power BI.

Tip

Sebaiknya Anda juga meninjau penerbitan konten layanan mandiri dan skenario penggunaan manajemen model data tingkat lanjut. Skenario penggunaan penerbitan konten perusahaan dibangun berdasarkan konsep yang diperkenalkan skenario ini.

Poin-poin penting

Berikut ini adalah beberapa poin penting untuk ditekankan tentang skenario penerbitan konten perusahaan.

Kontrol versi

Melacak perubahan selama siklus hidup konten penting untuk memastikan pengiriman konten yang stabil dan konsisten kepada konsumen. Dalam skenario penggunaan ini, pembuat konten dan pemilik mengelola perubahan konten di repositori jarak jauh dengan menggunakan kontrol versi. Kontrol versi adalah praktik mengelola perubahan pada file atau kode di repositori pusat. Praktik ini memungkinkan kolaborasi yang lebih baik dan manajemen riwayat versi yang efektif. Kontrol versi memiliki keuntungan bagi pembuat konten, termasuk kemampuan untuk mengembalikan atau menggabungkan perubahan.

Pembuat konten biasanya mengembangkan model data di Editor Tabular untuk mendukung kontrol versi yang lebih baik. Tidak seperti model data yang Anda kembangkan di Power BI Desktop, model data yang dikembangkan di Editor Tabular disimpan dalam format metadata yang dapat dibaca manusia. Format ini memungkinkan kontrol versi tingkat objek model data. Anda harus menggunakan kontrol versi tingkat objek saat berkolaborasi dengan beberapa orang pada model data yang sama. Untuk informasi selengkapnya, lihat skenario penggunaan manajemen model data tingkat lanjut. Tidak dimungkinkan untuk melihat perubahan yang Anda buat dalam file Power BI Desktop (.pbix), seperti definisi laporan atau model data. Misalnya, Anda tidak dapat melacak perubahan pada halaman laporan, seperti visual yang digunakan, posisinya, dan pemetaan atau pemformatan bidangnya.

Pembuat konten menyimpan file metadata model data dan file .pbix di repositori jarak jauh pusat, seperti Azure Repos. File-file ini dikumpulkan oleh pemilik teknis. Meskipun pembuat konten mengembangkan solusi, pemilik teknis bertanggung jawab untuk mengelola solusi dan meninjau perubahan, dan menggabungkannya menjadi satu solusi. Azure Repos menyediakan opsi canggih untuk melacak dan mengelola perubahan. Pendekatan ini berbeda dari pendekatan yang dijelaskan dalam skenario penggunaan penerbitan konten layanan mandiri, di mana pembuat menggunakan penyimpanan OneDrive dengan pelacakan versi. Mempertahankan repositori yang didokumentasikan dengan baik sangat penting karena merupakan dasar dari semua konten dan kolaborasi.

Berikut adalah beberapa pertimbangan utama untuk membantu Anda menyiapkan repositori jarak jauh untuk kontrol versi.

• Cakupan: Tentukan cakupan repositori dengan jelas. Idealnya, cakupan repositori identik dengan cakupan ruang kerja hilir dan aplikasi yang Anda gunakan untuk mengirimkan konten kepada konsumen.
• Akses: Anda harus menyiapkan akses ke repositori dengan menggunakan model izin serupa seperti yang telah Anda siapkan untuk izin alur penyebaran dan peran ruang kerja Anda. Pembuat konten memerlukan akses ke repositori.
• Dokumentasi: Tambahkan file teks ke repositori untuk mendokumen tujuan, kepemilikan, akses, dan proses yang ditentukan. Misalnya, dokumentasi dapat menjelaskan bagaimana perubahan harus ditahapkan dan diterapkan.
• Alat: Untuk menerapkan dan mendorong perubahan ke repositori jarak jauh, pembuat konten memerlukan klien Git seperti Visual Studio atau Visual Studio Code. Git adalah sistem kontrol versi terdistribusi yang melacak perubahan dalam file Anda. Untuk mempelajari dasar-dasar Git, lihat Apa itu Git?.

Catatan

Pertimbangkan untuk menggunakan Git Large File Storage (LFS) jika Anda berencana untuk menerapkan file Power BI Desktop (.pbix). Git LFS menyediakan opsi tingkat lanjut untuk mengelola file di mana perubahan tidak terlihat (file yang tidak dapat diblokir), seperti file .pbix. Misalnya, Anda dapat menggunakan penguncian file untuk mencegah perubahan bersamaan pada laporan Power BI selama pengembangan. Namun, Git LFS memiliki klien dan konfigurasinya sendiri.

Kolaborasi dengan Azure DevOps

Ketika solusi meningkat dalam cakupan dan kompleksitas, mungkin perlu bagi beberapa pembuat konten dan pemilik untuk bekerja dalam kolaborasi. Pembuat dan pemilik konten berkomunikasi dan berkolaborasi di hub pusat yang terorganisir dengan menggunakan Azure DevOps.

Untuk berkolaborasi dan berkomunikasi di Azure DevOps, Anda menggunakan layanan pendukung.

• Azure Boards: Pemilik konten menggunakan papan untuk melacak item kerja. Item kerja masing-masing ditetapkan ke satu pengembang di tim, dan mereka menjelaskan masalah, bug, atau fitur dalam solusi, dan pemangku kepentingan yang sesuai.
• Azure Wiki: Pembuat konten berbagi informasi dengan tim mereka untuk memahami dan berkontribusi pada solusi.
• Azure Repos: Pembuat konten melacak perubahan di repositori jarak jauh dan menggabungkannya menjadi satu solusi.
• Azure Pipelines: Pemilik alur menyiapkan logika terprogram untuk menyebarkan solusi, baik secara otomatis atau sesuai permintaan.

Diagram alur kolaborasi

Diagram berikut menggambarkan gambaran umum tingkat tinggi tentang salah satu contoh bagaimana Azure DevOps memungkinkan kolaborasi dalam skenario penggunaan penerbitan konten perusahaan. Fokus diagram ini adalah pada penggunaan Azure DevOps untuk membuat proses penerbitan konten terstruktur dan terdokumentasi.

Diagram menggambarkan tindakan, proses, dan fitur pengguna berikut.

Benda	Keterangan
	Pembuat konten membuat cabang baru berumur pendek dengan mengkloning cabang utama, yang berisi versi terbaru konten. Cabang baru sering disebut sebagai cabang fitur , karena digunakan untuk mengembangkan fitur tertentu atau memperbaiki masalah tertentu.
	Pembuat konten menerapkan perubahannya pada repositori lokal selama pengembangan.
	Pembuat konten menautkan perubahannya ke item kerja yang dikelola di Azure Boards. Item karya menjelaskan pengembangan, peningkatan, atau perbaikan bug tertentu yang tercakup ke cabang mereka.
	Pembuat konten secara teratur menerapkan perubahan mereka. Setelah siap, pembuat konten menerbitkan cabang mereka ke repositori jarak jauh.
	Untuk menguji perubahannya, pembuat konten menyebarkan solusi mereka ke ruang kerja terisolasi untuk pengembangannya (tidak ditampilkan dalam diagram ini). Pembuat konten juga dapat menyinkronkan cabang fitur ke ruang kerja dengan menggunakan integrasi Fabric Git.
	Pembuat konten dan pemilik konten mendokumenkan solusi dan prosesnya di Azure Wiki, yang tersedia untuk seluruh tim pengembangan.
	Setelah siap, pembuat konten membuka permintaan pull untuk menggabungkan cabang fitur ke cabang utama.
	Pemilik teknis bertanggung jawab untuk meninjau permintaan pull dan menggabungkan perubahan. Ketika mereka menyetujui permintaan pull, mereka menggabungkan cabang fitur ke cabang utama.
	Penggabungan yang berhasil memicu penyebaran solusi ke ruang kerja pengembangan dengan menggunakan Azure Pipeline (tidak diperlihatkan dalam diagram ini). Saat menggunakan integrasi Fabric Git, cabang utama disinkronkan ke ruang kerja pengembangan.
	Manajer rilis melakukan tinjauan akhir dan persetujuan solusi. Persetujuan rilis ini mencegah solusi diterbitkan sebelum siap. Dalam penerbitan konten perusahaan, manajer rilis biasanya merencanakan dan mengoordinasikan rilis konten untuk menguji dan produksi ruang kerja. Mereka berkoordinasi dan berkomunikasi dengan pembuat konten, pemangku kepentingan, dan pengguna.
	Saat manajer rilis menyetujui rilis, Azure Pipelines secara otomatis menyiapkan solusi untuk penyebaran. Atau, Azure Pipeline juga dapat memicu alur penyebaran untuk mempromosikan konten antar ruang kerja.
	Pengguna menguji dan memvalidasi konten di ruang kerja pengujian. Saat menggunakan integrasi Git dengan Azure Pipelines untuk penyebaran, ruang kerja pengujian tidak disinkronkan dengan cabang apa pun.
	Setelah pengguna menerima dan memvalidasi perubahan, manajer rilis melakukan tinjauan akhir dan persetujuan solusi untuk disebarkan ke ruang kerja produksi.
	Pengguna menampilkan konten yang diterbitkan ke ruang kerja produksi. Saat menggunakan integrasi Git dengan Azure Pipelines untuk penyebaran, ruang kerja produksi tidak disinkronkan dengan cabang apa pun.

Untuk menguraikan, pembuat konten mencapai kolaborasi dengan menggunakan strategi percabangan. Strategi percabangan adalah cara pembuat konten membuat, menggunakan, dan menggabungkan cabang untuk membuat dan mengelola perubahan konten secara efektif. Pembuat konten individual bekerja dalam isolasi di repositori lokal mereka. Ketika siap, mereka menggabungkan perubahan mereka sebagai solusi tunggal di repositori jarak jauh. Pembuat konten harus mencakup pekerjaan mereka ke cabang dengan menautkannya ke item kerja untuk pengembangan, peningkatan, atau perbaikan bug tertentu. Setiap pembuat konten membuat cabang repositori jarak jauh mereka sendiri untuk cakupan pekerjaan mereka. Pekerjaan yang dilakukan pada solusi lokal mereka diterapkan dan didorong ke versi cabang di repositori jarak jauh dengan pesan penerapan. Pesan penerapan menjelaskan perubahan yang dibuat dalam penerapan tersebut.

Untuk menggabungkan perubahan, pembuat konten membuka permintaan pull. Permintaan pull adalah pengiriman untuk tinjauan serekan yang dapat menyebabkan penggabungan pekerjaan yang dilakukan menjadi satu solusi. Penggabungan dapat mengakibatkan konflik, yang harus diselesaikan sebelum cabang dapat digabungkan. Peninjauan permintaan pull penting untuk memastikan pembuat mematuhi standar dan praktik organisasi untuk pengembangan, kualitas, dan kepatuhan.

Rekomendasi kolaborasi

Kami menyarankan agar Anda menentukan proses terstruktur tentang bagaimana pembuat konten harus berkolaborasi. Pastikan Anda menentukan:

• Cara kerja dicakup dan bagaimana cabang dibuat, dinamai, dan digunakan.
• Bagaimana grup penulis berubah dan menjelaskannya dengan pesan penerapan.
• Siapa bertanggung jawab untuk meninjau dan menyetujui permintaan pull.
• Bagaimana konflik penggabungan diselesaikan.
• Bagaimana perubahan yang dilakukan di cabang yang berbeda digabungkan bersama-sama menjadi satu cabang.
• Bagaimana konten diuji dan siapa yang melakukan pengujian sebelum konten disebarkan.
• Bagaimana dan kapan perubahan disebarkan ke ruang kerja pengembangan, pengujian, dan produksi.
• Bagaimana dan kapan perubahan atau versi solusi yang disebarkan harus digulung balik.

Penting

Nilai yang disediakan oleh DevOps sebanding langsung dengan kepatuhan terhadap proses yang menentukan penggunaannya.

Kolaborasi yang sukses tergantung pada proses yang terdefinisi dengan baik. Penting untuk menjelaskan dan mendokumenkan alur kerja pengembangan end-to-end dengan jelas. Pastikan bahwa strategi dan proses yang dipilih selaras dengan praktik yang ada di tim Anda, dan jika tidak, bagaimana Anda akan mengelola perubahan. Selanjutnya, pastikan bahwa prosesnya jelas dan dikomunikasikan kepada semua anggota tim dan pemangku kepentingan. Pastikan bahwa anggota tim dan pemangku kepentingan yang baru dalam proses dilatih dalam cara mengadopsinya, dan bahwa mereka menghargai nilai adopsi DevOps yang sukses.

REST API Power BI

Anda mengembangkan logika terprogram untuk mengimpor dan menyebarkan konten dari Azure DevOps dengan menggunakan REST API Power BI. Anda mengimpor file Power BI (.pbix) ke ruang kerja dengan menggunakan operasi impor. Anda menggunakan operasi alur untuk menyebarkan beberapa konten atau semua konten untuk menguji atau ruang kerja produksi dengan menggunakan alur penyebaran Power BI. Logika terprogram ditentukan dalam Azure Pipelines.

Kami menyarankan agar Anda menggunakan perwakilan layanan untuk memanggil REST API Power BI di alur Anda. Perwakilan layanan ditujukan untuk aktivitas tanpa pengawas dan otomatis, dan tidak bergantung pada kredensial pengguna. Namun, beberapa item dan aktivitas tidak didukung oleh REST API Power BI atau saat menggunakan perwakilan layanan, seperti aliran data.

Saat Anda menggunakan perwakilan layanan, pastikan untuk mengelola izin dengan hati-hati. Tujuan Anda harus mengikuti prinsip hak istimewa paling sedikit. Anda harus menetapkan izin yang memadai untuk perwakilan layanan tanpa izin provisi berlebihan. Gunakan Azure Key Vault atau layanan lain yang menyimpan rahasia dan kredensial perwakilan layanan dengan aman.

Perhatian

Jika Anda memiliki model data yang disimpan sebagai format metadata yang dapat dibaca manusia, model tersebut tidak dapat diterbitkan dengan menggunakan REST API Power BI. Sebagai gantinya, Anda harus menerbitkannya dengan menggunakan titik akhir XMLA. Anda dapat menerbitkan file metadata dengan menggunakan alat pihak ketiga seperti antarmuka baris perintah (CLI) Editor Tabular. Anda juga dapat menerbitkan file metadata secara terprogram dengan menggunakan pengembangan .NET kustom Anda sendiri. Mengembangkan solusi kustom memerlukan lebih banyak upaya, karena Anda harus menggunakan ekstensi Microsoft Tabular Object Model (TOM) dari pustaka klien Analysis Management Object (AMO).

Azure Pipelines

Azure Pipelines secara terprogram mengotomatiskan pengujian, manajemen, dan penyebaran konten. Saat alur dijalankan, langkah-langkah dalam alur dijalankan secara otomatis. Pemilik alur dapat menyesuaikan pemicu, langkah, dan fungsionalitasnya untuk memenuhi kebutuhan penyebaran. Dengan demikian, jumlah dan jenis alur bervariasi tergantung pada persyaratan solusi. Misalnya, Azure Pipeline dapat menjalankan pengujian otomatis atau memodifikasi parameter model data sebelum penyebaran.

Ada tiga jenis Azure Pipelines yang bisa Anda siapkan untuk menguji, mengelola, dan menyebarkan solusi Power BI Anda:

• Alur validasi.
• Membangun alur.
• Merilis alur.

Catatan

Tidak perlu memiliki ketiga alur ini dalam solusi penerbitan Anda. Bergantung pada alur kerja dan kebutuhan Anda, Anda mungkin menyiapkan satu atau beberapa varian alur yang dijelaskan dalam artikel ini untuk mengotomatiskan publikasi konten. Kemampuan untuk menyesuaikan alur ini adalah keuntungan dari Azure Pipelines melalui alur penyebaran Power BI bawaan. Misalnya, Anda tidak perlu memiliki alur validasi; Anda hanya dapat menggunakan alur build dan rilis.

Alur validasi

Alur validasi melakukan pemeriksaan kualitas dasar model data sebelum diterbitkan ke ruang kerja pengembangan. Biasanya, perubahan di cabang repositori jarak jauh memicu alur untuk memvalidasi perubahan tersebut dengan pengujian otomatis.

Contoh pengujian otomatis termasuk memindai model data untuk pelanggaran aturan praktik terbaik dengan menggunakan Best Practice Analyzer (BPA), atau dengan menjalankan kueri DAX terhadap model semantik yang diterbitkan. Hasil pengujian ini kemudian disimpan di repositori jarak jauh untuk tujuan dokumentasi dan audit. Model data yang gagal validasi tidak boleh diterbitkan. Sebagai gantinya, alur harus memberi tahu pembuat konten tentang masalah tersebut.

Membangun alur

Membangun alur menyiapkan model data untuk publikasi ke layanan Power BI. Alur ini menggabungkan metadata model berseri ke dalam satu file yang kemudian diterbitkan oleh alur rilis (dijelaskan dalam diagram alur rilis). Alur build juga dapat membuat perubahan lain pada metadata, seperti memodifikasi nilai parameter. Alur build menghasilkan artefak penyebaran yang terdiri dari metadata model data (untuk model data) dan file Power BI Desktop (.pbix) yang siap untuk publikasi ke layanan Power BI.

Rilis alur

Rilis alur menerbitkan atau menyebarkan konten. Solusi penerbitan biasanya mencakup beberapa alur rilis, tergantung pada lingkungan target.

• Alur rilis pengembangan: Alur pertama ini dipicu secara otomatis. Ini menerbitkan konten ke ruang kerja pengembangan setelah alur build dan validasi berhasil.
• Alur rilis pengujian dan produksi: Alur ini tidak dipicu secara otomatis. Sebaliknya, mereka dipicu sesuai permintaan atau saat disetujui. Alur rilis pengujian dan produksi menyebarkan konten ke ruang kerja pengujian atau produksi, masing-masing, setelah persetujuan rilis. Persetujuan rilis memastikan bahwa konten tidak disebarkan secara otomatis ke tahap pengujian atau produksi sebelum siap. Persetujuan ini diberikan oleh manajer rilis, yang bertanggung jawab untuk merencanakan dan mengoordinasikan rilis konten untuk lingkungan pengujian dan produksi.

Ada dua pendekatan berbeda untuk menerbitkan konten dengan alur pengujian dan rilis. Keduanya mempromosikan konten dengan menggunakan alur penyebaran Power BI, atau menerbitkan konten ke layanan Power BI dari Azure DevOps.

Diagram berikut menggambarkan pendekatan pertama. Dalam pendekatan ini, rilis alur mengatur penyebaran konten untuk menguji dan menghasilkan ruang kerja dengan menggunakan alur penyebaran Power BI. Konten dipromosikan melalui ruang kerja pengembangan, pengujian, dan produksi di Power BI. Meskipun pendekatan ini lebih kuat dan lebih sederhana untuk dipertahankan, pendekatan ini membutuhkan lisensi Premium.

Diagram menggambarkan tindakan, proses, dan fitur pengguna berikut dari pendekatan pertama.

Benda	Keterangan
	Dalam pendekatan pertama, alur rilis menerbitkan konten dengan menggunakan titik akhir XMLA dan REST API Power BI dengan alur penyebaran Power BI. Konten diterbitkan lalu dipromosikan melalui ruang kerja pengembangan, pengujian, dan produksi. Alur penyebaran Power BI dan titik akhir baca/tulis XMLA adalah fitur Premium.
	Penggabungan cabang yang berhasil atau penyelesaian alur upstream memicu alur build. Alur build kemudian menyiapkan konten untuk penerbitan, dan memicu alur rilis pengembangan.
	Alur rilis pengembangan menerbitkan konten ke ruang kerja pengembangan dengan menggunakan titik akhir XMLA (untuk metadata model data) atau API REST Power BI (untuk file Power BI Desktop, yang dapat berisi model dan laporan data). Alur pengembangan menggunakan antarmuka baris perintah Editor Tabular (CLI) untuk menyebarkan metadata model data dengan menggunakan titik akhir XMLA.
	Persetujuan rilis atau pemicu sesuai permintaan mengaktifkan alur rilis pengujian.
	Alur rilis pengujian menyebarkan konten dengan menggunakan operasi penyebaran Power BI REST API, yang menjalankan alur penyebaran Power BI.
	Alur penyebaran Power BI mempromosikan konten dari ruang kerja pengembangan ke ruang kerja pengujian. Setelah penyebaran, alur rilis melakukan aktivitas pasca-penyebaran dengan menggunakan REST API Power BI (tidak diperlihatkan dalam diagram).
	Persetujuan rilis atau pemicu sesuai permintaan mengaktifkan alur rilis produksi.
	Alur rilis produksi menyebarkan konten dengan menggunakan operasi penyebaran Power BI REST API, yang menjalankan alur penyebaran Power BI.
	Alur penyebaran Power BI mempromosikan konten dari ruang kerja pengujian ke ruang kerja produksi. Setelah penyebaran, alur rilis melakukan aktivitas pasca-penyebaran dengan menggunakan REST API Power BI (tidak diperlihatkan dalam diagram).

Diagram berikut menggambarkan pendekatan kedua. Pendekatan ini tidak menggunakan alur penyebaran. Sebagai gantinya, ia menggunakan alur rilis untuk menerbitkan konten untuk menguji dan produksi ruang kerja dari Azure DevOps. Terutama, pendekatan kedua ini tidak memerlukan lisensi Premium saat Anda hanya menerbitkan file Power BI Desktop dengan REST API Power BI. Ini melibatkan lebih banyak upaya penyiapan dan kompleksitas, karena Anda harus mengelola penyebaran di luar Power BI. Tim pengembangan yang sudah menggunakan DevOps untuk solusi data di luar Power BI mungkin lebih terbiasa dengan pendekatan ini. Tim pengembangan yang menggunakan pendekatan ini dapat mengonsolidasikan penyebaran solusi data di Azure DevOps.

Diagram menggambarkan tindakan, proses, dan fitur pengguna berikut dalam pendekatan kedua.

Benda	Keterangan
	Dalam pendekatan kedua, alur rilis menerbitkan konten dengan menggunakan titik akhir XMLA dan REST API Power BI saja. Konten diterbitkan untuk ruang kerja pengembangan, pengujian, dan produksi.
	Penggabungan cabang yang berhasil atau penyelesaian alur upstream memicu alur build. Alur build kemudian menyiapkan konten untuk penerbitan, dan memicu alur rilis pengembangan.
	Alur rilis pengembangan menerbitkan konten ke ruang kerja pengembangan dengan menggunakan titik akhir XMLA (untuk metadata model data) atau API REST Power BI (untuk file Power BI Desktop, yang dapat berisi model dan laporan data). Alur pengembangan menggunakan antarmuka baris perintah Editor Tabular (CLI) untuk menyebarkan metadata model data dengan menggunakan titik akhir XMLA.
	Persetujuan rilis atau pemicu sesuai permintaan mengaktifkan alur rilis pengujian.
	Alur rilis pengembangan menerbitkan konten ke ruang kerja pengujian dengan menggunakan titik akhir XMLA (untuk metadata model data) atau API REST Power BI (untuk file Power BI Desktop, yang dapat berisi model dan laporan data). Alur pengembangan menggunakan antarmuka baris perintah Editor Tabular (CLI) untuk menyebarkan metadata model data dengan menggunakan titik akhir XMLA. Setelah penyebaran, alur rilis melakukan aktivitas pasca-penyebaran dengan menggunakan REST API Power BI (tidak diperlihatkan dalam diagram).
	Persetujuan rilis atau pemicu sesuai permintaan mengaktifkan alur rilis produksi.
	Alur rilis pengembangan menerbitkan konten ke ruang kerja produksi dengan menggunakan titik akhir XMLA (untuk metadata model data) atau API REST Power BI (untuk file Power BI Desktop, yang dapat berisi model dan laporan data). Alur pengembangan menggunakan antarmuka baris perintah Editor Tabular (CLI) untuk menyebarkan metadata model data dengan menggunakan titik akhir XMLA. Setelah penyebaran, alur rilis melakukan aktivitas pasca-penyebaran dengan menggunakan REST API Power BI (tidak diperlihatkan dalam diagram).

Alur rilis harus mengelola aktivitas pasca-penyebaran. Aktivitas ini dapat mencakup pengaturan kredensial model semantik atau memperbarui aplikasi Power BI untuk ruang kerja pengujian dan produksi. Kami menyarankan agar Anda menyiapkan pemberitahuan untuk memberi tahu orang-orang yang relevan tentang aktivitas penyebaran.

Tip

Menggunakan repositori untuk kontrol versi memungkinkan pembuat konten membuat proses pemutaran kembali. Proses putar kembali dapat membalikkan penyebaran terakhir dengan memulihkan versi sebelumnya. Pertimbangkan untuk membuat sekumpulan Azure Pipelines terpisah yang dapat Anda picu untuk mengembalikan perubahan produksi. Pikirkan dengan cermat proses dan persetujuan apa yang diperlukan untuk memulai pemutaran kembali. Pastikan bahwa proses ini didokumenkan.

Alur penyebaran Power BI

Alur penyebaran Power BI terdiri dari tiga tahap: pengembangan, pengujian, dan produksi. Anda menetapkan satu ruang kerja Power BI ke setiap tahap dalam alur penyebaran. Saat penyebaran terjadi, alur penyebaran mempromosikan item Power BI dari satu ruang kerja ke ruang kerja lainnya.

Alur rilis Azure Pipelines menggunakan REST API Power BI untuk menyebarkan konten dengan menggunakan alur penyebaran Power BI. Akses ke ruang kerja dan alur penyebaran diperlukan untuk pengguna yang melakukan penyebaran. Kami menyarankan agar Anda merencanakan akses alur penyebaran sehingga pengguna alur dapat melihat riwayat penyebaran dan membandingkan konten.

Tip

Saat Anda memisahkan ruang kerja data dari ruang kerja pelaporan, pertimbangkan untuk menggunakan Azure Pipelines untuk mengatur penerbitan konten dengan beberapa alur penyebaran Power BI. Model semantik disebarkan terlebih dahulu, lalu di-refresh. Terakhir, laporan disebarkan. Pendekatan ini membantu Anda menyederhanakan penyebaran.

Lisensi premium

Alur penyebaran Power BI dan titik akhir baca/tulis XMLA adalah fitur Premium. Fitur-fitur ini tersedia dengan kapasitas Power BI Premium dan Power BI Premium Per Pengguna (PPU).

PPU adalah cara hemat biaya untuk mengelola penerbitan konten perusahaan untuk ruang kerja pengembangan dan pengujian, yang biasanya memiliki beberapa pengguna. Pendekatan ini memiliki keuntungan tambahan untuk mengisolasi beban kerja pengembangan dan pengujian dari beban kerja produksi.

Catatan

Anda masih dapat menyiapkan penerbitan konten perusahaan tanpa lisensi Premium, seperti yang dijelaskan oleh pendekatan kedua di bagian alur rilis. Dalam pendekatan kedua, Anda menggunakan Azure Pipelines untuk mengelola penyebaran file Power BI Desktop untuk pengembangan, pengujian, dan ruang kerja produksi. Namun, Anda tidak dapat menyebarkan metadata model dengan menggunakan titik akhir XMLA karena tidak dimungkinkan untuk menerbitkan model semantik format metadata dengan REST API Power BI. Selain itu, tidak mungkin untuk mempromosikan konten melalui lingkungan dengan alur penyebaran tanpa lisensi Premium.

Penyetelan gateway

Biasanya, gateway data diperlukan saat mengakses sumber data yang berada dalam jaringan organisasi privat atau jaringan virtual. Dua tujuan gateway adalah untuk me-refresh data yang diimpor, dan melihat laporan yang meminta koneksi langsung atau model semantik DirectQuery (tidak digambarkan dalam diagram skenario).

Saat bekerja dengan beberapa lingkungan, biasanya menyiapkan koneksi pengembangan, pengujian, dan produksi ke sistem sumber yang berbeda. Dalam hal ini, gunakan aturan sumber data dan aturan parameter untuk mengelola nilai yang berbeda antar lingkungan. Anda bisa menggunakan Azure Pipelines untuk mengelola gateway dengan menggunakan operasi gateway API REST Power BI.

Catatan

Gateway data terpusat dalam mode standar sangat direkomendasikan melalui gateway dalam mode pribadi. Dalam mode standar, gateway data mendukung operasi koneksi langsung dan DirectQuery (selain operasi refresh data terjadwal).

Pengawasan sistem

Log aktivitas merekam peristiwa yang terjadi di layanan Power BI. Administrator Power BI dapat menggunakan log aktivitas untuk mengaudit aktivitas penyebaran.

Anda dapat menggunakan API pemindaian metadata Power BI untuk membuat inventarisasi penyewa. Hasil API sangat membantu untuk memverifikasi item mana yang telah disebarkan ke setiap ruang kerja, untuk memeriksa silsilah data, dan untuk memvalidasi pengaturan keamanan.

Ada juga log audit dalam Azure DevOps, yang berada di luar layanan Power BI. Administrator Azure DevOps dapat menggunakan log audit untuk meninjau aktivitas di repositori dan alur jarak jauh.

Konten terkait

Untuk skenario berguna lainnya untuk membantu Anda dengan keputusan implementasi Power BI, lihat artikel skenario penggunaan Power BI.