Halaman ini diterjemahkan oleh Cloud Translation API.

Sistem Build Berbasis Tugas

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

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 sebelumnya. Sebagian besar sistem build utama yang digunakan saat ini, seperti Ant, Maven, Gradle, Grunt, dan Rake, berbasis tugas. Sebagian besar sistem build modern mengharuskan engineer untuk membuat file build yang menjelaskan cara menjalankan build, bukan skrip shell.

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 ini ditulis dalam XML dan menentukan 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 ke perintah.) Setiap tugas menjalankan daftar kemungkinan perintah yang ditentukan oleh Ant, yang meliputi membuat dan menghapus direktori, menjalankan javac, dan membuat file JAR. Kumpulan perintah ini dapat diperluas oleh plugin yang disediakan pengguna untuk mencakup segala jenis logika. Setiap tugas juga dapat menentukan tugas yang menjadi dependensinya melalui atribut dependen. Dependensi ini membentuk grafik asiklik, seperti yang terlihat pada Gambar 1.

Gambar 1. Grafik asiklik yang menunjukkan dependensi

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

Memuat file bernama build.xml dalam direktori saat ini dan mengurainya untuk membuat struktur grafik yang ditampilkan dalam Gambar 1.
Mencari tugas bernama dist yang disediakan di command line dan mendapati bahwa tugas tersebut memiliki dependensi pada tugas bernama compile.
Mencari tugas bernama compile dan menemukan bahwa tugas tersebut memiliki dependensi pada tugas bernama init.
Mencari tugas bernama init dan menemukan bahwa tugas tersebut tidak memiliki dependensi.
Mengeksekusi perintah yang ditentukan dalam tugas init.
Mengeksekusi perintah yang ditentukan dalam tugas compile asalkan semua dependensi tugas tersebut telah dijalankan.
Mengeksekusi perintah yang ditentukan dalam tugas dist asalkan semua dependensi tugas tersebut telah dijalankan.

Pada akhirnya, kode yang dieksekusi oleh Ant saat menjalankan tugas dist setara dengan 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, kita telah mendapatkan banyak manfaat dengan melakukannya. Kita dapat membuat buildfile baru di direktori lain dan menautkannya bersama. Kita dapat dengan mudah menambahkan tugas baru yang bergantung pada tugas yang ada dengan cara yang arbitrer dan kompleks. Kita hanya perlu meneruskan nama satu tugas ke alat command line ant, dan alat tersebut akan menentukan semua yang perlu dijalankan.

Ant adalah perangkat lunak lawas, yang awalnya dirilis pada tahun 2000. Pada tahun-tahun berikutnya, alat lain seperti Maven dan Gradle telah berkembang di Ant dan pada dasarnya menggantikannya dengan menambahkan fitur seperti pengelolaan otomatis dependensi eksternal dan sintaksis yang lebih bersih tanpa XML. Namun, sifat dari sistem yang lebih baru ini tetap sama: mereka memungkinkan engineer untuk menulis skrip build dengan cara yang prinsip dan modular sebagai tugas, serta menyediakan alat untuk menjalankan tugas-tugas tersebut dan mengelola dependensi di antara tugas-tugas tersebut.

Sisi gelap dari sistem build berbasis tugas

Karena alat ini pada dasarnya memungkinkan engineer untuk menentukan skrip apa pun sebagai tugas, alat ini sangat canggih, sehingga Anda dapat melakukan hampir semua hal yang dapat Anda bayangkan dengannya. Namun, keunggulan tersebut memiliki kekurangan, dan sistem build berbasis tugas dapat menjadi sulit digunakan karena skrip build-nya menjadi lebih kompleks. Masalah dengan sistem tersebut adalah sistem tersebut sebenarnya memberikan terlalu banyak daya kepada engineer dan tidak cukup daya ke sistem. Karena sistem tidak mengetahui apa yang dilakukan skrip, performa akan terpengaruh karena cara tersebut harus sangat konservatif dalam menjadwalkan dan menjalankan langkah-langkah build. Dan tidak ada cara bagi sistem untuk mengonfirmasi bahwa setiap skrip berfungsi sebagaimana mestinya, sehingga skrip cenderung bertambah kompleks dan akhirnya menjadi hal lain yang memerlukan proses debug.

Kesulitan untuk memparalelkan 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 memparalelkan eksekusi tugas meskipun tampaknya sistem tersebut bisa melakukannya. Misalkan tugas A bergantung pada tugas B dan C. Karena tugas B dan C tidak memiliki dependensi satu sama lain, apakah aman untuk menjalankannya secara bersamaan sehingga sistem dapat lebih cepat sampai ke tugas A? Mungkin, jika mereka tidak menggunakan sumber daya yang sama. Namun, mungkin tidak—mungkin keduanya menggunakan file yang sama untuk melacak statusnya dan menjalankannya bersamaan akan menyebabkan konflik. Secara umum, tidak ada cara bagi sistem untuk mengetahui, jadi sistem harus berisiko konflik ini (yang menyebabkan masalah build yang jarang terjadi tetapi sangat sulit untuk di-debug), atau harus membatasi seluruh build agar berjalan pada satu thread dalam satu proses. Hal ini dapat sangat memboroskan mesin developer yang andal, dan sepenuhnya mengesampingkan kemungkinan mendistribusikan build ke beberapa mesin.

