Merancang fondasi layanan mandiri pengembang

Setelah Anda memiliki pemahaman yang baik tentang target Anda untuk sistem teknik Anda, Anda dapat menciptakan pengalaman layanan mandiri pengembang yang lebih canggih. Pengalaman layanan mandiri pengembang dibangun di atas fondasi konsep, pola, dan komponen.

Meskipun Anda mungkin tidak memerlukan semua yang dijelaskan di sini di organisasi Anda hari ini, Anda harus mengingat konsep-konsep ini jika Anda membangun sesuatu yang kustom atau mengevaluasi produk terkait. Model pengalaman layanan mandiri untuk pengembang Anda dapat terdiri dari kombinasi produk rumahan, siap pakai, dan sumber terbuka. Produk atau toolkit portal sumber terbuka seperti Backstage.io mungkin menggunakan istilah yang berbeda untuk beberapa elemen model yang dijelaskan di sini, tetapi model masih dapat membantu Anda berorientasi.

Mengotomatiskan alur kerja, mengagregasi data, memulai sederhana, dan memperluas secara bertahap

Tujuan Anda adalah mengaktifkan layanan mandiri dengan pagar pembatas melalui eksekusi dan provisi tugas yang terkontrol dan diatur, bersama dengan visibilitas terpusat. Area yang paling berharga untuk difokuskan adalah area yang melelahkan atau adalah hal-hal yang tidak dapat dilakukan pengembang sendiri karena kompleksitas atau izin. Bagian terakhir ini penting untuk memungkinkan Anda mengikuti prinsip hak istimewa paling sedikit tanpa memaksa pengembang melalui proses meja layanan manual.

Meskipun Anda dapat memilih untuk memperluas rangkaian DevOps untuk memenuhi kebutuhan ini, Anda mungkin perlu mendukung beberapa platform aplikasi dari waktu ke waktu, dan alat dan proses tertentu yang mendukungnya mungkin perlu berubah juga. Masalah intinya adalah bahwa standar Anda adalah target bergerak. Seperti yang dinyatakan oleh salah satu praktisi teknik platform:

Kesulitan melibatkan standardisasi ... dan menghadapi masalah 'abandonware'... Standardisasi sering kali tidak tercapai karena potensi gangguan proses otomatis dan tugas yang memakan waktu untuk mengidentifikasi perubahan yang diperlukan. - Martin, teknisi DevOps, perusahaan logistik besar

Beralih dengan cepat ke standar baru atau yang diperbarui biasanya tidak layak, dan meninggalkan proses yang ada menciptakan risiko. Organisasi Anda mungkin sudah menggunakan beberapa suite DevOps atau kombinasi alat individual dan layanan pengembang yang berbeda berdasarkan skenario. Bahkan dengan tim pusat dan solusi standar, karena kebutuhan layanan mandiri Anda meningkat, varianbilitas tidak dapat dihindari. Jadi, Anda akan ingin mengizinkan eksperimen terkontrol di mana tim yang ditunjuk dapat mencoba teknologi baru, strategi penyebaran, dan sebagainya, diikuti dengan adopsi yang disarankan dan peluncuran bertahap.

Umumnya pengalaman layanan mandiri termasuk dalam dua kategori utama: otomatisasi dan agregasi data.

Meskipun agregasi data menciptakan pengalaman pengguna yang baik, otomatisasi lebih penting:

Automasi adalah kunci dan akan dicintai oleh semua orang. Agregasi [Data] bersifat sekunder. – Peter, pemimpin teknik platform, perusahaan teknologi multinasial

Dalam perjalanan rekayasa platform, Anda mengidentifikasi masalah yang berpotensi diselesaikan dengan otomatisasi. Selain mengurangi beban kognitif dan beban kerja pengembang, otomatisasi juga dapat membantu memastikan aplikasi terhubung ke alat dan layanan terbaik untuk operasi, keamanan, serta peran lain dalam menjalankan tugas mereka.

Namun, jika Anda bekerja dengan lebih dari satu sistem untuk mendorong otomatisasi Anda, beberapa tingkat agregasi data berguna untuk membantu melacak permintaan otomatis dan hasil terkait. Anda dapat memulai dengan menautkan ke sistem eksternal untuk memenuhi kebutuhan lain atau untuk detail selengkapnya. Agregasi dan visibilitas data juga penting untuk mengaudit, mengatur, dan mengurangi limbah (misalnya, lingkungan yang tidak digunakan).

Mengotomatiskan hal-hal seperti provisi infrastruktur dapat dilakukan menggunakan integrasi sistem, tetapi Anda juga dapat memicu dan memfasilitasi proses alur kerja manual yang terlihat otomatis bagi pengembang. Ini berguna pada tahap awal platform Anda, untuk produk baru yang Anda bawa ke ekosistem Anda, atau di area yang belum Anda atau tidak dapat mengotomatiskan menggunakan sistem (misalnya, penetapan lisensi perangkat lunak). Dengan desain yang tepat, Anda dapat memulai dengan proses manual yang difasilitasi oleh sesuatu seperti Power Automate yang Anda alihkan ke alur yang sepenuhnya otomatis dari waktu ke waktu. Jadi, desain untuk otomatisasi sejak awal.

Mulailah sederhana dengan menggunakan kembali investasi yang ada seperti sistem teknik atau portal internal Anda, lalu pindah ke pembuatan CLI, halaman web dasar, atau bahkan dasbor Power Pages, Power BI, atau Microsoft Fabric , dan perluas saat kebutuhan muncul. Memiliki API konsisten yang kemudian digunakan UX dapat membantu Anda mendukung beberapa antarmuka dari waktu ke waktu saat kebutuhan dan preferensi Anda berubah.

Komponen platform layanan mandiri pengembang: API, grafik, orkestrator, penyedia, dan metadata

Pertimbangkan fondasi layanan mandiri pengembang:

Seperti yang ditunjukkan oleh ilustrasi, komponen berikut membentuk inti konsep fondasi layanan mandiri pengembang:

