Sistem Build Berbasis Tugas

Laporkan masalah Lihat sumber Nightly · 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Halaman ini membahas sistem build berbasis tugas, cara kerjanya, dan beberapa komplikasi yang dapat terjadi dengan sistem berbasis tugas. Setelah skrip shell, sistem build berbasis tugas adalah evolusi logis berikutnya dari pembangunan.

Memahami sistem build berbasis tugas

Dalam sistem build berbasis tugas, unit kerja dasar adalah tugas. Setiap tugas adalah skrip yang dapat menjalankan logika apa pun, dan tugas menentukan tugas lain sebagai dependensi yang harus dijalankan sebelum tugas tersebut. Sebagian besar sistem build utama yang digunakan saat ini, seperti Ant, Maven, Gradle, Grunt, dan Rake, berbasis tugas. Sebagai ganti skrip shell, sebagian besar sistem build modern mengharuskan engineer membuat file build yang menjelaskan cara melakukan build.

Ambil contoh ini dari Manual Ant:

<project name="MyProject" default="dist" basedir=".">
   <description>
     simple example build file
   </description>
   <!-- set global properties for this build -->
   <property name="src" location="src"/>
   <property name="build" location="build"/>
   <property name="dist" location="dist"/>

   <target name="init">
     <!-- Create the time stamp -->
     <tstamp/>
     <!-- Create the build directory structure used by compile -->
     <mkdir dir="${build}"/>
   </target>
   <target name="compile" depends="init"
       description="compile the source">
     <!-- Compile the Java code from ${src} into ${build} -->
     <javac srcdir="${src}" destdir="${build}"/>
   </target>
   <target name="dist" depends="compile"
       description="generate the distribution">
     <!-- Create the distribution directory -->
     <mkdir dir="${dist}/lib"/>
     <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file -->
     <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
   </target>
   <target name="clean"
       description="clean up">
     <!-- Delete the ${build} and ${dist} directory trees -->
     <delete dir="${build}"/>
     <delete dir="${dist}"/>
   </target>
</project>

Buildfile ditulis dalam XML dan mendefinisikan beberapa metadata sederhana tentang build beserta daftar tugas (tag <target> dalam XML). (Ant menggunakan kata target untuk mewakili tugas, dan menggunakan kata task untuk merujuk perintah.) Setiap tugas mengeksekusi daftar kemungkinan perintah yang ditentukan oleh Ant, yang di sini mencakup pembuatan dan penghapusan direktori, menjalankan javac, dan membuat file JAR. Kumpulan perintah ini dapat diperluas oleh plugin yang disediakan pengguna untuk mencakup semua jenis logika. Setiap tugas juga bisa menentukan tugas yang bergantung pada atribut dependen. Dependensi ini membentuk grafik acyclic, seperti yang terlihat pada Gambar 1.

Grafik akrilik yang menampilkan dependensi

Gambar 1. Grafik acyclic yang menunjukkan dependensi

Pengguna melakukan build dengan memberikan tugas ke alat command line Ant. Misalnya, saat pengguna mengetik ant dist, Ant akan melakukan langkah-langkah berikut:

  1. Memuat file bernama build.xml di direktori saat ini dan mengurainya untuk membuat struktur grafik yang ditampilkan pada Gambar 1.
  2. Mencari tugas bernama dist yang disediakan di command line dan menemukan bahwa tugas tersebut memiliki dependensi pada tugas bernama compile.
  3. Mencari tugas bernama compile dan menemukan bahwa tugas tersebut memiliki dependensi pada tugas bernama init.
  4. Mencari tugas bernama init dan menemukan bahwa tugas tersebut tidak memiliki dependensi.
  5. Menjalankan perintah yang ditentukan dalam tugas init.
  6. Menjalankan perintah yang ditentukan dalam tugas compile dengan mempertimbangkan bahwa semua dependensi tugas tersebut telah dijalankan.
  7. Menjalankan perintah yang ditentukan dalam tugas dist dengan mempertimbangkan bahwa semua dependensi tugas tersebut telah dijalankan.

Pada akhirnya, kode yang dieksekusi oleh Ant saat menjalankan tugas dist akan setara ke skrip shell berikut:

