Saat melihat halaman sebelumnya, satu tema berulang: mengelola kode Anda sendiri cukup mudah, tetapi mengelola dependensinya akan lebih sulit. Ada berbagai jenis dependensi: terkadang ada dependensi pada tugas (seperti “push dokumentasi sebelum saya menandai rilis sebagai selesai”), dan terkadang ada dependensi pada artefak (seperti “Saya perlu memiliki library computer vision versi terbaru untuk mem-build kode saya”). Terkadang, Anda memiliki dependensi internal pada bagian lain codebase, dan terkadang Anda memiliki dependensi eksternal pada kode atau data yang dimiliki oleh tim lain (baik di organisasi Anda maupun pihak ketiga). Tapi bagaimanapun juga, gagasan tentang “Saya memerlukan itu sebelum saya dapat memiliki ini” adalah sesuatu yang berulang kali dalam sistem build, dan mengelola dependensi mungkin yang paling dasar sistem build.
Menangani Modul dan Dependensi
Project yang menggunakan sistem build berbasis artefak seperti Bazel dibagi menjadi kumpulan
modul, dengan modul yang mengekspresikan dependensi satu sama lain melalui file
BUILD. Pengaturan yang tepat dari modul dan dependensi ini
dapat memiliki dampak yang besar
berpengaruh pada kinerja sistem build dan berapa banyak pekerjaan yang diperlukan
pertahankan.
Menggunakan Modul yang Lebih Mendetail dan Aturan 1:1:1
Pertanyaan pertama yang muncul saat menyusun build berbasis artefak adalah
memutuskan seberapa banyak fungsi
yang harus disertakan dalam modul individu. Di Bazel,
modul direpresentasikan oleh target yang menentukan unit yang dapat di-build seperti
java_library atau go_binary. Di satu sisi ekstrem, seluruh project dapat
berisi dalam satu modul dengan menempatkan satu file BUILD di root dan
menggabungkan semua file sumber project tersebut secara rekursif. Di sisi lain,
hampir setiap file sumber dapat dibuat menjadi modulnya sendiri, yang secara efektif
memerlukan setiap file untuk mencantumkan setiap file lain yang menjadi dependensinya dalam file BUILD.
Sebagian besar proyek berada di antara titik ekstrem ini, dan pemilihannya melibatkan
kompromi antara performa
dan kemudahan pemeliharaan. Menggunakan satu modul untuk
keseluruhan project mungkin berarti Anda tidak perlu menyentuh file BUILD kecuali
saat menambahkan dependensi eksternal, tetapi itu berarti bahwa sistem build harus
selalu membangun
seluruh proyek sekaligus. Artinya, ia tidak akan dapat
memparalelkan atau mendistribusikan bagian-bagian build, serta tidak dapat meng-cache bagian
bahwa layanan tersebut sudah dibuat. Satu modul per file adalah kebalikannya: sistem build
memiliki fleksibilitas maksimum dalam menyimpan dalam cache dan menjadwalkan langkah-langkah build, tetapi
engineer perlu mengeluarkan lebih banyak upaya untuk mengelola daftar dependensi setiap kali
mereka mengubah file yang mereferensikan file mana.
Meskipun perincian yang tepat bervariasi menurut bahasa (dan bahkan sering dalam
bahasa), Google cenderung mendukung modul yang jauh lebih kecil daripada
yang biasanya ditulis dalam sistem
build berbasis tugas. Biner produksi yang umum di
Google sering kali bergantung pada puluhan ribu target, dan bahkan target berukuran sedang
dapat memiliki beberapa ratus target dalam codebase-nya. Untuk bahasa seperti
Java yang memiliki konsep bawaan pengemasan yang kuat, setiap direktori biasanya
berisi satu paket, target, dan file BUILD (Pants, sistem build lain
berdasarkan Bazel, menyebutnya sebagai aturan 1:1:1). Bahasa dengan konvensi pengemasan
yang lebih lemah sering kali menentukan beberapa target per file BUILD.
Manfaat target versi yang lebih kecil
benar-benar mulai terlihat dalam skala besar karena
menghasilkan build yang terdistribusi lebih cepat dan mengurangi kebutuhan untuk membangun ulang target.
Keuntungannya menjadi lebih menarik setelah pengujian masuk ke dalam gambar, karena
target yang lebih terperinci berarti sistem build dapat menjadi jauh lebih cerdas dalam
hanya menjalankan subset pengujian terbatas yang dapat terpengaruh oleh perubahan
tertentu. Karena Google percaya pada manfaat sistemik dari penggunaan yang lebih kecil
target, kami telah mengambil beberapa langkah dalam mengurangi sisi negatif dengan berinvestasi dalam
alat untuk mengelola file BUILD secara otomatis agar tidak membebani developer.
Beberapa alat ini, seperti buildifier dan buildozer, tersedia dengan
Bazel di
direktori buildtools.
Meminimalkan Visibilitas Modul
Bazel dan sistem build lainnya memungkinkan setiap target menentukan visibilitas —
properti yang menentukan target lain yang mungkin bergantung padanya. Target pribadi
hanya dapat direferensikan dalam file BUILD-nya sendiri. Target dapat memberikan visibilitas
yang lebih luas ke target daftar file BUILD yang ditentukan secara eksplisit, atau, dalam
hal visibilitas publik, ke setiap target di ruang kerja.
Seperti kebanyakan bahasa pemrograman, sebaiknya
meminimalkan visibilitas sebagai
sebanyak mungkin. Umumnya, tim di Google akan membuat target bersifat publik hanya jika
target tersebut mewakili perpustakaan yang banyak digunakan,
yang tersedia untuk tim mana pun di Google.
Tim yang mewajibkan orang lain untuk berkoordinasi dengan mereka sebelum menggunakan kode mereka akan
mempertahankan daftar yang diizinkan untuk target pelanggan sebagai visibilitas target mereka. Masing-masing
target implementasi internal tim akan dibatasi hanya untuk direktori
dimiliki oleh tim, dan sebagian besar file BUILD hanya akan memiliki satu target yang tidak
pribadi.
Mengelola dependensi
Modul harus dapat saling merujuk. Kelemahan dari merusak
menjadi modul terperinci adalah Anda perlu mengelola dependensi
di antara modul tersebut (meskipun alat dapat membantu mengotomatiskannya). Dengan menyatakan
dependensi biasanya menjadi bagian terbesar dari konten dalam file BUILD.
Dependensi internal
Dalam project besar yang dibagi menjadi modul terperinci, sebagian besar dependensi kemungkinan bersifat internal; yaitu, pada target lain yang ditentukan dan dibuat di repositori sumber yang sama. Dependensi internal berbeda dari dependensi eksternal di bahwa library tersebut dibuat dari sumber, bukan didownload sebagai artefak bawaan saat menjalankan build. Ini juga berarti bahwa tidak ada istilah “versi” untuk dependensi internal—target dan semua dependensi internalnya selalu dibangun pada commit/revisi yang sama dalam repositori. Salah satu masalah yang harus ditangani dengan cermat terkait dependensi internal adalah cara memperlakukan dependensi transitif (Gambar 1). Misalkan target A bergantung pada target B, yang bergantung pada target library umum C. Apakah target A dapat menggunakan class yang ditentukan di target C?
Gambar 1. Dependensi transitif
Selama alat yang mendasarinya, tidak ada masalah dengan hal ini; keduanya B dan C akan ditautkan ke target A ketika dibangun, jadi setiap simbol yang ditentukan dalam C dikenal oleh A. Bazel mengizinkan hal ini selama bertahun-tahun, tetapi seiring berkembangnya Google, kami mulai melihat masalah. Misalkan B difaktorkan ulang sehingga tidak lagi harus bergantung pada C. Jika dependensi B pada C kemudian dihapus, A dan target lain yang menggunakan C melalui dependensi pada B akan rusak. Secara efektif, dependensi menjadi bagian dari kontrak publiknya dan tidak pernah bisa ubah. Ini berarti ketergantungan yang diakumulasi seiring waktu dan dibangun di Google mulai melambat.
Google akhirnya menyelesaikan masalah ini dengan memperkenalkan model mode dependensi” di Bazel. Dalam mode ini, Bazel mendeteksi apakah target mencoba mereferensikan simbol tanpa bergantung padanya secara langsung dan, jika demikian, gagal dengan error dan perintah shell yang dapat digunakan untuk menyisipkan dependensi secara otomatis. Meluncurkan perubahan ini di seluruh codebase Google dan memfaktorkan ulang setiap jutaan target build untuk mencantumkan secara eksplisit dependensi adalah upaya yang berlangsung selama bertahun-tahun, tapi hal itu sangat bermanfaat. Build kami kini jauh lebih cepat karena target memiliki lebih sedikit dependensi yang tidak perlu, dan engineer diberi kemampuan untuk menghapus dependensi yang tidak mereka perlukan tanpa khawatir akan merusak target yang bergantung padanya.
Seperti biasa, menerapkan dependensi transitif yang ketat melibatkan kompromi. Hal ini membuat
file build lebih panjang, karena library yang sering digunakan kini perlu dicantumkan
secara eksplisit di banyak tempat, bukan ditarik secara insidental, dan engineer
perlu menghabiskan lebih banyak upaya untuk menambahkan dependensi ke file BUILD. Sejak saat itu
mengembangkan alat yang mengurangi toil ini dengan secara otomatis mendeteksi banyak
dependensi dan menambahkannya ke file BUILD tanpa developer apa pun
intervensi. Namun, bahkan tanpa alat seperti itu, komprominya sangat baik
sepadan dengan skala codebase: secara eksplisit menambahkan dependensi ke file BUILD
adalah biaya satu kali, tetapi berurusan dengan
dependensi transitif implisit dapat menyebabkan
masalah yang sedang berlangsung selama target build ada. Roti Bazel
menerapkan dependensi transitif yang ketat
kode Java secara default.
Dependensi eksternal
Jika tidak bersifat internal, dependensi harus bersifat eksternal. Dependensi eksternal adalah dependensi pada artefak yang di-build dan disimpan di luar sistem build. Tujuan dependensi diimpor langsung dari repositori artefak (biasanya diakses melalui internet) dan digunakan apa adanya dan bukan dibuat dari sumber. Salah satu perbedaan terbesar antara dependensi eksternal dan internal adalah dependensi eksternal memiliki versi, dan versi tersebut ada secara independen dari kode sumber project.
Pengelolaan dependensi otomatis versus manual
Sistem build dapat mengizinkan versi dependensi eksternal dikelola
secara manual atau otomatis. Jika dikelola secara manual, buildfile
secara eksplisit mencantumkan versi yang ingin didownload dari repositori artefak,
sering kali menggunakan string versi semantik seperti
1.1.4. Jika dikelola secara otomatis, file sumber akan menentukan rentang
versi yang dapat diterima, dan sistem build selalu mendownload versi terbaru. Misalnya,
Gradle memungkinkan versi dependensi dideklarasikan sebagai “1.+” untuk menentukan
bahwa versi minor atau patch dependensi dapat diterima selama
versi utamanya adalah 1.
Dependensi yang dikelola secara otomatis dapat memudahkan project kecil, tetapi biasanya menjadi penyebab masalah pada project dengan ukuran yang tidak biasa atau yang dikerjakan oleh lebih dari satu engineer. Masalahnya dengan sistem dependensi terkelola adalah Anda tidak memiliki kendali atas kapan versi diperbarui. Tidak ada cara untuk menjamin bahwa pihak eksternal tidak akan membuat update yang merusak (meskipun mereka mengklaim menggunakan pembuatan versi semantik), sehingga build yang berfungsi pada suatu hari mungkin rusak pada hari berikutnya tanpa cara mudah untuk mendeteksi perubahan atau untuk mengembalikannya ke status yang berfungsi. Bahkan jika bangunannya tidak rusak, dapat berupa perubahan perilaku atau kinerja halus yang mustahil untuk dilacak.
Sebaliknya, karena dependensi yang dikelola secara manual memerlukan perubahan kontrol sumber, dependensi tersebut dapat ditemukan dan di-roll back dengan mudah, dan Anda dapat mengambil versi lama repositori untuk mem-build dengan dependensi lama. Bazel mewajibkan versi semua dependensi ditentukan secara manual. Bahkan skala sedang, overhead pengelolaan versi manual sepadan dengan harganya stabilitas yang diberikannya.
Aturan Satu Versi
Versi {i>library<i} yang berbeda biasanya diwakili oleh artefak yang berbeda, Jadi secara teori tidak ada alasan bahwa versi berbeda dari sumber daya dependensi tidak dapat dideklarasikan keduanya dalam sistem build dengan nama yang berbeda. Dengan demikian, setiap target dapat memilih versi dependensi yang ingin digunakan. Hal ini menyebabkan banyak masalah dalam praktik, jadi Google memberlakukan Aturan Satu Versi untuk semua dependensi pihak ketiga di codebase kami.
Masalah terbesar dalam mengizinkan beberapa versi adalah dependensi diamond masalah performa. Misalkan target A bergantung pada target B dan pada v1 eksternal library. Jika target B difaktorkan ulang untuk menambahkan dependensi pada v2 library eksternal, target A akan rusak karena sekarang bergantung secara implisit pada dua versi berbeda dari pustaka yang sama. Secara efektif, tidak pernah aman untuk menambahkan dependensi baru dari target ke library pihak ketiga dengan beberapa versi, karena pengguna target tersebut mungkin sudah bergantung pada versi yang berbeda. Dengan mengikuti Aturan Satu Versi, konflik ini tidak akan terjadi—jika target menambahkan dependensi pada library pihak ketiga, dependensi yang ada akan sudah berada pada versi yang sama, sehingga keduanya dapat berdampingan dengan baik.
Dependensi eksternal transitif
Menangani dependensi transitif dari dependensi eksternal dapat hal ini sangat sulit. Banyak repositori artefak seperti Maven Central, artefak untuk menentukan dependensi pada versi tertentu dari artefak lain dalam repositori. Alat build seperti Maven atau Gradle sering kali mendownload setiap dependensi transitif secara rekursif secara default, yang berarti bahwa menambahkan satu dependensi dalam project Anda berpotensi menyebabkan puluhan artefak didownload secara total.
Ini sangat nyaman: ketika menambahkan dependensi pada {i>library<i} baru, akan kesulitan besar untuk melacak setiap dependensi transitif {i>library<i} dan menambahkan semuanya secara manual. Tapi ada juga kerugian besar: karena perbedaan bisa bergantung pada versi yang berbeda dari pustaka pihak ketiga yang sama, maka strategi selalu melanggar Aturan Satu Versi dan menyebabkan dependensi. Jika target Anda bergantung pada dua library eksternal yang menggunakan versi berbeda dari dependensi yang sama, tidak ada yang tahu mana yang akan Anda dapatkan. Hal ini juga berarti bahwa mengupdate dependensi eksternal dapat menyebabkan kegagalan yang tampaknya tidak terkait di seluruh codebase jika versi baru mulai menarik versi yang bertentangan dari beberapa dependensinya.
Karena alasan ini, Bazel tidak secara otomatis mengunduh dependensi transitif.
Sayangnya, tidak ada solusi praktis—alternatif Bazel adalah mewajibkan
file global yang mencantumkan setiap dependensi eksternal
repositori dan versi eksplisit yang digunakan untuk dependensi tersebut di seluruh
repositori. Untungnya, Bazel menyediakan
alat yang mampu secara otomatis
membuat file seperti itu yang berisi dependensi transitif dari satu set Maven
artefak. Alat ini dapat dijalankan sekali untuk membuat file WORKSPACE awal
untuk sebuah proyek, dan file tersebut kemudian
dapat diperbarui secara manual untuk menyesuaikan
dari setiap dependensi.
Sekali lagi, pilihan di sini adalah antara kemudahan dan skalabilitas. Kecil proyek mungkin lebih memilih untuk tidak perlu mengkhawatirkan pengelolaan dependensi transitif sendiri dan mungkin bisa menggunakan penggunaan transitif otomatis dependensi. Strategi ini menjadi kurang menarik karena organisasi ini dan codebase berkembang, konflik dan hasil yang tak terduga menjadi semakin sering dilakukan. Pada skala yang lebih besar, biaya pengelolaan dependensi secara manual jauh lebih kecil daripada biaya untuk menangani masalah yang disebabkan oleh pengelolaan dependensi otomatis.
Menyimpan hasil build dalam cache menggunakan dependensi eksternal
Ketergantungan eksternal paling sering disediakan oleh pihak ketiga yang mengeluarkan versi stabil dari library, mungkin tanpa menyediakan kode sumber. Beberapa organisasi mungkin juga memilih untuk menyediakan beberapa kode mereka sendiri sebagai artefak, sehingga memungkinkan bagian kode lain bergantung padanya sebagai pihak ketiga, bukan dependensi internal. Hal ini secara teoritis dapat mempercepat build jika artefak lambat dibangun tetapi cepat diunduh.
Namun, hal ini juga menimbulkan banyak {i>overhead<i} dan kompleksitas: seseorang harus bertanggung jawab untuk membangun setiap artefak itu dan menguploadnya ke artefak artefak, dan klien perlu memastikan bahwa mereka tetap diperbarui dengan ke versi terbaru. {i>Debugging<i} juga menjadi jauh lebih sulit karena perbedaan bagian-bagian dari sistem akan dibangun dari titik-titik yang berbeda di repositori, dan tidak ada lagi tampilan hierarki sumber yang konsisten.
Cara yang lebih baik untuk memecahkan masalah artefak yang membutuhkan waktu lama untuk dibangun adalah dengan menggunakan sistem pembangunan yang mendukung {i> cache<i} jarak jauh, seperti dijelaskan sebelumnya. Sungguh sistem build menyimpan artefak yang dihasilkan dari setiap build ke lokasi yang dibagikan kepada seluruh engineer, jadi jika developer bergantung pada artefak yang baru-baru ini dibuat oleh orang lain, sistem build akan otomatis mendownload alih-alih membangunnya. Hal ini memberikan semua manfaat performa yang bergantung langsung pada artefak sekaligus memastikan bahwa build konsisten seolah-olah selalu dibuat dari sumber yang sama. Ini adalah strategi yang digunakan secara internal oleh Google, dan Bazel dapat dikonfigurasi untuk menggunakan cache jarak jauh.
Keamanan dan keandalan dependensi eksternal
Bergantung pada artefak dari sumber pihak ketiga, berisiko secara inheren. Terdapat
risiko ketersediaan jika sumber pihak ketiga (seperti repositori artefak)
karena seluruh build mungkin akan berhenti jika tidak dapat didownload
dependensi eksternal. Terdapat juga risiko keamanan: jika sistem pihak ketiga
disusupi oleh penyerang, maka penyerang
dapat mengganti perangkat yang direferensikan
artefak dengan salah satu desainnya sendiri, yang memungkinkan mereka memasukkan kode arbitrer
ke dalam build Anda. Kedua masalah tersebut dapat dimitigasi dengan mencerminkan artefak apa pun yang Anda
butuhkan ke server yang Anda kontrol dan memblokir sistem build agar tidak mengakses
repositori artefak pihak ketiga seperti Maven Central. Konsekuensinya adalah
cermin ini membutuhkan usaha dan
sumber daya untuk dipelihara, jadi pilihan apakah akan
menggunakannya sering tergantung
pada skala proyek. Masalah keamanan juga dapat
dicegah sepenuhnya dengan sedikit overhead dengan mewajibkan hash setiap
artefak pihak ketiga untuk ditentukan di repositori sumber, sehingga menyebabkan build
gagal jika artefak dirusak. Alternatif lain yang sepenuhnya
menghindari masalah ini adalah dengan membeli dependensi project Anda. Ketika sebuah proyek
dependensinya, vendor ini memeriksanya ke dalam kontrol sumber bersama
kode sumber project Anda, baik sebagai sumber atau biner. Hal ini secara efektif berarti
bahwa semua dependensi eksternal project dikonversi menjadi dependensi
internal. Google menggunakan pendekatan ini secara internal, memeriksa setiap pihak ketiga
library yang dirujuk di seluruh Google ke dalam direktori third_party di root
pohon sumber Google. Namun, hal ini hanya berfungsi di Google karena sistem kontrol sumber Google
dibuat secara khusus untuk menangani monorepo yang sangat besar, sehingga
vendoring mungkin bukan opsi untuk semua organisasi.