Komponen	Description
platform API pengembang	Satu titik kontak Anda untuk pengalaman pengguna. Ini secara efektif merupakan kesepakatan sistem dengan sistem-sistem lainnya.
Grafik interaksi platform pengembang	Grafik data terkelola dan aman yang memungkinkan Anda menemukan, mengaitkan, dan menggunakan berbagai jenis entitas dan templat. Entitas adalah objek yang memungkinkan agregasi data dari beberapa sumber, sementara templat mendorong input pengguna yang mengaktifkan otomatisasi.
Pengatur platform pengembang	Kemampuan yang merutekan dan melacak permintaan berbasis templat untuk melakukan tindakan baik dalam sistem atau melalui proses manual. Permintaan ini dirutekan ke salah satu set penyedia platform pengembang yang dapat diintegrasikan ke sejumlah sistem alur kerja yang berbeda atau layanan lainnya.
Penyedia platform pengembang	Sekumpulan komponen yang merangkum logika yang diperlukan untuk diintegrasikan dengan sistem hilir untuk mendukung operasi CRUD pada entitas atau pemenuhan permintaan tindakan berbasis templat. Setiap penyedia dapat mendukung jenis templat spesifiknya sendiri dan memancarkan jenis entitas yang unik atau umum.
Profil pengguna dan metadata tim	Kemampuan untuk mempertahankan informasi tentang sekumpulan individu yang terkait dengan tim konseptual untuk pengelompokan dan akses ke API platform pengembang. Pengguna dikaitkan erat dengan akun penyedia identitas (misalnya, masuk dengan ID Microsoft Entra), tetapi baik pengguna maupun tim dapat terhubung dengan sejumlah representasi dalam sistem hilir terkait. Salah satu implementasi penyimpanan informasi ini adalah menggunakan kembali grafik platform pengembang. Fondasi layanan mandiri pengembang dapat membuat jenis entitas umum untuk pengguna dan tim dan mempertahankan informasi tersebut dalam grafik. Namun, kami akan memisahkan toko ini demi kejelasan di sini.

Komponen dasar ini memungkinkan Anda untuk menggunakan dan menukar blok bangunan yang berbeda dari waktu ke waktu.

Apakah saya harus membangun semua ini untuk memulai?

Tidak. Pertama, ini adalah model konseptual untuk membantu Anda mempertimbangkan apa yang seharusnya dapat dilakukan oleh fondasi seperti ini setelah selesai. Kedua, spesifikasi implementasi kurang penting di sini mengingat API platform pengembang menjadi antarmuka utama Anda. Implementasi awal Anda mungkin dimulai dengan menggunakan antarmuka dan kelas dalam kode Anda untuk berbagai lapisan yang dijelaskan, atau menggabungkan produk lain. Anda juga dapat menghilangkan aspek karena proses pengembangan pelanggan menunjukkan kepada Anda bahwa itu hanya prioritas yang lebih rendah. Mulailah dengan apa yang Anda miliki dan tumbuh.

Platform API Pengembang

Anda harus menentukan API platform pengembang untuk bertindak sebagai kontrak sistem Anda. Berbagai antarmuka pengguna menggunakan API untuk mengaktifkan akses data atau penyediaan drive dan tindakan lainnya.

API ini bertindak sebagai lapisan autentikasi dan keamanan penting dengan membatasi akses ke API mentah yang mendasar di sistem lain ke data dan operasi yang lebih spesifik dan terkontrol. API menyediakan akses ke representasi profil penggunanya sendiri, peran tingkat tinggi pengguna dalam platform (anggota tim, admin, dll.), dan pengidentifikasi sistem penyedia identitas utama. Untuk informasi selengkapnya, lihat Pengguna dan tim.

Penyedia platform pengembang

Mengingat luasnya platform pengembang internal, Anda harus membuat atau mengidentifikasi sistem yang mengikuti model penyedia yang dapat diperluas untuk memperkenalkan fungsionalitas ke dalam API. Idenya adalah bahwa fungsionalitas utama seperti otomatisasi dan agregasi data disediakan dengan berinteraksi dengan komponen yang dapat dicolokkan dengan antarmuka yang terdefinisi dengan baik. Kopling longgar ini membantu Anda menyambungkan apa yang Anda butuhkan secara bertahap dan meningkatkan ketahanan karena Anda dapat menguji fungsionalitas terlepas dari sisa fondasi.

Ini juga merupakan cara penting untuk mengaktifkan mentalitas sumber dalam yang dapat diskalakan untuk platform Anda. Biasanya, upaya pemanfaatan sumber daya internal dalam bidang rekayasa platform gagal menjadi populer karena tantangan dengan pemeliharaan berkelanjutan. Tim lain mungkin bersedia berkontribusi fungsionalitas tetapi cenderung tidak bersedia mempertahankan dan menguji sesuatu di dalam inti platform Anda. Sebaliknya, setiap tim terpusat memiliki kapasitas terbatas untuk mempertahankan kode yang dikontribusikan atau bahkan meninjau permintaan pull. Konsep penyedia platform pengembang meringankan ketegangan ini dengan memungkinkan kode yang ditulis secara independen untuk terhubung ke fungsionalitas inti dalam fondasi layanan mandiri pengembang Anda. Meskipun Anda harus mengelola penyedia mana yang Anda gunakan dengan hati-hati, meninjau kode penyedia apa pun, dan membatasi area permukaan yang dapat diakses penyedia tertentu di platform pengembang Anda, pendekatan yang dapat dicolokkan dapat membantu Anda menyelesaikan lebih banyak hal dengan menskalakan upaya di sebagian besar organisasi.

Konsep penyedia platform pengembang utama

Entities

Konsep entitas adalah sesuatu yang diperlukan pengembang atau sistem lain di platform pengembang internal Anda untuk melacak, memperbarui, menyajikan, atau bertindak. Entitas dapat memiliki hubungan satu sama lain yang, ketika digabungkan, membentuk grafik yang memberikan informasi penting tentang potongan platform pengembang internal Anda. Penyedia platform pengembang kemudian dapat menghasilkan entitas untuk mengaktifkan kemampuan inti, termasuk:

• Memunculkan sumber daya/ lingkungan yang disediakan secara eksternal atau API yang tersedia untuk penemuan dan penggunaan
• Mengekspos hubungan untuk analisis dependensi, analisis dampak, penemuan, dll.
• Menampilkan informasi pengelola/kepemilikan untuk temuan dan kolaborasi
• Memunculkan lebih banyak data untuk digunakan dalam pengalaman pengguna

Merangkum fungsionalitas ini ke dalam antarmuka penyedia platform pengembang yang terdefinisi dengan baik menyederhanakan integrasi dan pengujian, memungkinkan penyebaran independen, dan memungkinkan pengembang di luar tim platform pengembang internal utama untuk berkontribusi dan mengelola penyedia. Ini penting dalam organisasi besar atau divisi di mana tidak setiap alat, layanan, atau platform dikelola secara terpusat, tetapi organisasi yang lebih luas masih ingin berbagi kemampuan. Jadi, bahkan jika Anda tidak menuju ke jalur ini pada awalnya, itu adalah sesuatu yang perlu dipikirkan selama jangka panjang.

