Latest / M365.FM – Podcast Microsoft 365, Copilot & AI Bahasa Indonesia / ALM Power Platform dengan GitHub Actions: Source, Build, Test, dan Deploy Tanpa Menebak (Sulih Suara AI)

Transcript

ALM Power Platform dengan GitHub Actions: Source, Build, Test, dan Deploy Tanpa Menebak (Sulih Suara AI) · M365.FM – Podcast Microsoft 365, Copilot & AI Bahasa Indonesia

• 0:00
  Siap untuk 10 hari pembahasan Microsoft 365, Copilot AI, Azure, dan para penggerak
• 0:05
  Masa depan dunia kerja
• 0:07
  Januari ini, M365 John kembali hadir dengan skala yang lebih besar
• 0:11
  Bergabunglah dalam sesi langsung
• 0:14
  Demo nyata dan ilmu praktis dari MVP serta pakar industri di seluruh dunia
• 0:18
  Tanpa slide yang umum, tanpa istilah teknis yang berubah
• 0:21
  Kita akan membahas tantangan nyata
• 0:23
  Copilot Studio, agen AI, fabrik, keamanan, tata kelola, dan otomatisasi
• 0:28
  Baik Anda seorang profesional TI, pengembang, atau pemimpin bisnis
• 0:32
  Ada sesi yang gerancang khusus untuk Anda
• 0:34
  Selama 10 hari penuh, Anda bisa menjelajahi berbagai teknologi
• 0:38
  Dan terhubung dengan komunitas global
• 0:40
  Saksikan secara langsung, dan bawa wasam praktis kembali ke organisasi Anda
• 0:44
  Januari 2020 7, 10 hari, satu komunitas Microsoft
• 0:49
  Pendaftaran sudah dibuka sekarang
• 0:50
  Amankan tempat Anda hari ini
• 0:54
  Kunjungi m365.com.net
• 0:58
  Daftar sekarang di m365.com.net
• 1:02
  Dan sampai jumpa, secara langsung di bulan Januari
• 1:04
  Pernah merasa penerapan power platform Anda seperti kota hitam yang misterius?
• 1:08
  Apakah Anda merilis pembaruan, menahan nafas, dan hanya berharap semua yang berjalan lancar di lingkungan dev, tes, dan prod?
• 1:13
  Bagaimana jika Anda bisa mengontrol dan melihat setiap tahap proses ALM Anda
• 1:16
  Menggunakan GitHub Actions tanpa perlu menebak-nebak atau melakukan perbaikan manual?
• 1:20
  Mari kita buka tirai tentang bagaimana setiap komponen, kontrol sumber, otomatisasi, dan variable aman sebenarnya terhubung
• 1:27
  Ah, ini bukan sekadar panduan biasa
• 1:29
  Ini adalah alasan yang sering diabaikan panduan lain agar penerapan Anda berikutnya tidak membuat Anda ragu
• 1:34
  Jadi, mengapa ALM Power Platform terasa seperti labirin?
• 1:38
  Jika Anda pernah mencoba menerapkan power app dan merasa tidak yakin seperti ada sesuatu yang penting terlewatkan, Anda tidak sendiri
• 1:44
  Di atas kertas, Power Platform menjanjikan pengembangan aplikasi yang mudah, namun, dibalik tampilan ramai itu, ALM justru sangat rumit
• 1:52
  Aplikasi web disebarkan, dari kontrol sumber, dibangun dalam pipeline, dan mendarat diproduksi dengan perilaku yang dapat diprediksi
• 1:58
  Sebaliknya, Power Platform menyembunyikan separuh logikanya di dalam antarmuka seret lepas, layar konektor, dan rumus yang tidak terlihat di repository Git manapun
• 2:07
  Jadi, meskipun Anda mengikuti setiap langkah dari panduan admin tingkat atas
• 2:11
  Anda tetap akan menemukan kegagalan aneh yang sulit didiagnosis saat aplikasi bisnis penting keluar dari tahap pengembangan
• 2:16
  Mari kita lihat panduan ALM yang beredar di luar sana
• 2:19
  Sebagian besar akan memandu Anda untuk mengeksplore zip solusi dan mengimpornya ke tempat lain
• 2:23
  Cukup sederhana, bukan?
• 2:25
  Namun, cara melakukannya hanya set rapi sensasi
• 2:27
  Yang mereka lewatkan adalah alasannya
• 2:28
  Mengapa penerapan Power Platform rusak dengan cara yang tidak pernah terjadi pada kode biasa?
• 2:33
  Itulah penyebab kebingungan yang tidak habisnya
• 2:35
  Akar masalahnya adalah logika, koneksi, dan konfigurasi di Power Apps tidak disimpan seperti kode klasik