Kesulitan saat menjalankan build inkremental

Sistem build yang baik memungkinkan engineer untuk melakukan build inkremental yang andal sehingga perubahan kecil tidak mengharuskan seluruh codebase dibangun ulang dari awal. Hal ini sangat penting jika sistem build lambat dan tidak dapat paralelkan langkah-langkah build karena alasan yang disebutkan di atas. Namun sayangnya, sistem build berbasis tugas juga kesulitan di sini. Karena tugas dapat melakukan apa saja, secara umum tidak ada cara untuk memeriksa apakah tugas tersebut sudah dilakukan. Banyak tugas hanya mengambil satu set file sumber dan menjalankan compiler untuk membuat serangkaian biner, sehingga tidak perlu dijalankan ulang jika file sumber yang mendasarinya belum berubah. Namun tanpa informasi tambahan, sistem tidak dapat memastikannya mungkin tugas mendownload file yang dapat berubah, atau mungkin menulis stempel waktu yang mungkin berbeda setiap kali dijalankan. Untuk menjamin ketepatan, sistem biasanya harus menjalankan ulang setiap tugas selama setiap build. Beberapa sistem build mencoba mengaktifkan build inkremental dengan mengizinkan engineer untuk menentukan kondisi di mana tugas perlu dijalankan ulang. Terkadang hal ini dapat dilakukan, tetapi sering kali ini menjadi masalah yang jauh lebih rumit daripada yang terlihat. Misalnya, dalam bahasa seperti C++ yang memungkinkan file disertakan secara langsung oleh file lain, Anda tidak dapat menentukan seluruh kumpulan file yang harus dipantau untuk perubahan tanpa mengurai sumber input. Engineer sering kali mengambil pintasan, dan pintasan ini dapat menyebabkan masalah yang jarang terjadi dan menjengkelkan karena hasil tugas digunakan kembali meskipun seharusnya tidak. Jika hal ini sering terjadi, engineer akan membiasakan diri menjalankan clean sebelum setiap build untuk mendapatkan status baru, yang sepenuhnya menggagalkan tujuan memiliki build inkremental sejak awal. Mencari tahu kapan suatu tugas perlu dijalankan ulang sangat halus, dan merupakan pekerjaan yang lebih baik ditangani oleh mesin daripada manusia.

Kesulitan mengelola dan melakukan debug skrip

Terakhir, skrip build yang diterapkan oleh sistem build berbasis tugas sering kali hanya sulit untuk digunakan. Meskipun sering menerima lebih sedikit pemeriksaan, skrip build adalah kode seperti sistem yang sedang di-build, dan merupakan tempat yang mudah bagi bug untuk menyembunyikan bug. Berikut ini beberapa contoh bug yang sangat umum terjadi saat menggunakan sistem build berbasis tugas:

Tugas A bergantung pada tugas B untuk menghasilkan file tertentu sebagai {i>output<i}. Pemilik tugas B tidak menyadari bahwa tugas lain mengandalkannya, sehingga mereka mengubahnya untuk menghasilkan output di lokasi yang berbeda. Tindakan ini tidak dapat dideteksi sampai seseorang mencoba menjalankan tugas A dan menemukan bahwa tugas tersebut gagal.
Tugas A bergantung pada tugas B, yang bergantung pada tugas C, yang menghasilkan file tertentu sebagai output yang diperlukan oleh tugas A. Pemilik tugas B memutuskan bahwa tugas tersebut tidak perlu bergantung pada tugas C lagi, yang menyebabkan tugas A gagal meskipun tugas B sama sekali tidak peduli dengan tugas C.
Developer tugas baru secara tidak sengaja membuat asumsi tentang mesin yang menjalankan tugas, seperti lokasi alat atau nilai variabel lingkungan tertentu. Tugas ini berfungsi di komputer mereka, tetapi gagal setiap kali developer lain mencobanya.
Tugas berisi komponen nondeterministik, seperti mendownload file dari internet atau menambahkan stempel waktu ke build. Sekarang, orang-orang mendapatkan kemungkinan hasil yang berbeda setiap kali mereka menjalankan build, yang berarti bahwa engineer tidak akan selalu dapat mereproduksi dan memperbaiki kegagalan atau kegagalan satu sama lain yang terjadi pada sistem build otomatis.
Tugas dengan beberapa dependensi dapat membuat kondisi race. Jika tugas A bergantung pada tugas B dan tugas C, serta tugas B dan C memodifikasi file yang sama, tugas A akan mendapatkan hasil yang berbeda, bergantung pada tugas B dan C yang selesai lebih dahulu.

Tidak ada cara umum untuk menyelesaikan masalah performa, ketepatan, atau pengelolaan ini dalam framework berbasis tugas yang diuraikan di sini. Selama engineer dapat menulis kode arbitrer yang berjalan selama build, sistem tidak dapat memiliki cukup informasi untuk selalu dapat menjalankan build dengan cepat dan benar. Untuk mengatasi masalah ini, kita perlu mengambil alih beberapa kekuatan dari tangan engineer dan menyerahkannya kembali ke sistem serta mengonsep ulang peran sistem, bukan sebagai tugas yang berjalan, melainkan sebagai memproduksi artefak.

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