Menerapkan sistem rekayasa perangkat lunak

Meningkatkan layanan mandiri pengembang harus menjadi salah satu masalah pertama yang Anda atasi dalam perjalanan rekayasa platform Anda.

Salah satu cara term mudah untuk mulai mengaktifkan pengalaman layanan mandiri otomatis adalah dengan menggunakan kembali sistem teknik yang ada. Sistem ini tidak hanya akrab bagi Anda dan pelanggan internal Anda, tetapi juga memungkinkan berbagai skenario otomatisasi, meskipun pengalaman pengguna awalnya tidak begitu menarik.

Artikel ini menyediakan tips untuk menerapkan sistem teknik Anda untuk mengatasi berbagai skenario layanan mandiri yang lebih luas, dan detail tentang cara merangkum praktik terbaik ke dalam templat yang membantu Anda memulai dengan benar dan tetap benar.

Mengevaluasi praktik DevOps dan DevSecOps dasar Anda

Sistem teknik adalah aspek penting dari platform pengembang internal Anda. Platform pengembangan internal dibangun dari prinsip utama DevOps dan DevSecOps untuk mengurangi beban kognitif bagi semua orang yang terlibat.

DevOps menggabungkan pengembangan dan operasi untuk menyatukan orang, proses, dan teknologi dalam perencanaan, pengembangan, pengiriman, dan operasi aplikasi. Ini dimaksudkan untuk meningkatkan kolaborasi di seluruh peran yang terpisah secara historis seperti pengembangan, operasi TI, rekayasa kualitas, dan keamanan. Anda membuat perulangan berkelanjutan antara pengembangan, penyebaran, pemantauan, pengamatan, dan umpan balik. DevSecOps melapisi perulangan ini dengan praktik keamanan berkelanjutan sepanjang proses pengembangan aplikasi.

Diagram siklus hidup DevOps dengan rencana, memberikan, mengembangkan, mengoperasikan.

Bagian berikut berfokus pada peningkatan yang lebih langsung dikaitkan dengan pergerakan rekayasa platform: jalur yang telah diperbaiki, provisi infrastruktur secara otomatis (selain penyebaran aplikasi), penyiapan lingkungan pengkodean, bersama dengan penyediaan dan konfigurasi alat secara layanan mandiri, sumber daya tim, dan layanan yang tidak secara langsung termasuk dalam proses pengembangan aplikasi.

Menetapkan jalur beraspal yang Anda inginkan

Jika Anda sudah memiliki beberapa set alat yang membentuk sistem teknik Anda, salah satu keputusan awal yang harus dibuat adalah apakah Anda ingin mengonsolidasikannya sebagai bagian dari upaya rekayasa platform awal Anda atau jika Anda akan mendukung konstelasi alat yang berbeda dari awal. Menentukan serangkaian jalur yang diaspal dalam konstelasi alat ini paling efektif dan memberikan peningkatan tingkat fleksibilitas.

Saat Anda mulai bergeser ke arah pola pikir produk, pikirkan sistem teknik dalam jalur yang diaspal ini sebagai terdiri dari alat yang dikelola secara terpusat sebagai layanan kepada tim pengembangan. Tim individu atau divisi dalam organisasi Anda kemudian dapat menyimpang tetapi diharapkan untuk mengelola, memelihara, dan membayar alat mereka secara terpisah sambil tetap mematuhi persyaratan kepatuhan apa pun. Ini menyediakan cara untuk memasukkan alat baru ke dalam ekosistem tanpa gangguan karena Anda dapat memantau setiap penyimpangan untuk kemungkinan dimasukkan ke dalam jalur standar seiring waktu. Sebagaimana yang dikatakan oleh salah satu pemimpin rekayasa platform:

Anda tetap bisa melakukan hal Anda sendiri tetapi lakukan ke arah yang sama dengan kita. Anda dapat mengubah apa pun yang Anda inginkan, tetapi ini menjadi tanggung jawab Anda. Anda memiliki perubahan - Anda memiliki pisau tajam. - Mark, pemimpin rekayasa platform, perusahaan ritel multinasial Eropa besar

Mengingat bahwa tujuan utama untuk rekayasa platform adalah untuk beralih ke pola pikir produk di mana Anda memberikan nilai kepada pelanggan internal Anda, pendekatan konstelasi ini biasanya bekerja lebih baik daripada mandat top-down. Saat Anda menetapkan dan memperbaiki jalur yang diaspal, meninggalkan beberapa fleksibilitas memungkinkan tim untuk memberikan input dan mengatasi persyaratan yang benar-benar unik untuk aplikasi tertentu tanpa memengaruhi orang lain di organisasi. Ini mengarah ke satu set jalur emas yang sepenuhnya diaspal, sementara yang lain hanya diaspal sebagian. Dalam kasus di mana tidak ada persyaratan unik, pengembangan kerja ekstra yang dilakukan tim secara alami menyebabkan mereka ingin pindah ke jalur yang didukung dari waktu ke waktu.