• 2:41
  Anda tidak hanya sekadar mengkloning repo dan melihat hasil pengujian unit
• 2:44
  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
• 2:53
  Jelas, sekian adunya
• 2:55
  Anda memiliki aplikasi baru yang berfungsi dengan baik di lingkungan berkontak
• 2:57
  Anda mengekspor solusi mengimpornya ke lingkungan pengejian tes dan tiba-tiba alur kerjanya berhenti berhenti
• 3:02
  Ini jarang terjadi hanya karena masalah, Pak
• 3:03
  Sebaliknya, koneksi mengarah ke tempat yang salah, izin tidak selaras, dan kebijakan data memblokir koneksi yang tadinya baik-baik saja beberapa menit lalu
• 3:11
  Sekarang, bayangkan melakukan ini di tiga lingkungan
• 3:14
  Dev, Tes, dan Prod
• 3:15
  Dengan masing-masing, menggunakan koneksi, kebijakan pelindungan data, penyetuju, dan pengamaran admin yang berbeda
• 3:21
  Anda tidak bisa mengatasinya yang saya menempel
• 3:23
  Penelitian mendukung apa yang dilihat admin dan pembuat aplikasi setiap minggunya
• 3:27
  Mayoritas kegagalan penerapan power platform berasal dari referensi konektor yang hilang atau variable lingkungan yang tidak dikelola dengan benar
• 3:33
  Kehilangan referensi konektor berarti alur kerja tidak dapat menemukan koneksi Outlook atau Dataverse-nya
• 3:39
  Jadi, saat Anda mencoba menjalankan aplikasi atau alur kerja di lingkungan lain, Anda akan mendapatkan kesalahan waktu proses
• 3:45
  Dan karena variable lingkungan di power platform bekerja berbeda dibandingkan produk Microsoft 365 lainnya, hal ini sering menjebak pengembang berpengalaman sekalipun
• 3:54
  Variable seharusnya menangani endpoint kunci atau konfigurasi khusus penyewa, tenat
• 3:59
  Namun, jika seseorang lupa memperbaruinya setelah mengekspor solusi, perubahan yang terlihat sepeli pun bisa merusak aplikasi yang sedang berjalan
• 4:06
  Banyak dari kita terjebak dalam masalah yang sama pada awalnya
• 4:08
  Anda mungkin mengekspor zip solusi sudah mencakup segalanya, padahal sebenarnya sistem melewatkan referensi konektor dinamis
• 4:14
  Misalnya, Anda memiliki aplikasi yang menggunakan konektor HTTP untuk layanan pihak ketiga di pengandang
• 4:19
  Saat Anda mengimpor kelingkungan tes atau prod, instans konektor tersebut tidak akan ada
• 4:23
  Referensi konektor di dalam aplikasi Anda mengarah ke objek yang hilang
• 4:27
  Dan alur kerja di dalam solusi tersebut rusak diam-diam
• 4:30
  Hingga pengguna atau admin membuat ulang dan memetakan koneksi secara manual
• 4:34
  Jika Anda memiliki lebih dari satu pembuat atau admin
• 4:37
  Akan lebih mudah kehilangan jejak referensi
• 4:39
  Dan tidak ada yang menginginkan evaluasi pasca kejadian di dev tadi berhasil
• 4:43
  Masalah lainnya adalah service prinsipal
• 4:46
  Kebanyakan orang mulai dengan menggunakan akun pengguna
• 4:49
  Untuk mengekspor dan mengimpor solusi karena lebih cepat untuk memulai
• 4:52
  Namun, saat Anda mencoba melakukan otomatisasi dengan GitHub Actions atau sistem CI
• 4:57
  Apapun menggunakan kredensial pribadi akan menemui jalan bentuk dengan cepat
• 4:59
  Anda akan terbenturi izin, terkadang tanpa pesan kesalahan yang jelas
• 5:02
  Atau bahkan memicu audit kepatuhan karena Anda menjalankan penerapan kritis
• 5:05
  Menggunakan akun pribadi bukan akun yang memang ditujukan untuk otomatisasi
• 5:08
  Bukan akun yang memang ditujukan untuk otomatisasi
• 5:10
  Service prinsipal yang pada dasarnya adalah identitas aplikasi yang dibuat di Azure AD
• 5:14
  Menangani semua izin, pencatatan, dan audit yang dibutuhkan pipeline Anda
• 5:18
  Tanpanya, rantai otomatisasi Anda berubah menjadi serangkaian serah terima
• 5:22
  Antara orang yang tidak rapi dan Anda tidak akan pernah tahu siapa yang mengubah apa