Properti umum

Setiap entitas harus memiliki sekumpulan properti umum untuk memungkinkan fondasi mengelolanya. Beberapa properti yang perlu dipertimbangkan meliputi:

• Pengidentifikasi unik
• Nama
• Penyedia asal
• Asosiasi opsional untuk:
  • Memiliki pengguna
  • Tim pemilik
  • Entitas lain

Properti pengguna dan tim penting karena tiga alasan: kontrol akses berbasis peran (RBAC), penemuan, dan agregasi data (seperti ringkasan tingkat tim). Menggabungkan RBAC dari awal sangat penting bagi keamanan dan menumbuhkan platform pengembang internal Anda dari waktu ke waktu. Mengingat pengembangan adalah kerja tim, menemukan siapa yang dapat diajak bicara tentang entitas akan dengan cepat menjadi sangat penting untuk keberlanjutan penggunaan, dukungan, dan innersourcing.

Entitas umum dan khusus penyedia

Anda juga harus dapat menetapkan sekumpulan entitas umum tingkat tinggi yang dinormalisasi yang dapat dihasilkan oleh beberapa penyedia. Contohnya:

• Environments
• Resources
• Antarmuka Pemrograman Aplikasi (API)
• Repositori
• Components
• Tools

Ini umumnya harus berada pada level tinggi, seperti yang akan Anda tempatkan dalam konteks model C4 atau paling tidak pada diagram komponen level tinggi. Misalnya, untuk lingkungan, Anda tidak perlu menyertakan detail topografi infrastruktur internal; Anda hanya perlu informasi yang cukup untuk mencantumkan dan mengaitkan lingkungan konseptual yang berbeda dari beberapa penyedia di UX yang sama. Entitas dapat menunjuk ke tingkat detail yang lebih rendah di luar sistem daripada mencoba mengonsumsi semuanya. Ini menyediakan titik awal penemuan yang menjadi pusat untuk memungkinkan agregasi data dari waktu ke waktu.

Yang lain khusus untuk kasus penggunaan atau penyedia tertentu, jadi Anda harus memikirkan bagaimana Anda dapat mengakomodasi serangkaian jenis entitas yang berkembang dari waktu ke waktu.

Templat

Konsep templat dalam konteks ini berbeda dari gagasan entitas karena mereka dimaksudkan untuk mendorong tindakan. Contoh skenario termasuk provisi infrastruktur, pembuatan repositori, dan proses jangka panjang lainnya. Templat ini juga harus tersedia melalui penyedia platform pengembang yang dapat diperluas dan harus mendukung properti umum yang sama dengan entitas, termasuk asosiasi entitas.

Namun, mereka juga dapat menentukan input yang diperlukan, baik sistem atau pengguna yang ditentukan, yang diperlukan untuk melakukan tindakan. Ini dapat berkisar dari apa pun seperti penamaan sumber daya hingga penambahan opsional.

Contoh templat meliputi:

• Templat Infrastruktur sebagai kode (IaC)
• Templat aplikasi (mulai kanan) atau repositori templat
• Membangun templat alur/alur kerja
• Templat alur kerja penyebaran
• Skrip yang diparameterkan
• Alur Power Automate berparameter (misalnya, permintaan HTTP memicu alur cloud)
• Templat email

Seperti entitas, templat dapat menyertakan properti khusus penyedia.

Setiap templat mungkin memiliki representasi berbeda yang unik untuk penyedia. Ini mungkin berkisar dari templat Terraform atau ARM, hingga Grafik Helm, alur kerja GitHub Actions dengan parameter atau Azure Pipelines, skrip sederhana, atau format kustom.

Rincian dasarnya dari template mungkin tidak perlu disimpan secara terpusat. Mereka bisa ada di repositori, registri, atau katalog yang berbeda. Misalnya, Anda dapat menggunakan repositori templat GitHub untuk templat aplikasi Anda, sementara templat IaC Anda mungkin ada di repositori katalog terbatas yang hanya dapat diakses pengembang secara tidak langsung melalui sesuatu seperti Lingkungan Penyebaran Azure. Templat IaC lainnya mungkin disimpan di Registri Artefak OCI seperti bagan Helm. Dalam kasus lain, templat mungkin menjadi referensi ke titik akhir HTTP berparameter. Penyedia platform pengembang harus memberikan informasi yang cukup tentang setiap jenis templat sehingga dapat direferensikan, dan opsi apa pun yang diekspos untuk digunakan dalam pengalaman pengguna. Tapi, templat itu sendiri dapat ditempatkan di tempat yang paling sesuai untuk kasus penggunaan Anda.

Teknisi platform atau pakar di area tertentu menulis templat dan kemudian membagikannya dengan tim pengembangan untuk digunakan kembali. Memusatkan penggunaan templat ini melalui sistem memungkinkan pengembang layanan mandiri dan membuat pagar pembatas yang membantu menegakkan kepatuhan dengan standar atau kebijakan organisasi. Lebih lanjut tentang hal ini akan dibahas saat kita membahas orkestrator platform pengembang sebentar lagi.

Graf platform pengembang

Anda dapat menganggap grafik platform pengembang sebagai sesuatu yang memungkinkan Anda mengaitkan entitas dan templat dari beberapa penyedia ke dalam grafik yang dapat dicari. Namun, data aktual untuk entitas tidak selalu perlu disimpan langsung dalam database khusus grafik. Sebaliknya, interaksi dengan penyedia dapat di-cache bersama dengan metadata yang diperlukan untuk membuatnya serasi.

Grafik ini kuat ketika digunakan dengan entitas umum yang dapat dikontribusikan oleh beberapa penyedia. Misalnya, daftar API mungkin berasal dari produk seperti Azure API Center, tetapi Anda mungkin juga ingin secara otomatis memberi umpan dalam penyebaran dan lingkungan dari sistem penyebaran berkelanjutan Anda. Seiring waktu, Anda dapat beralih di antara sistem penyebaran yang berbeda atau bahkan mendukung lebih dari satu sistem penyebaran. Asalkan setiap sistem penyebaran memiliki penyedia platform pengembang, Anda harus tetap dapat mengasosiasikan.

Setiap pengalaman pengguna Anda yang berasal dari grafik ini kemudian dapat memanfaatkan API terpadu untuk penemuan, pencarian, tata kelola, dan lainnya. Orkestrator platform pengembang kemudian dapat memanfaatkan grafik yang sama ini, sehingga setiap tindakan yang dilakukan oleh penyedia platform pengembang secara otomatis membuat entitas tersebut tersedia untuk API yang sama.

Platform orkestrator pengembang