Jika Anda lebih suka strategi konsolidasi, memigrasikan aplikasi yang ada mungkin lebih banyak pekerjaan daripada yang Anda harapkan, jadi untuk memulai, Anda mungkin ingin fokus pada aspek mulai dengan baik dari area ini dan fokus pada proyek baru. Ini menyediakan jalur beraspal pertama Anda, sementara semua yang ada secara inheren belum diaspal. Tim pengembangan di jalur yang belum diaspal kemudian dapat mempertimbangkan untuk pindah setelah jalur beraspal baru Anda menunjukkan nilainya kepada organisasi. Pada saat itu Anda dapat menjalankan kampanye perbaikan untuk membawa semua orang ke kondisi yang Anda inginkan melalui komunikasi dua arah karena tim pengembangan melihat ini sebagai keuntungan daripada beban. Selama kampanye, tim teknik platform dapat fokus untuk membantu tim bermigrasi, sementara tim pengembang memberikan umpan balik tentang cara membuat jalur yang diaspal lebih baik.

Terlepas dari itu, hindari mengamanatkan penggunaan jalur beraspal Anda. Cara paling efektif untuk meluncurkan jalur beraspal adalah dengan menekankan apa yang tim dapatkan dari mereka daripada melalui adopsi paksa. Karena platform pengembang internal Anda berfokus pada membuat tim yang sama persis ini bahagia, tekanan anggaran dan waktu pencapaian nilai pada masing-masing pemimpin menangani sisanya. Dapatkan kampanye yang tepat kemudian berikan jalan untuk percakapan dua arah dengan cara yang paling tepat bagi mereka yang berada di jalur tidak beraspal untuk beralih.

Gunakan alat otomatisasi pengembang untuk meningkatkan layanan mandiri untuk jalur beraspal Anda

Bagian dari membuat jalur beraspal pertama Anda adalah membangun produk otomatisasi pengembang inti Anda. Ini penting saat Anda mulai berpikir untuk mengaktifkan kemampuan layanan mandiri pengembang.

Mengaktifkan penyediaan infrastruktur aplikasi secara otomatis selama proses pengiriman berkelanjutan

Jika belum diterapkan, masalah yang Anda identifikasi selama perencanaan Anda kemungkinan menunjuk ke masalah yang dapat membantu mengatasi masalah integrasi berkelanjutan (CI) dan pengiriman berkelanjutan (CD). Produk seperti GitHub Actions, Azure DevOps, Jenkins, bersama dengan solusi GitOps berbasis pull seperti Flux atau Argo CD ada di ruang ini. Anda dapat memulai topik ini di pusat sumber daya Microsoft DevOps.

Bahkan jika Anda telah menerapkan cara untuk terus menyebarkan aplikasi Anda di infrastruktur yang ada, Anda harus mempertimbangkan untuk menggunakan infrastruktur sebagai kode (IaC) untuk membuat atau memperbarui infrastruktur aplikasi yang diperlukan sebagai bagian dari alur CD Anda.

Misalnya, pertimbangkan ilustrasi berikut yang menunjukkan dua pendekatan yang menggunakan GitHub Actions untuk memperbarui infrastruktur dan menyebarkan ke Azure Kubernetes Service: satu menggunakan penyebaran berbasis push, dan satu penyebaran berbasis pull (GitOps).

Yang Anda pilih didorong oleh set keterampilan IaC yang ada dan detail platform aplikasi target Anda. Pendekatan GitOps lebih baru dan populer di kalangan organisasi yang menggunakan Kubernetes sebagai basis untuk aplikasi mereka, sementara model berbasis pull saat ini memberi Anda fleksibilitas terbanyak mengingat jumlah opsi yang tersedia untuknya. Kami mengharapkan sebagian besar organisasi menggunakan campuran keduanya. Terlepas dari itu, menjadi berpengalaman dalam praktik IaC dapat membantu Anda mempelajari pola yang berlaku untuk skenario otomatisasi lebih lanjut.

Mempusatkan IaC dalam katalog atau registri untuk menskalakan dan meningkatkan keamanan

Untuk mengelola dan menskalakan IaC di seluruh aplikasi, Anda harus menerbitkan artefak IaC Anda secara terpusat untuk digunakan kembali. Misalnya, Anda dapat menggunakan modul Terraform dalam registri, modul Bicep, resep Radius, atau Bagan Helm yang disimpan dalam registri Artefak OCI cloud-native seperti Azure Container Registry (ACR), DockerHub, atau katalog di Azure Deployment Environments (ADE). Untuk GitOps dan Kubernetes, API Kluster (dan implementasi seperti CAPZ) dapat memungkinkan Anda mengelola kluster beban kerja Kubernetes, sementara definisi sumber daya kustom seperti Operator Layanan Azure dapat memberikan dukungan tambahan untuk jenis sumber daya Azure lainnya. Alat lain seperti Crossplane mendukung sumber daya di beberapa cloud. Ini memungkinkan Anda menggunakan bagan Helm terpusat atau umum dalam sesuatu seperti ACR untuk berbagai skenario yang lebih luas.

Memusatkan IaC meningkatkan keamanan dengan memberi Anda kontrol yang lebih baik atas siapa yang dapat membuat pembaruan karena mereka tidak lagi disimpan dengan kode aplikasi. Ada risiko kesalahan yang lebih rendah akibat perubahan tak terencana selama pembaruan kode ketika para ahli, tim operasi, atau insinyur platform melakukan perubahan yang dibutuhkan. Pengembang juga mendapat manfaat dari blok penyusun ini karena mereka tidak perlu menulis templat IaC lengkap itu sendiri dan secara otomatis mendapat manfaat dari praktik terbaik yang dikodekan.