• 5:25
  Kontrol sumber pun menjadi tidak menentu
• 5:27
  Dengan kode biasa, Anda memiliki rewak commit dan alat pelacakan perubahan
• 5:31
  File solusi Power Platform hanya memakai snapshot
• 5:34
  Yang berarti Anda kehilangan pelacakan perubahan secara mendetail
• 5:36
  Logika yang tersembunyi dalam rumus layar Canvas App
• 5:39
  Atau dalam alur yang kurang terdokumentasi tidak terlihat sampai Anda mengekspornya kembali
• 5:43
  Seseorang mengubah pengaturan alur di UI
• 5:46
  Dan semoga berhasil mencari tahu mengapa lingkungan hilir tiba-tiba berperilaku berbeda
• 5:49
  Hasil akhirnya, mengelola ILM untuk Power Platform
• 5:52
  Terasa seperti menyusun teka-teki dengan separuh bagian yang hilang
• 5:55
  Atau setidaknya tersembunyi di bawah kotak
• 5:56
  Dependensi yang tidak terlihat, konektor spesifik lingkungan, dan variable
• 6:00
  Yang tidak bisa Anda lihat dalam kode
• 6:02
  Semuanya mengubah alur kerja pengembang yang biasa
• 6:05
  Dan itu belum termasuk fakta bahwa lingkungan produksi hampir selalu memiliki izin yang lebih ketat
• 6:10
  Kebijakan data yang berbeda
• 6:12
  Dan persyaratan audit yang tidak tampak di lingkungan pengembangan atau pengujian
• 6:15
  Tapi nah sisi positifnya
• 6:18
  Kompleksitas ini bukan kebetulan
• 6:19
  Ada alasan praktis mengapa Power Platform menangani sumber variable dan konektor dengan carai
• 6:25
  Yang unik
• 6:26
  Platform ini berupaya agar pengguna bisnis dapat membangun aplikasi canggih tanpa perlu khawatir soal kode
• 6:31
  Efek sampingnya adalah Anda sebagai orang yang mengatur otomatisasi harus melacak apa yang tersembunyi di balik layar
• 6:37
  Jika Anda tahu kemana kabel-kabel tak terlihat itu terhubung
• 6:41
  Anda dapat memperbaiki atau menghindari sebagian besar kesalahan fatal yang mengganggu ALM Power Platform
• 6:45
  Sekarang jika semua ini terdengar berat
• 6:48
  Anda tidak salah
• 6:49
  Namun ada empat pilar ALM yang benar-benar membantu mengurai kerumitan ini
• 6:53
  Sumber bangun uji dan sebarkan
• 6:55
  Masing-masing memiliki keunikan di Power Platform tetapi bersama-sama mereka menggembalikan struktur ke dalam situasi yang terasa kacau
• 7:01
  Sistem ALM inti sumber bangun uji sebarkan
• 7:04
  Setiap kali seseorang meminta pipeline Power Platform yang langsung berfungsi
• 7:08
  Hal pertama yang terlintas di pikiran adalah empat pilar ALM lama tersebut yaitu sumber bangun uji dan sebarkan
• 7:14
  Dalam dunia pengembangan tradisional Anda hampir bisa melakukannya sambil tidur
• 7:18
  Power Platform tidak membiarkan Anda lepas dengan mudah
• 7:21
  Tiba-tiba sumber tidak berarti kode
• 7:24
  Itu berarti harus bergulat dengan file solusi
• 7:26
  Mengekspor bundel zip berisi aplikasi alur dan terkadang konektor yang berpura-pura menjadi bagian dari sumber
• 7:33
  Mari mulai dengan dasarnya
• 7:35
  Lalu beda apa yang membuat setiap pilar terasa sedikit aneh di dunia ini
• 7:38
  Anda memiliki file tips Anda
• 7:40
  Ini bukan kode dalam pengertian biasa
• 7:41
  Buka file tersebut dan Anda akan disambut oleh file penjelasan XML dan JSON bukan logika yang biasa Anda lihat di TypeScript atau C-SARP
• 7:48
  Namun inilah sumber untuk workload
• 7:50
  Tim seringkali terkendala di sini
• 7:52
  Terlihat portable sampai Anda menyadari sebagian besar perubahan
• 7:55
  Seperti memperbarui rumus di layar atau mengubah logika alur tidak terlihat jelas sampai Anda mengekspor zip solusi yang baru
• 8:01
  Jadi ya Anda bisa membuat versi file solusi ini di git tetapi kecuali Anda disiplin mengekspor setelah setiap pengeditan yang relevan
• 8:07
  Riwet Anda akan memiliki celah yang mencolok
