Manajemen Ketergantungan

Saat mempelajari halaman-halaman sebelumnya, satu tema berulang kali: mengelola kode Anda sendiri cukup mudah, tetapi mengelola dependensinya jauh lebih sulit. Ada segala macam dependensi: terkadang ada dependensi pada tugas (seperti "kirim dokumentasi sebelum saya menandai rilis sebagai selesai"), dan terkadang ada dependensi pada artefak (seperti "Saya perlu memiliki versi terbaru library computer vision untuk membuat kode saya"). Terkadang, Anda memiliki dependensi internal pada bagian lain codebase Anda, dan terkadang Anda memiliki dependensi eksternal pada kode atau data milik tim lain Namun, dalam kasus apa pun, gagasan "Saya memerlukannya sebelum dapat memiliki ini" adalah sesuatu yang berulang kali terjadi dalam desain sistem build, dan mengelola dependensi mungkin merupakan tugas yang paling dasar dari sistem build.

Menangani Modul dan Dependensi

Project yang menggunakan sistem build berbasis artefak seperti Bazel dibagi menjadi satu kumpulan modul, dengan modul yang menyatakan dependensi satu sama lain melalui file BUILD. Pengaturan yang tepat pada modul dan dependensi ini dapat berdampak besar pada performa sistem build dan jumlah pekerjaan yang diperlukan untuk memeliharanya.

Menggunakan Modul Halus dan Aturan 1:1:1

Pertanyaan pertama yang muncul saat menyusun build berbasis artefak adalah menentukan berapa banyak fungsi yang harus disertakan dalam setiap modul. Di Bazel, modul direpresentasikan oleh target yang menentukan unit yang dapat di-build seperti java_library atau go_binary. Pada satu titik yang ekstrem, seluruh project dapat ditampung dalam satu modul dengan menempatkan satu file BUILD di root dan secara rekursif menghimpun semua file sumber project tersebut. Di sisi lain, hampir setiap file sumber dapat dibuat menjadi modulnya sendiri, yang secara efektif mengharuskan setiap file dicantumkan dalam file BUILD setiap file lain yang menjadi dependensinya.

Sebagian besar project berada di antara hal-hal ekstrem ini, dan pilihan tersebut melibatkan kontra antara performa dan pemeliharaan. Dengan menggunakan satu modul untuk seluruh project, Anda tidak perlu menggunakan file BUILD kecuali saat menambahkan dependensi eksternal. Namun, ini berarti sistem build harus selalu mem-build seluruh project sekaligus. Artinya, SDK tidak akan dapat paralelkan atau mendistribusikan bagian-bagian build, juga tidak dapat meng-cache bagian-bagian yang sudah dibangun. Kebalikannya: sistem build memiliki fleksibilitas maksimum dalam meng-cache dan menjadwalkan langkah-langkah build, tetapi engineer perlu berusaha lebih keras untuk mempertahankan daftar dependensi setiap kali mereka mengubah referensi file mana.

Meskipun tingkat perincian yang tepat bervariasi menurut bahasa (dan sering kali dalam bahasa), Google cenderung mendukung modul yang jauh lebih kecil daripada yang biasanya ditulis dalam sistem build berbasis tugas. Biner produksi standar di Google sering kali bergantung pada puluhan ribu target, dan bahkan tim berukuran sedang dapat memiliki beberapa ratus target dalam codebase-nya. Untuk bahasa seperti Java yang memiliki konsep paket bawaan yang kuat, setiap direktori biasanya berisi satu file paket, target, dan BUILD (Pants, sistem build lain berdasarkan Bazel, menyebutnya aturan 1:1:1). Bahasa dengan konvensi pemaketan yang lebih lemah sering menentukan beberapa target per file BUILD.

Manfaat target build yang lebih kecil benar-benar mulai terlihat dalam skala besar karena menghasilkan build yang terdistribusi lebih cepat dan kebutuhan untuk mem-build ulang target menjadi lebih jarang. Keuntungannya menjadi lebih menarik setelah pengujian masuk ke dalam gambaran, karena target yang terperinci berarti bahwa sistem build dapat jauh lebih cerdas dalam menjalankan hanya subset pengujian terbatas yang dapat terpengaruh oleh perubahan tertentu. Karena Google percaya pada manfaat sistemik penggunaan target yang lebih kecil, kami telah membuat beberapa langkah dalam mengurangi kelemahannya 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 untuk menentukan visibilitas — yaitu properti yang menentukan target lain mana yang mungkin bergantung padanya. Target pribadi hanya dapat direferensikan dalam file BUILD-nya sendiri. Target dapat memberikan visibilitas yang lebih luas ke target dari daftar file BUILD yang ditentukan secara eksplisit, atau, dalam hal visibilitas publik, ke setiap target di ruang kerja.

