Selamat datang di episode lain dari Microsoft Knowledge Nuggets di M365FM. Saya pemandu Anda, Mirko Peters. Anda selama ini mendeploy sumber daya Azure dengan mengeklik di dump port. Cara itu berhasil-hasil tidak berfungsi. Lalu Anda perlu melakukannya lagi tetapi Anda tidak ingat apa yang Anda pilih. Anda perlu menyerahkannya kepada rekantin dan mereka tidak bisa mengikuti langkah. Kontroversi. Tidak ada yang bisa dikomit. Itulah masalah yang akan kita selesaikan hari ini. Di akhir episode ini, Anda akan mengerti apa itu infrastructure escort, mengapa BICIP ada, dan bagaimana hal itu membuat deployment Azure lebih mudah dan andal. Kita akan mulai dengan masalahnya, lalu solusinya, kemudian contoh praktis yang bisa Anda ikuti. Ambil kopi Anda, dan mari kita mulai. Masalah portal. Jebakan klik untuk deploy terasa cepat. Anda masuk, isi formulir, tekan buat, dan selesai. Namun apa yang terjadi saat Anda perlu melakukannya lagi dengan pengaturan wilayah dan konvensi penambahan yang sama?

Anda harus mengingat setiap hal yang Anda pilih, dan disitulah segalanya berantakan. Deployment manual berarti hasil yang tidak konsisten, kesalahan manusia, dan tanpa jejak audit. Ini contoh dunia nyata. Seseorang di tim Anda membuat sumber daya dengan pengaturan yang sedikit berbeda. Sekarang Anda punya dua lingkungan yang tidak cocok. Satu berfungsi, yang lain tidak, dan semoga berhasil mencari tahu alasan. Lalu ada masalah dokumentasi. Infrastruktur dalam dokumen Word, atau lebih buruk lagi, video YouTube yang direkam 6 bulan lalu saat portal terlihat sangat berbeda. Fitur pindah menu berubah, opsi baru muncul. Saya berbincang dengan manajer produk dari tim portal Azure, dan dia bilang mereka merilis fitur baru 2 kali sehari. 2 kali sehari. Dokumen Word Anda suak dalam luar sabahkan sebelum Anda selesai menulis. Begini masalah. Mengklik itu efektif untuk belajar, tapi gagal untuk produksi.

Jadi apa alternatifnya? Anda menulis file yang menjelaskan apa yang Anda inginkan. Lalu Anda minta Azure untuk membangun. Apa itu Infrastructure as Code? Infrastructure as Code berarti mengelola pengaturan kode Anda dengan kode alih-alih mengeklik di portal. Ini ide utamanya. Anda menulis file yang mendeskripsikan infrastruktur Anda. File itu ada di repository Anda. Dan Anda bisa melakukan kontroversi, meninjaunya dalam pull request, dan menjalankannya lagi besok untuk hasil yang sama. Ada istilah kunci di sini, deklaratif. Itu berarti Anda menjelaskan apa yang Anda inginkan, bukan cara membangunnya. Anda tidak memberitahu Azure untuk membuat grup sumber daya dulu, lalu menambah akun penyimpanan, lalu mengonfigurasi jaring. Sebaliknya, Anda katakan saya ingin grup sumber daya dengan akun penyimpanan dan jaringan yang dikonfigurasi seperti ini. Dan Azure menentukan urutan. Hasilnya adalah sebuah yang disebutkan di potensi.

Jalangkan sekali, jalangkan 100 kali, dan Anda mendapatkan hasil yang sama. Belak kekuatan. Anggap saja seperti cetak biru dibandingkan membangun dengan tangan. Cetak biru dapat diulang, dibagikan, dan ditinjau. Berikan kepada orang lain, dan mereka akan membangun hal yang persis. Sekarang beberapa alat nih. Templat IRM, Bicep, Terraform, Bulmi. Semuanya menerapkan konsep yang sama dengan cara yang berbeda. Itu adalah perbedaan yang penting. Infrastruktur sebagai kodera konsepnya. Bicep hanyalah salah satu alat yang menerapkannya. Dan inilah masalahnya. Azure telah memiliki bahasa IAC selama bertahun-tahun yang disebut templatan. Dan ada alasan mengapa Microsoft membuat yang baru. Masalah templat IRM. Templat IRM adalah format IAC Azure yang asli. Itu adalah file JSON. Dan punya banyak keunggulan. Cakupan penuh setiap sumber daya Azure. Dan mesin penyebaran yang sama seperti yang Anda gunakan secara internal.