• 8:09
  Sekarang masuk ke konfigurasi
• 8:11
  Untuk aplikasi biasa Anda mungkin menyimpan string koneksi dalam file konfigurasi dan selesai
• 8:16
  Power Platform menyisipkan data khusus lingkungan di dalam solusi ini
• 8:20
  Ini bukan hanya variable lingkungan tetapi referensi konektor, titik akhir dinamis, peran, dan izin yang digabungkan bersama logika bisnis
• 8:28
  Jika Anda lupa memperbaruinya sebelum mengekspor dari pengembangan atau pengujian, Anda mengunci penunjuk ke tempat yang salah
• 8:35
  Saya telah melihat tim dengan tekun melakukan komit pada file zip solusi mereka
• 8:39
  Hanya untuk menyadari saat diterapkan bahwa separuh aplikasi mereka masih terhubung ke data first pengembangan
• 8:44
  Bukan produksi karena tidak ada yang memetakkan ulang referensi konektor
• 8:47
  Selanjutnya kita masuk ke tab
• 8:49
  Kata build biasanya memunculkan bayangan kompilasi kode dan melihat tanda centang hijau dalam pekerjaan CI
• 8:54
  Dengan Power Platform, proses build adalah tentang menyimpan bundel zip tersebut, memeriksa skema dua kali, dan meverifikasi dependensi
• 9:01
  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
• 9:11
  Langkah validasi adalah tempat keajaiban atau kekacauan terjadi
• 9:14
  Langkah ini mungkin mendeteksi referensi yang rusak atau tindakan yang tidak didukai
• 9:17
  Lebih buruk lagi, jika perubahan pada alur Anda bergantung pada konektor custom yang tidak pernah masuk ke kontrol sumber
• 9:22
  Build Anda secara diam-diam mengemas sesuatu yang tidak lengkap
• 9:25
  Disinilah keadaan menjadi rumit
• 9:27
  Pekerjaan build tersebut lebih tentang mengatur ekspor yang andal dan memastikan apa yang ada di dalamnya siap dikirim
• 9:33
  Bukan sekadar kompilasi, bukan sekadar kompilasi
• 9:35
  Tim yang melewatkan atau terburu-buru melakukan ini akan dengan cepat berada dalam situasi di mana build secara teknis berhasil
• 9:40
  Tetapi apa yang sampai ke UAT atau produksi kehilangan separuh fitur yang diinginkan
• 9:44
  Microsoft terus menekankan pesan bahwa file solusi membuat ALM portable namun selalu ada catatan kaki
• 9:49
  Portabilitas bergantung pada konektor yang dipetakan dengan benar dan peran yang disiapkan di seluruh lingkungan
• 9:54
  Pengujian adalah tab berikutnya
• 9:56
  Dalam pipeline aplikasi web, pengujian otomatis mungkin menjalankan tes unit atau pemeriksaan UI
• 10:01
  Untuk power platform, apa yang dianggap sebagai pengujian masih bisa diperbatkan
• 10:05
  Terkadang itu adalah validasi solusi
• 10:07
  Dengan kata lain apakah solusi terbuka dan apakah dependensi utama teratasi
• 10:11
  Dilain waktu itu adalah menjalankan alur pengujian atau meriksa apakah konektor merespons di lingkungan pengujian-pengujian
• 10:17
  Seringkali pengujian dilakukan secara manual karena memvalidasi logika bisnis di dalam kanvas app belum terhubung ke alur kerja otomatis
• 10:24
  Wits
• 10:24
  Namun, Anda bisa mengotomatiskan pemeriksaan untuk mendeteksi konektor yang hilang memvalidasi alur penting
• 10:29
  Atau sekadar melakukan ping ke lingkungan pengujian untuk memastikan kredensial berfungsi
• 10:33
  Penyebaran BWM adalah bagian ini
• 10:35
  Saat mendeplay aplikasi standar, Anda mungkin hanya perlu mendorong artefak web ke Azure
• 10:39
  Dengan power platform, Anda harus membutuhkan koneksi, menetapkan izin, memperbarui rahasia, menukar variable lingkungan
• 10:44
  Dan akhirnya memicu import menggunakan service prinsipal, bukan akun biasa
• 10:48
  Bukan akun biasa
• 10:49
  Jika tidak, Anda akan terjebak dengan audit dan penolakan izin
• 10:52
  GitHub Actions dapat menyatukan proses ini
• 10:55
  Tetapi hanya jika setiap tugas tahu lingkungan mana yang dituju dan rahasia mana yang digunakan
• 10:59
  Saya pernah melihat tim mencoba jalan pintas dengan menggunakan satu set kredensial untuk dev dan prod