./createTimestamp.sh
mkdir build/
javac src/* -d build/
mkdir -p dist/lib/
jar cf dist/lib/MyProject-$(date --iso-8601).jar build/*

Jika sintaksis dihapus, buildfile dan skrip build sebenarnya tidak terlalu berbeda. Namun, kami telah memperoleh banyak manfaat dengan melakukan hal ini. Kita dapat membuat file build baru di direktori lain dan menautkannya. Kita dapat dengan mudah menambahkan tugas baru yang tergantung pada tugas yang ada dengan cara yang sewenang-wenang dan kompleks. Kita hanya perlu meneruskan nama satu tugas ke alat command line ant, dan alat ini akan menentukan semua yang perlu dijalankan.

Ant adalah software lama, yang awalnya dirilis pada tahun 2000. Alat lain seperti Maven dan Gradle telah meningkatkan Ant dalam beberapa tahun terakhir dan pada dasarnya mengganti Ant dengan menambahkan fitur seperti pengelolaan dependensi eksternal otomatis dan sintaksis yang lebih bersih tanpa XML. Namun, sifat sistem yang lebih baru ini tetap sama: sistem ini memungkinkan engineer menulis skrip build dengan cara yang berprinsip dan modular sebagai tugas serta menyediakan alat untuk menjalankan tugas tersebut dan mengelola dependensi di antara tugas tersebut.

Sisi gelap sistem build berbasis tugas

Karena alat ini pada dasarnya memungkinkan para insinyur menentukan skrip apa pun sebagai tugas, mereka sangat canggih, memungkinkan Anda untuk melakukan hampir apa pun yang bisa Anda bayangkan dengan mereka. Namun, kemampuan tersebut memiliki kelemahan, dan sistem build berbasis tugas dapat menjadi sulit digunakan seiring dengan semakin kompleksnya skrip build. Tujuan masalah pada sistem semacam itu adalah pada akhirnya sistem tersebut akan memberi banyak daya pada sistem teknisi dan tidak ada cukup daya ke sistem. Karena sistem tidak tahu apa yang dilakukan skrip, performa akan terpengaruh, karena harus sangat konservatif dalam cara menjadwalkan dan menjalankan langkah-langkah build. Selain itu, sistem tidak dapat mengonfirmasi bahwa setiap skrip melakukan hal yang seharusnya, sehingga skrip cenderung menjadi lebih kompleks dan akhirnya menjadi hal lain yang perlu di-debug.

Kesulitan dalam melakukan paralelisasi langkah-langkah build

Workstation pengembangan modern cukup canggih, dengan beberapa core yang mampu menjalankan beberapa langkah build secara paralel. Namun, sistem berbasis tugas sering kali tidak dapat melakukan paralelisasi eksekusi tugas meskipun tampaknya dapat melakukannya. Misalkan tugas A tergantung pada tugas B dan C. Karena tugas B dan C tidak saling bergantung satu sama lain, apakah aman untuk menjalankannya pada saat yang sama jadi bahwa sistem bisa lebih cepat menuju tugas A? Mungkin, jika mereka tidak menyentuh resource yang sama. Namun, mungkin tidak—mungkin keduanya menggunakan file yang sama untuk melacak statusnya dan menjalankannya secara bersamaan menyebabkan konflik. Secara umum, sistem tidak dapat mengetahuinya, sehingga sistem harus mengambil risiko konflik ini (menyebabkan masalah build yang jarang terjadi tetapi sangat sulit di-debug), atau harus membatasi seluruh build agar berjalan di satu thread dalam satu proses. Hal ini dapat menjadi pemborosan besar bagi mesin developer yang canggih, dan sepenuhnya menghilangkan kemungkinan mendistribusikan build di beberapa mesin.

Kesulitan saat melakukan build inkremental

Sistem build yang baik memungkinkan engineer melakukan build inkremental yang andal sehingga perubahan kecil tidak memerlukan seluruh codebase untuk di-build ulang dari awal. Hal ini sangat penting jika sistem build lambat dan tidak dapat memparalelkan langkah-langkah build karena alasan yang disebutkan di atas. Tapi sayangnya, sistem build berbasis tugas juga bermasalah di sini. Karena tugas dapat melakukan apa saja, secara umum, tidak ada cara untuk memeriksa apakah itu sudah dilakukan. Banyak tugas hanya mengambil kumpulan file sumber dan menjalankan compiler untuk membuat kumpulan biner; sehingga, tugas tersebut tidak perlu dijalankan ulang jika file sumber yang mendasarinya belum berubah. Namun, tanpa informasi tambahan, sistem tidak dapat mengatakannya pastinya—mungkin tugas tersebut mendownload file yang bisa diubah, atau mungkin menulis stempel waktu yang mungkin berbeda pada setiap operasi. Untuk menjamin ketepatan, sistem biasanya harus menjalankan kembali setiap tugas dalam setiap pembangunan. Agak besar sistem build mencoba mengaktifkan build inkremental dengan mengizinkan kondisi di mana tugas perlu dijalankan kembali. Terkadang hal ini bisa dilakukan, tetapi sering kali ini masalah yang jauh lebih rumit daripada yang terlihat. Misalnya, dalam bahasa seperti C++ yang memungkinkan file untuk disertakan langsung oleh file lain, tidak mungkin menentukan seluruh rangkaian file yang harus dipantau untuk melihat perubahan tanpa mengurai sumber input. Engineer sering kali mengambil jalan pintas, dan jalan pintas ini dapat menyebabkan masalah yang jarang terjadi dan menjengkelkan saat hasil tugas digunakan kembali meskipun tidak seharusnya. Jika hal ini sering terjadi, engineer akan memiliki kebiasaan menjalankan clean sebelum setiap build untuk mendapatkan status baru, yang benar-benar mengalahkan tujuan memiliki build inkremental di awal. Mencari tahu kapan suatu tugas perlu dijalankan kembali sangat halus, dan pekerjaan yang lebih baik ditangani oleh komputer daripada manusia.

Kesulitan mengelola dan men-debug skrip

Terakhir, skrip build yang diberlakukan oleh sistem build berbasis tugas sering kali hanya sulit untuk dikerjakan. Meskipun sering kali tidak terlalu diperiksa, skrip build adalah kode seperti sistem yang sedang dibuat, dan merupakan tempat yang mudah untuk menyembunyikan bug. Berikut adalah beberapa contoh bug yang sangat umum terjadi saat menggunakan sistem build berbasis tugas:

  • Tugas A bergantung pada tugas B untuk menghasilkan file tertentu sebagai output. Pemilik dari tugas B tidak menyadari bahwa tugas lain bergantung pada hal itu, jadi mereka mengubahnya menjadi menghasilkan {i>output<i} di lokasi yang berbeda. Ini tidak dapat dideteksi sampai seseorang mencoba menjalankan tugas A dan menemukan bahwa tugas itu gagal.
  • Tugas A tergantung pada tugas B, yang tergantung pada tugas C, yang menghasilkan {i>file<i} tertentu sebagai {i>output<i} yang diperlukan oleh tugas A. Pemilik tugas B memutuskan bahwa tugas tersebut tidak perlu lagi bergantung pada tugas C, yang menyebabkan tugas A gagal meskipun tugas B tidak peduli sama sekali dengan tugas C.
  • Developer tugas baru tidak sengaja membuat asumsi tentang komputer yang menjalankan tugas, seperti lokasi alat atau nilai variabel lingkungan tertentu. Tugas itu bekerja di komputer mereka, tetapi gagal kapan pun pengembang lain mencobanya.
  • Tugas berisi komponen nondeterministik, seperti mendownload file dari internet atau menambahkan stempel waktu ke build. Sekarang, orang-orang menjadi hasil yang berpotensi berbeda setiap kali mereka menjalankan build, artinya bahwa para insinyur tidak selalu dapat direproduksi dan memperbaiki kegagalan satu sama lain atau kegagalan yang terjadi pada sistem build otomatis.
  • Tugas dengan beberapa dependensi dapat membuat kondisi race. Jika tugas A tergantung pada tugas B dan tugas C, dan tugas B dan C keduanya memodifikasi , tugas A mendapatkan hasil yang berbeda tergantung pada tugas B dan C yang mana selesai lebih dahulu.

Tidak ada cara umum untuk menyelesaikan masalah performa, ketepatan, atau masalah pemeliharaan dalam kerangka kerja berbasis tugas yang diuraikan di sini. Selama engineer dapat menulis kode arbitrer yang berjalan selama build, sistem tidak dapat memiliki informasi yang cukup untuk selalu dapat menjalankan build dengan cepat dan benar. Untuk mengatasi masalah ini, kita perlu melepaskan beberapa kekuatan insinyur dan menyerahkannya kembali ke sistem dan menyusun ulang konsep peran sistem bukan sebagai menjalankan tugas, tetapi sebagai menghasilkan artefak.

Pendekatan ini menghasilkan pembuatan sistem build berbasis artefak, seperti Blaze dan Bazel.