Jika Anda bisa membuatnya di portal, Anda bisa mendefinisikannya di templat IRM. Apa masalahnya? JSON bagus untuk mesin, tetapi buruk bagi manusia. Biar saya tunjukkan maksud saya. Akun penyimpanan dalam templat IRM membutuhkan sekitar 20 baris kod. Akun penyimpanan yang sama di Bicep sekitar 10 baris. Versi JSON kira-kira dua kali ukurannya. Dan itu hanya sumber daya yang sederhana. Bayangkan penyebaran penuh dengan jaringan, komputasi, basis data, dan aturan keamanan. Templat IRM menjadi dinding teks. Titik masalah yang umum dapat diprediksi. Koma yang hilang, kurung yang tidak cocok, penumpukan kata yang membuat sulit untuk mengetahui di mana satu sumber daya berakhir dan yang lain dimulai. Anda menghabiskan lebih banyak waktu bergulat dengan sintaks JSON daripada benar mendefinisikan infrastrukturan. Lalu ada dependensi. Di ARM, Anda harus secara manual menyatakan depends on. Jika sumber daya A membutuhkan sumber daya B untuk Anda terlebih dahulu, Anda harus menuliskannya secara eksplisit.

Lewatkan satu dan penyebaran Anda gagal. Semoga berhasil mencari tahu mana yang Anda lapatkan. Jika Anda pernah mencoba menulis file JSON 200 baris dengan tangan, itu tidak menyenangkan. Bahkan sedikit pun tidak. Kurva pembelajarannya curah. Anggota tim baru berjuang untuk memahami templat IRM. Hambatan masuknya tinggi. Dan apa yang terjadi dalam praktek? Banyak tim berakhir dengan satu orang yang mengetahui templat IRM. Orang itu menjadi titik kegagalan tunggal. Mereka satu-satunya yang bisa memodifikasi penyebaran dan satu-satunya yang bisa mendebaknya saat ada yang rusak. Itu tidak berkelanjutan. Microsoft mendengar masukan tersebut. Jadi mereka membangun B-CEP untuk mengatasi masalah lain. Apa itu B-CEP? Jadi apa sebenarnya B-CEP itu? Ini adalah bahasa yang dirancang untuk mendeploy sumber daya Azure dan intinya adalah sebuah transpiler. Anda menulis B-CEP dan ia akan dikompilasi menjadi JSON-ARM.

Mesinnya sama tetapi cara penulisannya jauh lebih rapi. Dan nama B-CEP sebenarnya adalah ARM yang dieja terbalik. B-CEP, ARM. Sebuah lucu yang ternak kecil dari Microsoft. Namun begitu Anda melihatnya beraksi itu masalah. B-CEP berada di atas ARM alih menggantikannya. Anda mendapatkan kekuatan yang sama dengan sintaks yang lebih sederhana. B-CEP tidak menggantikan ARM-nya dibangun di atasnya. Semua yang bisa Anda lakukan dengan ARM misalnya dengan B-CEP. Setiap jenis sumber daya, setiap versi API, setiap opsi konfigurasi semuanya ada di sana. Satu-satunya berbeda adalah cara Anda meluisi. Sintaksnya jauh lebih bersih. Tanpa tanda kutip di nama properti, tanpa koma di antara properti, tanpa kurung yang bingungkan. Itu jauh lebih sederhana. Bandingkan kedua versi tersebut secara berdamping. Versi JSON ARM dari akun penyimpanan penuh dengan gangguan. Tanda kutip koma kurung dan pelapisan. Versi B-CEP memiliki informasi yang sama, tetapi lebih mudah dibaca.

Anda bisa melihatnya dan langsung memahami apa fungsinya tanpa harus menelusuri lapisan sintaks JSON. Satu peningkatan besar adalah inferensi dependensi otomatis. Di ARM Anda harus meneklarasikan dependensi secara mana? Namun di B-CEP, jika sumber daya A merujuk ke sumber daya B, sistem menentukan dependensinya secara otomatis. Anda tidak perlu menulisnya secara. Semuanya berjalan otomatis. Dan itu saja menghemat waktu berjam-jam untuk proses bug. Modul adalah bagian besar lainnya. Anda dapat memecah infrastruktur menjadi bagian-bagian kecil yang dapat digunakan kembali dan dibagikan ke seluruh proyek. Satu tim membuat modul jaringan dan tim lain bisa menggunakannya. Tidak perlu terus-menerus menciptakan kembali roda yang sama. Parameter dan variable memungkinkan Anda mendefinisikan input sekali dan menggunakannya kembali dimana saja. Tidak perlu lagi mencari dan mengganti nilai yang dikodekan secara statis.