• 11:04
  Yang justru memicu kekacauan, kebocoran data, kesalahan izin, dan fitur rusak yang hanya muncul di satu lingkungan
• 11:09
  Dan fitur lingkungan
• 11:10
  Ambil contoh tim nyata yang sudah bekerja dengan saya beberapa bulan lalu
• 11:13
  Mereka melakukan banyak hal dengan benar
• 11:15
  Seperti menggunakan repository git standar, file chip solusi perversi, dan percambangan engine
• 11:18
  Namun, pipeline mereka selalu gagal saat deployment
• 11:20
  Mereka tidak pernah menukar variable lingkungan
• 11:23
  Atau memperbarui referensi konektor sebelum mengimpor ke prod
• 11:26
  Hal itu menyebabkan alu utama mengarah ke titik akhir yang salah
• 11:29
  Dengan data yang mengalir ke sistem yang clear
• 11:30
  Solusinya adalah
• 11:32
  Menambahkan langkah-langkah script di pipeline GitHub mereka
• 11:34
  Yang menukar variable dan memetakkan ulang setiap konektor saat import
• 11:37
  Panduan resmi dari Microsoft sangat jelas mengenai hal ini
• 11:40
  Gunakan file solusi untuk memindahkan komponen antar lingkungan
• 11:43
  Namun, selalu tangani referensi konektor dan pembetahan peran sebagai bagian dari pipeline Anda
• 11:47
  Mereka menekankan bahwa melewatkan langkah-langkah ini adalah penyebab utama rusaknya aplikasi
• 11:51
  Terutama saat lingkungan semakin diperketat keamanannya
• 11:53
  Setelah Anda memperlakukan sumber, build, pengujian, dan penyebaran sebagai bagian yang saling terhubung
• 11:58
  Bukan langkah terpisah akan lebih mudah untuk melihat mengapa banyak upaya LM gagal
• 12:02
  Dan bagaimana Anda bisa memecahkan masalah alih-alih hanya berharap
• 12:05
  Selanjutnya, mari kita bahas bagaimana GitHub Actions mengkoordinasikan proses ini
• 12:11
  Pemicu, percambangan, dan pemisahan tugas yang menjaga otomatisasi power platform Anda tetap fleksibel dan aman
• 12:16
  GitHub Actions menghubungkan semuanya dengan pemicu dan tugas
• 12:20
  Jika Anda pernah menunggu pipeline GitHub Actions selesai setelah memperbarui Power App
• 12:24
  Anda tahu bahwa otomatisasi tidak berarti instan dan tentu saja bukan sihir
• 12:27
  Kebanyakan tim terbentur kendala tepat setelah keseruan melihat alur kerja pertama mereka berjalan
• 12:33
  Anda menyiapkan skrip, menghubungkannya ke repository, dan berharap setiap komitmen baru akan dirilis dengan mulus di semua lingkungan
• 12:41
  Lalu kenyataan mulai terasa
• 12:42
  Alih-alih sekadar menjalankan skrip, kita baiknya menggunakan rantai logika
• 12:46
  Yang dibangun berdasarkan pemicu, tugas, dan serah terima antar lingkungan
• 12:50
  Urutan dan struktur tersebut menjaga penerapan agar tidak menjadi tumpukan langkah yang gagal dan kesalahan yang aneh
• 12:56
  Titik awal dalam sistem ini adalah pemicu
• 12:58
  Kebanyakan pengguna pemula membuat alur kerja yang aktif
• 13:02
  Pada setiap dorongan push atau kapanpun permintaan tarik pull request masuk ke cabang utama
• 13:07
  Sekilas, itu tampak seperti terbaik
• 13:10
  Mengapa tidak menjalankan alur pipa Anda setiap kali jangan?
• 13:12
  Inilah masalahnya
• 13:13
  Saat Anda hanya mengatur pemicu di cabang utama, semuanya disalurkan melalui satu jalur saja
• 13:17
  Bagaimana jika perubahan perlu masuk ke dev tetapi tidak ke tes atau prod?
• 13:20
  Bagaimana jika Anda siap mendorong ke prod tetapi tes masih menjalankan validasi?
• 13:23
  Tim yang terpaku pada pemicu satu ukuran untuk semua cenderung mengalami masalah
• 13:27
  Dimana fitur yang ditujukan untuk lingkungan pengembangan menyusup ke produksi
• 13:30
  Atau penerapan pengujian secara tiba-tiba menimpa pengaturan prod
• 13:34
  Anda bisa mencabangkan alur kerja untuk setiap lingkungan
• 13:37
  Dev, tes, dan prod
• 13:38
  Serta mengatur pemicu yang sangat spesifik untuk masing-masing