Orkestrator platform pengembang memungkinkan pengembang atau sistem membuat permintaan untuk melakukan tindakan menggunakan templat. Ini tidak melakukan tindakan ini sendiri, tetapi sebaliknya berkoordinasi dengan mesin tugas, mesin alur kerja, atau orkestrator lain untuk melakukannya. Ini adalah salah satu bagian penting yang ingin Anda pastikan adalah bagian dari fondasi layanan mandiri Anda. Ini memungkinkan pengembang untuk membuat permintaan dengan templat atau menjalankan tindakan tanpa izin langsung. Selain itu, tidak seperti konsep CI atau CD, tindakan ini tidak harus terkait dengan kode sumber aplikasi.

Anda dapat menggunakan GitHub Actions, Azure Pipelines, atau mesin alur kerja lain sebagai orkestrator Anda. Ini adalah tempat yang wajar untuk memulai, tetapi Anda mungkin ingin menerapkan tingkat abstraksi untuk memungkinkan berbagai jenis templat menggunakan mesin dasar yang berbeda. Ini dapat berguna karena beberapa alasan:

• Pertama, Anda mungkin ingin dapat memilih alur kerja dan mesin eksekusi tugas yang berbeda dari waktu ke waktu tanpa harus memotong lampu kilat. Dengan mengizinkan lebih dari satu mesin, Anda dapat bermigrasi seiring waktu atau menggunakan mesin baru hanya untuk tindakan baru tanpa memengaruhi mesin yang lebih lama.
• Beberapa proses yang ingin Anda bantu mengatur mungkin memerlukan langkah manual pada awalnya bahkan jika Anda berencana untuk mengotomatiskannya sepenuhnya nanti.
• Tindakan lain mungkin menargetkan peran di luar tim pengembang seperti bagian akuntansi hutang atau admin lisensi. Mesin pengembangan dengan sedikit pengkodean seperti Power Automate sering kali efektif untuk peran ini.
• Tindakan lain mungkin ditangani melalui permintaan HTTP sederhana, di mana menggunakan GitHub Actions atau Azure Pipelines dengan kemampuan seperti itu tidak diperlukan atau tidak ekonomis untuk pengembangan skala besar.

Untungnya, memperluas gagasan penyedia platform pengembang untuk mencakup langkah-langkah pemicu dan pelacakan otomatisasi dapat memberikan abstraksi yang diperlukan ini. Pertimbangkan ilustrasi berikut:

Berikut adalah konsep umumnya:

• Templat dapat secara opsional menentukan sekumpulan input yang dapat dimasukkan pengguna. Saat pengembang memicu tindakan tertentu, mereka memilih templat (bahkan jika tidak dijelaskan dengan cara itu) dan memasukkan input apa pun.
• Referensi ke input terkait templat menjadi permintaan di API platform pengembang.
• Setelah permintaan dikirimkan, komponen perutean dan penanganan permintaan dalam orkestrator mulai melacak siklus hidup permintaan. Templat perutean dan penanganan komponen permintaan dalam permintaan ke penyedia platform pengembang tempat templat berasal.
• Penyedia platform pengembang kemudian melakukan langkah-langkah yang sesuai untuk implementasinya.
• (Opsional) Penyedia platform pengembang memperbarui status permintaan saat melakukan tindakan.
• Setelah permintaan terpenuhi, penyedia platform pengembang dapat mengembalikan sekumpulan entitas untuk ditambahkan atau diperbarui dalam grafik platform pengembang. Ini bisa berupa entitas khusus atau umum penyedia.

Secara opsional, untuk mendukung interaksi yang lebih canggih, penyedia platform pengembang dapat memanggil API platform pengembang secara langsung untuk mendapatkan lebih banyak entitas sebagai input atau bahkan meminta tindakan terkait lainnya.

Pilih penyedia platform pengembang yang menggunakan tugas umum atau mesin alur kerja. Lebih khusus lagi, Anda ingin sesuatu untuk menjembatani apa yang Anda satukan sebagai bagian dari Menerapkan sistem rekayasa perangkat lunak. Salah satu sistem alur kerja umum atau eksekusi tugas yang bisa diinvestasikan adalah sistem CI/CD.

Contoh menggunakan GitHub Actions atau Azure Pipelines

Mari kita lihat secara singkat bagaimana GitHub Actions atau Azure Pipelines sebagai penyedia platform pengembang akan bekerja.

Untuk GitHub Actions, kunci untuk membuat pekerjaan ini adalah bahwa penyedia platform pengembang dapat terhubung ke instans GitHub yang ditentukan dan menggunakan Actions REST API untuk mengaktifkan peristiwa pengiriman alur kerja untuk memicu eksekusi alur kerja. Setiap alur kerja dapat mendukung serangkaian input dengan menambahkan konfigurasi workflow_dispatch ke file YAML alur kerja. Pemicu Azure DevOps serupa dan Anda juga dapat menggunakan AZURE DevOps Pipeline API untuk dijalankan. Anda kemungkinan akan melihat kemampuan yang sama di produk lain.

Alur kerja atau pipeline ini tidak harus berada di repositori kode sumber aplikasi. Konsepnya adalah memanfaatkan fakta ini untuk melakukan sesuatu seperti ini:

• Teknisi platform atau anggota tim DevOps dapat mempertahankan alur kerja /alur di satu atau beberapa repositori pusat yang tidak dapat diakses pengembang sendiri, tetapi penyedia platform pengembang disiapkan untuk digunakan. Repositori yang sama ini dapat mencakup skrip dan cuplikan IaC yang digunakan alur kerja/pipeline.
• Untuk memungkinkan alur kerja atau jalur ini berinteraksi dengan sistem hilir yang sesuai, anggota tim operasi atau anggota lain dari tim teknik platform Anda dapat menambahkan rahasia yang diperlukan ke repositori pusat. Lihat GitHub Actions dan dokumentasi Azure DevOps untuk detail tentang cara melakukan ini, atau Anda dapat memilih untuk memusatkan rahasia menggunakan sesuatu seperti Azure Key Vault.
• Alur kerja dan alur ini kemudian dapat mengikuti model di mana mereka menerbitkan entitas yang dihasilkan sebagai artefak build dan penyebaran (dokumen GitHub, dokumen Azure DevOps).
• Selama eksekusi, penyedia platform pengembang kemudian dapat memantau status alur kerja dan memperbarui status siklus hidup di orkestrator hingga selesai. Misalnya, Anda dapat menggunakan webhook dengan GitHub Actions dan service hooks dengan Azure Pipelines untuk melacak pembaruan.
• Setelah selesai, penyedia kemudian dapat menggunakan artefak yang diterbitkan untuk dimasukkan dalam grafik platform pengembang sesuai kebutuhan.