Dan interpolasi string berarti Anda bisa menulis prefix storage, alih-alih fungsi penggabungan yang rumit. Peralatan pendukung adalah halasan lain mengapa B-CEP sangat nyaman digunakan. Eksensi VS Code memberikan Anda intelligence, pewarnaan sintaks, dan pemeriksaan kesalahan secara real-time. Sejujurnya, ini adalah salah satu eksensi bahasa terbaik di VS Code. Anda mulai mengetik dan ia akan menyarankan apa yang harus ditulis selanjutnya. Jika melakukan kesalahan, ia akan langsung memberi tahuan. Tidak perlu lagi menunggu deployment gagal sebelum mengetahui bahwa Anda melewatkan sebuah koma. Jadi, seperti apa ini sebenarnya dan praktiknya? Mari kita lihat bagaimana perbedaan B-CEP dengan ARM. B-CEP VS ARM, apa sebenarnya perbedaannya? Mari kita bahas apa perbedaan sebenarnya saat Anda menulis B-CEP dibandingkan dengan RMJSON. Ukuran file adalah salah satu perbedaan yang jelas. File B-CEP kira-kira setengah ukuran dari template ARM yang setara.

Itu bukan berlebihan. Anda menghapus semua tanda kutip koma, kurung, dan boilerplate, dan yang tersisa hanya ada definisi infrastrukturnya. Setengah dari kode hasil yang sama. Keterbaca mengikutinya secara alam. Lebih sedikit baris, struktur yang lebih bersih, dan lebih mudah dipahami dalam sekalian lihat. Saat Anda membuka file B-CEP, Anda dapat memindahinya dan memahami apa yang sedang hidup. Dengan RMJSON, Anda harus melewati lapisan-lapisan penumpukan sebelum menemukan konfigurasi resource yang sebenarnya. Dependensi sangat menghemat waktu. Di ARM, Anda secara manum mendeklarasikan Depend-Song. Relot satu saja dan deployment Anda akan gagal. Di B-CEP, jika resource A merujuk ke resource B, sistem menangannya secara otomatis. Sistem menambahkan dependensi tersebut saat mempulasi ke RMJSON. Anda tidak perlu memikirkannya, sistem langsung bekerja. Dan itu saja sudah menghemat waktu berjam-jam untuk debugging.

Modul perbedaan utama lainnya. RM memiliki template tertingkat, tetapi sulit untuk dikerjakan. File terpisah, penauta yang kompak, sulit untuk diberi versi. B-CEP memiliki modul yang lebih bersih, dapat diberi versi, dan dapat digunakan kembali. Anda menentukan modul sekali, memublikasikannya ke registri dan mereferensikannya dari mana saja. Modul yang sama, konfigurasi yang sama setiap saat. Proses deployment-nya sendiri identik. B-CEP dikompilasi ke ARMJSON, kemudian Azure Resource Manager mendeploy-nya. Mesin yang sama, pipeline yang sama. Anda tidak perlu mengubah proses deployment Anda, Anda hanya perlu mengubah cara menulis template. What if adalah fitur yang secara teknis dimiliki ARM, tetapi B-CEP membuatnya jauh lebih mudah diakses. Anda dapat melihat pertinjau perubahan sebelum mendeploy dan melihat dengan tepat apa yang akan dibuat di modifikasi itu diakui. Tanpa kejutan, tanpa menghapusan yang tidak disengaja.

Anda menjalankan what if tinjau hasilnya, dan jika terlihat benar, Anda melakukan itu. Merfaat pembelajaran adalah satu area di mana B-CEP menonjol. ARMJSON berasumsi bahwa Anda tahu apa yang akan dilakukan. Template ini dilancang untuk mesin, bukan untuk manusia. B-CEP dirancang untuk pemula.