• 13:42
  Sebagai contoh, atur alur kerja yang hanya berjalan saat ada dorongan ke cabang dev
• 13:45
  Atau aktifkan alur kerja berbeda saat seseorang menggabungkan ke release prod
• 13:49
  Pendekatan ini memberikan lebih banyak kontrol dan menciptakan batasan yang jelas
• 13:53
  Antara pekerjaan yang sedang berlangsung dan perubahan langsung
• 13:55
  Namun banyak tim tidak pernah menjauh kembali pemicu mereka setelah membuat
• 13:58
  Begitulah rahasia dari satu lingkungan bisa menyelinap ke lingkungan lain
• 14:01
  Dan konfigurasi yang ditujukan untuk dev berakhir di prod secara tidak sengaja
• 14:05
  Satu tim yang pernah bekerja dengan saya mencoba menjalankan seluruh proses alam mereka dari satu alur kerja tulu
• 14:10
  Untuk sementara, itu tampak baik-baik saja
• 14:12
  Sampai seseorang menyadari bahwa string koneksi basis data produksi muncul di lingkungan dev muncul di lingkungan dev
• 14:18
  Mereka tidak menyadari bahwa rahasia mereka dibagikan di antara tugas-tugas
• 14:21
  Dan begitu kode berpindah antar lingkungan, rahasia-rahasia itu bocor bersamanya
• 14:24
  Itu bukan kerusakan atau kesalahan yang mencob
• 14:26
  Itu terjadi sejarah game
• 14:27
  Kebocoran data semacam ini lebih umum terjadi daripada yang Anda kira
• 14:30
  Terutama jika Anda tidak mengatur alur kerja untuk memisahkan rahasia dan variable lingkungan
• 14:34
  Setiap tugas dalam alur kerja GitHub Actions menangani bagian yang jelas dari proses tersebut
• 14:39
  Satu tugas mungkin menangani ekspor solusi dari lingkungan sumber
• 14:43
  Tugas lain menangani validasi pembongkaran
• 14:45
  Pemindahkan metadata solusi, memeriksa semua dependensi
• 14:48
  Dan memastikan referensi, konektor, ada
• 14:51
  Selanjutnya adalah tugas yang menyiapkan variable khusus lingkungan
• 14:55
  Menerjemahkan solusi agar sesuai dengan lingkungan targetnya
• 14:58
  Tugas terakhir memicu proses impor menggunakan prinsip pelayanan untuk menulis perubahan ke dalam lingkungan yang tepat
• 15:04
  Anda mungkin menganggap variable lingkungan dan rahasia sebagai penampung dasar
• 15:07
  Tetapi dalam prakteknya mereka adalah perkat yang menyatukan semuanya
• 15:10
  Merekat yang menyatukan semua
• 15:12
  String koneksi, kunci API, dan kata Sandy bersama harus ditukar
• 15:16
  Antar tugas tetapi tidak boleh bocor melintasi batasan
• 15:19
  Dalam ILM Power Platform Anda mungkin memiliki koneksi data khusus yang berbeda untuk setiap lingkungan
• 15:24
  Atau perlu menukar titik akhir tergantung pada alur atau power app yang ditargetkan
• 15:28
  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
• 15:36
  Proses impor bergantung pada pengambilan rahasia hanya dari berangkas yang tepat sehingga produksi tidak terekspos oleh kesalahan pengujian atau pengembangan
• 15:43
  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
• 15:52
  GitHub memberi Anda kontrolan presisi
• 15:54
  Anda dapat membatasi rahasia pada lingkungan tertentu sehingga tugas yang berjalan di dev tidak dapat mengakses kredensial prod dan sebaliknya
• 16:01
  Atur berangkas ini dan meskipun seseorang yang mengubah pipeline mencoba sesuatu yang berisiko
• 16:06
  Aturan perlindungan lingkungan akan mencegah kesalahan meluas
• 16:09
  Dokumentasi dari Microsoft maupun GitHub sendiri sangat menekankan poin ini
• 16:13
  Mereka merekomendasikan aturan perlindungan lingkungan dan perbatasan rahasia yang ketat untuk menghentikan kebocoran antar lingkungan sebelum terjadi
• 16:19
  Tanpa perlindungan semacam itu, alur kerja ALM yang dirancang paling baik sekalipun akan berantakan
• 16:24
  Bayangkan alur kerja yang menyebarkan ke prod saat masih menggunakan string koneksi dev atau lingkungan pengujian yang tiba-tiba memiliki akses ke data prod
• 16:32
  Hal ini tidak salah merusak sistem secara kesat mata
