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). Namun, ide “Saya memerlukannya sebelum saya bisa memiliki ini” adalah sesuatu yang berulang kali muncul dalam desain sistem build, dan mengelola dependensi mungkin adalah tugas yang paling mendasar dari sistem build.
Menangani Modul dan Dependensi
Project yang menggunakan sistem build berbasis artefak seperti Bazel dipecah menjadi satu set
modul, dengan modul yang mengekspresikan dependensi satu sama lain melalui 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. Pada satu ekstrem, seluruh proyek bisa
yang ada dalam satu modul dengan meletakkan satu file BUILD di root dan
secara rekursif menggabungkan semua
file sumber proyek itu. Di sisi lain
hampir setiap file sumber dapat dibuat
ke dalam modul sendiri, secara efektif
mengharuskan setiap file dicantumkan dalam file BUILD untuk setiap file lain yang menjadi dependensinya.
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 tingkat perincian yang tepat bervariasi menurut bahasa (dan sering kali bahkan dalam
bahasa), Google cenderung lebih menyukai 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 pengemasan bawaan yang kuat, setiap direktori biasanya
berisi satu paket, target, dan file BUILD (Celana, sistem build lain
menurut Bazel, menyebutnya 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 sistemis dari penggunaan target yang lebih kecil, kami telah melakukan beberapa langkah untuk memitigasi kelemahan 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 ke target daftar file BUILD yang ditentukan secara eksplisit, atau, di
visibilitas publik, ke setiap target di ruang kerja.
Seperti sebagian besar bahasa pemrograman, sebaiknya minimalkan visibilitas
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 mengharuskan orang lain berkoordinasi dengan mereka sebelum menggunakan kode mereka akan
mempertahankan daftar target pelanggan yang diizinkan sebagai visibilitas target mereka. Target
implementasi internal setiap tim akan dibatasi hanya untuk direktori
yang dimiliki oleh tim, dan sebagian besar file BUILD hanya akan memiliki satu target yang tidak
pribadi.
Mengelola dependensi
Modul harus dapat saling merujuk satu sama lain. Kelemahan dari merusak
menjadi modul terperinci adalah Anda perlu mengelola dependensi
di antara modul tersebut (meskipun alat dapat membantu mengotomatiskannya). Menyatakan dependensi
ini biasanya menjadi sebagian besar konten dalam file BUILD.
Dependensi internal
Dalam sebuah proyek besar yang dibagi menjadi modul-modul halus, sebagian besar dependensi mungkin bersifat internal; yaitu, pada target lain yang ditentukan dan dibuat dengan ke repositori sumber. Dependensi internal berbeda dengan dependensi eksternal karena dependensi internal dibuat dari sumber, bukan didownload sebagai artefak bawaan saat menjalankan build. Hal ini juga berarti tidak ada konsep “versi” untuk dependensi internal—target dan semua dependensi internalnya selalu di-build pada commit/revisi yang sama di repositori. Satu masalah yang harus diperhatikan ditangani dengan hati-hati sehubungan dengan dependensi internal, adalah bagaimana memperlakukan dependensi transitif (Gambar 1). Misalkan target A bergantung pada target B, yang bergantung pada target library umum C. Harus menargetkan A agar dapat menggunakan class yang didefinisikan dalam 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 mengizinkannya selama bertahun-tahun, tetapi seiring dengan berkembangnya Google, kami mulai menemukan masalah. Misalkan B difaktorkan ulang sedemikian rupa sehingga tidak lagi yang diperlukan untuk 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 target menjadi bagian dari kontrak publiknya dan tidak dapat diubah dengan aman. Ini berarti ketergantungan yang diakumulasi seiring waktu dan dibangun di Google mulai melambat.
Google akhirnya menyelesaikan masalah ini dengan memperkenalkan “mode dependensi transitip ketat” 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 kami untuk mencantumkan dependensinya secara eksplisit adalah upaya yang berlangsung selama beberapa tahun, tetapi hasilnya sangat sepadan. 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. Bazel
menerapkan dependensi transitif yang ketat
pada kode Java secara default.
Dependensi eksternal
Jika bukan internal, dependensi harus 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 pengelolaan versi dependensi eksternal
baik secara manual
maupun otomatis. Jika dikelola secara manual, buildfile
secara eksplisit mencantumkan versi yang
ingin diunduh dari repositori artefak,
sering kali menggunakan string versi semantik seperti
sebagai 1.1.4. Jika dikelola secara otomatis, file sumber menentukan rentang
yang dapat diterima, dan sistem pembangunan
selalu mengunduh 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 pada tetap mudah ditemukan dan di-roll back, serta memungkinkan periksa repositori versi lama untuk membangun dengan dependensi yang lebih lama. Bazel mengharuskan versi semua dependensi ditentukan secara manual. Bahkan pada skala sedang, overhead pengelolaan versi manual sangat sebanding dengan stabilitas yang diberikannya.
Aturan Satu Versi
Versi library yang berbeda biasanya diwakili oleh artefak yang berbeda, jadi secara teori tidak ada alasan mengapa versi yang berbeda dari dependensi eksternal yang sama tidak dapat dideklarasikan dalam sistem build dengan nama yang berbeda. Dengan begitu, setiap target dapat memilih versi dependensi mana yang ingin gunakan. 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. Ini juga berarti bahwa memperbarui dependensi eksternal dapat menyebabkan kegagalan yang tidak terkait di seluruh codebase jika versi baru mulai digunakan versi yang bertentangan dari beberapa dependensinya.
Karena alasan ini, Bazel tidak secara otomatis mengunduh dependensi transitif.
Dan, sayangnya, tidak ada solusi alternatif — alternatif Bazel adalah mengharuskan
yang mencantumkan setiap resource eksternal repositori
dependensi dan versi eksplisit yang digunakan
untuk dependensi itu di seluruh
repositori resource. 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 satu kali untuk membuat file WORKSPACE awal
untuk project, dan file tersebut kemudian dapat diperbarui secara manual untuk menyesuaikan versi
setiap dependensi.
Sekali lagi, pilihannya adalah antara kenyamanan dan skalabilitas. Project kecil mungkin lebih memilih untuk tidak perlu khawatir mengelola dependensi transitif sendiri dan mungkin dapat menggunakan dependensi transitif otomatis. Strategi ini menjadi semakin tidak menarik seiring berkembangnya organisasi dan codebase, serta konflik dan hasil yang tidak terduga menjadi semakin sering. Pada skala yang lebih besar, biaya pengelolaan dependensi secara manual jauh lebih murah daripada biaya untuk menangani masalah yang disebabkan oleh dependensi otomatis otomatisasi pengelolaan biaya.
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. Secara teoritis, hal ini dapat mempercepat build jika artefak lambat di-build, tetapi cepat didownload.
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. Proses debug juga menjadi jauh lebih sulit karena berbagai bagian sistem akan di-build dari berbagai titik di repositori, dan tidak ada lagi tampilan hierarki sumber yang konsisten.
Cara yang lebih baik untuk mengatasi masalah artefak yang memerlukan waktu lama untuk di-build adalah dengan menggunakan sistem build yang mendukung penyimpanan cache jarak jauh, seperti yang dijelaskan sebelumnya. Sistem build tersebut menyimpan artefak yang dihasilkan dari setiap build ke lokasi yang dibagikan ke seluruh engineer, sehingga jika developer bergantung pada artefak yang baru-baru ini dibuat oleh orang lain, sistem build akan otomatis mendownloadnya bukan membangunnya. Hal ini memberikan semua manfaat kinerja tergantung langsung pada artefak sambil tetap memastikan bahwa build konsisten seolah-olah mereka 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
bergantung pada server yang Anda kontrol dan memblokir akses sistem build
repositori artefak pihak ketiga seperti Maven Central. Namun, mirror ini memerlukan upaya dan resource untuk dikelola, sehingga pilihan untuk menggunakannya sering kali bergantung pada skala project. 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 proyek dikonversi menjadi
dependensi. 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.