Microsoft telah menjadikan B-CEP sebagai pengalaman penulisan yang direkomendasikan. Semua fitur dan peningkatan baru menargetkan B-CEP terlebih dahulu. Template ARM masih berfungsi dan tidak akan hilang, tetapi Anda mungkin tidak perlu lagi menulis yang baru. Jika Anda memulai proyek baru hari ini, B-CEP adalah pilihan apa? Tiga baris B-CEP untuk mendeploy group resource. Hanya tiga baris. ARMJSON yang setelah membutuhkan sekitar 15 baris. Hasil sama, penerapan sama, tapi yang satu mudah dibaca dan yang lain membingungkan. Sekarang Anda mungkin bertanya bagaimana dengan Terraform? Haruskah saya mempelajari B-CEP atau Terraform? B-CEP versus Terraform, mana yang harus Anda gunakan? Selamat datang kembali di Microsoft Knowledge Network. Saya Mirko Peters, dan hari ini kita akan membahas pertanyaan yang terus muncul. B-CEP atau Terraform? Mari kita bedah. Terraform bekerja di berbagai cloud.

Anda dapat menggunakannya untuk Azure, AWS, GCP, atau ketiganya sekaligus. Di sisi lain, B-CEP dibuat khusus untuk Azure dan tidak engkau. Perbedaan mendasar itu mengaruhi segitanya. Jika Anda bekerja di berbagai cloud, Terraform adalah pilihan yang tepat. Anda mempelajari satu bahasa, satu alat, satu alur kerja, dan berfungsi mana saja. Namun, jika Anda fokus pada Azure, B-CEP punya keunggulan nyata. Inilah yang pertama. Tidak ada file state yang perlu di cloud. Terraform menyimpan file state untuk melacak penyebarannya, dan file itu sangat krusial. Jika rusak atau tidak sinkron, Anda akan menghadapi masalah serius. Anda harus menyimpannya dengan aman, mencadangkannya, dan mengelola akses. B-CEP berbicara langsung ke Azure Resource Manager, memperiksa apa yang ada, dan menghitung perbedaannya. Tidak ada file state berarti tidak ada masalah sinkronisasi dan risiko kerusakan. Keunggulan kedua, dukungan D-Zero.

Saat Microsoft merilis fitur Azure baru, B-CEP mendukungnya segera pada hari yang sama. Terraform harus menunggu pembaruan provider, yang terkadang cepat, terkadang butuh berminggu-minggu. Jika Anda perlu menggunakan fitur baru segera, B-CEP adalah satu-satunya pilihan. Ketiga, ini dibuat oleh tim Azure. Perkakasnya, IntelliSense, pesan error, semua dirancang sesuai cara kerja Azure sebenarnya. Saat Anda menulis B-CEP, Anda menggunakan bahasa yang memahami sumber daya Azure secara natif. Ia tahu properti apa yang diperlukan, nilai apa yang valid, dan dependensi apa yang ada. Integrasi mendalam itu sulit direplikasi oleh alat pihak ketika. Anda juga bisa menggunakan kedua. Banyak organisasi menggunakan B-CEP untuk platform dan landing zone, serta terraform untuk beban kerja multi-cloud. Keduanya tidak saling menedakan. Anda bisa memilih alat yang tepat untuk setiap pekerja. Jawaban jujurnya adalah ini.

Untuk mempelajari Azure secara spesifik, B-CEP memiliki komponen yang lebih sederhana. Ini adalah jelas lebih sederhana saat Anda bermula. Anda tidak perlu mempelajari tentang file slide provider atau konfigurasi backend. Anda cukup install Azure CLI, buka VS Code, dan mulai menulis. Cukup teorinya. Mari bicara tentang apa yang benar-benar Anda butuhkan untuk memulai. Apa yang sebenarnya Anda butuhkan? Anda butuh dua hal untuk memulai. Azure CLI dan ekstensi B-CEP untuk VS Code. Tidak perlu install B-CEP CLI terpisah, tidak ada alat tambahan untuk dikonfigurasi. Azure CLI sudah dilengkapi dengan B-CEP bawah. Menginstall Azure CLI cukup mudah. Buka Microsoft Docs. Cari halaman installasi untuk sistem operasi Anda. Jika Anda menggunakan Mac, cukup satu print. Beri install Azure CLI. Di Windows ada penginstall MSI. Undul jalankan selesai. Ini juga berfungsi di Linux melalui manajer paketan.

