Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Organisasi dan cara kerja

Seperti semua strategi arsitektur, frontend mikro memiliki implikasi jauh melampaui teknologi yang dipilih organisasi untuk diterapkan. Keputusan untuk membangun aplikasi micro-frontend harus selaras dengan bisnis, produk, organisasi, operasi, dan bahkan budaya (misalnya, memberdayakan tim dan desentralisasi pengambilan keputusan). Sebagai imbalannya, jenis arsitektur micro-frontend ini mendukung pengembangan yang benar-benar gesit dan didorong oleh produk, karena secara signifikan mengurangi overhead komunikasi antara tim independen.

Pengembangan tangkas

Gagasan pengembangan perangkat lunak tangkas telah menjadi begitu universal dalam beberapa tahun terakhir sehingga hampir setiap organisasi mengklaim bekerja gesit. Sementara definisi konklusif agile berada di luar cakupan strategi ini, ada baiknya meninjau elemen-elemen kunci yang relevan dengan pengembangan mikro-frontend.

Landasan paradigma tangkas adalah Agile Manifesto (2001), yang mendalilkan empat prinsip utama (misalnya, “Individu dan interaksi atas proses dan alat”) dan dua belas prinsip. Kerangka kerja proses seperti Scrum dan Scaled Agile Framework (SAFE) telah muncul di sekitar Agile Manifesto dan telah menemukan jalan mereka ke dalam praktik sehari-hari. Namun, filosofi di balik mereka sebagian besar disalahpahami atau diabaikan.

Dalam konteks arsitektur mikro-frontend, prinsip-prinsip tangkas berikut ini penting untuk dirangkul:

Komposisi dan ukuran tim

Agar tim perangkat lunak dapat menjalankan kepemilikan, ia harus mengatur dirinya sendiri, termasuk bagaimana dan apa yang diberikan tim, dalam batas-batas yang diberlakukan oleh organisasi.

Agar efektif, tim harus mampu memberikan perangkat lunak secara mandiri dan memiliki wewenang untuk memutuskan cara terbaik untuk mengirimkannya. Tim yang menerima persyaratan fitur dari manajer produk eksternal atau desain UI dari desainer eksternal, tanpa terlibat dalam perencanaan item ini, tidak dapat dianggap otonom. Fitur tersebut mungkin melanggar kontrak atau fungsionalitas yang ada. Pelanggaran semacam itu akan membutuhkan diskusi dan negosiasi lebih lanjut, dengan risiko menunda pengiriman dan memperkenalkan konflik yang tidak perlu antar tim.

Pada saat yang sama, tim tidak boleh menjadi terlalu besar. Sementara tim yang lebih besar memiliki lebih banyak sumber daya dan dapat mengakomodasi ketidakhadiran individu, kompleksitas komunikasi tumbuh secara eksponensial dengan setiap anggota baru. Tidak mungkin untuk menyatakan ukuran tim maksimum yang valid secara universal. Jumlah orang yang dibutuhkan untuk suatu proyek tergantung pada faktor-faktor seperti kematangan tim, kompleksitas teknis, laju inovasi, dan infrastruktur. Misalnya, Amazon mengikuti aturan dua pizza: Tim yang terlalu besar untuk diberi makan dua pizza harus dibagi menjadi tim yang lebih kecil. Itu bisa menjadi tantangan. Perpecahan harus terjadi di sepanjang batas-batas alami dan harus memberikan masing-masing tim otonomi dan kepemilikan atas pekerjaan mereka.

DevOps budaya

DevOps mengacu pada praktik rekayasa perangkat lunak di mana langkah-langkah siklus hidup pengembangan terintegrasi erat dari perspektif organisasi dan teknis. Berlawanan dengan kepercayaan populer, DevOps sangat banyak tentang budaya dan pola pikir, dan sangat sedikit tentang peran dan perkakas.

Secara tradisional, organisasi perangkat lunak akan memiliki tim spesialis, seperti untuk desain, implementasi, pengujian, penyebaran, dan operasi. Setiap kali tim menyelesaikan pekerjaan mereka, mereka akan menyerahkan proyek itu ke tim berikutnya. Namun, pengiriman perangkat lunak melalui silo tim khusus menyebabkan gesekan selama serah terima. Pada saat yang sama, ketika spesialis dipaksa untuk bekerja dengan fokus yang sempit, mereka tidak memiliki pengetahuan di domain tetangga, dan mereka tidak memiliki pandangan sistemik tentang produk. Defisit tersebut dapat menyebabkan koherensi produk perangkat lunak yang rendah.

Misalnya, ketika seorang arsitek perangkat lunak merancang solusi yang akan diterapkan oleh seseorang di tim yang berbeda, mereka mungkin mengabaikan aspek yang melekat pada implementasi (seperti ketidakcocokan ketergantungan). Pengembang kemudian mengambil jalan pintas (seperti patch monyet), atau back-and-forth diformalkan dimulai antara arsitek dan tim pengembangan. Karena overhead mengelola proses ini, pengembangan tidak lagi gesit (dalam arti fleksibel, adaptif, inkremental, dan informal).

Meskipun istilah ini DevOps terutama berkaitan dengan budaya, ini menyiratkan teknologi dan proses yang DevOps memungkinkan dalam praktik. DevOps berkaitan erat dengan CI/CD. Ketika pengembang telah selesai menerapkan peningkatan perangkat lunak, mereka mengkomitmenkannya ke sistem kontrol versi seperti Git. Secara tradisional, sistem build kemudian akan membangun dan mengintegrasikan perangkat lunak, dan mengujinya dan dirilis dalam proses yang kurang lebih terpadu dan terpusat. Dengan CI/CD, pembangunan, integrasi, pengujian, dan rilis perangkat lunak melekat dan otomatis. Idealnya, proses adalah bagian dari proyek perangkat lunak itu sendiri melalui file konfigurasi yang disesuaikan dengan proyek yang diberikan secara khusus.