Terakhir, Anda kemudian dapat menyiapkan penyedia platform pengembang ini untuk menghasilkan serangkaian templat ke dalam grafik platform pengembang yang mereferensikan repositori dan alur kerja / alur yang sesuai, bersama dengan input untuk tugas tertentu.

Keuntungan utama dari menggunakan sistem CI/CD adalah bahwa mereka sering disiapkan untuk mendukung menjalankan CLI arbitrer, sehingga Anda tidak memerlukan integrasi unik kelas satu untuk semua yang Anda lakukan. Anda dapat menambahkannya dari waktu ke waktu sesuai kebutuhan.

Sebagian besar apa yang dijelaskan dalam contoh ini berlaku untuk bagaimana jenis penyedia lain dapat berfungsi. Penting juga untuk dicatat bahwa penggunaan GitHub Actions atau Azure Pipelines dalam konteks ini tidak mengharuskan Anda juga menggunakannya untuk alur CI/CD Anda yang sebenarnya.

Contoh lainnya

Berikut adalah beberapa contoh jenis penyedia platform pengembang lainnya yang dapat memproses templat.

Example	Description
Operasi kontrol sumber	Dalam beberapa kasus, Anda mungkin perlu membuat atau memperbarui repositori, mengirimkan PR, atau melakukan operasi terkait kontrol sumber lainnya. Meskipun mesin alur kerja asinkron dapat mengelola jenis operasi ini, kemampuan melakukan operasi Git dasar tanpa mesin alur kerja dapat sangat berguna.
Penyedia infrastruktur	Meskipun GitHub Actions dan Azure Pipelines bekerja dengan baik untuk mengelola provisi infrastruktur, Anda juga dapat memilih integrasi yang lebih langsung. Penyedia khusus dapat menyederhanakan penyiapan dan menghindari overhead. Layanan seperti Lingkungan Penyebaran Azure atau Terraform Cloud lebih langsung berfokus pada memungkinkan provisi berbasis templat IaC dengan aman dan terpercaya. Contoh lain dapat mencakup hal-hal seperti membuat namespace Layanan Kubernetes untuk aplikasi di kluster bersama atau menggunakan Git dengan alur kerja GitOps menggunakan Flux atau Argo CD sebagai jenis penyedia tertentu. Bahkan model yang lebih berpusat pada aplikasi seperti proyek inkubasi Radius OSS eksperimental dengan CLI mereka sendiri dapat memiliki penyedia platform pengembang mereka sendiri dari waktu ke waktu. Kuncinya adalah mencari dan merencanakan ekstensibilitas sehingga Anda dapat beradaptasi.
Kerangka/pemulaian aplikasi	Templat aplikasi adalah bagian penting dari arah perkembangan rekayasa platform seiring waktu. Anda dapat mendukung mesin templat pilihan Anda dengan menyediakan penyedia platform pengembang khusus yang dirancang untuk tidak hanya membuat perancah pohon sumber aplikasi, tetapi juga membuat dan mendorong konten ke repositori kode sumber dan menambahkan entitas yang dihasilkan ke dalam grafik. Setiap ekosistem memiliki preferensi perancah aplikasinya sendiri, baik Yeoman, cookiecutter, atau sesuatu seperti Azure Developer CLI, sehingga model penyedia di sini dapat memungkinkan Anda untuk mendukung lebih dari satu dari antarmuka yang sama. Di sini lagi, itu adalah ekstensibilitas yang merupakan kunci.
Proses manual	Apakah secara otomatis menghasilkan PR untuk persetujuan manual atau langkah-langkah alur kerja manual bagi persona nondeveloper untuk merespons menggunakan sesuatu seperti Power Platform, model berbasis templat yang sama dapat digunakan di penyedia platform pengembang. Anda bahkan dapat berpindah ke langkah yang lebih otomatis dari waktu ke waktu.

Meskipun Anda mungkin tidak memerlukan semua penyedia ini untuk memulai, Anda dapat melihat seberapa luasnya melalui sesuatu seperti penyedia platform pengembang dapat membantu kemampuan otomatisasi Anda tumbuh dari waktu ke waktu.

Pengguna dan tim

Rekayasa platform secara inheren merupakan urusan multi-sistem, jadi penting untuk merencanakan bagaimana fondasi layanan mandiri harus menangani masalah yang lebih menantang dengan mengintegrasikan sistem ini bersama-sama. Berikut adalah strategi untuk mengatasi tantangan umum dengan identitas, pengguna, dan tim.

Recommendation	Description
Integrasikan API platform pengembang secara langsung dengan penyedia identitas Anda untuk keamanan yang optimal.	Untuk mengamankan API platform pengembang, kami merekomendasikan integrasi langsung dengan penyedia identitas seperti ID Microsoft Entra, karena identitas yang kuat serta kemampuan RBAC dari Entra ID. Ada banyak keuntungan untuk langsung menggunakan SDK dan API asli penyedia identitas (misalnya, melalui MSAL Entra ID) daripada melalui abstraksi. Anda dapat menggerakkan keamanan end-to-end dan mengandalkan model RBAC yang sama di seluruh sistem sambil memastikan kebijakan akses bersyarat terus dievaluasi alih-alih hanya pada saat masuk.
Gunakan integrasi Single Sign-On dan grup penyedia identitas dalam sistem turunannya.	Integrasi single sign-on (SSO) Anda harus menggunakan penyedia identitas dan penyewa yang sama dengan yang Anda gunakan untuk API platform pengembangan Anda. Pastikan juga untuk memanfaatkan dukungan untuk protokol apa pun seperti SCIM untuk menghubungkan kelompok penyedia identitas (seperti grup AD). Mengikat grup penyedia identitas ini ke dalam izin sistem hilir tidak selalu otomatis, tetapi minimal, Anda dapat mengaitkan grup penyedia identifikasi secara manual dengan konsep pengelompokan setiap alat tanpa mengelola keanggotaan secara manual setelahnya. Misalnya, Anda dapat menggabungkan dukungan Enterprise Managed User (EMU) GitHub bersama dengan memanfaatkan kemampuan untuk mengikat grup penyedia identitas secara manual ke tim GitHub. Azure DevOps memiliki kemampuan yang sama.

Menetapkan konsep tim di luar satu grup penyedia identitas

Saat perjalanan rekayasa platform berlanjut, Anda mungkin akan menemukan bahwa grup penyedia identitas sangat bagus untuk mengelola keanggotaan, tetapi bahwa beberapa grup benar-benar perlu berkumpul untuk membentuk konsep tim untuk RBAC dan agregasi data.