Setelah terinstall, jalankan Azure version untuk memastikan semuanya berfungsi. Anda akan melihat versi Azure CLI dan versi B-CEP tercantum. Sekarang, buka VS Code, pergi ke pandai ekstensi di sebelah kiri, dan cari B-CEP. Install yang dari Microsoft, bukan pihak ketiga yang resmi. Anda sangat membutuhkan ekstensi ini. Ekstensi ini memberi Anda IntelliSense yang menyarankan properti sumber daya saat mengetik, menyoroti sintaks agar mudah melihat kesalahan, dan meliksa kekliruan secara real-time. Anda akan melihat garis bergelombang merah di bawah bagian yang salah bahkan sebelum Anda mencoba mendeploy. Sejujurnya, ini adalah salah satu ekstensi bahasa terbaik di VS Code dan alasan utama mengapa B-CEP sangat nyaman digunakan. Sekarang, buat file baru dan beri nama main.b-CEP. Ekstensi B-CEP itu memberitahu VS Code untuk mengaktifkan ekstensinya. Tanpa itu, Anda hanya menulis teks biasa. Dengan itu, Anda mendapatkan pengalaman lengkap.

Berikut contoh singkatnya, deployment group sumber daya dalam tiga baris kode. Pertama, Anda mengatur target scope ke subscription, lalu mendefinisikan sumber daya, group sumber daya dengan nama dan lokasi. Selesai tiga baris saja. Pendingan dengan ARM JSON yang setara, yang merupakan sekitar 15 baris kurung dan tanda kutip. Untuk mendeploynya, Anda menggunakan Azure Challenge. Karena Anda mendeploy pada lingkup subscription, perintahnya adalah AZ Deployment Subcrete. Anda memasukkan lokasi untuk metadata deployment dan mengarahkannya ke file bcap Anda. Itu cara melalui baris perintah, tetapi ada juga pengalaman yang dipandung. DVS Code, klik kanan file bcap, dan pilih Deploy bcap file. Berhasilnya kena moda Anda melalui seluatu. Ini meminta nama deployment. Meminta Anda memilih langganan, meminta membuat atau memilih grup sumber daya, dan menanyakan apakah Anda punya file parameter. Anda jawab tidak, Anda boleh menjalankan.

Hasilnya akan muncul di portal Azure Anda. Sama seperti klik sana-sini di portal, tapi sekarang Anda bisa digunakan kembali. Anda bisa melakukan commit ke repository, membagikannya ke tim, dan menjalankannya lagi besok. Dan inilah bagian ajaibnya. Jalankan penyebaran yang sama lagi, dan lihat apa yang terjadi. Kekuatan idempotensi Inilah hal penting tentang menjalankan penyebaran. Anda ingin bisa menjalankannya berulang kali tanpa merusak apapun. Itulah tepatnya yang diberikan oleh idempotensi kepada Anda. Pertama kali Anda menjalankan file bcap, ia membuat grup sumber daya. Namun kali kedua Anda menjalankannya, tidak ada yang terjadi. Tanpa error, tanpa duplikat, tidak ada apapun. Bcap memeriksa apa yang sudah ada di Azure, membandingkannya dengan yang Anda minta, dan menyatakan tidak ada yang perlu diukur. Ia tidak mencoba membuat grup sumber daya baru, dan tidak memberikan error yang menyatakan grup sudah ada.

Ia hanya mengonfirmasi bahwa status saat ini sesuai dengan status yang diinginkan. Anggap saja seperti menjalankan git status pada repositoran bersih. Tidak ada yang perlu dilakukan. Semuanya sudah tepat seperti yang seharusnya. Inilah kekuatan infrastruktur sebagai kode. Anda dapat menjalankan penyebaran Anda berulang kali dan mendapatkan hasil yang sama setiap saat. Tanpa kejutan, tanpa penyimpangan. Anda tahu persis apa yang disebarkan karena file tersebut mengatakan. File tersebut menjadi satu-satunya sumber kebenaran. Anda tidak perlu bertanya-tanya apakah Anda ingat suatu pengaturan, atau menghadapi masalah berjalan di mesin saya, atau mencari di portal Azure untuk memeriksa apakah ada yang berubah. File tersebut memberitahu Anda apa yang ada di. Jika Anda ingin mengubah sesuatu, Anda ubah file-nya dan sembarkan ulang. Jika Anda ingin meverifikasi, Anda jalankan penyebaran lagi dan ia akan mengonfirmasi bahwa semuanya cocok.