Format IaC mana yang Anda pilih tergantung pada set keterampilan yang ada, tingkat kontrol yang Anda butuhkan, dan model aplikasi yang Anda gunakan. Misalnya, Azure Container Apps (ACA) dan proyek inkubasi OSS Radius eksperimental terbaru lebih berpendapat daripada menggunakan Kubernetes secara langsung, tetapi juga menyederhanakan pengalaman pengembang. Untuk mempelajari tentang pro dan kontra dari berbagai model, lihat Menjelaskan jenis layanan cloud. Terlepas dari itu, mereferensikan IaC terpusat dan terkelola daripada memiliki definisi lengkap di pohon sumber Anda memiliki manfaat yang signifikan.

Mempertahankan identitas atau rahasia provisi yang diperlukan dengan cara agar pengembang tidak dapat langsung mengakses lapisannya di blok penyusun dasar untuk tata kelola. Misalnya, pertimbangkan ilustrasi ini pada pemisahan peran yang dapat Anda capai menggunakan Azure Deployment Environments (ADE).

Di sini, teknisi platform dan spesialis lainnya mengembangkan IaC dan templat lainnya dan menempatkannya dalam katalog. Operasi kemudian dapat menambahkan identitas dan langganan terkelola berdasarkan jenis lingkungan dan menetapkan pengembang dan pengguna lain yang mempunyai izin untuk menggunakannya dalam proses provisi.

Pengembang atau alur CI/CD Anda kemudian dapat menggunakan Azure CLI atau Azure Developer CLI untuk menyediakan infrastruktur yang telah dikonfigurasi dan dikontrol tanpa memiliki akses ke langganan atau identitas yang mendasarinya yang diperlukan untuk melakukannya. Apakah Anda menggunakan sesuatu seperti ADE atau tidak, sistem pengiriman berkelanjutan pilihan Anda dapat membantu Anda memperbarui infrastruktur dengan aman dan aman dengan memisahkan rahasia dan sumber konten IaC dari lokasi yang tidak dapat diakses atau dimodifikasi pengembang sendiri.

Mengaktifkan layanan mandiri dalam skenario di luar pengiriman berkelanjutan aplikasi

Meskipun konsep CI dan CD terkait dengan pengembangan aplikasi, banyak hal yang ingin disediakan pelanggan internal Anda tidak langsung mengikat aplikasi tertentu. Ini dapat berupa infrastruktur bersama, membuat repositori, alat provisi, dan banyak lagi.

Untuk memahami di mana ini dapat membantu, pikirkan di mana Anda saat ini memiliki proses berbasis manual atau meja layanan. Untuk masing-masing, pikirkan tentang pertanyaan-pertanyaan ini:

Seberapa sering proses ini terjadi?
Apakah prosesnya lambat, rawan kesalahan, atau memerlukan pekerjaan yang signifikan untuk dicapai?
Apakah proses ini manual karena langkah persetujuan yang diperlukan atau hanya kurangnya otomatisasi?
Apakah pemberi persetujuan terbiasa dengan sistem kontrol sumber dan proses permintaan pull?
Apa saja persyaratan audit untuk proses tersebut? Apakah ini berbeda dari persyaratan audit sistem kontrol sumber Anda?
Apakah ada proses yang dapat Anda mulai dengan risiko yang lebih rendah sebelum beralih ke proses yang lebih kompleks?

Identifikasi proses yang sering, upaya tinggi, atau rawan kesalahan sebagai target potensial untuk mengotomatiskan terlebih dahulu.

Gunakan semuanya sebagai pola kode

Salah satu hal bagus tentang Git selain keberadaannya di mana-mana adalah bahwa ia dimaksudkan untuk menjadi sumber informasi yang aman dan dapat diaudit. Di luar riwayat komit dan kontrol akses, konsep seperti permintaan tarik dan perlindungan cabang menyediakan cara untuk menetapkan peninjau tertentu, riwayat percakapan, dan atau pemeriksaan otomatis yang harus lolos sebelum digabungkan ke dalam cabang utama. Ketika dikombinasikan dengan mesin tugas fleksibel seperti yang ditemukan dalam sistem CI/CD, Anda memiliki kerangka kerja otomatisasi yang aman.

Ide di balik segala sesuatu sebagai kode adalah bahwa Anda dapat mengubah hampir apa pun menjadi file di repositori Git yang aman. Alat atau agen yang berbeda yang terhubung ke repositori kemudian dapat membaca konten. Memperlakukan semuanya sebagai kode membantu pengulangan melalui templat dan menyederhanakan layanan mandiri pengembang. Mari kita lihat beberapa contoh cara kerjanya.

Menerapkan pola IaC ke infrastruktur apa pun

Meskipun IaC mendapatkan popularitas untuk membantu mengotomatiskan pengiriman aplikasi, pola meluas ke infrastruktur, alat, atau layanan apa pun yang mungkin ingin Anda provisikan dan konfigurasikan, bukan hanya yang terkait dengan aplikasi tertentu. Misalnya, kluster Kubernetes bersama dengan Flux diinstal, menyediakan sesuatu seperti DataDog yang digunakan oleh beberapa tim dan aplikasi, atau bahkan menyiapkan alat kolaborasi favorit Anda.

