Halaman ini membahas definisi sistem build, fungsi sistem build, alasan Anda harus menggunakan sistem build, serta alasan mengapa compiler dan skrip build bukanlah pilihan terbaik saat organisasi Anda mulai berkembang. Model ini ditujukan bagi developer yang tidak memiliki banyak pengalaman dengan sistem build.
Apa itu sistem build?
Pada dasarnya, semua sistem build memiliki tujuan sederhana: mengubah kode sumber yang ditulis oleh engineer menjadi biner yang dapat dieksekusi dan dapat dibaca oleh mesin. Sistem build tidak hanya untuk kode yang ditulis manusia, tetapi juga memungkinkan mesin membuat build secara otomatis, baik untuk pengujian maupun rilis ke produksi. Dalam organisasi yang terdiri dari ribuan engineer, biasanya sebagian besar build dipicu secara otomatis, bukan langsung oleh engineer.
Tidak bisakah saya menggunakan compiler?
Kebutuhan akan sistem build mungkin tidak segera terlihat. Sebagian besar engineer
tidak menggunakan sistem build sambil mempelajari cara membuat kode: sebagian besar memulai dengan memanggil alat
seperti gcc atau javac langsung dari command line, atau yang setara dalam
lingkungan pengembangan terintegrasi (IDE). Selama semua kode sumber berada dalam
direktori yang sama, perintah seperti ini berfungsi dengan baik:
javac *.java
Ini akan menginstruksikan compiler Java untuk mengambil setiap file sumber Java dalam direktori saat ini dan mengubahnya menjadi file class biner. Dalam kasus paling sederhana, itulah yang Anda butuhkan.
Namun, segera setelah kode diperluas, detailnya akan dimulai. javac cukup pintar
untuk melihat di subdirektori direktori saat ini guna menemukan kode yang
akan diimpor. Namun, LLM tidak dapat menemukan kode yang disimpan di bagian lain
sistem file (mungkin library yang digunakan bersama oleh beberapa project). Ia juga hanya tahu
cara membangun kode Java. Sistem besar sering melibatkan bagian yang berbeda yang ditulis dalam
berbagai bahasa pemrograman dengan web dependensi di antara bagian-bagian tersebut.
Artinya, tidak ada compiler untuk satu bahasa yang mungkin dapat membangun keseluruhan sistem.
Setelah Anda menangani kode dari beberapa bahasa atau beberapa unit kompilasi, pembuatan kode bukan lagi proses satu langkah. Sekarang Anda harus mengevaluasi apa yang menjadi dependensi kode dan mem-build bagian tersebut dalam urutan yang tepat, mungkin menggunakan rangkaian alat yang berbeda untuk setiap bagian. Jika ada perubahan dependensi, Anda harus mengulangi proses ini untuk menghindari ketergantungan pada biner yang sudah tidak berlaku. Untuk codebase yang berukuran sedang, proses ini dengan cepat menjadi membosankan dan rentan terhadap error.
Compiler juga tidak mengetahui cara menangani dependensi
eksternal, seperti file JAR pihak ketiga di Java. Tanpa sistem build,
Anda dapat mengelola ini dengan mendownload dependensi dari internet, menempelkannya
di folder lib di hard drive, dan mengonfigurasi compiler untuk membaca
library dari direktori tersebut. Seiring waktu, sulit untuk mempertahankan
update, versi, dan sumber dependensi eksternal ini.
Bagaimana dengan skrip shell?
Misalkan project hobi Anda dimulai dengan cukup sederhana sehingga Anda dapat mem-build-nya hanya menggunakan compiler, tetapi Anda mulai mengalami beberapa masalah yang dijelaskan sebelumnya. Anda mungkin masih merasa tidak memerlukan sistem build dan dapat mengotomatiskan bagian-bagian yang membosankan dengan menggunakan beberapa skrip shell sederhana yang menangani proses build dalam urutan yang benar. Cara ini membantu beberapa saat, tetapi segera Anda akan mulai menghadapi lebih banyak masalah:
Ini menjadi membosankan. Ketika sistem Anda tumbuh menjadi lebih kompleks, Anda mulai menghabiskan waktu yang hampir sama untuk mengerjakan skrip build seperti pada kode sebenarnya. Proses debug skrip shell sangat merepotkan, karena semakin banyak peretasan yang dilapiskan di atas satu sama lain.
Ini lambat. Untuk memastikan Anda tidak mengandalkan library lama secara tidak sengaja, skrip build harus mem-build setiap dependensi secara berurutan setiap kali Anda menjalankannya. Anda mempertimbangkan untuk menambahkan beberapa logika untuk mendeteksi bagian mana yang perlu di-build ulang, tetapi kedengarannya sangat rumit dan rentan error untuk skrip. Atau Anda berpikir untuk menentukan bagian mana saja yang perlu dibuat ulang, tetapi kemudian Anda kembali ke titik awal.
Kabar baik: sudah waktunya rilis! Sebaiknya cari tahu semua argumen yang perlu Anda teruskan ke perintah jar untuk membuat build akhir. Dan ingat cara menguploadnya dan mengirimkannya ke repositori pusat. Buat dan kirim pembaruan dokumentasi, serta kirimkan notifikasi kepada pengguna. Hmm, mungkin ini perlu skrip lain...
Gawat! {i>Hard drive<i} Anda rusak, dan sekarang Anda perlu membuat ulang seluruh sistem. Anda cukup pintar untuk menyimpan semua file sumber dalam kontrol versi, tetapi bagaimana dengan library yang Anda download? Bisakah Anda menemukan semuanya lagi dan memastikan semuanya memiliki versi yang sama dengan saat pertama kali Anda mendownloadnya? Skrip Anda mungkin bergantung pada alat tertentu yang diinstal di tempat tertentu—dapatkah Anda memulihkan lingkungan yang sama agar skrip berfungsi kembali? Bagaimana dengan semua variabel lingkungan yang telah Anda tetapkan sebelumnya agar compiler berfungsi dengan benar, lalu dilupakan?
Terlepas dari masalah-masalah tersebut, proyek Anda cukup berhasil sehingga Anda dapat mulai mempekerjakan lebih banyak engineer. Sekarang Anda menyadari bahwa tidak perlu bencana untuk masalah sebelumnya yang timbul—Anda harus melalui proses bootstrap yang menyakitkan yang sama setiap kali developer baru bergabung dengan tim Anda. Dan terlepas dari upaya terbaik Anda, masih ada perbedaan kecil dalam sistem setiap orang. Sering kali, apa yang berfungsi di komputer seseorang tidak berfungsi di komputer lain, dan setiap kali diperlukan waktu beberapa jam untuk men-debug jalur alat atau versi library untuk mencari tahu letak perbedaannya.
Anda memutuskan bahwa Anda perlu mengotomatiskan sistem build. Secara teori, hal ini semudah mendapatkan komputer baru dan menyiapkannya untuk menjalankan skrip build Anda setiap malam menggunakan cron. Anda masih perlu menjalani proses penyiapan yang menyakitkan, tetapi sekarang Anda tidak memiliki manfaat dari otak manusia yang mampu mendeteksi dan menyelesaikan masalah kecil. Setiap pagi saat login, Anda melihat bahwa build tadi malam gagal karena kemarin developer membuat perubahan yang bekerja pada sistem mereka, tetapi tidak berfungsi pada sistem build otomatis. Setiap kali melakukan perbaikan sederhana, tetapi hal tersebut sering terjadi sehingga Anda akhirnya menghabiskan banyak waktu setiap hari untuk menemukan dan menerapkan perbaikan sederhana ini.
Build menjadi semakin lambat seiring pertumbuhan project. Suatu hari, saat menunggu build selesai, Anda menatap dengan sedih desktop rekan kerja Anda yang sedang berlibur, dan berharap ada cara untuk memanfaatkan semua daya komputasi yang terbuang.
Anda mengalami masalah klasik tentang skala. Untuk satu developer yang mengerjakan maksimum beberapa ratus baris kode selama maksimum satu atau dua minggu (yang mungkin merupakan pengalaman developer junior yang baru lulus universitas sejauh ini), Anda hanya memerlukan compiler. Skrip mungkin dapat membawa Anda sedikit lebih jauh. Namun, segera setelah Anda perlu berkoordinasi dengan banyak developer dan mesinnya, skrip build yang sempurna pun belum cukup karena menjadi sangat sulit untuk memperhitungkan perbedaan kecil pada mesin tersebut. Pada tahap ini, pendekatan sederhana ini diuraikan dan sekarang saatnya berinvestasi dalam sistem build yang sebenarnya.