Begitulah cara Anda membangun kepercayaan peraturan Anda. File tersebut adalah sumber kebenaran. Bukan ingatan Anda, bukan dokumen Word, bukan video YouTube 6 bulan lalu, melainkan file tersebut. Jadi mana posisi Bichap dalam gambaran besar Azure? Gambaran besar, di mana Bichap berada. Bichap berada dalam ekosistem Azure Resource Manager. Itu bukan alat yang terpisah. Banyak orang mengira demikian, padahal sebenarnya itu hanya cara yang lebih baik untuk menulis template ARM. Di baliknya, itu tetap ARM, mesin penyebarannya sama, api yang sama, segalanya sama. Satu-satunya perbedaan adalah jalan dan minusnya. Dan karena Bichap dikompilasi ke ARM, semua yang berfungsi dengan ARM juga berfungsi dengan Bichap. Azure Policy menegakkan kepatuhan pada penyebaran Anda. RPSC mengontrol siapa yang dapat menyebarkan apa. Cost Management melacak pengelolaan untuk sumber daya Anda. Azure DevOps dan GitHub Actions menyebarkan file Bichap Anda melalui pipeline.

Semuanya bekerja dengan sempurna, karena Bichap menghasilkan JSON ARM standar. Anda tidak kehilangan apapun dengan berat. Bahkan Anda mendapatkan kejelasan. Microsoft telah membangun seluruh ekosistem di sekitar Bichap. Azure Verified Modules atau AVM adalah pustaka kurasi modul Bichap dan Terraform yang mengikuti praktek terbaik. Anda tidak perlu menulis semuanya dari awal. Anda bisa menggunakan modul yang sudah jadi untuk pola umum seperti jaringan virtual, akun penyimpanan, dan layanan aplikasi. Semuanya telah diuji, dipelihara, dan diselaraskan dengan WeArchitected Framework. Cloud Adoption Framework menyertakan implementasi referensi Bichap untuk arsitektur perusahaan yang terstandarisasi. Jika Anda membangun zona pendaratan landing zone, ada temprat Bichap untuk deployment stack memberi Anda pengelolaan siklus hidup untuk kelompok sumber daya. Anda bisa mendeploy stack, dan jika Anda menghapus sumber daya dari file Bichap Anda, stack dapat bersihkannya untuk Anda.

Atau melindunginya dari penghapusan yang tidak disengat. Anda yang memutuskan. Ekosistem terus berkembang dengan lebih banyak modul, perangkat yang lebih baik, dan integrasi lebih dalam dengan AI dan GitHub Copilot. Anda bisa mendeskripsikan keinginan Anda dengan bahasa sederhana, dan Copilot akan membuatkan kode Bichap untuk Anda. Microsoft terus berinvestasi pada Bichap sebagai pengalaman penulisan utama untuk Azure. Jadi fitur baru akan menargetkan Bichap terlebih dahulu. Templat ARM masih berfungsi, tetapi inovasi terjadi di Bichap. Inilah kesimpulan. Jika Anda bekerja di Azure, Bichap adalah langkah selanjutnya yang alami setelah sekadar mengeklik di portal. Anda tidak perlu mempelajari terraform atau menguasai jasennya. Anda cukup menginstall dua hal, menulis beberapa baris kode, dan Anda sudah mendeploy infrastruktur yang dapat diulang, dikontrol versinya, dan Anda. Izinkan saya meninggalkan selutan praktis yang bisa Anda lakukan hari ini.

Jadi sekarang Anda tahu apa itu infrastruktur sebagai kode IAC, mengapa Bichap ada, dan bagaimana Bichap membuat deployment Azure lebih sederhana. Inilah poin utamanya. Bichap bukanlah sistem deployment yang berbeda. Ini adalah cara yang lebih baik untuk menulis template ARM yang sama menggunakan mesin, dan Azure Resource Manager yang sama di balik layar, hanya saja dalam bahasai, yang bisa dibaca dan ditulis manusia. Ini adalah tantangan untuk Anda. Buat FileMind.Bichap, deploy grup sumber daya, dan jalankan deployment dua kali. Perhatikan cara kerjanya di kedua kesempatan. Pertama kali ia membuat sumber daya, dan kedua kalinya ia mengonfirmasi bahwa tidak ada yang berubah. Anda tidak akan pernah kembali, hanya mengeklik di portal. Ini adalah fondasinya. Dari sini Anda bisa menambahkan akun penyimpanan jaringan virtual dan layanan aplikasi menggunakan pola yang sama. Tulis FileDeploy, lalu jalankan lagi.

File tersebut menjadi sumber kebenaran Anda, dan hal lainnya mengikuti dari sana. Jika menurut Anda ini bermanfaat, bagikan kepada seseorang yang masih sering mengeklik di portal. Mereka berterima kasih. Berlanggananlah di platform podcast favorit Anda, dan pada episode berikutnya, kita akan mendalami Bichap lebih jauh dengan mendeploy sumber daya nyata dengan properti yang nyata.