Dalam konteks rekayasa platform, kami mendefinisikan tim sebagai sekumpulan orang dalam berbagai peran yang bekerja sama. Untuk agregasi data, gagasan tim multi-peran sangat penting untuk menggerakkan penemuan wawasan dan meringkas informasi di tempat-tempat seperti dasbor. Di sisi lain, grup adalah konsep penyedia identitas umum untuk sekumpulan pengguna dan dirancang dengan ide menambahkan beberapa orang ke peran tertentu, bukan sebaliknya. Dengan RBAC, oleh karena itu tim dapat berhubungan dengan beberapa grup penyedia identitas melalui peran yang berbeda.

Sumber data tim Anda dapat berasal dari beberapa tempat berbeda. Misalnya, jika Anda menggunakan pola tim sebagai kode (TAC), penyedia platform pengembang dapat melihat perubahan file di repositori, dan menyimpannya di profil pengguna dan penyimpanan metadata tim. Atau Anda dapat berintegrasi langsung dengan sesuatu seperti Proyek Azure Dev Center yang sudah memiliki konstruksi RBAC inti ini yang tersedia.

Membuat model untuk berintegrasi dengan sistem hilir di tingkat tim atau pengguna

Sementara beberapa pengembang dan alat operasi/layanan secara asli mengintegrasikan dan menggunakan konsep Penyedia Identitas secara langsung, banyak yang mengabstraksikan ini ke dalam representasi grup atau pengguna mereka sendiri (bahkan dengan SSO). Selain memungkinkan akses ke berbagai alat, kenyataan ini juga dapat menimbulkan masalah dalam agregasi data. Secara khusus, Anda mungkin menemukan bahwa API dalam sistem hilir menggunakan pengidentifikasi mereka sendiri daripada pengidentifikasi penyedia identitas (misalnya, ID Objek di ID Entra tidak digunakan secara langsung). Itu membuat pemfilteran dan mengaitkan data tingkat pengguna atau tim sulit kecuali Anda dapat memetakan antara ID yang berbeda.

Mengatasi perbedaan tingkat tim dan grup

Pola seperti TaC dapat memungkinkan Anda menyimpan dan mengakses hubungan antara tim setiap sistem atau pengidentifikasi grup sehingga Anda dapat memetakan di antara mereka. Untuk rekap, repositori Git yang aman dan dapat diaudit menjadi sumber tim, dan PR menyediakan antarmuka pengguna yang terkontrol untuk membuat pembaruan. Sistem CI/CD kemudian dapat memperbarui sistem hilir dan mempertahankan hubungan pengidentifikasi terkait untuk tim yang digunakan untuk melakukannya.

Misalnya, ini memungkinkan hubungan berikut disimpan dalam panggilan API:

Jika Anda lebih suka menggunakan sumber data selain file di repositori tim Anda, konsep umum yang sama ini dapat diterapkan menggunakan orkestrator platform pengembang untuk mencapai hal yang sama. Di bawah model ini, penyedia platform pengembang sumber data tim dapat memicu peristiwa pembaruan tim yang diterima dan ditindaklanjuti oleh semua penyedia lain sesuai kewenangan.

Mengatasi tantangan ID pengguna

Tantangan terkait lainnya untuk akses dan agregasi data adalah perbedaan ID pengguna. Seperti dalam kasus tim, jika Anda menggunakan integrasi sistem-ke-sistem untuk mengkueri data tentang pengguna, Anda tidak dapat berasumsi bahwa ID asli penyedia identitas (misalnya, ID Objek untuk ID Entra) mendukung API tertentu. Di sini lagi, menyimpan pemetaan untuk ID pengguna yang mengakses data melalui API platform pengembang dapat membantu. Misalnya, pertimbangkan GitHub:

Untuk setiap sistem, jika Anda dapat melakukan pencarian ID pengguna di sistem lain melalui API tanpa token pengguna, penyedia platform pengembang tertentu dapat menghasilkan pemetaan ini dengan cepat. Dalam beberapa kasus, ini bisa menjadi rumit karena Anda mungkin perlu melakukan operasi ini secara massal dan menyimpan hasilnya untuk referensi guna mempertahankan performa.

Kembali menggunakan beberapa token pengguna

Untuk situasi di mana penyedia perlu mengakses data tingkat pengguna tanpa cara untuk melakukan terjemahan ID pengguna yang akan berfungsi, API platform pengembang dapat disiapkan untuk mengelola beberapa token pengguna. Contohnya:

• API platform pengembang dapat mendukung cache token pengguna khusus penyedia untuk digunakan dengan sistem hilir.
• Interaksi apa pun dengan penyedia tertentu yang dipicu oleh API akan disertakan dalam token pengguna penyedia jika tersedia.
• Untuk menangani kasus di mana tidak ada token pengguna yang tersedia, penyedia akan memicu alur OAuth untuk mendapatkannya.
• Untuk memulai, API platform pengembang akan meneruskan kembali URI autentikasi untuk alur OAuth dengan URI pengalihan yang diteruskan ke penyedia. URI yang diteruskan akan menyertakan kode nonce / kode sekali pakai.
• API kemudian mengembalikan respons yang tidak diautentikasi dengan URI.
• UX apa pun kemudian dapat menggunakan URI ini untuk mendorong alur autentikasi yang sesuai di browser.
• Setelah pengalihan terjadi, platform pengembang akan menerima token pengguna yang diperlukan, dan menyimpannya untuk referensi di masa mendatang bersama dengan ID pengguna.
• Klien kemudian dapat mencoba kembali panggilan API, yang kemudian akan berhasil.

Konsep ini menguraikan cara untuk menangani autentikasi yang rumit karena Anda dapat menggunakan kembali ID jika memungkinkan, dan tidak perlu mempertahankan URI pengalihan terpisah per sistem hilir.

Menggunakan tautan mendalam konteks yang sadar akan alat dan sistem pelaporan

Sampai saat ini kita telah berbicara tentang aspek otomatisasi ruang masalah. Ini saja dapat berjalan jauh karena UI Anda dapat menggunakan nilai dalam entitas yang dikembalikan selama otomatisasi untuk membuat tautan mendalam ke sistem lain untuk tim.