• 16:34
  Terkadang ini hanya berarti bendera kepatuhan menyala atau log dipenuhi dengan kesalahan halus yang perlahan menumpuk menjadi masalah yang lebih besar
• 16:40
  Inilah sebabnya alur kerja percabang dan pembatasan rahasia bukan sekadar topik tingkat lanjut
• 16:44
  Hal-hal tersebut adalah jaring pengaman yang menjaga otomatisasi Anda agar tidak hancur secara dip
• 16:48
  Ada juga nilai dalam membagi alur kerja tidak hanya berdasarkan lingkungan tetapi berdasarkan tanggung jawab
• 16:52
  Koda yang mengekspor dan memvalidasi solusi seharusnya bahkan tidak perlu tahu cara menyebarkan atau menukar rahasia
• 16:59
  Jika setiap tugas menangani satu bagian dari teka-teki akan jauh lebih mudah untuk menemukan dimana letak kerusakan melakukan pemulihan dan mengaudit perubahan setelahnya
• 17:07
  Rahasia tetap berada di berangkasnya tugas mengikuti izin yang dibatasi dengan jelas dan kegagalan pipeline langsung menunjuk ke bagian yang perlu diperbaiki
• 17:15
  Memahami bagaimana GitHub Actions menyerahkan pekerjaan dari satu tugas ke tugas lain
• 17:19
  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
• 17:28
  Segmentasi alur kerja ini bukan sekadar tentang mengikuti praktek terbaik
• 17:32
  Hal ini memblokir kebocoran keamanan, diam-diam, dan penimpaan yang tidak disengaja
• 17:37
  Serta memotong seluruh kategori kesalahan tidak terlihat sebelum mulai menghantui lingkungan Anda
• 17:41
  Sekarang dengan bagian-bagian yang bekerja bersama melalui otomatisasi yang dibatasi dengan tepat saatnya kita mengatasi hambatan lainnya
• 17:48
  Konektor, prinsip layanan, dan jebakan kecil namun krusial yang bisa menghambat penerapan Anda tepat saat Anda mulai merasa percaya diri
• 17:56
  Rahasia prinsip layanan dan masalah pada konektor
• 17:59
  Jika Anda pernah mencoba mendahkan power app atau flow dari dev ke prod, Anda pasti tahu ceritanya
• 18:04
  Semuanya berjalan lancar di satu lingkungan, tetapi begitu Anda beralih, semuanya terhenti atau muncul kesalahan koneksi yang membingungkan
• 18:12
  Ini bukan hanya di alam latin tertentu saja
• 18:15
  Setiap admin power platform pada akhirnya akan menghadapi kendala ini
• 18:18
  Akar permasalahannya terletak pada bagaimana konektor dan rahasia bekerja di balik layar
• 18:23
  Anda tidak bisa begitu saja mengekspor jeb solusi dari pengembangan dan berharap itu berfungsi di tempat lain karena alurnya berubah di setiap lingkungan
• 18:32
  Ambil contoh referensi konektor sebagai permulaan
• 18:34
  Di power platform, konektor bukanlah sekadar informasi statis yang dibundang ke dalam aplikasi Anda, dev
• 18:40
  Sifatnya dinamis bisa diubah dan seringkali unik untuk setiap lingkungan
• 18:43
  Saat Anda mengekspor solusi, referensi konektor bertindak hampir seperti penanda
• 18:47
  Referensi tersebut menunjuk ke objek koneksi yang hanya ada di lingkungan tempat objek tersebut dibuat
• 18:52
  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
• 19:00
  Di sini ada tim seringkali tebak
• 19:02
  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
• 19:16
  Banyak orang mencoba mengatasinya dengan membagikan kredensial pengguna di seluruh lingkungan
• 19:20
  Mereka pikir, jika menggunakan akun atau kata sandi yang sama untuk membuat koneksi di dev, mungkin itu akan berhasil di prod
• 19:26
  Kenyataannya, cara ini mengundang banyak masalah, mulai dari penolakan izin hingga pemicu audit kepatuhan
• 19:31
  Panduan Microsoft sudah jelas menggunakan kredensial pengguna individu untuk penerapan otomatis tidak layak atau tidak aman
• 19:38
  Hal ini membuat otomatisasi Anda bergantung pada pengaturan ulang kata sandi dan bisa meninggalkan jejak yang membingungkan dalam loka audita
• 19:44
  Tidak ada akuntabilitas yang jelas dan pada akhirnya izin akan memblokir alur kerja saat pengguna asli ditandai, dihapus, atau kehilangan akses
• 19:52
  Mesyuapan Prinsip Layanan
• 19:54
  Jika Anda belum pernah menggunakannya, bayangkan Prinsip Layanan sebagai tangan digital tambahan yang dibuat khusus untuk otomatisasi