Cara kerjanya adalah Anda memiliki repositori terpusat yang terpisah dan aman yang menampung serangkaian file yang mewakili apa yang harus disediakan dan dikonfigurasi (dalam hal ini apa pun mulai dari Bicep atau Terraform, hingga bagan Helm dan format asli Kubernetes lainnya). Tim operasi atau sekumpulan administrator lainnya memiliki repositori, dan pengembang (atau sistem) dapat mengirimkan permintaan pull (PR). Setelah PR ini digabungkan ke cabang utama oleh administrator ini, alat CI/CD yang sama yang digunakan selama pengembangan aplikasi dapat dimulai untuk memproses perubahan. Pertimbangkan ilustrasi berikut yang menunjukkan GitHub Actions, IaC, dan identitas penyebaran yang bertempat di Lingkungan Penyebaran Azure:

Jika Anda sudah menggunakan pendekatan GitOps untuk penyebaran aplikasi, Anda juga dapat menggunakan kembali alat-alat ini. Menggabungkan alat seperti Flux dan Operator Layanan Azure memungkinkan Anda untuk memperluas di luar Kubernetes:

Dalam kedua kasus, Anda memiliki sumber informasi yang dikelola sepenuhnya, dapat direproduksi, dan dapat diaudit, bahkan jika apa yang dihasilkan bukan untuk aplikasi. Seperti halnya pengembangan aplikasi, rahasia atau identitas terkelola apa pun yang Anda butuhkan disimpan di mesin alur/alur kerja atau dalam kemampuan asli layanan provisi.

Karena orang-orang yang membuat PR tidak memiliki akses langsung ke rahasia ini, hal ini menyediakan cara bagi pengembang untuk memulai tindakan dengan aman bahwa mereka tidak memiliki izin langsung untuk melakukan sendiri. Ini memungkinkan Anda mematuhi prinsip hak istimewa paling sedikit sambil tetap memberi pengembang opsi layanan mandiri.

Melacak infrastruktur yang disediakan

Saat Anda mulai menskalakan pendekatan ini, pikirkan tentang bagaimana Anda ingin melacak infrastruktur yang disediakan. Repositori Git Anda adalah sumber kebenaran untuk konfigurasi, tetapi tidak memberi tahu Anda URI dan informasi status tertentu tentang apa yang Anda buat. Namun, mengikuti pendekatan segala sesuatu sebagai kode memberi Anda sumber informasi untuk mensintesis inventaris infrastruktur yang disediakan. Penyedia Anda mungkin juga merupakan sumber informasi yang baik yang dapat Anda manfaatkan. Misalnya, Lingkungan Penyebaran Azure menyertakan kemampuan pelacakan lingkungan yang dapat dipandang oleh pengembang.

Untuk mempelajari selengkapnya tentang pelacakan di berbagai sumber data, lihat Mendesain fondasi layanan mandiri pengembang.

Menerapkan keamanan sebagai kode dan kebijakan sebagai pola kode

Meskipun infrastruktur provisi berguna, pastikan lingkungan ini aman dan umumnya mengikuti kebijakan organisasi Anda sama pentingnya. Hal ini menyebabkan munculnya kebijakan sebagai kode. Di sini, file konfigurasi di repositori kontrol sumber dapat digunakan untuk melakukan hal-hal seperti pemindaian keamanan drive atau menerapkan kebijakan infrastruktur.

Banyak produk dan proyek sumber terbuka yang berbeda telah mengadopsi pendekatan ini, termasuk Azure Policy, Open Policy Agent, GitHub Advanced Security, dan GitHub CODEOWNERS, antara lain. Saat memilih infrastruktur, layanan, atau alat aplikasi Anda, pastikan untuk mengevaluasi seberapa baik mereka mendukung pola-pola ini. Untuk informasi selengkapnya tentang menyempurnakan aplikasi dan tata kelola Anda, lihat Memperbaiki platform aplikasi Anda.

Gunakan semuanya sebagai kode untuk skenario Anda sendiri

Segala sesuatu sebagai kode memperluas pola-pola ini ke berbagai tugas otomatisasi dan konfigurasi di luar IaC. Ini dapat mendukung tidak hanya membuat atau mengonfigurasi semua jenis infrastruktur, tetapi juga memperbarui data atau memicu alur kerja di sistem hilir apa pun.

PR menjadi pengalaman pengguna mandiri dasar yang baik untuk berbagai proses, terutama ketika Anda memulai. Prosesnya secara alami mendapatkan manfaat keamanan, auditabilitas, dan pemutaran kembali yang diberikan Git itu sendiri dan sistem yang terlibat juga dapat berubah dari waktu ke waktu tanpa memengaruhi pengalaman pengguna.

Teams sebagai kode

Salah satu contoh penerapan konsep 'everything as code' ke skenario Anda sendiri adalah pola 'tim sebagai kode'. Organisasi menerapkan pola ini untuk menstandarkan keanggotaan tim dan, dalam beberapa kasus, pemberian izin alat/layanan pengembang di berbagai sistem. Pola ini menghilangkan proses help desk penerimaan dan pelepasan pengguna secara manual yang didorong oleh kebutuhan pengembang dan operator sistem untuk mengakses konsep mereka tentang pengelompokan, pengguna, dan akses. Proses meja layanan secara manual adalah potensi risiko keamanan karena memungkinkan adanya pemberian akses yang berlebihan. Saat menggunakan tim sebagai pola kode, kombinasi Git dan PR dapat mengaktifkan layanan mandiri dari sumber data yang dapat diaudit.