Sebanyak mungkin langkah otomatis. Misalnya, praktik pengujian manual harus dikurangi, karena hampir semua jenis pengujian dapat diotomatisasi. Ketika proyek diatur dengan cara itu, pembaruan untuk produk perangkat lunak dapat dikirimkan beberapa kali setiap hari dengan keyakinan tinggi. Teknologi lain yang mendukung DevOps adalah infrastruktur sebagai kode (IAc).

Secara tradisional, menyiapkan dan memelihara infrastruktur TI akan membutuhkan pekerjaan manual untuk menginstal dan memelihara perangkat keras (menyiapkan kabel dan server di pusat data) dan perangkat lunak operasional. Ini perlu, tetapi memiliki banyak kelemahan. Pengaturan memakan waktu dan rawan kesalahan. Perangkat keras sering disediakan secara berlebihan atau kurang disediakan, yang mengarah pada pengeluaran berlebih atau kinerja yang menurun. Dengan menggunakan IAC, Anda dapat menjelaskan persyaratan infrastruktur untuk sistem TI melalui file konfigurasi dari mana layanan cloud dapat digunakan dan diperbarui secara otomatis.

Apa hubungannya semua ini dengan frontend mikro? DevOps, CI/CD, dan IAc adalah pelengkap ideal untuk arsitektur micro-frontend. Manfaat mikro-frontend bergantung pada proses pengiriman yang cepat dan tanpa gesekan. DevOps Budaya dapat berkembang hanya di lingkungan di mana tim memiliki proyek perangkat lunak dengan end-to-end tanggung jawab.

Mengatur pengembangan mikro-frontend di beberapa tim

Saat menskalakan pengembangan mikro-frontend di beberapa tim lintas fungsi, dua masalah muncul: Pertama, tim mulai mengembangkan interpretasi paradigma mereka sendiri, membuat pilihan kerangka kerja dan perpustakaan, dan membuat perpustakaan perkakas dan pembantu mereka sendiri. Kedua, tim yang sepenuhnya otonom harus bertanggung jawab atas kemampuan generik seperti manajemen infrastruktur tingkat rendah. Oleh karena itu, masuk akal untuk memperkenalkan dua tim tambahan dalam organisasi mikro-frontend multi-tim: tim pemberdayaan dan tim platform. Konsep-konsep ini diadopsi secara luas dalam organisasi TI modern dengan sistem terdistribusi dan didokumentasikan dengan baik dalam Topologi Tim.

Diagram berikut menunjukkan tim pemberdayaan yang menyediakan alat, pustaka, standar, dan pengujian untuk tiga tim mikro-frontend. Tim platform menyediakan infrastruktur, kemampuan runtime bersama, dan layanan domain untuk tiga tim micro-frontend yang sama.

Tim platform mendukung tim mikro-frontend dengan membebaskan mereka dari angkat berat yang tidak berdiferensiasi. Dukungan ini dapat mencakup layanan infrastruktur seperti runtime kontainer, pipeline CI/CD, alat kolaborasi, dan pemantauan. Namun, menyiapkan tim platform tidak boleh mengarah ke organisasi di mana pengembangan terlepas dari operasi. Yang sebaliknya adalah benar: Tim platform menawarkan produk teknik, dan tim micro-frontend memiliki kepemilikan dan tanggung jawab runtime atas layanan mereka di platform.

Tim pemberdayaan memberikan dukungan dengan berfokus pada tata kelola dan memastikan konsistensi di seluruh tim mikro-frontend. (Tim platform tidak boleh terlibat dengan ini.) Tim pemberdayaan mengelola sumber daya bersama seperti pustaka UI, dan menciptakan standar seperti pilihan kerangka kerja, anggaran kinerja, dan konvensi interoperabilitas. Pada saat yang sama, ini memberikan pelatihan kepada tim atau anggota tim baru dalam menerapkan standar dan perkakas sebagaimana didefinisikan oleh tata kelola.

Men-deploy

Bintang utara untuk otonomi dalam tim mikro-frontend adalah memiliki pipa otomatis dengan jalur produksi yang independen dari tim mikro-frontend lainnya. Tim yang mengikuti prinsip share-nothing dapat menerapkan jaringan pipa independen. Tim yang berbagi pustaka atau bergantung pada tim platform harus memutuskan cara mengelola dependensi dalam pipeline penerapan.

Biasanya, setiap pipa melakukan hal berikut:

Langkah-langkah pipeline sebenarnya bervariasi tergantung pada tumpukan teknologi dan pendekatan komposisi halaman.

Untuk komposisi sisi klien, ini berarti mengunggah bundel aplikasi ke bucket hosting, dan melepaskan ke konsumsi melalui caching di CDN. Aplikasi yang menggunakan cache browser dengan pekerja layanan juga harus menerapkan cara untuk memperbarui cache pekerja layanan.

Untuk komposisi sisi server, ini biasanya berarti menyebarkan versi baru komponen server dan memperbarui registri mikro-frontend untuk membuat versi baru dapat ditemukan. Anda dapat menggunakan pola penyebaran biru/hijau atau kenari untuk secara bertahap meluncurkan versi baru.