• 20:00
  Tidak seperti pengguna biasa, prinsip layanan terikat pada pendaftaran aplikasi di Azure AD bukan orang sungguhan
• 20:08
  Anda memberinya izin minimum yang diperlukan untuk menjalankan tugas penerapan Anda
• 20:12
  Terdengar sederhana, tetapi hasilnya sangat besar
• 20:14
  Alih-alih mengandalkan pengguna yang bisa saja keluar dari organisasi atau berganti peran, penerapan tetap konsisten, dapat diaudit, dan dapat dilacak
• 20:21
  Setiap lingkungan hanya mendapatkan akses ke koneksi dan sumber daya yang tepat, dan setiap perubahan dicatat di bawah akun robot ini
• 20:27
  Ketika terjadi kegagalan, Anda memiliki jejak audit yang jelas dan tidak akan mendapati alur kerja yang terbengkalai tanpa bisa diperbaiki
• 20:33
  Terkait masalah pemetaan konektor, pertimbangkan apa yang terjadi ketika lingkungan kerja menjadi tidak selaras
• 20:39
  Mungkin tim pengembang mendapatkan persetujuan untuk konektor kustom yang baru
• 20:43
  Katakanlah konektor itu mengakses API Sandbox
• 20:45
  Saat waktunya pindah ke lingkungan produksi, konektor itu tidak hanya hilang, tetapi mungkin juga tidak diizinkan oleh kebijakan data organisasi
• 20:52
  Jika Anda lupa memetakan ulang, aplikasi akan memanggil ketika akhir yang salah atau rusak sepenuhnya
• 20:57
  Saya baru saja melihat hal ini berdampak berupa di sebuah perubahan yang sehat
• 21:00
  Satu pemetaan konektor yang terlewat memicu penggunaan data uji dalam produksi dan hampir menciptakan insiden kepatuhan
• 21:06
  Pipa otomatis mereka mengekspor semuanya sesuai rencana, tetapi referensi konektor di dalam solusi masih mengarah ke basis data uji lama
• 21:13
  Yang tidak ditandai oleh power platform, hingga data asli mulai mengalir melalui jalur yang salah hingga jalur yang salah
• 21:19
  Variable lingkungan hadir untuk meredakan sebagian kesulitan ini
• 21:22
  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
• 21:30
  Anda dapat menukar titik akhir kunci API atau rahasia lainnya di setiap penyebaran tanpa menulis ulang aplikasi atau alur kerja Anda
• 21:37
  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
• 21:47
  Pipa GitHub Actions membuat hal ini menjadi perak
• 21:50
  Setiap pekerjaan dapat menuntikkan nilai yang tepat pada waktu yang tepat
• 21:53
  Namun, disiplin tetap menjadi kuncinya
• 21:55
  Lupa memperbarui variabel atau membiarkan rahasia bocor antar lingkungan dapat membuat alur kerja Anda tiba-tiba terekspos
• 22:02
  Microsoft nekankan perlunya membatasi ruang lingkungan rahasia dengan cermat dan memetakan referensi konektor secara sengaja
• 22:08
  Kebijakan pencegahan kehilangan data, DLP mereka ada karena suatu alasan untuk mencegah informasi sensitif berpindah antar lingkungan atau muncul di tempat yang salah
• 22:17
  Jika Anda mencoba mengabaikan ini dengan berbagi variabel atau koneksi
• 22:21
  Anda akan terbentur kendali keamanan atau kepatuhan perusahaan
• 22:26
  Lebih penting lagi Anda kehilangan pereditabilitas karena tidak ada lagi batasan antara apa yang ditujukan untuk pengembangan, pengujian, atau produksi
• 22:32
  Manfaat yang didapat ketika Anda melakukan semua ini dengan benar sangatlah besar
• 22:36
  Prinsip layanan yang dikombinasikan dengan variabel lingkungan yang terkelola dengan baik dan konektor yang dipetakan dengan tepat akan mengubah pipa kerja Anda
• 22:42
  Penyebaran Anda menjadi dapat diprediksi
• 22:44
  Saat terjadi kerusakan, Anda memiliki rantai pengawasan yang jelas dan tahu persis kemana harus mencarinya
• 22:48
  Apakah itu kesalahan pembentangan konektor, variabel, atau izin yang terlewat
• 22:52
  Auditor dapat melacak perubahan dan tidak ada keraguan saat seseorang meninggalkan organisasi atau mengubah kata sandi
• 22:57
  Semuanya bermuara pada cara menangani rahasia, konektor, dan prinsip layanan seolah-olah itu hal yang penting
• 23:01
  Selamat menikmati