Untuk contoh variasi pola ini yang matang dan luas, lihat posting blog GitHub tentang cara mereka mengelola Pemberian Izin. GitHub juga membuka sumber implementasi Pemberian Hak canggih mereka bagi Anda untuk mencoba atau mengadopsi. Meskipun posting blog menjelaskan hak karyawan secara keseluruhan, Anda dapat menerapkan konsep 'teams as code' untuk skenario tim pengembangan dengan lingkup yang lebih sempit. Tim pengembangan ini mungkin sama sekali tidak tercantum dalam bagan organisasi karyawan dan melibatkan alat atau layanan milik yang dapat mempersulit proses orientasi atau keluarnya anggota tim.

Berikut ringkasan variasi yang disederhanakan dari ide ini yang menggunakan sistem CI/CD dan grup penyedia identitas untuk mengoordinasikan pembaruan:

Dalam contoh ini:

Setiap sistem yang terlibat disiapkan untuk menggunakan penyedia identitas Anda (misalnya, ID Microsoft Entra) untuk masuk tunggal (SSO).
Anda menggunakan grup penyedia identitas (misalnya, grup Entra) di seluruh sistem untuk mengelola keanggotaan berdasarkan peran untuk mengurangi kompleksitas dan mempertahankan audit terpusat.

Pada tingkat tinggi, berikut cara kerja pola ini:

Repositori Git yang dikunci pusat memiliki sekumpulan file (biasanya YAML) di dalamnya yang mewakili setiap tim abstrak, keanggotaan pengguna terkait, dan peran pengguna. Pemilik atau pemberi persetujuan untuk perubahan tim juga dapat disimpan di tempat yang sama ini (misalnya, melalui CODEOWNERS). Referensi ke pengguna dalam file-file ini adalah penyedia identitas, tetapi repositori ini bertindak sebagai sumber kebenaran bagi tim ini (tetapi bukan pengguna).
Semua pembaruan untuk file-file ini dilakukan melalui permintaan pull. Ini menghubungkan percakapan dan peserta terkait pada permintaan ke komit Git untuk dapat diaudit.
Prospek dan pengguna individual dapat membuat PR untuk menambahkan atau menghapus orang, dan dev leads serta peran lainnya dapat membuat tim baru dengan menggunakan PR berdasarkan file tim baru dari templat.
Setiap kali PR digabungkan menjadi utama, sistem CI/CD yang terkait dengan repositori kemudian memperbarui sistem penyedia identitas dan semua sistem hilir yang sesuai.

Secara khusus, sistem CI/CD:

Menggunakan API sistem penyedia identitas yang sesuai untuk membuat atau memperbarui grup penyedia identitas per peran dengan individu yang tepat dalam file (tidak lebih, tidak kurang).
Menggunakan API untuk setiap sistem hilir untuk mengikat konsep pengelompokan sistem ke grup penyedia identifikasi untuk setiap peran (misalnya, GitHub dan Azure DevOps). Hal ini dapat mengakibatkan hubungan satu-ke-banyak antara tim Anda dan sistem hilir untuk mewakili peran.
(Opsional) Menggunakan API untuk setiap sistem hilir untuk menerapkan logika izin yang terkait dengan mekanisme pengelompokan sistem.
Menggunakan API untuk memperbarui penyimpanan data yang dikunci dengan hasil (termasuk mengaitkan ID tim sistem hilir) yang kemudian dapat digunakan untuk salah satu sistem yang dibuat secara internal. Anda juga dapat menyimpan asosiasi untuk representasi sistem yang berbeda dari ID pengguna untuk pengguna/akun penyedia identitas yang sama di sini, jika diperlukan.

Jika organisasi Anda sudah menggunakan sesuatu seperti pengelolaan pemberian izin Entra, Anda mungkin dapat menghilangkan pengelolaan keanggotaan grup dari pola ini.

Kebutuhan dan kebijakan Anda mungkin merubah detailnya, tetapi pola umum dapat diadaptasikan dengan sejumlah variasi. Rahasia apa pun yang diperlukan untuk diintegrasikan dengan sistem hilir apa pun dipertahankan baik dalam sistem CI/CD (misalnya, di GitHub Actions atau Azure Pipelines) atau dalam sesuatu seperti Azure Key Vault.

Gunakan alur kerja berparameter yang dipicu secara manual atau eksternal.

Beberapa masalah terkait layanan mandiri yang Anda identifikasi mungkin tidak kondusif untuk menggunakan file di Git. Atau, Anda mungkin memiliki antarmuka pengguna yang ingin Anda gunakan untuk mendorong pengalaman layanan mandiri.

Untungnya, sebagian besar sistem CI, termasuk GitHub Actions dan Azure Pipelines, memiliki kemampuan untuk menyiapkan alur kerja dengan input yang kemudian dapat Anda picu secara manual melalui UI atau CLI mereka. Mengingat bahwa pengembang dan peran operasi terkait kemungkinan sudah terbiasa dengan pengalaman pengguna ini, pemicu manual dapat menambah semuanya sebagai pola kode untuk mengaktifkan otomatisasi untuk aktivitas (atau pekerjaan) yang tidak memiliki representasi file alami atau harus sepenuhnya otomatis tanpa memerlukan proses PR.