Seperti sebagian besar bahasa pemrograman, sebaiknya minimalkan visibilitas sebanyak mungkin. Biasanya, tim di Google akan membuat target menjadi publik hanya jika target tersebut mewakili library yang digunakan secara luas yang tersedia bagi tim mana pun di Google. Tim yang mengharuskan orang lain untuk berkoordinasi dengan mereka sebelum menggunakan kode mereka akan mempertahankan daftar target pelanggan yang diizinkan sesuai 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 bersifat pribadi.

Mengelola Dependensi

Modul harus dapat merujuk satu sama lain. Kelemahan dari membagi codebase menjadi modul terperinci adalah Anda perlu mengelola dependensi di antara modul tersebut (meskipun alat dapat membantu mengotomatiskan hal ini). Mengekspresikan dependensi ini biasanya berakhir menjadi sebagian besar konten dalam file BUILD.

Dependensi internal

Dalam sebuah project besar yang dipecah menjadi modul-modul terperinci, sebagian besar dependensi kemungkinan bersifat internal; yaitu, pada target lain yang ditentukan dan dibangun di repositori sumber yang sama. Dependensi internal berbeda dengan dependensi eksternal karena di-build dari sumber, bukan didownload sebagai artefak bawaan saat menjalankan build. Ini juga berarti bahwa tidak ada gagasan tentang “versi” untuk dependensi internal—target dan semua dependensi internalnya selalu di-build pada commit/revisi yang sama dalam repositori. Salah satu masalah yang harus ditangani dengan hati-hati sehubungan dengan dependensi internal adalah cara menangani dependensi transitif (Gambar 1). Misalkan target A bergantung pada target B, yang bergantung pada target library umum C. Haruskah target A dapat menggunakan kelas yang ditentukan dalam target C?

Gambar 1. Dependensi transitif

Sejauh yang berkaitan dengan alat dasar, tidak ada masalah dengan hal ini; baik B maupun C akan ditautkan ke target A saat di-build, sehingga setiap simbol yang ditentukan dalam C diketahui oleh A. Bazel mengizinkan hal ini selama bertahun-tahun, tetapi seiring dengan perkembangan Google, kami mulai mengalami masalah. Misalkan B difaktorkan ulang sedemikian rupa sehingga tidak perlu lagi 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 pernah dapat diubah dengan aman. Ini berarti dependensi yang terakumulasi dari waktu ke waktu dan build di Google mulai melambat.

Google akhirnya menyelesaikan masalah ini dengan memperkenalkan "mode dependensi transitif yang ketat" di Bazel. Dalam mode ini, Bazel mendeteksi apakah target mencoba mereferensikan simbol tanpa bergantung padanya secara langsung, dan jika demikian, akan gagal dengan error serta perintah shell yang dapat digunakan untuk menyisipkan dependensi secara otomatis. Meluncurkan perubahan ini di seluruh codebase Google dan memfaktorkan ulang setiap dari jutaan target build kami untuk mencantumkan dependensi mereka secara eksplisit merupakan upaya multitahun, tetapi hal ini sangat sepadan. Build kami sekarang jauh lebih cepat mengingat target memiliki lebih sedikit dependensi yang tidak diperlukan, dan engineer diberdayakan untuk menghapus dependensi yang tidak mereka perlukan tanpa khawatir akan merusak target yang bergantung padanya.

Seperti biasa, penerapan dependensi transitif yang ketat memerlukan kompromi. Hal ini membuat file build menjadi lebih panjang, karena library yang sering digunakan kini harus dicantumkan secara eksplisit di banyak tempat, bukan secara tidak sengaja, dan engineer harus berupaya lebih keras untuk menambahkan dependensi ke file BUILD. Kami telah mengembangkan alat yang mengurangi toil ini dengan secara otomatis mendeteksi banyak dependensi yang hilang dan menambahkannya ke file BUILD tanpa intervensi developer. Namun, bahkan tanpa alat seperti itu, kami telah merasakan konsekuensinya sangat sepadan karena skala codebase: menambahkan dependensi secara eksplisit ke file BUILD hanya memerlukan biaya satu kali, tetapi menangani dependensi transitif implisit dapat menyebabkan masalah yang berkelanjutan selama target build masih ada. Bazel menerapkan dependensi transitif yang ketat pada kode Java secara default.

Dependensi eksternal