Bahkan ketika tidak terkait otomatisasi, penyedia platform pengembang dapat memancarkan segala jenis entitas yang diperlukan. Namun, Anda umumnya tidak ingin membawa semua data terperinci di seluruh platform pengembang internal Anda ke dalam grafik platform pengembang Anda. Dashboard dalam solusi pengamatan seperti Grafana, Prometheus, DataDog, atau kecerdasan kode dalam produk seperti SonarQube, dan kemampuan asli di suite DevOps seperti GitHub dan Azure DevOps, semua mampu melakukannya. Sebaliknya, pendekatan terbaik sering kali adalah membuat tautan mendalam ke dalam sistem lain ini. Entitas Anda dapat memberikan informasi yang memadai untuk membuat tautan tanpa secara langsung berisi informasi terperinci seperti konten log.

Untuk kasus di mana Anda ingin menggabungkan dan meringkas data di seluruh alat atau perlu mendorong metrik kustom, solusi pelaporan Power BI atau Microsoft Fabric bisa menjadi port panggilan Anda berikutnya. Untuk menggabungkan data tim, Anda dapat terhubung ke database yayasan Anda atau melalui API platform pengembang. Misalnya, seperti yang dijelaskan dalam Merencanakan dan memprioritaskan, satu tempat di mana Anda mungkin ingin dasbor kustom mengukur keberhasilan platform pengembang internal Anda.

Selektiflah dengan setiap pengalaman tambahan yang Anda bangun

Meskipun dapat menarik untuk menciptakan ulang kemampuan yang sudah ada dalam sesuatu seperti portal publik, perlu diingat bahwa Anda juga perlu mempertahankannya. Ini adalah bidang di mana penting untuk mengikuti pola pikir produk. Antarmuka gaya dasbor mudah dibayangkan dan dipahami, tetapi pengembang Anda mungkin menemukan lebih banyak nilai di tempat lain.

Meskipun demikian, model di sini memungkinkan Anda menggunakan data agregat dalam grafik platform pengembang untuk membuat pengalaman pengguna kustom. Entitas harus memiliki dukungan bawaan sehingga mereka dapat mengikat pengguna atau tim. Ini memungkinkan API platform pengembang Anda untuk menentukan ruang lingkup output (bersama dengan menggunakan pengindeksan dan penyimpanan sementara).

Namun, bahkan ketika Anda perlu membuat UX kustom daripada tautan mendalam, menarik semua data ke grafik platform pengembang Anda biasanya masih bukan pendekatan terbaik. Misalnya, pertimbangkan situasi di mana Anda mungkin ingin menampilkan log di pengalaman pengguna Anda yang sudah memiliki tempat yang terdefinisi dengan baik dan dikelola. Gunakan informasi dalam entitas terkait untuk membantu UX Anda mengumpulkan informasi langsung dari sistem hilir.

Untuk memulai, Anda mungkin perlu menggunakan integrasi sistem-ke-sistem untuk terhubung, tetapi setelah menerapkan salah satu model yang dijelaskan dalam pengguna dan tim, Anda dapat menggunakan ID pengguna/tim hilir yang disimpan atau token autentikasi pengguna jika perlu.

Berikut adalah beberapa contoh pengalaman umum yang perlu dipertimbangkan:

Example	Description
Penemuan dan eksplorasi	Sebagai salah satu praktisi teknik platform, "Yang memperlambat proyek adalah komunikasi, bukan keterampilan pengembang." -Daniel, Insinyur Cloud, Perusahaan Media Fortune 500. Karena pengembangan perangkat lunak adalah kerja tim, membuat antarmuka pengguna untuk membantu menemukan tim dan entitas yang mereka miliki biasanya adalah salah satu hal pertama yang harus ditangani. Pencarian lintas tim, penemuan, dan dokumentasi mempromosikan penggunaan kembali serta mempermudah kolaborasi untuk inner sourcing atau dukungan. Teams juga mendapat manfaat dari memiliki one stop shop untuk menemukan hal-hal yang mereka miliki termasuk lingkungan, repositori, dan sumber daya lain seperti dokumen.
Pendaftaran manual lingkungan atau sumber daya	Meskipun banyak hal dapat disediakan dan dilacak melalui orkestrator platform pengembang, Anda mungkin juga ingin mendaftarkan sumber daya atau lingkungan yang sudah ada atau belum diotomatisasi. Penyedia sederhana yang mengambil informasi dari repositori git dan menambahkan informasi ke dalam manajemen sumber daya/lingkungan dapat berguna di sini. Jika Anda sudah memiliki katalog perangkat lunak, ini juga menjadi cara untuk mengintegrasikannya ke dalam model.
Katalog API	API Pelacakan yang harus digunakan pengembang bisa sangat berguna. Jika Anda belum memiliki sesuatu, Anda bahkan dapat memulai dengan repositori Git sederhana dengan serangkaian file yang mewakili API, statusnya, menggunakan PR untuk mengelola alur kerja persetujuan Anda. Ini dapat ditambahkan ke grafik platform pengembang Anda sehingga dapat ditampilkan atau dikaitkan dengan entitas lain. Untuk kemampuan yang lebih kuat, Anda dapat mengintegrasikan sesuatu seperti API Center Microsoft atau produk lain.
Kepatuhan lisensi	Dalam beberapa kasus, Anda mungkin juga ingin memberikan visibilitas ke dalam kepatuhan lisensi perangkat lunak dan konsumsi lisensi. Platform pengembang perangkat lunak juga dapat menambahkan otomatisasi yang diperlukan untuk menggunakan lisensi, tetapi bahkan jika lisensi ditetapkan secara manual (misalnya, melalui proses Pull Request dalam repositori Git), pengembang memiliki visibilitas terhadap apa yang mereka miliki dan administrator memiliki kemampuan untuk melihat semua hal secara menyeluruh.
Tampilan aplikasi yang berfokus pada Kubernetes	Ketika Anda menggunakan kluster Kubernetes bersama, mungkin sulit bagi pengembang untuk menemukan dan memahami status aplikasi mereka melalui UX admin kluster. Organisasi yang berbeda mungkin memilih untuk menangani masalah ini secara berbeda, tetapi menggunakan namespace untuk mewakili aplikasi adalah salah satu cara yang dikenal luas. Dari sana Anda dapat menggunakan entitas untuk membangun asosiasi antara namespace aplikasi di kluster dan tim dan membuat tampilan status yang lebih berfokus pada pengembang untuk aplikasi dan menyediakan tautan mendalam ke alat atau UI web lainnya.

Pengalaman pengguna

Peran yang berbeda dalam organisasi Anda memiliki alat atau layanan yang mewakili pusat gravitasi untuk pekerjaan sehari-hari mereka. Tarikan sistem ini dapat mempersulit pengalaman pengguna baru di luar pusat gravitasi ini untuk mendapatkan daya tarik. Dalam dunia yang sempurna, pengembang, operasi, dan peran lainnya dapat terus bekerja di lingkungan yang masuk akal bagi mereka, seringkali yang sudah mereka gunakan.