Sistem CI Anda mungkin memungkinkan Anda untuk memilih untuk memicu alur kerja atau alur ini dari pengalaman pengguna Anda sendiri melalui API. Untuk GitHub Actions, kunci untuk membuat pekerjaan ini adalah Actions REST API untuk mengaktifkan peristiwa pengiriman alur kerja untuk memicu eksekusi 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. Baik dipicu secara manual atau melalui API, setiap alur kerja dapat mendukung serangkaian input dengan menambahkan konfigurasi workflow_dispatch ke file YAML alur kerja. Misalnya, ini adalah bagaimana toolkit portal seperti Backstage.io berinteraksi dengan GitHub Actions.

Alur kerja atau sistem pekerjaan sistem CI/CD Anda tidak diragukan lagi melacak aktivitas, melaporkan kembali status, dan memiliki log terperinci yang dapat digunakan oleh pengembang dan tim operasi untuk melihat apa yang salah. Dengan demikian, ini memiliki beberapa keuntungan dalam hal keamanan, auditabilitas, dan visibilitas yang sama dengan pola "everything as code". Namun, satu hal yang perlu diingat adalah bahwa setiap tindakan yang dilakukan oleh alur kerja atau alur ini terlihat seperti identitas sistem (misalnya, perwakilan layanan atau identitas terkelola di MICROSOFT Entra ID) ke sistem hilir.

Anda akan memiliki visibilitas tentang siapa yang memulai permintaan dalam sistem CI/CD Anda, tetapi Anda harus menilai apakah ini informasi yang cukup dan memastikan pengaturan retensi CI/CD Anda mematuhi persyaratan audit Anda untuk kasus ketika informasi ini penting.

Dalam kasus lain, alat yang Anda integrasikan mungkin memiliki mekanisme pelacakannya sendiri yang dapat Anda gunakan. Misalnya, alat CI/CD ini hampir selalu memiliki beberapa mekanisme pemberitahuan yang tersedia seperti menggunakan saluran Microsoft Teams atau Slack , yang dapat memungkinkan Anda untuk membuat siapa pun mengirimkan permintaan untuk mendapatkan pembaruan status dan saluran memberikan catatan informal tentang apa yang terjadi. Mesin alur kerja yang sama ini sering kali dirancang untuk diintegrasikan dengan alat operasi untuk lebih memperluas kegunaan pola-pola ini.

Singkatnya, Anda dapat menerapkan beberapa otomatisasi menggunakan file yang disimpan dalam repositori kontrol sumber berkat fleksibilitas alat CI/CD dan pengalaman pengguna yang siap pakai. Untuk melihat bagaimana platform pengembang internal dapat menggunakan pendekatan ini sebagai titik awal tanpa mengorbankan kemampuan yang lebih canggih dari waktu ke waktu, lihat Merancang fondasi layanan mandiri pengembang.

Mengotomatiskan penyiapan lingkungan pengkodian pengembang

Masalah umum lainnya dalam sistem teknik adalah bootstrap dan normalisasi lingkungan pengembangan kode pengembang. Berikut adalah beberapa masalah umum yang mungkin Anda dengar di area ini:

Dalam beberapa kasus, dibutuhkan beberapa minggu bagi pengembang untuk sampai ke permintaan pull pertama mereka. Ini adalah area yang bermasalah ketika Anda memindahkan pengembang antara tim fitur dan proyek yang cukup sering (misalnya, di organisasi matriks), perlu meningkatkan jumlah kontraktor, atau berada di tim yang sedang merekrut.
Ketidakkonsistenan antara pengembang dan sistem CI Anda dapat menyebabkan seringnya masalah "berfungsi di komputer saya" bahkan untuk anggota tim yang berpengalaman.
Eksperimen dan peningkatan kerangka kerja, durasi, dan perangkat lunak lainnya juga dapat merusak lingkungan pengembang yang ada dan menyebabkan hilangnya waktu mencoba mencari tahu persis apa yang salah.
Untuk pemimpin pengembangan, tinjauan kode dapat memperlambat pengembangan karena mungkin memerlukan perubahan konfigurasi untuk pengujian dan pembatalan setelah peninjauan selesai.
Anggota dan operator tim juga harus menghabiskan waktu untuk mengembangkan peran terkait di luar pengembangan (operator, QA, bisnis, sponsor) untuk membantu menguji, melihat kemajuan, melatih peran di bidang bisnis, dan mempromosikan pekerjaan yang dilakukan tim.

Bagian dari jalur beraspal Anda

Untuk membantu mengatasi masalah ini, pikirkan tentang penyiapan alat dan utilitas tertentu sebagai bagian dari jalur beraspal yang terdefinisi dengan baik. Pengaturan mesin pengembang skrip bisa sangat membantu, dan Anda dapat menggunakan kembali skrip yang sama di lingkungan CI Anda. Namun, pertimbangkan untuk mendukung lingkungan pengembangan kontainer atau virtual karena manfaat yang dapat mereka berikan. Lingkungan pengkodian ini dapat disiapkan terlebih dahulu untuk spesifikasi organisasi atau proyek Anda.

Penggantian stasiun kerja yang ditujukan untuk Windows

Jika Anda menargetkan Windows atau ingin melakukan virtualisasi stasiun kerja penuh (alat klien dan pengaturan OS host selain pengaturan spesifik proyek), VM biasanya menyediakan fungsionalitas terbaik. Lingkungan ini dapat berguna untuk apa pun dari pengembangan klien Windows ke layanan Windows atau mengelola dan memelihara aplikasi web kerangka kerja penuh .NET.