Jika dependensi bukan internal, dependensi harus eksternal. Dependensi eksternal adalah dependensi pada artefak yang dibuat dan disimpan di luar sistem build. Dependensi diimpor langsung dari repositori artefak (biasanya diakses melalui internet) dan digunakan apa adanya, bukan di-build dari sumber. Salah satu perbedaan terbesar antara dependensi eksternal dan internal adalah dependensi eksternal memiliki beberapa versi, dan versi tersebut tidak bergantung pada kode sumber project.

Manajemen 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 berbagai versi yang dapat diterima, dan sistem build akan selalu mendownload versi terbaru. Misalnya, Gradle mengizinkan versi dependensi dideklarasikan sebagai “1.+” untuk menentukan bahwa versi minor atau patch dari dependensi dapat diterima selama versi utamanya adalah 1.

Dependensi yang dikelola secara otomatis nyaman untuk project kecil, tetapi biasanya merupakan penyebab bencana pada project berukuran tidak umum atau yang sedang dikerjakan oleh lebih dari satu engineer. Masalah pada dependensi yang dikelola secara otomatis adalah Anda tidak dapat mengontrol kapan versi diupdate. Tidak ada cara untuk menjamin bahwa pihak eksternal tidak akan melakukan update yang dapat menyebabkan gangguan (bahkan jika mereka mengklaim menggunakan pembuatan versi semantik). Oleh karena itu, build yang berfungsi pada satu hari ke depan mungkin akan rusak pada hari berikutnya tanpa cara mudah untuk mendeteksi apa yang berubah atau melakukan roll back ke status kerja. Meskipun build tidak rusak, mungkin ada perubahan perilaku atau performa yang samar yang tidak mungkin dilacak.

Sebaliknya, karena dependensi yang dikelola secara manual memerlukan perubahan pada kontrol sumber, dependensi tersebut dapat dengan mudah ditemukan dan di-roll back, serta Anda dapat memeriksa versi repositori yang lebih lama untuk mem-build dengan dependensi yang lebih lama. Bazel mengharuskan versi semua dependensi ditentukan secara manual. Pada skala yang sedang, overhead pengelolaan versi manual sangat berharga untuk stabilitas yang diberikannya.

Aturan Satu Versi

Versi library yang berbeda biasanya direpresentasikan oleh artefak yang berbeda. Jadi, secara teori, tidak ada alasan jika versi berbeda dari dependensi eksternal yang sama tidak dapat dideklarasikan dalam sistem build dengan nama yang berbeda. Dengan begitu, setiap target dapat memilih versi dependensi yang ingin digunakan. Hal ini menyebabkan banyak masalah dalam praktiknya, sehingga Google menerapkan Aturan Satu Versi yang ketat untuk semua dependensi pihak ketiga di codebase kami.

Masalah terbesar saat mengizinkan beberapa versi adalah masalah dependensi diamond. Misalkan target A bergantung pada target B dan v1 dari library eksternal. Jika target B kemudian difaktorkan ulang untuk menambahkan dependensi pada v2 dari library eksternal yang sama, target A akan rusak karena sekarang target tersebut secara implisit bergantung pada dua versi berbeda dari library yang sama. Sebenarnya, menambahkan dependensi baru dari target ke library pihak ketiga dengan beberapa versi tidaklah aman, karena salah satu pengguna target tersebut mungkin sudah bergantung pada versi yang berbeda. Aturan Satu Versi membuat konflik ini tidak mungkin terjadi. Jika target menambahkan dependensi pada library pihak ketiga, semua dependensi yang ada sudah berada di versi yang sama, sehingga dependensi tersebut dapat berdampingan dengan senang hati.

Dependensi eksternal transitif

Berurusan dengan dependensi transitif dari dependensi eksternal bisa jadi sangat sulit. Banyak repositori artefak seperti Maven Central memungkinkan artefak menentukan dependensi pada versi tertentu artefak lain dalam repositori. Alat build seperti Maven atau Gradle sering kali mendownload setiap dependensi transitif secara default, yang berarti menambahkan satu dependensi dalam project Anda berpotensi menyebabkan puluhan artefak didownload secara total.

Cara ini sangat praktis: saat menambahkan dependensi pada library baru, akan sangat merepotkan jika Anda harus melacak setiap dependensi transitif library tersebut dan menambahkan semuanya secara manual. Namun, ada juga kelemahan besar: karena library yang berbeda dapat bergantung pada versi yang berbeda dari library pihak ketiga yang sama, strategi ini tentu melanggar Aturan Satu Versi dan menyebabkan masalah dependensi berlian. Jika target Anda bergantung pada dua library eksternal yang menggunakan versi berbeda dari dependensi yang sama, tidak ada yang tahu versi mana yang akan Anda dapatkan. Ini juga berarti bahwa mengupdate dependensi eksternal dapat menyebabkan kegagalan yang tampaknya tidak terkait di seluruh codebase jika versi baru mulai mengambil versi beberapa dependensinya yang bertentangan.