Dengan mengingat hal ini, merencanakan beberapa antarmuka pengguna saat Anda maju dalam perjalanan rekayasa platform Anda adalah ide yang baik. Ini juga dapat memberikan kesempatan untuk memulai dengan sederhana, membuktikan nilainya, dan berkembang menuju antarmuka yang lebih kompleks saat kebutuhan muncul.

Mengintegrasikan apa yang Anda miliki

Jika Anda telah membaca artikel Terapkan sistem rekayasa perangkat lunak dan Perbaiki platform aplikasi , Anda mungkin mengidentifikasi sistem yang ingin terus Anda gunakan. Dalam kedua kasus, evaluasi apakah Anda dapat meningkatkan dan memperluas apa yang Anda miliki sebelum Anda mulai membangun pengalaman baru dari awal. (Tanyakan pada diri Anda sendiri, apakah orang akan bereaksi lebih baik terhadap pengalaman pengguna baru lain atau versi yang ditingkatkan dari sesuatu yang mereka miliki sekarang?)

Beberapa alat, utilitas, atau aplikasi web yang ingin Anda terus gunakan akan kustom, dan ini adalah kandidat yang baik untuk penyempurnaan. Tetapi jangan lupa untuk memperhatikan apakah alat dan layanan favorit Anda memiliki model ekstensibilitas yang dapat Anda gunakan. Anda akan mendapatkan banyak manfaat dari memulai di sana. Ini dapat menghilangkan sakit kepala pemeliharaan dan keamanan dan memungkinkan Anda fokus pada masalah yang ingin Anda selesaikan

Misalnya, Anda mungkin dapat memperluas permukaan berikut yang sudah Anda gunakan:

• Editor dan IDEs
• Rangkaian DevOps Anda
• CLI juga semakin mudah diperluas
• Lingkungan rendah/tanpa kode seperti Power Pages

Masing-masing mungkin memberikan titik awal yang lebih baik untuk peran tertentu daripada sesuatu yang Anda siapkan dari awal karena mereka adalah pusat gravitasi yang ada. Memiliki API platform pengembang umum sebagai garis besar memungkinkan Anda untuk menukar hal-hal, bereksperimen, dan mengubah dari waktu ke waktu.

Pertimbangkan ekstensi editor web untuk membuat portal pengembang

Jika Anda mencari pengalaman berbasis web untuk pengembang, perlu diingat bahwa tren terbaru adalah versi editor dan IDEs berbasis web. Banyak, seperti yang menggunakan Visual Studio Code, memiliki dukungan ekstensi. Dengan Visual Studio Code, apa pun yang Anda buat untuk pengalaman web ini kemudian diterjemahkan secara lokal untuk manfaat ganda.

Di luar layanan seperti GitHub Codespaces, vscode.dev adalah versi web gratis dari editor Visual Studio Code tanpa komputasi, tetapi menyertakan dukungan untuk jenis ekstensi tertentu termasuk yang menggunakan tampilan web untuk UI kustom.

Bahkan jika pengembang Anda tidak menggunakan VS Code itu sendiri, pola UX yang sudah dikenal, dan terbukti di alat pengembang lainnya. Menggunakan vscode.dev dapat memberikan fondasi berbasis web yang nyaman dan akrab untuk pengalaman pengembang selain alat itu sendiri.

Ini dapat bertindak sebagai portal yang berfokus pada pengembang dalam bentuk familier yang juga dapat diterjemahkan ke penggunaan lokal.

ChatOps

Kesempatan lain yang sering diabaikan adalah menerapkan antarmuka ChatOps. Mengingat peningkatan antarmuka berbasis obrolan karena munculnya produk AI seperti ChatGPT dan GitHub Copilot, perintah tindakan atau perintah garis miring dapat memberikan cara yang berguna untuk memicu alur kerja otomatisasi, memeriksa status, dan banyak lagi. Mengingat sebagian besar platform CI/CD aplikasi memiliki dukungan siap pakai untuk sistem seperti Microsoft Teams, Slack, atau Discord, ini bisa menjadi cara alami untuk berintegrasi dengan pengembang antarmuka pengguna lain dan peran operasi terkait yang digunakan setiap hari. Selain itu, semua produk ini memiliki model ekstensibilitas.

Berinvestasi di portal pengembang baru

Dengan asumsi Anda tidak memiliki portal atau antarmuka yang sudah ada yang ingin Anda gunakan sebagai basis, Anda mungkin memutuskan untuk membangun portal pengembang baru. Pikirkan ini sebagai sebuah tujuan ketimbang sebuah titik awal. Jika Anda belum memiliki tim pengembangan yang bekerja dengan Anda, memulai upaya ini adalah waktu untuk melakukannya. Setiap organisasi berbeda, jadi tidak ada jawaban yang cocok untuk apa yang harus ada dalam pengalaman semacam ini. Akibatnya, tidak ada jawaban bawaan untuk produk yang sudah dikemas yang dapat Anda aktifkan dan gunakan apa adanya untuk sesuatu seperti ini hari ini.

Untuk opsi yang dihost sendiri yang dibangun khusus, kerangka kerja portal web umum tidak baru, dan tim pengembangan Anda mungkin sudah menggunakan salah satu yang dapat Anda manfaatkan. Jika Anda mencoba mengeluarkan sesuatu di depan pengguna untuk mendapatkan umpan balik awal, Anda bahkan dapat memulai dengan sesuatu sesederhana Power Pages kode rendah untuk terhubung ke API platform pengembang umum.

Upaya portal pengembang yang lebih baru lebih tegas. Misalnya, Backstage.io adalah toolkit portal pengembang kustom yang awalnya dibuat untuk memenuhi kebutuhan Spotify. Ini termasuk CLI untuk membantu menginisialisasi pohon sumber Anda seperti yang dilakukan oleh create-react-app untuk React.js.

Sebagai toolkit portal, diperlukan pekerjaan untuk bangun dan kustomisasi membutuhkan pengetahuan tentang TypeScript, Node.js, dan React. Namun, hal hebat tentang hal itu adalah bahwa, sebagai toolkit, Anda dapat mengubah hampir apa pun. Ini memang memiliki katalog perangkat lunak dan mekanisme templatnya sendiri juga, tetapi penggunaannya tidak diperlukan, dan ini adalah cara yang terdefinisi dengan baik untuk membawa kode baru yang disebut plugin.

Konten terkait

• Halaman Microsoft Power
• Backstage.io
• Menerapkan sistem rekayasa perangkat lunak