Halaman ini membahas apa yang dimaksud dengan sistem build, apa fungsinya, mengapa Anda harus menggunakan sistem build, dan mengapa compiler serta skrip build bukan pilihan terbaik organisasi mulai berkembang. Ditujukan bagi developer yang tidak memiliki banyak dengan sistem build.
Apa itu sistem build?
Pada dasarnya, semua sistem build memiliki tujuan yang sederhana: mereka mengubah kode sumber yang ditulis oleh para insinyur ke dalam biner yang dapat dieksekusi yang dapat dibaca oleh mesin. Sistem build tidak hanya untuk kode yang ditulis manusia; mereka juga mengizinkan untuk membuat {i>build <i}secara otomatis, baik untuk pengujian atau rilis untuk produksi. Dalam sebuah organisasi dengan ribuan insinyur, adalah hal biasa sebagian besar build dipicu secara otomatis, bukan langsung oleh engineer.
Tidak bisakah saya hanya menggunakan compiler?
Kebutuhan akan sistem build mungkin tidak selalu terlihat jelas. Sebagian besar engineer
jangan gunakan sistem build sambil belajar coding: sebagian besar dimulai dengan memanggil alat
seperti gcc atau javac langsung dari command line, atau yang setara dalam
{i>Integrated Development Environment <i}(IDE). Selama semua kode sumber berada
direktori yang sama, perintah seperti ini
berfungsi dengan baik:
javac *.java
Ini menginstruksikan compiler Java untuk mengambil setiap file sumber Java di dan mengubahnya menjadi file kelas biner. Dalam kasus paling sederhana, ini adalah yang Anda butuhkan.
Namun, segera setelah kode diperluas, detail akan dimulai. javac termasuk pintar
untuk mencari di subdirektori
direktori saat ini guna menemukan kode untuk
impor. Tetapi kode tidak dapat menemukan kode yang disimpan di bagian lain dari
sistem file (mungkin library yang digunakan bersama oleh beberapa project). AI hanya mengetahui
cara membangun kode Java. Sistem besar sering kali melibatkan
bagian-bagian berbeda yang ditulis dalam
berbagai bahasa pemrograman dengan
web dependensi di antara bagian-bagian itu,
artinya tidak ada kompilator untuk satu bahasa
yang mungkin bisa membangun seluruh sistem.
Setelah Anda berurusan dengan kode dari beberapa bahasa atau beberapa kompilasi unit iklan, kode bangunan bukan lagi proses satu langkah. Sekarang Anda harus mengevaluasi apa yang kode Anda bergantung pada dan membangun potongan-potongan dalam urutan yang tepat, mungkin menggunakan seperangkat alat yang berbeda untuk setiap bagian. Jika ada dependensi yang berubah, Anda harus ulangi proses ini untuk menghindari tergantung pada biner yang sudah usang. Untuk codebase bahkan sedang, proses ini cepat menjadi membosankan dan rentan terhadap kesalahan.
Kompilator juga tidak mengetahui
apa pun tentang cara menangani
dependensi, seperti file JAR pihak ketiga di Java. Tanpa sistem build,
Anda dapat mengelolanya dengan mengunduh
dependensi dari internet, menempelkan
dalam folder lib di hard drive, lalu mengonfigurasi compiler untuk membaca
{i>library<i} dari direktori tersebut. Seiring waktu, sulit untuk mempertahankan
pembaruan, versi, dan sumber
dependensi eksternal ini.
Bagaimana dengan skrip shell?
Misalkan proyek hobi Anda dimulai dengan cukup sederhana sehingga Anda dapat membangunnya hanya menggunakan kompiler, tetapi Anda mulai mengalami beberapa masalah yang dijelaskan seperti yang telah dibahas sebelumnya. Mungkin Anda masih tidak berpikir bahwa Anda membutuhkan sistem build dan dapat mengotomatiskan hal-hal yang membosankan dengan menggunakan beberapa skrip {i>shell <i}sederhana yang menangani membangun hal-hal dalam urutan yang benar. Hal ini cukup membantu, tapi akan segera Anda mulai mengalami lebih banyak masalah:
Hal ini melelahkan. Ketika sistem Anda menjadi lebih kompleks, Anda mulai waktu yang hampir sama untuk mengerjakan skrip build Anda seperti pada kode aktual. {i>Debugging<i} skrip {i>shell<i} sangat menyakitkan, dengan semakin banyak peretasan yang ditempatkan di atas satu sama lain.
Ini terlalu pelan. Untuk memastikan Anda tidak secara tidak sengaja mengandalkan {i>library<i} yang sudah usang, Anda memiliki skrip build yang membangun setiap dependensi secara berurutan setiap kali Anda menjalankannya. Anda berpikir untuk menambahkan beberapa logika untuk mendeteksi bagian mana yang perlu dibuat ulang, tetapi kedengarannya sangat rumit dan rentan terhadap kesalahan penulisan. Atau Anda berpikir untuk menentukan bagian mana yang perlu dibangun ulang setiap kali, tetapi maka Anda kembali ke awal.
Kabar baik: kini saatnya merilis laporan! Lebih baik cari tahu semua argumen Anda harus meneruskan ke perintah {i>jar<i} untuk membuat build akhir Anda. Dan ingatlah, cara menguploadnya dan mengirimnya ke repositori pusat. Dan membangun dan mendorong pembaruan dokumentasi, dan mengirimkan notifikasi kepada pengguna. Baik, mungkin proses ini membutuhkan skrip lain...
Gawat! {i>Hard drive <i}Anda rusak, dan sekarang Anda harus membuat ulang seluruh sistem file. Anda cukup pintar untuk menyimpan semua file sumber dalam versi {i>control<i}, tetapi bagaimana dengan pustaka yang telah Anda unduh? Bisakah Anda menemukannya sekali lagi dan memastikan bahwa mereka memiliki versi yang sama seperti ketika Anda pertama kali mendownloadnya? Skrip Anda mungkin tergantung pada alat tertentu yang diinstal di tempat tertentu—dapatkah Anda memulihkan lingkungan yang sama sehingga skripnya berfungsi lagi? Bagaimana dengan semua variabel lingkungan yang Anda tetapkan lama agar kompiler bekerja dengan benar dan kemudian terlupakan?
Terlepas dari permasalahan tersebut, proyek Anda cukup sukses sehingga Anda dapat mulai mempekerjakan lebih banyak insinyur. Sekarang, Anda menyadari bahwa tidak perlu waktu lama untuk melakukan bencana timbulnya masalah sebelumnya—Anda harus mengalami hal yang sama proses bootstrap setiap kali pengembang baru bergabung dengan tim Anda. Dan meskipun Anda sudah berupaya sebaik mungkin, masih ada perbedaan kecil di masing-masing seseorang. Sering kali, apa yang bekerja dengan komputer seseorang tidak berfungsi ke situs lain, dan setiap kali dibutuhkan beberapa jam untuk men-debug jalur alat atau versi {i>library<i} untuk mengetahui perbedaannya.
Anda memutuskan bahwa Anda perlu mengotomatiskan sistem build. Secara teori, ini adalah semudah mendapatkan komputer baru dan menyiapkannya untuk menjalankan build Anda {i>script<i} setiap malam menggunakan {i>cron<i}. Kamu masih harus melewati masa sulit proses pengaturan, tetapi sekarang Anda tidak memiliki manfaat dari otak manusia mampu mendeteksi dan menyelesaikan masalah kecil. Sekarang, setiap pagi ketika Anda tiba Anda lihat bahwa build tadi malam gagal karena kemarin developer membuat perubahan yang berhasil pada sistem mereka tetapi tidak berhasil pada sistem sistem build. Setiap kali perbaikannya sederhana, tetapi hal itu sering terjadi sehingga Anda menghabiskan banyak waktu setiap hari untuk menemukan dan menerapkan model sejumlah perbaikan.
Build menjadi lebih lambat dan lebih lambat seiring pertumbuhan project. Suatu hari, sambil menunggu menyelesaikan pembangunan, Anda menatap dengan sedih ke desktop yang menganggur rekan kerja, yang sedang berlibur, dan berharap ada cara untuk memanfaatkan semua daya komputasi yang terbuang.
Anda telah menghadapi masalah klasik mengenai skala. Untuk satu pengembang yang bekerja di paling banyak beberapa ratus baris kode untuk paling lama satu atau dua minggu (yang mungkin adalah keseluruhan pengalaman sejauh ini sebagai pengembang junior yang baru saja lulus universitas), Anda hanya membutuhkan sebuah kompiler. Skrip mungkin dapat membawa Anda sedikit lebih jauh. Tetapi segera setelah Anda perlu berkoordinasi dengan beberapa pengembang dan komputer mereka, bahkan skrip pembangunan yang sempurna saja tidak cukup karena menjadi sulit untuk memperhitungkan perbedaan kecil pada komputer tersebut. Pada tahap ini, pendekatan sederhana ini rusak dan sekarang waktunya untuk berinvestasi dalam sistem {i>build<i} nyata.