Pendekatan	Examples
Menggunakan VM yang di-host cloud	Microsoft Dev Box adalah opsi virtualisasi stasiun kerja Windows lengkap dengan integrasi bawaan ke perangkat lunak manajemen desktop.
Menggunakan komputer virtual lokal	Hashicorp Vagrant adalah pilihan yang baik dan Anda dapat menggunakan HashiCorp Packer untuk membangun gambar VM untuk itu dan Dev Box.

Virtualisasi lingkungan kerja dan penargetan sistem Linux

Jika Anda menargetkan Linux, pertimbangkan opsi virtualisasi ruang kerja. Opsi ini kurang berfokus pada mengganti desktop pengembang Anda dan banyak lagi pada ruang kerja khusus proyek atau aplikasi.

Pendekatan	Examples
Menggunakan kontainer yang dihost di cloud	GitHub Codespaces adalah lingkungan berbasis cloud untuk Kontainer Dev yang mendukung integrasi dengan Visual Studio Code, IntelliJ JetBrains, dan alat berbasis terminal. Jika layanan ini atau layanan serupa tidak memenuhi kebutuhan Anda, Anda dapat menggunakan dukungan SSH atau penggunaan terowongan jarak jauh VS Code dengan Dev Containers pada VM Linux jarak jauh. Opsi berbasis terowongan yang tidak hanya berfungsi dengan klien, tetapi juga dengan vscode.dev yang berbasis web.
Menggunakan kontainer lokal	Jika Anda lebih suka opsi Kontainer Dev lokal sebagai gantinya atau selain yang dihosting cloud, Dev Containers memiliki dukungan yang solid di VS Code, dukungan di IntelliJ, dan alat dan layanan lainnya.
Menggunakan VM yang dihosting cloud	Jika Anda menemukan kontainer terlalu membatasi, dukungan SSH dalam alat seperti Visual Studio Code atau alat JetBrains seperti IntelliJ memungkinkan Anda untuk langsung terhubung ke VM Linux yang Anda kelola sendiri. Visual Studio Code memiliki opsi berbasis terowongan yang juga berfungsi di sini.
Menggunakan Subsistem Windows untuk Linux	Jika pengembang Anda secara eksklusif berada di Windows, Subsistem Windows untuk Linux (WSL) adalah cara yang bagus bagi pengembang untuk menargetkan Linux secara lokal. Anda dapat mengekspor distribusi WSL untuk tim Anda dan membagikannya dengan segala sesuatu yang disiapkan. Untuk opsi cloud, layanan stasiun kerja cloud seperti Microsoft Dev Box juga dapat memanfaatkan WSL untuk menargetkan pengembangan Linux.

Membuat templat aplikasi mulai dengan benar yang menyertakan konfigurasi tetap benar

Hal hebat tentang segala sesuatu sebagai pola kode adalah bahwa ia dapat menjaga pengembang di jalur beraspal yang Anda tetapkan dari awal. Jika ini adalah tantangan bagi organisasi Anda, templat aplikasi dapat dengan cepat menjadi cara penting untuk menggunakan kembali blok penyusun untuk mendorong konsistensi, mempromosikan standardisasi, dan mengkodifikasi praktik terbaik organisasi Anda.

Untuk memulai, Anda dapat menggunakan sesuatu yang sederhana seperti repositori templat GitHub, tetapi jika organisasi Anda mengikuti pola monorepo , ini mungkin kurang efektif. Anda juga dapat membuat templat yang membantu menyiapkan sesuatu yang tidak terkait langsung dengan pohon sumber aplikasi. Sebagai gantinya, Anda dapat menggunakan mesin templat seperti cookiecutter, Yeoman, atau sesuatu seperti Azure Developer CLI (azd) yang, selain membuat templat dan penyiapan CI/CD yang disederhanakan, juga menyediakan serangkaian perintah pengembang yang nyaman. Karena Azure Developer CLI dapat digunakan untuk mendorong penyiapan lingkungan di semua skenario, azure Developer CLI terintegrasi dengan Lingkungan Penyebaran Azure untuk menyediakan keamanan yang ditingkatkan, IaC terintegrasi, pelacakan lingkungan, pemisahan kekhawatiran, dan penyiapan CD yang disederhanakan.

Setelah Anda memiliki sekumpulan templat, pemimpin pengembang dapat menggunakan alat command line ini atau pengalaman pengguna yang terintegrasi lainnya untuk memulai konten mereka untuk aplikasi mereka. Namun, karena pengembang mungkin tidak memiliki izin untuk membuat repositori atau konten lain dari templat Anda, ini juga merupakan kesempatan lain untuk menggunakan alur kerja atau alur yang dipicu secara manual dan berparameter. Anda dapat mengatur input agar sistem CI/CD Anda membuat apa pun dari repositori ke infrastruktur atas nama mereka.

Mempertahankan kebenaran dan mencapai kebenaran

Namun, untuk membantu menskalakan, templat aplikasi ini harus mereferensikan blok penyusun terpusat jika memungkinkan (misalnya, templat IaC atau bahkan alur kerja dan alur CI/CD). Bahkan, memperlakukan blok penyusun yang terpusat ini sebagai bentuk template awal mereka sendiri bisa menjadi strategi yang efektif untuk mengatasi beberapa masalah yang telah Anda identifikasi.