Karena alasan ini, Bazel tidak mendownload dependensi transitif secara otomatis. Dan, 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 dapat otomatis membuat file yang berisi dependensi transitif dari sekumpulan artefak Maven. Alat ini dapat dijalankan satu kali untuk membuat file WORKSPACE awal untuk sebuah project, dan file tersebut kemudian dapat diupdate secara manual untuk menyesuaikan versi setiap dependensi.

Namun sekali lagi, di sini ada satu pilihan antara kenyamanan dan skalabilitas. Project kecil mungkin lebih memilih untuk tidak perlu mengkhawatirkan pengelolaan dependensi transitif sendiri dan mungkin dapat menghindari penggunaan dependensi transitif otomatis. Strategi ini menjadi kurang menarik seiring dengan berkembangnya organisasi dan codebase, dan konflik serta hasil yang tidak terduga menjadi semakin sering terjadi. Pada skala yang lebih besar, biaya pengelolaan dependensi secara manual jauh lebih rendah daripada biaya untuk menangani masalah yang disebabkan oleh pengelolaan dependensi otomatis.

Menyimpan hasil build ke dalam cache menggunakan dependensi eksternal

Dependensi eksternal paling sering disediakan oleh pihak ketiga yang merilis versi library stabil, mungkin tanpa menyediakan kode sumber. Beberapa organisasi mungkin juga memilih untuk menyediakan beberapa kode mereka sendiri sebagai artefak, sehingga bagian kode lain dapat bergantung padanya sebagai pihak ketiga, bukan dependensi internal. Secara teoritis, hal ini dapat mempercepat build jika artefak di-build lambat tetapi cepat didownload.

Namun, hal ini juga menimbulkan banyak overhead dan kompleksitas: seseorang harus bertanggung jawab untuk membangun setiap artefak tersebut dan menguploadnya ke repositori artefak, dan klien perlu memastikan bahwa mereka selalu mendapatkan versi terbaru. Proses debug juga menjadi jauh lebih sulit karena bagian sistem yang berbeda akan di-build dari titik yang berbeda di repositori, dan tidak ada lagi tampilan hierarki sumber yang konsisten.

Cara yang lebih baik untuk menyelesaikan masalah artefak yang memerlukan waktu lama untuk di-build adalah dengan menggunakan sistem build yang mendukung caching jarak jauh, seperti yang dijelaskan sebelumnya. Sistem build tersebut 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 mendownloadnya, bukan mem-build-nya. Hal ini memberikan semua manfaat performa dari bergantungnya langsung pada artefak sambil tetap memastikan bahwa build akan tetap konsisten seolah-olah selalu di-build 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

Tergantung pada artefak dari sumber pihak ketiga sangat berisiko. Ada risiko ketersediaan jika sumber pihak ketiga (seperti repositori artefak) berhenti karena seluruh build Anda mungkin terhenti jika tidak dapat mendownload dependensi eksternal. Ada juga risiko keamanan: jika sistem pihak ketiga disusupi oleh penyerang, penyerang dapat mengganti artefak yang direferensikan dengan salah satu desain mereka sendiri, sehingga memungkinkan mereka memasukkan kode arbitrer ke dalam build Anda. Kedua masalah tersebut dapat dimitigasi dengan mencerminkan artefak yang Anda bergantung ke server yang Anda kontrol dan memblokir sistem build agar tidak mengakses repositori artefak pihak ketiga seperti Maven Central. Konsekuensinya, mirror ini membutuhkan upaya dan resource untuk mempertahankannya, sehingga pilihan untuk menggunakannya sering kali bergantung pada skala project. Masalah keamanan juga dapat dicegah sepenuhnya dengan overhead yang sedikit dengan mengharuskan hash setiap artefak pihak ketiga ditentukan di repositori sumber, menyebabkan build gagal jika artefak dirusak. Alternatif lain yang sepenuhnya menggantikan masalah ini adalah dengan vendor dependensi project Anda. Saat menyediakan dependensinya, project akan memeriksanya ke dalam kontrol sumber bersama dengan kode sumber project, baik sebagai sumber maupun biner. Ini secara efektif berarti semua dependensi eksternal project dikonversi menjadi dependensi internal. Google menggunakan pendekatan ini secara internal, yang memeriksa setiap library pihak ketiga yang dirujuk di seluruh Google ke dalam direktori third_party di root hierarki sumber Google. Namun, hal ini hanya berfungsi di Google karena sistem kontrol sumber Google dibuat secara khusus untuk menangani monorepo yang sangat besar, sehingga vendor mungkin bukan pilihan untuk semua organisasi.