WEBVTT 00:00:00.340 --> 00:00:05.660 Siap untuk 10 hari pembahasan Microsoft 365, Copilot AI, Azure, dan para penggerak 00:00:05.660 --> 00:00:07.040 Masa depan dunia kerja 00:00:07.040 --> 00:00:11.840 Januari ini, M365 John kembali hadir dengan skala yang lebih besar 00:00:11.840 --> 00:00:14.200 Bergabunglah dalam sesi langsung 00:00:14.200 --> 00:00:18.040 Demo nyata dan ilmu praktis dari MVP serta pakar industri di seluruh dunia 00:00:18.040 --> 00:00:21.160 Tanpa slide yang umum, tanpa istilah teknis yang berubah 00:00:21.160 --> 00:00:23.380 Kita akan membahas tantangan nyata 00:00:23.380 --> 00:00:28.620 Copilot Studio, agen AI, fabrik, keamanan, tata kelola, dan otomatisasi 00:00:28.620 --> 00:00:32.780 Baik Anda seorang profesional TI, pengembang, atau pemimpin bisnis 00:00:32.780 --> 00:00:34.400 Ada sesi yang gerancang khusus untuk Anda 00:00:34.400 --> 00:00:38.520 Selama 10 hari penuh, Anda bisa menjelajahi berbagai teknologi 00:00:38.520 --> 00:00:40.040 Dan terhubung dengan komunitas global 00:00:40.040 --> 00:00:44.280 Saksikan secara langsung, dan bawa wasam praktis kembali ke organisasi Anda 00:00:44.280 --> 00:00:49.000 Januari 2020 7, 10 hari, satu komunitas Microsoft 00:00:49.000 --> 00:00:50.580 Pendaftaran sudah dibuka sekarang 00:00:50.580 --> 00:00:54.660 Amankan tempat Anda hari ini 00:00:54.660 --> 00:00:58.760 Kunjungi m365.com.net 00:00:58.760 --> 00:01:02.340 Daftar sekarang di m365.com.net 00:01:02.340 --> 00:01:04.780 Dan sampai jumpa, secara langsung di bulan Januari 00:01:04.780 --> 00:01:07.920 Pernah merasa penerapan power platform Anda seperti kota hitam yang misterius? 00:01:08.420 --> 00:01:12.860 Apakah Anda merilis pembaruan, menahan nafas, dan hanya berharap semua yang berjalan lancar di lingkungan dev, tes, dan prod? 00:01:13.640 --> 00:01:16.820 Bagaimana jika Anda bisa mengontrol dan melihat setiap tahap proses ALM Anda 00:01:16.820 --> 00:01:20.760 Menggunakan GitHub Actions tanpa perlu menebak-nebak atau melakukan perbaikan manual? 00:01:20.760 --> 00:01:27.740 Mari kita buka tirai tentang bagaimana setiap komponen, kontrol sumber, otomatisasi, dan variable aman sebenarnya terhubung 00:01:27.740 --> 00:01:29.820 Ah, ini bukan sekadar panduan biasa 00:01:29.820 --> 00:01:34.580 Ini adalah alasan yang sering diabaikan panduan lain agar penerapan Anda berikutnya tidak membuat Anda ragu 00:01:34.580 --> 00:01:37.600 Jadi, mengapa ALM Power Platform terasa seperti labirin? 00:01:38.940 --> 00:01:44.800 Jika Anda pernah mencoba menerapkan power app dan merasa tidak yakin seperti ada sesuatu yang penting terlewatkan, Anda tidak sendiri 00:01:44.800 --> 00:01:52.420 Di atas kertas, Power Platform menjanjikan pengembangan aplikasi yang mudah, namun, dibalik tampilan ramai itu, ALM justru sangat rumit 00:01:52.420 --> 00:01:58.880 Aplikasi web disebarkan, dari kontrol sumber, dibangun dalam pipeline, dan mendarat diproduksi dengan perilaku yang dapat diprediksi 00:01:58.880 --> 00:02:07.680 Sebaliknya, Power Platform menyembunyikan separuh logikanya di dalam antarmuka seret lepas, layar konektor, dan rumus yang tidak terlihat di repository Git manapun 00:02:07.680 --> 00:02:11.540 Jadi, meskipun Anda mengikuti setiap langkah dari panduan admin tingkat atas 00:02:11.540 --> 00:02:16.920 Anda tetap akan menemukan kegagalan aneh yang sulit didiagnosis saat aplikasi bisnis penting keluar dari tahap pengembangan 00:02:16.920 --> 00:02:19.500 Mari kita lihat panduan ALM yang beredar di luar sana 00:02:19.500 --> 00:02:23.840 Sebagian besar akan memandu Anda untuk mengeksplore zip solusi dan mengimpornya ke tempat lain 00:02:23.840 --> 00:02:25.200 Cukup sederhana, bukan? 00:02:25.520 --> 00:02:27.080 Namun, cara melakukannya hanya set rapi sensasi 00:02:27.080 --> 00:02:28.800 Yang mereka lewatkan adalah alasannya 00:02:28.800 --> 00:02:33.300 Mengapa penerapan Power Platform rusak dengan cara yang tidak pernah terjadi pada kode biasa? 00:02:33.900 --> 00:02:35.600 Itulah penyebab kebingungan yang tidak habisnya 00:02:35.600 --> 00:02:41.200 Akar masalahnya adalah logika, koneksi, dan konfigurasi di Power Apps tidak disimpan seperti kode klasik 00:02:41.200 --> 00:02:44.980 Anda tidak hanya sekadar mengkloning repo dan melihat hasil pengujian unit 00:02:44.980 --> 00:02:53.780 Jadi, saat Anda mencoba memindahkan aplikasi, semua dependensi tersembunyi, koneksi ke Outlook SharePoint, dan API Custom tidak selalu tersimpan rapi di dalam file zip tersebut 00:02:53.780 --> 00:02:55.060 Jelas, sekian adunya 00:02:55.060 --> 00:02:57.960 Anda memiliki aplikasi baru yang berfungsi dengan baik di lingkungan berkontak 00:02:57.960 --> 00:03:02.020 Anda mengekspor solusi mengimpornya ke lingkungan pengejian tes dan tiba-tiba alur kerjanya berhenti berhenti 00:03:02.020 --> 00:03:03.420 Ini jarang terjadi hanya karena masalah, Pak 00:03:03.420 --> 00:03:11.200 Sebaliknya, koneksi mengarah ke tempat yang salah, izin tidak selaras, dan kebijakan data memblokir koneksi yang tadinya baik-baik saja beberapa menit lalu 00:03:11.200 --> 00:03:14.540 Sekarang, bayangkan melakukan ini di tiga lingkungan 00:03:14.540 --> 00:03:15.860 Dev, Tes, dan Prod 00:03:15.860 --> 00:03:21.360 Dengan masing-masing, menggunakan koneksi, kebijakan pelindungan data, penyetuju, dan pengamaran admin yang berbeda 00:03:21.360 --> 00:03:23.460 Anda tidak bisa mengatasinya yang saya menempel 00:03:23.460 --> 00:03:27.040 Penelitian mendukung apa yang dilihat admin dan pembuat aplikasi setiap minggunya 00:03:27.040 --> 00:03:33.960 Mayoritas kegagalan penerapan power platform berasal dari referensi konektor yang hilang atau variable lingkungan yang tidak dikelola dengan benar 00:03:33.960 --> 00:03:39.220 Kehilangan referensi konektor berarti alur kerja tidak dapat menemukan koneksi Outlook atau Dataverse-nya 00:03:39.220 --> 00:03:45.900 Jadi, saat Anda mencoba menjalankan aplikasi atau alur kerja di lingkungan lain, Anda akan mendapatkan kesalahan waktu proses 00:03:45.900 --> 00:03:54.800 Dan karena variable lingkungan di power platform bekerja berbeda dibandingkan produk Microsoft 365 lainnya, hal ini sering menjebak pengembang berpengalaman sekalipun 00:03:54.800 --> 00:03:59.220 Variable seharusnya menangani endpoint kunci atau konfigurasi khusus penyewa, tenat 00:03:59.220 --> 00:04:06.080 Namun, jika seseorang lupa memperbaruinya setelah mengekspor solusi, perubahan yang terlihat sepeli pun bisa merusak aplikasi yang sedang berjalan 00:04:06.080 --> 00:04:08.740 Banyak dari kita terjebak dalam masalah yang sama pada awalnya 00:04:08.740 --> 00:04:14.360 Anda mungkin mengekspor zip solusi sudah mencakup segalanya, padahal sebenarnya sistem melewatkan referensi konektor dinamis 00:04:14.360 --> 00:04:19.100 Misalnya, Anda memiliki aplikasi yang menggunakan konektor HTTP untuk layanan pihak ketiga di pengandang 00:04:19.100 --> 00:04:23.320 Saat Anda mengimpor kelingkungan tes atau prod, instans konektor tersebut tidak akan ada 00:04:23.320 --> 00:04:27.360 Referensi konektor di dalam aplikasi Anda mengarah ke objek yang hilang 00:04:27.360 --> 00:04:30.100 Dan alur kerja di dalam solusi tersebut rusak diam-diam 00:04:30.100 --> 00:04:34.380 Hingga pengguna atau admin membuat ulang dan memetakan koneksi secara manual 00:04:34.380 --> 00:04:37.740 Jika Anda memiliki lebih dari satu pembuat atau admin 00:04:37.740 --> 00:04:39.840 Akan lebih mudah kehilangan jejak referensi 00:04:39.840 --> 00:04:43.000 Dan tidak ada yang menginginkan evaluasi pasca kejadian di dev tadi berhasil 00:04:43.000 --> 00:04:46.680 Masalah lainnya adalah service prinsipal 00:04:46.680 --> 00:04:49.940 Kebanyakan orang mulai dengan menggunakan akun pengguna 00:04:49.940 --> 00:04:52.860 Untuk mengekspor dan mengimpor solusi karena lebih cepat untuk memulai 00:04:52.860 --> 00:04:57.060 Namun, saat Anda mencoba melakukan otomatisasi dengan GitHub Actions atau sistem CI 00:04:57.060 --> 00:04:59.700 Apapun menggunakan kredensial pribadi akan menemui jalan bentuk dengan cepat 00:04:59.700 --> 00:05:02.240 Anda akan terbenturi izin, terkadang tanpa pesan kesalahan yang jelas 00:05:02.240 --> 00:05:05.220 Atau bahkan memicu audit kepatuhan karena Anda menjalankan penerapan kritis 00:05:05.220 --> 00:05:08.320 Menggunakan akun pribadi bukan akun yang memang ditujukan untuk otomatisasi 00:05:08.320 --> 00:05:10.160 Bukan akun yang memang ditujukan untuk otomatisasi 00:05:10.160 --> 00:05:14.680 Service prinsipal yang pada dasarnya adalah identitas aplikasi yang dibuat di Azure AD 00:05:14.680 --> 00:05:18.340 Menangani semua izin, pencatatan, dan audit yang dibutuhkan pipeline Anda 00:05:18.340 --> 00:05:22.500 Tanpanya, rantai otomatisasi Anda berubah menjadi serangkaian serah terima 00:05:22.500 --> 00:05:25.320 Antara orang yang tidak rapi dan Anda tidak akan pernah tahu siapa yang mengubah apa 00:05:25.320 --> 00:05:27.560 Kontrol sumber pun menjadi tidak menentu 00:05:27.560 --> 00:05:31.220 Dengan kode biasa, Anda memiliki rewak commit dan alat pelacakan perubahan 00:05:31.220 --> 00:05:34.200 File solusi Power Platform hanya memakai snapshot 00:05:34.200 --> 00:05:36.600 Yang berarti Anda kehilangan pelacakan perubahan secara mendetail 00:05:36.600 --> 00:05:39.760 Logika yang tersembunyi dalam rumus layar Canvas App 00:05:39.760 --> 00:05:43.760 Atau dalam alur yang kurang terdokumentasi tidak terlihat sampai Anda mengekspornya kembali 00:05:43.760 --> 00:05:46.080 Seseorang mengubah pengaturan alur di UI 00:05:46.080 --> 00:05:49.580 Dan semoga berhasil mencari tahu mengapa lingkungan hilir tiba-tiba berperilaku berbeda 00:05:49.580 --> 00:05:52.500 Hasil akhirnya, mengelola ILM untuk Power Platform 00:05:52.500 --> 00:05:55.160 Terasa seperti menyusun teka-teki dengan separuh bagian yang hilang 00:05:55.160 --> 00:05:56.960 Atau setidaknya tersembunyi di bawah kotak 00:05:56.960 --> 00:06:00.980 Dependensi yang tidak terlihat, konektor spesifik lingkungan, dan variable 00:06:00.980 --> 00:06:02.540 Yang tidak bisa Anda lihat dalam kode 00:06:02.540 --> 00:06:05.220 Semuanya mengubah alur kerja pengembang yang biasa 00:06:05.220 --> 00:06:10.820 Dan itu belum termasuk fakta bahwa lingkungan produksi hampir selalu memiliki izin yang lebih ketat 00:06:10.820 --> 00:06:12.000 Kebijakan data yang berbeda 00:06:12.000 --> 00:06:15.820 Dan persyaratan audit yang tidak tampak di lingkungan pengembangan atau pengujian 00:06:15.820 --> 00:06:18.080 Tapi nah sisi positifnya 00:06:18.080 --> 00:06:19.720 Kompleksitas ini bukan kebetulan 00:06:19.720 --> 00:06:25.720 Ada alasan praktis mengapa Power Platform menangani sumber variable dan konektor dengan carai 00:06:25.720 --> 00:06:26.840 Yang unik 00:06:26.840 --> 00:06:31.440 Platform ini berupaya agar pengguna bisnis dapat membangun aplikasi canggih tanpa perlu khawatir soal kode 00:06:31.440 --> 00:06:37.820 Efek sampingnya adalah Anda sebagai orang yang mengatur otomatisasi harus melacak apa yang tersembunyi di balik layar 00:06:37.820 --> 00:06:41.040 Jika Anda tahu kemana kabel-kabel tak terlihat itu terhubung 00:06:41.040 --> 00:06:45.920 Anda dapat memperbaiki atau menghindari sebagian besar kesalahan fatal yang mengganggu ALM Power Platform 00:06:45.920 --> 00:06:48.540 Sekarang jika semua ini terdengar berat 00:06:48.540 --> 00:06:49.680 Anda tidak salah 00:06:49.680 --> 00:06:53.420 Namun ada empat pilar ALM yang benar-benar membantu mengurai kerumitan ini 00:06:53.420 --> 00:06:55.520 Sumber bangun uji dan sebarkan 00:06:55.520 --> 00:07:01.380 Masing-masing memiliki keunikan di Power Platform tetapi bersama-sama mereka menggembalikan struktur ke dalam situasi yang terasa kacau 00:07:01.380 --> 00:07:04.720 Sistem ALM inti sumber bangun uji sebarkan 00:07:04.720 --> 00:07:08.740 Setiap kali seseorang meminta pipeline Power Platform yang langsung berfungsi 00:07:08.740 --> 00:07:14.700 Hal pertama yang terlintas di pikiran adalah empat pilar ALM lama tersebut yaitu sumber bangun uji dan sebarkan 00:07:14.700 --> 00:07:18.600 Dalam dunia pengembangan tradisional Anda hampir bisa melakukannya sambil tidur 00:07:18.600 --> 00:07:21.520 Power Platform tidak membiarkan Anda lepas dengan mudah 00:07:21.520 --> 00:07:24.100 Tiba-tiba sumber tidak berarti kode 00:07:24.100 --> 00:07:26.380 Itu berarti harus bergulat dengan file solusi 00:07:26.380 --> 00:07:33.720 Mengekspor bundel zip berisi aplikasi alur dan terkadang konektor yang berpura-pura menjadi bagian dari sumber 00:07:33.720 --> 00:07:35.120 Mari mulai dengan dasarnya 00:07:35.120 --> 00:07:38.720 Lalu beda apa yang membuat setiap pilar terasa sedikit aneh di dunia ini 00:07:38.720 --> 00:07:40.220 Anda memiliki file tips Anda 00:07:40.220 --> 00:07:41.920 Ini bukan kode dalam pengertian biasa 00:07:41.920 --> 00:07:48.800 Buka file tersebut dan Anda akan disambut oleh file penjelasan XML dan JSON bukan logika yang biasa Anda lihat di TypeScript atau C-SARP 00:07:48.800 --> 00:07:50.800 Namun inilah sumber untuk workload 00:07:50.800 --> 00:07:52.380 Tim seringkali terkendala di sini 00:07:52.380 --> 00:07:55.880 Terlihat portable sampai Anda menyadari sebagian besar perubahan 00:07:55.880 --> 00:08:01.560 Seperti memperbarui rumus di layar atau mengubah logika alur tidak terlihat jelas sampai Anda mengekspor zip solusi yang baru 00:08:01.560 --> 00:08:07.960 Jadi ya Anda bisa membuat versi file solusi ini di git tetapi kecuali Anda disiplin mengekspor setelah setiap pengeditan yang relevan 00:08:07.960 --> 00:08:09.880 Riwet Anda akan memiliki celah yang mencolok 00:08:09.880 --> 00:08:11.840 Sekarang masuk ke konfigurasi 00:08:11.840 --> 00:08:16.320 Untuk aplikasi biasa Anda mungkin menyimpan string koneksi dalam file konfigurasi dan selesai 00:08:16.320 --> 00:08:20.280 Power Platform menyisipkan data khusus lingkungan di dalam solusi ini 00:08:20.280 --> 00:08:28.480 Ini bukan hanya variable lingkungan tetapi referensi konektor, titik akhir dinamis, peran, dan izin yang digabungkan bersama logika bisnis 00:08:28.480 --> 00:08:35.540 Jika Anda lupa memperbaruinya sebelum mengekspor dari pengembangan atau pengujian, Anda mengunci penunjuk ke tempat yang salah 00:08:35.540 --> 00:08:39.560 Saya telah melihat tim dengan tekun melakukan komit pada file zip solusi mereka 00:08:39.560 --> 00:08:44.620 Hanya untuk menyadari saat diterapkan bahwa separuh aplikasi mereka masih terhubung ke data first pengembangan 00:08:44.620 --> 00:08:47.260 Bukan produksi karena tidak ada yang memetakkan ulang referensi konektor 00:08:47.260 --> 00:08:49.220 Selanjutnya kita masuk ke tab 00:08:49.220 --> 00:08:54.740 Kata build biasanya memunculkan bayangan kompilasi kode dan melihat tanda centang hijau dalam pekerjaan CI 00:08:54.740 --> 00:09:01.640 Dengan Power Platform, proses build adalah tentang menyimpan bundel zip tersebut, memeriksa skema dua kali, dan meverifikasi dependensi 00:09:01.640 --> 00:09:11.380 Dalam pipeline GitHub Actions, pekerjaan build mengambil file solusi yang Anda komit lalu menggunakan shell i, power platform Microsoft untuk membongkar, memvalidasi, dan mengemas ulang solusi tersebut 00:09:11.380 --> 00:09:14.440 Langkah validasi adalah tempat keajaiban atau kekacauan terjadi 00:09:14.440 --> 00:09:17.380 Langkah ini mungkin mendeteksi referensi yang rusak atau tindakan yang tidak didukai 00:09:17.680 --> 00:09:22.800 Lebih buruk lagi, jika perubahan pada alur Anda bergantung pada konektor custom yang tidak pernah masuk ke kontrol sumber 00:09:22.800 --> 00:09:25.660 Build Anda secara diam-diam mengemas sesuatu yang tidak lengkap 00:09:25.660 --> 00:09:27.660 Disinilah keadaan menjadi rumit 00:09:27.660 --> 00:09:33.080 Pekerjaan build tersebut lebih tentang mengatur ekspor yang andal dan memastikan apa yang ada di dalamnya siap dikirim 00:09:33.080 --> 00:09:35.820 Bukan sekadar kompilasi, bukan sekadar kompilasi 00:09:35.820 --> 00:09:40.980 Tim yang melewatkan atau terburu-buru melakukan ini akan dengan cepat berada dalam situasi di mana build secara teknis berhasil 00:09:40.980 --> 00:09:44.260 Tetapi apa yang sampai ke UAT atau produksi kehilangan separuh fitur yang diinginkan 00:09:44.860 --> 00:09:49.840 Microsoft terus menekankan pesan bahwa file solusi membuat ALM portable namun selalu ada catatan kaki 00:09:49.840 --> 00:09:54.760 Portabilitas bergantung pada konektor yang dipetakan dengan benar dan peran yang disiapkan di seluruh lingkungan 00:09:54.760 --> 00:09:56.380 Pengujian adalah tab berikutnya 00:09:56.380 --> 00:10:01.560 Dalam pipeline aplikasi web, pengujian otomatis mungkin menjalankan tes unit atau pemeriksaan UI 00:10:01.560 --> 00:10:05.600 Untuk power platform, apa yang dianggap sebagai pengujian masih bisa diperbatkan 00:10:05.600 --> 00:10:07.960 Terkadang itu adalah validasi solusi 00:10:07.960 --> 00:10:11.880 Dengan kata lain apakah solusi terbuka dan apakah dependensi utama teratasi 00:10:11.880 --> 00:10:17.980 Dilain waktu itu adalah menjalankan alur pengujian atau meriksa apakah konektor merespons di lingkungan pengujian-pengujian 00:10:17.980 --> 00:10:24.220 Seringkali pengujian dilakukan secara manual karena memvalidasi logika bisnis di dalam kanvas app belum terhubung ke alur kerja otomatis 00:10:24.220 --> 00:10:24.720 Wits 00:10:24.720 --> 00:10:29.880 Namun, Anda bisa mengotomatiskan pemeriksaan untuk mendeteksi konektor yang hilang memvalidasi alur penting 00:10:29.880 --> 00:10:33.400 Atau sekadar melakukan ping ke lingkungan pengujian untuk memastikan kredensial berfungsi 00:10:33.400 --> 00:10:35.260 Penyebaran BWM adalah bagian ini 00:10:35.260 --> 00:10:39.360 Saat mendeplay aplikasi standar, Anda mungkin hanya perlu mendorong artefak web ke Azure 00:10:39.360 --> 00:10:44.900 Dengan power platform, Anda harus membutuhkan koneksi, menetapkan izin, memperbarui rahasia, menukar variable lingkungan 00:10:44.900 --> 00:10:48.600 Dan akhirnya memicu import menggunakan service prinsipal, bukan akun biasa 00:10:48.600 --> 00:10:49.480 Bukan akun biasa 00:10:49.480 --> 00:10:52.440 Jika tidak, Anda akan terjebak dengan audit dan penolakan izin 00:10:52.440 --> 00:10:55.060 GitHub Actions dapat menyatukan proses ini 00:10:55.060 --> 00:10:59.760 Tetapi hanya jika setiap tugas tahu lingkungan mana yang dituju dan rahasia mana yang digunakan 00:10:59.760 --> 00:11:04.180 Saya pernah melihat tim mencoba jalan pintas dengan menggunakan satu set kredensial untuk dev dan prod 00:11:04.180 --> 00:11:09.500 Yang justru memicu kekacauan, kebocoran data, kesalahan izin, dan fitur rusak yang hanya muncul di satu lingkungan 00:11:09.500 --> 00:11:10.560 Dan fitur lingkungan 00:11:10.560 --> 00:11:13.180 Ambil contoh tim nyata yang sudah bekerja dengan saya beberapa bulan lalu 00:11:13.180 --> 00:11:15.180 Mereka melakukan banyak hal dengan benar 00:11:15.180 --> 00:11:18.220 Seperti menggunakan repository git standar, file chip solusi perversi, dan percambangan engine 00:11:18.220 --> 00:11:20.340 Namun, pipeline mereka selalu gagal saat deployment 00:11:20.340 --> 00:11:23.340 Mereka tidak pernah menukar variable lingkungan 00:11:23.340 --> 00:11:26.180 Atau memperbarui referensi konektor sebelum mengimpor ke prod 00:11:26.180 --> 00:11:29.400 Hal itu menyebabkan alu utama mengarah ke titik akhir yang salah 00:11:29.400 --> 00:11:30.920 Dengan data yang mengalir ke sistem yang clear 00:11:30.920 --> 00:11:32.440 Solusinya adalah 00:11:32.440 --> 00:11:34.760 Menambahkan langkah-langkah script di pipeline GitHub mereka 00:11:34.760 --> 00:11:37.600 Yang menukar variable dan memetakkan ulang setiap konektor saat import 00:11:37.600 --> 00:11:40.360 Panduan resmi dari Microsoft sangat jelas mengenai hal ini 00:11:40.360 --> 00:11:43.500 Gunakan file solusi untuk memindahkan komponen antar lingkungan 00:11:43.500 --> 00:11:47.540 Namun, selalu tangani referensi konektor dan pembetahan peran sebagai bagian dari pipeline Anda 00:11:47.540 --> 00:11:51.740 Mereka menekankan bahwa melewatkan langkah-langkah ini adalah penyebab utama rusaknya aplikasi 00:11:51.740 --> 00:11:53.700 Terutama saat lingkungan semakin diperketat keamanannya 00:11:53.700 --> 00:11:58.920 Setelah Anda memperlakukan sumber, build, pengujian, dan penyebaran sebagai bagian yang saling terhubung 00:11:58.920 --> 00:12:02.740 Bukan langkah terpisah akan lebih mudah untuk melihat mengapa banyak upaya LM gagal 00:12:02.740 --> 00:12:05.720 Dan bagaimana Anda bisa memecahkan masalah alih-alih hanya berharap 00:12:05.720 --> 00:12:11.000 Selanjutnya, mari kita bahas bagaimana GitHub Actions mengkoordinasikan proses ini 00:12:11.000 --> 00:12:16.560 Pemicu, percambangan, dan pemisahan tugas yang menjaga otomatisasi power platform Anda tetap fleksibel dan aman 00:12:16.560 --> 00:12:20.860 GitHub Actions menghubungkan semuanya dengan pemicu dan tugas 00:12:20.860 --> 00:12:24.800 Jika Anda pernah menunggu pipeline GitHub Actions selesai setelah memperbarui Power App 00:12:24.800 --> 00:12:27.820 Anda tahu bahwa otomatisasi tidak berarti instan dan tentu saja bukan sihir 00:12:27.820 --> 00:12:33.120 Kebanyakan tim terbentur kendala tepat setelah keseruan melihat alur kerja pertama mereka berjalan 00:12:33.120 --> 00:12:41.040 Anda menyiapkan skrip, menghubungkannya ke repository, dan berharap setiap komitmen baru akan dirilis dengan mulus di semua lingkungan 00:12:41.040 --> 00:12:42.760 Lalu kenyataan mulai terasa 00:12:42.760 --> 00:12:46.660 Alih-alih sekadar menjalankan skrip, kita baiknya menggunakan rantai logika 00:12:46.660 --> 00:12:50.260 Yang dibangun berdasarkan pemicu, tugas, dan serah terima antar lingkungan 00:12:50.260 --> 00:12:56.200 Urutan dan struktur tersebut menjaga penerapan agar tidak menjadi tumpukan langkah yang gagal dan kesalahan yang aneh 00:12:56.200 --> 00:12:58.500 Titik awal dalam sistem ini adalah pemicu 00:12:58.500 --> 00:13:02.520 Kebanyakan pengguna pemula membuat alur kerja yang aktif 00:13:02.520 --> 00:13:07.900 Pada setiap dorongan push atau kapanpun permintaan tarik pull request masuk ke cabang utama 00:13:07.900 --> 00:13:10.160 Sekilas, itu tampak seperti terbaik 00:13:10.160 --> 00:13:12.340 Mengapa tidak menjalankan alur pipa Anda setiap kali jangan? 00:13:12.760 --> 00:13:13.400 Inilah masalahnya 00:13:13.400 --> 00:13:17.180 Saat Anda hanya mengatur pemicu di cabang utama, semuanya disalurkan melalui satu jalur saja 00:13:17.180 --> 00:13:20.180 Bagaimana jika perubahan perlu masuk ke dev tetapi tidak ke tes atau prod? 00:13:20.580 --> 00:13:23.660 Bagaimana jika Anda siap mendorong ke prod tetapi tes masih menjalankan validasi? 00:13:23.660 --> 00:13:27.720 Tim yang terpaku pada pemicu satu ukuran untuk semua cenderung mengalami masalah 00:13:27.720 --> 00:13:30.860 Dimana fitur yang ditujukan untuk lingkungan pengembangan menyusup ke produksi 00:13:30.860 --> 00:13:34.240 Atau penerapan pengujian secara tiba-tiba menimpa pengaturan prod 00:13:34.240 --> 00:13:37.660 Anda bisa mencabangkan alur kerja untuk setiap lingkungan 00:13:37.660 --> 00:13:38.740 Dev, tes, dan prod 00:13:38.740 --> 00:13:42.120 Serta mengatur pemicu yang sangat spesifik untuk masing-masing 00:13:42.120 --> 00:13:45.720 Sebagai contoh, atur alur kerja yang hanya berjalan saat ada dorongan ke cabang dev 00:13:45.720 --> 00:13:49.600 Atau aktifkan alur kerja berbeda saat seseorang menggabungkan ke release prod 00:13:49.600 --> 00:13:53.580 Pendekatan ini memberikan lebih banyak kontrol dan menciptakan batasan yang jelas 00:13:53.580 --> 00:13:55.840 Antara pekerjaan yang sedang berlangsung dan perubahan langsung 00:13:55.840 --> 00:13:58.120 Namun banyak tim tidak pernah menjauh kembali pemicu mereka setelah membuat 00:13:58.120 --> 00:14:01.200 Begitulah rahasia dari satu lingkungan bisa menyelinap ke lingkungan lain 00:14:01.200 --> 00:14:05.400 Dan konfigurasi yang ditujukan untuk dev berakhir di prod secara tidak sengaja 00:14:05.400 --> 00:14:10.040 Satu tim yang pernah bekerja dengan saya mencoba menjalankan seluruh proses alam mereka dari satu alur kerja tulu 00:14:10.040 --> 00:14:12.380 Untuk sementara, itu tampak baik-baik saja 00:14:12.380 --> 00:14:18.180 Sampai seseorang menyadari bahwa string koneksi basis data produksi muncul di lingkungan dev muncul di lingkungan dev 00:14:18.180 --> 00:14:21.080 Mereka tidak menyadari bahwa rahasia mereka dibagikan di antara tugas-tugas 00:14:21.080 --> 00:14:24.600 Dan begitu kode berpindah antar lingkungan, rahasia-rahasia itu bocor bersamanya 00:14:24.600 --> 00:14:26.420 Itu bukan kerusakan atau kesalahan yang mencob 00:14:26.420 --> 00:14:27.460 Itu terjadi sejarah game 00:14:27.460 --> 00:14:30.800 Kebocoran data semacam ini lebih umum terjadi daripada yang Anda kira 00:14:30.800 --> 00:14:34.040 Terutama jika Anda tidak mengatur alur kerja untuk memisahkan rahasia dan variable lingkungan 00:14:34.560 --> 00:14:39.160 Setiap tugas dalam alur kerja GitHub Actions menangani bagian yang jelas dari proses tersebut 00:14:39.160 --> 00:14:43.220 Satu tugas mungkin menangani ekspor solusi dari lingkungan sumber 00:14:43.220 --> 00:14:45.460 Tugas lain menangani validasi pembongkaran 00:14:45.460 --> 00:14:48.340 Pemindahkan metadata solusi, memeriksa semua dependensi 00:14:48.340 --> 00:14:51.140 Dan memastikan referensi, konektor, ada 00:14:51.140 --> 00:14:55.300 Selanjutnya adalah tugas yang menyiapkan variable khusus lingkungan 00:14:55.300 --> 00:14:58.160 Menerjemahkan solusi agar sesuai dengan lingkungan targetnya 00:14:58.160 --> 00:15:04.000 Tugas terakhir memicu proses impor menggunakan prinsip pelayanan untuk menulis perubahan ke dalam lingkungan yang tepat 00:15:04.000 --> 00:15:07.960 Anda mungkin menganggap variable lingkungan dan rahasia sebagai penampung dasar 00:15:07.960 --> 00:15:10.700 Tetapi dalam prakteknya mereka adalah perkat yang menyatukan semuanya 00:15:10.700 --> 00:15:12.020 Merekat yang menyatukan semua 00:15:12.020 --> 00:15:16.120 String koneksi, kunci API, dan kata Sandy bersama harus ditukar 00:15:16.120 --> 00:15:19.440 Antar tugas tetapi tidak boleh bocor melintasi batasan 00:15:19.440 --> 00:15:24.520 Dalam ILM Power Platform Anda mungkin memiliki koneksi data khusus yang berbeda untuk setiap lingkungan 00:15:24.520 --> 00:15:28.240 Atau perlu menukar titik akhir tergantung pada alur atau power app yang ditargetkan 00:15:28.240 --> 00:15:36.580 Jika Anda menggunakan kembali variable atau membuat kode rahasia secara permanen hardcode Anda akan berakhir dengan pipeline yang rapuh atau yang lebih buruk risiko keamanannya signifikan 00:15:36.580 --> 00:15:43.480 Proses impor bergantung pada pengambilan rahasia hanya dari berangkas yang tepat sehingga produksi tidak terekspos oleh kesalahan pengujian atau pengembangan 00:15:43.480 --> 00:15:52.240 Model mental yang baik untuk rahasia di GitHub Actions adalah dengan membayangkan setiap lingkungan memiliki berangkas digital sendiri sebuah kotak terkunci yang hanya bisa dilihat oleh tugas yang tepat 00:15:52.240 --> 00:15:54.760 GitHub memberi Anda kontrolan presisi 00:15:54.760 --> 00:16:01.720 Anda dapat membatasi rahasia pada lingkungan tertentu sehingga tugas yang berjalan di dev tidak dapat mengakses kredensial prod dan sebaliknya 00:16:01.720 --> 00:16:06.720 Atur berangkas ini dan meskipun seseorang yang mengubah pipeline mencoba sesuatu yang berisiko 00:16:06.720 --> 00:16:09.480 Aturan perlindungan lingkungan akan mencegah kesalahan meluas 00:16:09.480 --> 00:16:13.180 Dokumentasi dari Microsoft maupun GitHub sendiri sangat menekankan poin ini 00:16:13.180 --> 00:16:19.560 Mereka merekomendasikan aturan perlindungan lingkungan dan perbatasan rahasia yang ketat untuk menghentikan kebocoran antar lingkungan sebelum terjadi 00:16:19.560 --> 00:16:24.560 Tanpa perlindungan semacam itu, alur kerja ALM yang dirancang paling baik sekalipun akan berantakan 00:16:24.560 --> 00:16:32.040 Bayangkan alur kerja yang menyebarkan ke prod saat masih menggunakan string koneksi dev atau lingkungan pengujian yang tiba-tiba memiliki akses ke data prod 00:16:32.040 --> 00:16:34.600 Hal ini tidak salah merusak sistem secara kesat mata 00:16:34.600 --> 00:16:40.740 Terkadang ini hanya berarti bendera kepatuhan menyala atau log dipenuhi dengan kesalahan halus yang perlahan menumpuk menjadi masalah yang lebih besar 00:16:40.740 --> 00:16:44.960 Inilah sebabnya alur kerja percabang dan pembatasan rahasia bukan sekadar topik tingkat lanjut 00:16:44.960 --> 00:16:48.580 Hal-hal tersebut adalah jaring pengaman yang menjaga otomatisasi Anda agar tidak hancur secara dip 00:16:48.580 --> 00:16:52.900 Ada juga nilai dalam membagi alur kerja tidak hanya berdasarkan lingkungan tetapi berdasarkan tanggung jawab 00:16:52.900 --> 00:16:59.000 Koda yang mengekspor dan memvalidasi solusi seharusnya bahkan tidak perlu tahu cara menyebarkan atau menukar rahasia 00:16:59.000 --> 00:17:07.640 Jika setiap tugas menangani satu bagian dari teka-teki akan jauh lebih mudah untuk menemukan dimana letak kerusakan melakukan pemulihan dan mengaudit perubahan setelahnya 00:17:07.640 --> 00:17:15.240 Rahasia tetap berada di berangkasnya tugas mengikuti izin yang dibatasi dengan jelas dan kegagalan pipeline langsung menunjuk ke bagian yang perlu diperbaiki 00:17:15.240 --> 00:17:19.980 Memahami bagaimana GitHub Actions menyerahkan pekerjaan dari satu tugas ke tugas lain 00:17:19.980 --> 00:17:28.240 Sambil menjaga rahasia tetap terbatas dan pemicu didefinisikan dengan jelas adalah hal yang mengubah ALM dari eksperimen harapan menjadi praktik yang andal aman dan dapat diprediksi 00:17:28.240 --> 00:17:32.980 Segmentasi alur kerja ini bukan sekadar tentang mengikuti praktek terbaik 00:17:32.980 --> 00:17:37.820 Hal ini memblokir kebocoran keamanan, diam-diam, dan penimpaan yang tidak disengaja 00:17:37.820 --> 00:17:41.640 Serta memotong seluruh kategori kesalahan tidak terlihat sebelum mulai menghantui lingkungan Anda 00:17:41.640 --> 00:17:48.660 Sekarang dengan bagian-bagian yang bekerja bersama melalui otomatisasi yang dibatasi dengan tepat saatnya kita mengatasi hambatan lainnya 00:17:48.660 --> 00:17:56.140 Konektor, prinsip layanan, dan jebakan kecil namun krusial yang bisa menghambat penerapan Anda tepat saat Anda mulai merasa percaya diri 00:17:56.140 --> 00:17:59.540 Rahasia prinsip layanan dan masalah pada konektor 00:17:59.540 --> 00:18:04.500 Jika Anda pernah mencoba mendahkan power app atau flow dari dev ke prod, Anda pasti tahu ceritanya 00:18:04.500 --> 00:18:12.180 Semuanya berjalan lancar di satu lingkungan, tetapi begitu Anda beralih, semuanya terhenti atau muncul kesalahan koneksi yang membingungkan 00:18:12.180 --> 00:18:15.160 Ini bukan hanya di alam latin tertentu saja 00:18:15.160 --> 00:18:18.680 Setiap admin power platform pada akhirnya akan menghadapi kendala ini 00:18:18.680 --> 00:18:23.860 Akar permasalahannya terletak pada bagaimana konektor dan rahasia bekerja di balik layar 00:18:23.860 --> 00:18:32.180 Anda tidak bisa begitu saja mengekspor jeb solusi dari pengembangan dan berharap itu berfungsi di tempat lain karena alurnya berubah di setiap lingkungan 00:18:32.180 --> 00:18:34.900 Ambil contoh referensi konektor sebagai permulaan 00:18:34.900 --> 00:18:40.260 Di power platform, konektor bukanlah sekadar informasi statis yang dibundang ke dalam aplikasi Anda, dev 00:18:40.260 --> 00:18:43.540 Sifatnya dinamis bisa diubah dan seringkali unik untuk setiap lingkungan 00:18:43.540 --> 00:18:47.080 Saat Anda mengekspor solusi, referensi konektor bertindak hampir seperti penanda 00:18:47.080 --> 00:18:52.040 Referensi tersebut menunjuk ke objek koneksi yang hanya ada di lingkungan tempat objek tersebut dibuat 00:18:52.040 --> 00:19:00.420 Jadi saat Anda mengimpor ke uji coba atau prod titik akhir HTTP atau tautan data first Anda tidak selalu dibuat ulang dengan cara yang sama atau bahkan tidak dibuat sama sekali 00:19:00.420 --> 00:19:02.040 Di sini ada tim seringkali tebak 00:19:02.040 --> 00:19:14.780 Jika dev menggunakan konektor untuk data uji dan konfigurasi yang sama tidak tercermin di prod, alur, atau aplikasi Anda akan gagal diam-diam atau berhenti saat pertama kali mencoba terhubung 00:19:16.160 --> 00:19:20.500 Banyak orang mencoba mengatasinya dengan membagikan kredensial pengguna di seluruh lingkungan 00:19:20.500 --> 00:19:26.920 Mereka pikir, jika menggunakan akun atau kata sandi yang sama untuk membuat koneksi di dev, mungkin itu akan berhasil di prod 00:19:26.920 --> 00:19:31.920 Kenyataannya, cara ini mengundang banyak masalah, mulai dari penolakan izin hingga pemicu audit kepatuhan 00:19:31.920 --> 00:19:38.180 Panduan Microsoft sudah jelas menggunakan kredensial pengguna individu untuk penerapan otomatis tidak layak atau tidak aman 00:19:38.180 --> 00:19:44.060 Hal ini membuat otomatisasi Anda bergantung pada pengaturan ulang kata sandi dan bisa meninggalkan jejak yang membingungkan dalam loka audita 00:19:44.060 --> 00:19:52.480 Tidak ada akuntabilitas yang jelas dan pada akhirnya izin akan memblokir alur kerja saat pengguna asli ditandai, dihapus, atau kehilangan akses 00:19:52.480 --> 00:19:54.480 Mesyuapan Prinsip Layanan 00:19:54.480 --> 00:20:00.060 Jika Anda belum pernah menggunakannya, bayangkan Prinsip Layanan sebagai tangan digital tambahan yang dibuat khusus untuk otomatisasi 00:20:00.060 --> 00:20:08.060 Tidak seperti pengguna biasa, prinsip layanan terikat pada pendaftaran aplikasi di Azure AD bukan orang sungguhan 00:20:08.060 --> 00:20:12.060 Anda memberinya izin minimum yang diperlukan untuk menjalankan tugas penerapan Anda 00:20:12.060 --> 00:20:14.640 Terdengar sederhana, tetapi hasilnya sangat besar 00:20:14.640 --> 00:20:21.360 Alih-alih mengandalkan pengguna yang bisa saja keluar dari organisasi atau berganti peran, penerapan tetap konsisten, dapat diaudit, dan dapat dilacak 00:20:21.360 --> 00:20:27.700 Setiap lingkungan hanya mendapatkan akses ke koneksi dan sumber daya yang tepat, dan setiap perubahan dicatat di bawah akun robot ini 00:20:27.700 --> 00:20:33.820 Ketika terjadi kegagalan, Anda memiliki jejak audit yang jelas dan tidak akan mendapati alur kerja yang terbengkalai tanpa bisa diperbaiki 00:20:33.820 --> 00:20:39.760 Terkait masalah pemetaan konektor, pertimbangkan apa yang terjadi ketika lingkungan kerja menjadi tidak selaras 00:20:39.760 --> 00:20:43.500 Mungkin tim pengembang mendapatkan persetujuan untuk konektor kustom yang baru 00:20:43.500 --> 00:20:45.660 Katakanlah konektor itu mengakses API Sandbox 00:20:45.660 --> 00:20:52.260 Saat waktunya pindah ke lingkungan produksi, konektor itu tidak hanya hilang, tetapi mungkin juga tidak diizinkan oleh kebijakan data organisasi 00:20:52.260 --> 00:20:57.620 Jika Anda lupa memetakan ulang, aplikasi akan memanggil ketika akhir yang salah atau rusak sepenuhnya 00:20:57.620 --> 00:21:00.920 Saya baru saja melihat hal ini berdampak berupa di sebuah perubahan yang sehat 00:21:00.920 --> 00:21:06.380 Satu pemetaan konektor yang terlewat memicu penggunaan data uji dalam produksi dan hampir menciptakan insiden kepatuhan 00:21:06.380 --> 00:21:13.460 Pipa otomatis mereka mengekspor semuanya sesuai rencana, tetapi referensi konektor di dalam solusi masih mengarah ke basis data uji lama 00:21:13.460 --> 00:21:19.380 Yang tidak ditandai oleh power platform, hingga data asli mulai mengalir melalui jalur yang salah hingga jalur yang salah 00:21:19.380 --> 00:21:22.740 Variable lingkungan hadir untuk meredakan sebagian kesulitan ini 00:21:22.740 --> 00:21:30.540 Berbeda dengan pemudaan titik akhir atau kunci API, secara permanen variabel lingkungan memungkinkan Anda memisahkan apa yang berubah antar lingkungan dari apa yang tetap sama 00:21:30.540 --> 00:21:37.040 Anda dapat menukar titik akhir kunci API atau rahasia lainnya di setiap penyebaran tanpa menulis ulang aplikasi atau alur kerja Anda 00:21:37.040 --> 00:21:47.040 Contohnya, alur yang bekerja dengan tabel dataverse pengembang dapat dikonfigurasi ulang saat impor untuk menggunakan tabel produksi hanya dengan mengubah variabel lingkungan di dalam proses penyebaran Anda 00:21:47.040 --> 00:21:50.160 Pipa GitHub Actions membuat hal ini menjadi perak 00:21:50.160 --> 00:21:53.080 Setiap pekerjaan dapat menuntikkan nilai yang tepat pada waktu yang tepat 00:21:53.080 --> 00:21:55.280 Namun, disiplin tetap menjadi kuncinya 00:21:55.280 --> 00:22:02.420 Lupa memperbarui variabel atau membiarkan rahasia bocor antar lingkungan dapat membuat alur kerja Anda tiba-tiba terekspos 00:22:02.420 --> 00:22:08.300 Microsoft nekankan perlunya membatasi ruang lingkungan rahasia dengan cermat dan memetakan referensi konektor secara sengaja 00:22:08.300 --> 00:22:17.200 Kebijakan pencegahan kehilangan data, DLP mereka ada karena suatu alasan untuk mencegah informasi sensitif berpindah antar lingkungan atau muncul di tempat yang salah 00:22:17.200 --> 00:22:21.980 Jika Anda mencoba mengabaikan ini dengan berbagi variabel atau koneksi 00:22:21.980 --> 00:22:26.140 Anda akan terbentur kendali keamanan atau kepatuhan perusahaan 00:22:26.500 --> 00:22:32.600 Lebih penting lagi Anda kehilangan pereditabilitas karena tidak ada lagi batasan antara apa yang ditujukan untuk pengembangan, pengujian, atau produksi 00:22:32.600 --> 00:22:36.420 Manfaat yang didapat ketika Anda melakukan semua ini dengan benar sangatlah besar 00:22:36.420 --> 00:22:42.560 Prinsip layanan yang dikombinasikan dengan variabel lingkungan yang terkelola dengan baik dan konektor yang dipetakan dengan tepat akan mengubah pipa kerja Anda 00:22:42.560 --> 00:22:44.280 Penyebaran Anda menjadi dapat diprediksi 00:22:44.280 --> 00:22:48.660 Saat terjadi kerusakan, Anda memiliki rantai pengawasan yang jelas dan tahu persis kemana harus mencarinya 00:22:48.660 --> 00:22:52.160 Apakah itu kesalahan pembentangan konektor, variabel, atau izin yang terlewat 00:22:52.520 --> 00:22:57.500 Auditor dapat melacak perubahan dan tidak ada keraguan saat seseorang meninggalkan organisasi atau mengubah kata sandi 00:22:57.500 --> 00:23:01.980 Semuanya bermuara pada cara menangani rahasia, konektor, dan prinsip layanan seolah-olah itu hal yang penting 00:23:01.980 --> 00:23:31.960 Selamat menikmati