Masing-masing templat ini dapat diterapkan tidak hanya ke aplikasi baru, tetapi juga yang sudah ada yang ingin Anda perbarui sebagai bagian dari kampanye yang tepat untuk meluncurkan panduan yang diperbarui atau ditingkatkan. Lebih baik lagi, sentralisasi ini membantu Anda menjaga aplikasi baru dan yang sudah ada tetap tepat memungkinkan Anda untuk mengembangkan atau memperluas praktik terbaik Anda dari waktu ke waktu.

Isi templat

Sebaiknya pertimbangkan area berikut saat membuat templat.

Area	Detail lebih lanjut
Sampel kode sumber yang memadai untuk mendorong pola aplikasi, SDK, dan penggunaan alat	Sertakan kode dan konfigurasi untuk mengarahkan pengembang ke arah bahasa yang direkomendasikan, model dan layanan aplikasi, API, SDK, dan pola arsitektur. Pastikan untuk menyertakan kode untuk pelacakan terdistribusi, pengelogan, dan pengamatan menggunakan alat pilihan Anda.
Membangun dan menyebarkan skrip	Memberi pengembang metode yang konsisten untuk memicu build dan penyebaran lokal / dalam lingkungan uji coba. Sertakan konfigurasi debug dalam IDE/editor untuk alat pilihan Anda untuk menggunakannya. Ini adalah cara penting untuk menghindari sakit kepala pemeliharaan dan mencegah CI/CD tidak sinkron. Jika mesin templat bersifat opinionated seperti Azure Developer CLI, mungkin sudah ada perintah yang bisa Anda gunakan.
Konfigurasi untuk CI/CD	Berikan alur kerja /alur untuk membangun dan menyebarkan aplikasi berdasarkan rekomendasi Anda. Manfaatkan alur kerja atau pipeline yang terpusat, dapat digunakan kembali, atau berdasarkan templat untuk membantu menjaga agar tetap terbaru. Bahkan, alur kerja / saluran yang dapat digunakan kembali ini dapat menjadi templat awal mereka sendiri. Pastikan untuk mempertimbangkan opsi untuk memicu alur kerja ini secara manual.
Infrastruktur sebagai aset kode	Berikan konfigurasi IaC yang direkomendasikan termasuk referensi ke modul atau item katalog yang dikelola secara terpusat untuk memastikan setiap penyiapan infrastruktur mengikuti praktik terbaik sedari awal. Referensi ini juga dapat membantu tim tetap tepat seiring berjalannya waktu. Dikombinasikan dengan workflows / pipelines, Anda juga dapat menyertakan IaC atau EaC untuk menyediakan hampir semua hal.
Keamanan dan kebijakan sebagai aset kode	Gerakan DevSecOps memindahkan konfigurasi keamanan ke dalam kode, yang sangat bagus untuk templat. Beberapa kebijakan sebagai artefak kode juga dapat diterapkan di tingkat aplikasi. Sertakan semuanya mulai dari file seperti CODEOWNERS hingga konfigurasi pemindaian seperti dependabot.yaml di GitHub Advanced Security. Berikan alur kerja/eksekusi alur terjadwal untuk pemindaian menggunakan sesuatu seperti Defender for Cloud bersama dengan eksekusi pengujian lingkungan. Ini penting untuk keamanan rantai pasokan, dan pastikan untuk memperhitungkan gambar kontainer selain paket dan kode aplikasi. Langkah-langkah ini membantu tim pengembangan tetap berada di jalur yang benar.
Pengamatan, pemantauan, dan pengelogan	Bagian dari mengaktifkan layanan mandiri adalah memberikan visibilitas yang mudah ke dalam aplikasi setelah disebarkan. Di luar infrastruktur runtime, pastikan untuk menyertakan penyiapan untuk pengamatan dan pemantauan. Dalam kebanyakan kasus, ada aspek IaC untuk disiapkan (misalnya, penyebaran agen, instrumentasi) sementara di kasus lain mungkin merupakan jenis lain dari artefak kode sebagai konfigurasi (misalnya, dasbor pemantauan untuk Azure Application Insights). Terakhir, pastikan untuk menyertakan kode sampel kode untuk pelacakan terdistribusi, pengelogan, dan pengamatan menggunakan alat pilihan Anda.
Penyiapan lingkungan pengkodian	Sertakan file konfigurasi untuk pengkodian linter, formatter, editor, dan IDEs. Sertakan skrip penyiapan bersama dengan file virtualisasi ruang kerja atau stasiun kerja seperti devcontainer.json, devbox.yaml, Dockerfiles yang berfokus pada pengembang, file Docker Compose, atau Vagrantfiles.
Konfigurasi pengujian	Sediakan file konfigurasi untuk pengujian unit dan lebih mendalam menggunakan layanan pilihan Anda seperti Pengujian Microsoft Playwright untuk UI atau Pengujian Aplikasi Azure.
Pengaturan perangkat kolaborasi	Jika manajemen masalah dan sistem manajemen kontrol sumber Anda mendukung templat tugas / masalah / PR sebagai kode, sertakan ini juga. Dalam kasus di mana lebih banyak pengaturan diperlukan, Anda dapat secara opsional menyediakan alur kerja / alur yang memperbarui sistem Anda menggunakan CLI atau API yang tersedia. Ini juga dapat memungkinkan Anda menyiapkan alat kolaborasi lain seperti Microsoft Teams atau Slack.

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2025-10-20