Pengembangan Terbuka Untuk Metodologi Aplikasi 12-Faktor – Bagaimana 12 prinsip dasar dapat membantu tim membangun aplikasi yang sangat skalabel dengan cepat dan efisien.
Metodologi Aplikasi 12-Faktor memberikan panduan untuk membangun aplikasi dalam jangka waktu singkat dan untuk membuatnya skalabel. Itu dibuat oleh pengembang di Heroku untuk digunakan dengan aplikasi Software-as-a-Service (SaaS), aplikasi web, dan kemungkinan aplikasi Communication-Platform-as-a-Service (CPaaS). https://www.premium303.pro/
Untuk mengatur proyek secara efektif dan mengelola aplikasi yang dapat diskalakan, metodologi Aplikasi 12-Faktor memiliki keunggulan yang kuat untuk pengembangan sumber terbuka.
Prinsip-Prinsip Metodologi Aplikasi 12 Faktor
Prinsip-prinsip metodologi Aplikasi 12-Faktor adalah aturan ketat yang bertindak sebagai blok pembangun untuk mengembangkan dan menerapkan aplikasi SaaS, dan tidak dibatasi oleh bahasa pemrograman atau database apa pun.
Satu Basis Kode Dilacak Dalam Kontrol Revisi, Banyak Penyebaran
Setiap aplikasi harus memiliki satu basis kode dengan beberapa lingkungan/penyebaran yang berbeda.
Pengembang tidak boleh mengembangkan basis kode lain hanya demi pengaturan di lingkungan yang berbeda. Lingkungan yang berbeda mewakili keadaan yang berbeda, tetapi lingkungan yang berbeda ini harus berbagi basis kode yang sama.
Lingkungan dapat dianggap sebagai cabang dalam konteks Sistem Kontrol Subversi seperti GitLab, tempat banyak proyek sumber terbuka disimpan. Misalnya, Anda dapat membuat satu repositori untuk aplikasi VoIP cloud bernama aplikasi VoIP di sistem kontrol versi pusat mana pun, lalu membuat dua cabang, pengembangan, dan staging, dengan “master” sebagai cabang rilis.
Mendeklarasikan dan Mengisolasi Dependensi Secara Eksplisit
Semua dependensi harus dideklarasikan. Aplikasi Anda mungkin bergantung pada alat atau pustaka sistem eksternal, tetapi tidak boleh ada ketergantungan implisit pada alat atau pustaka sistem. Aplikasi Anda harus selalu secara eksplisit mendeklarasikan semua dependensi dan versi yang benar.
Menyertakan dependensi dalam basis kode dapat menimbulkan masalah, terutama dalam proyek sumber terbuka di mana perubahan pada pustaka eksternal dapat menyebabkan kesalahan ke dalam basis kode. Misalnya, basis kode mungkin menggunakan pustaka eksternal tanpa secara eksplisit menyatakan ketergantungan ini atau versi mana.
Jika pustaka eksternal diperbarui ke versi yang lebih baru dan belum teruji, ini dapat menimbulkan masalah kompatibilitas dengan kode Anda. Basis kode Anda dilindungi dari masalah ini dengan deklarasi dependensi yang eksplisit dan versi yang benar.
Bergantung pada tumpukan teknologi, lebih baik menggunakan manajer paket untuk mengunduh dependensi pada sistem Anda masing-masing dengan membaca manifes deklarasi dependensi yang mewakili nama dan versi dependensi.
Simpan Konfigurasi di Lingkungan
Saat Anda perlu mendukung beberapa lingkungan atau klien, konfigurasi menjadi bagian penting dari sebuah aplikasi. Konfigurasi yang bervariasi antar penerapan harus disimpan dalam variabel lingkungan. Hal ini memudahkan untuk mengubah antara penerapan tanpa harus mengubah kode.
Untuk aplikasi sumber tertutup, prinsip ini bermanfaat, karena Anda tidak ingin informasi sensitif seperti informasi koneksi basis data, atau data rahasia lainnya, diberikan kepada publik. Namun, dalam pengembangan open source, detail ini bersifat terbuka.
Dalam hal ini, keuntungannya adalah Anda tidak perlu mengubah kode berulang kali. Anda cukup mengatur variabel sedemikian rupa sehingga Anda hanya perlu mengubah lingkungan agar basis kode Anda berjalan dengan sempurna.
Perlakukan Layanan Dukungan Sebagai Sumber Daya Terlampir
Semua layanan pencadangan (seperti database, penyimpanan eksternal, atau antrian pesan) diperlakukan sebagai sumber daya yang dilampirkan dan dilampirkan serta dilepaskan oleh lingkungan eksekusi. Dengan prinsip ini, jika lokasi atau detail koneksi layanan ini berubah, Anda tetap tidak perlu mengubah kodenya. Detailnya tersedia di konfigurasi sebagai gantinya.
Layanan pencadangan dapat dilampirkan atau dilepaskan dari penerapan dengan cepat. Misalnya, jika basis data erp berbasis cloud Anda tidak berfungsi dengan benar, pengembang harus dapat membuat server basis data baru yang dipulihkan dari cadangan terbaru tanpa perubahan apa pun pada basis kode.
Pisahkan Tahapan Build dan Run Secara Ketat
Aplikasi 12-Faktor memerlukan pemisahan yang ketat antara tahapan build, release, dan run.
- Tahap pertama adalah tahap pembuatan. Pada fase ini, kode sumber dirakit atau dikompilasi menjadi executable sambil juga memuat dependensi dan membuat aset. Setiap kali kode baru perlu di-deploy, fase build dimulai.
- Tahap kedua adalah tahap pelepasan. Pada fase ini, kode yang dihasilkan selama tahap build digabungkan dengan konfigurasi deployment saat ini. Rilis yang dihasilkan berisi build dan konfigurasi dan siap untuk segera dieksekusi di lingkungan eksekusi.
- Tahap ketiga adalah fase rundan merupakan tahap terakhir: aplikasi dijalankan di lingkungan eksekusi. Itu tidak boleh diinterupsi oleh tahap lain.
Dengan memisahkan tahapan ini secara ketat, kami menghindari kerusakan kode dan membuat pemeliharaan sistem jauh lebih mudah dikelola.
Jalankan Aplikasi Sebagai Satu atau Lebih Proses Tanpa Kewarganegaraan
Aplikasi dijalankan di lingkungan eksekusi sebagai kumpulan dari satu atau beberapa proses. Proses ini tidak memiliki kewarganegaraan, dengan data yang disimpan di layanan pendukung, seperti database.
Ini berguna untuk open source, karena pengembang yang menggunakan versi aplikasi dapat membuat penerapan multinode pada platform cloud mereka untuk skalabilitas. Data tidak bertahan di dalamnya, karena data akan hilang jika salah satu dari node tersebut mogok.
Layanan Ekspor Melalui Pengikatan Port
Aplikasi Anda harus bertindak sebagai layanan mandiri yang tidak bergantung pada aplikasi tambahan. Itu harus dapat diakses oleh layanan lain melalui URL, bertindak sebagai layanan. Dengan cara ini, aplikasi Anda dapat berfungsi sebagai sumber daya untuk aplikasi lain bila diperlukan. Dengan menggunakan konsep ini, Anda dapat membangun REST APIS.
Keluarkan Skala Melalui Model Proses
Juga dikenal sebagai prinsip konkurensi, prinsip ini menunjukkan bahwa setiap proses di aplikasi Anda harus dapat menskalakan, memulai ulang, atau mengkloning dirinya sendiri.
Alih-alih membuat proses menjadi lebih besar, pengembang dapat membuat beberapa proses dan mendistribusikan beban aplikasi mereka di antara proses tersebut. Pendekatan ini memungkinkan Anda membangun aplikasi untuk menangani beban kerja yang beragam dengan menetapkan setiap beban kerja ke jenis proses.
Maksimalkan Ketahanan Dengan Startup Cepat dan Shutdown yang Anggun
Aplikasi Anda harus dibangun di atas proses sederhana, sehingga pengembang dapat meningkatkan proses sambil tetap mengizinkan mereka untuk memulai ulang jika terjadi kesalahan. Ini membuat proses aplikasi sekali pakai.
Membangun aplikasi berdasarkan prinsip ini berarti penerapan kode yang cepat, penskalaan elastis yang cepat, lebih banyak kelincahan untuk proses rilis, dan penerapan produksi yang kuat. Semua ini sangat membantu dalam lingkungan pengembangan sumber terbuka.
Pertahankan Pengembangan, Pementasan, dan Produksi Semirip Mungkin
Tim yang mengerjakan proyek harus menggunakan sistem operasi, layanan pendukung, dan dependensi yang sama. Ini mengurangi kemungkinan munculnya bug, dan lebih sedikit waktu yang dibutuhkan untuk pengembangan.
Menerapkan prinsip ini ke dalam praktik dapat menjadi tantangan bagi proyek sumber terbuka karena sifat pengembangnya yang tersebar, yang mungkin tidak dapat berkomunikasi tentang sistem, layanan, dan dependensi yang mereka gunakan. Salah satu kemungkinan untuk mengurangi perbedaan ini adalah pedoman pengembangan yang menyarankan sistem operasi, layanan, dan dependensi apa yang akan digunakan.
Perlakukan Log Sebagai Aliran Acara
Log sangat penting untuk memecahkan masalah produksi atau memahami perilaku pengguna. Namun, Aplikasi 12-Faktor seharusnya tidak peduli dengan pengelolaan log.
Sebagai gantinya, itu harus mengarahkan entri log sebagai aliran peristiwa, yang ditulis sebagai keluaran standar, ke layanan terpisah untuk analisis dan pengarsipan. Teknologi otomatisasi proses robot (RPA) dapat berguna sebagai layanan pihak ketiga untuk memproses dan menganalisis log. Lingkungan eksekusi akan memutuskan bagaimana memproses aliran ini. Ini memberikan fleksibilitas dan kekuatan yang lebih besar untuk mengintrospeksi perilaku aplikasi.
Jalankan Tugas Admin/Manajemen Sebagai Proses Satu Kali
Prinsip ini tidak benar-benar terkait dengan pengembangan tetapi tentang manajemen aplikasi. Proses admin harus dijalankan di lingkungan yang identik dengan proses aplikasi yang berjalan lama secara reguler.
Dalam penerapan lokal, pengembang dapat menggunakan perintah shell langsung di dalam direktori checkout aplikasi untuk melakukan proses admin satu kali.