Lima Faedah Utama Mempraktekkan Integrasi Berkesinambungan
Bekerja di perusahaan yang mengembangkan aplikasi atau mengerjakan perangkat lunak? Pastinya pernah mendengar yang namanya Continuous Integration atau disingkat sebagai CI (diucapkan: see-eye) atau yang cocok diterjemahkan sebagai Integrasi Berkesinambungan. Mengapa praktek CI ini sering digadang-gadang sebagai alat bantu untuk menghasilkan rekayasa perangkat lunak yang paripurna? Simak lebih lanjut.
Definisi yang ciamik dari CI adalah yang pernah dikemukakan oleh tokoh termasyur dalam dunia software, Martin Fowler:
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily — leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.
Berlandaskan pendapat Pak Martin di atas, kita bisa maknakan bahwa Integrasi Berkesinambungan adalah sebuah pendekatan yang mendorong tiap engineer untuk mengintegrasikan pekerjaan mereka (implementasi fitur baru, memperbaiki masalah, memoles dokumentasi, dll) sesering mungkin. Dalam dunia Git, hal ini berarti menghindarkan pembuatan cabang (branch) yang semakin menjauh dari cabang utamanya (misalnya master).
Kunci dari praktek integrasi berkesinambungan adalah mekanisme yang otomatis untuk mendeteksi dan melacak kesalahan integrasi seawal mungkin. Misalnya, jika tidak ada sistem yang akan melakukan proses kompilasi dan tes dengan otomatis, tanpa campur tangan si engineer, maka akan mustahil untuk sepenuhnya mengikut aliran integrasi berkesinambungan.
Bila kita menyiman proyek-proyek open-source yang sangat ngetop, mulai dari TypeScript hingga React ataupun Laravel, semuanya dilengkapi dengan CI. Untuk proyek yang kode sumbernya diletakkan di GitHub, lazimnya ini dipasangkan dengan Travis CI, salah satu sistem CI yang bisa digunakan secara cuma-cuma untuk proyek open-source. Selain Travis CI, ada juga misalnya Circle CI, AppVeyor, dan Azure Pipelines.
Mengapa kita wajib memikirkan strategi integrasi berkesinambungan? Berikut ringkasan lima faedahnya.
#1: Anti Khilaf
Developer juga manusia! Karenanya, emosinya bisa naik turun, hati tidak senantiasa tentram 100%, kadang teledor atau terlena, suka baper, gundah gulana karena diputusin pacar, gebetan nggak perhatian, atau cekcok sama mertua. Atau misalnya MU kalah lagi. Ataupun lagi pusing cari tiket mudik. Dan seribu satu masalah lainnya.
Akhirnya sang developer pun khilaf. Membuat kesalahan. Kadang sederhana dan remeh, tapi sesekali juga fatal. Nggak bisa di-compile tapi main commit aja. Ada merge conflict belum dibetulkan, tapi hajar terus proses check-in-nya. Dependency baru lupa dijebloskan ke package.json. Bikin fitur baru nggak pakai unit test (UT) sama sekali. Lebih parah lagi, gagal UT tapi main jebret paksa masuk terus ke repositori.
Dengan memanfaatkan filosofi integrasi berkesinambungan, persoalan itu dapat dicegah secara dini. Berbagai macam bentuk pengecekan, apakah itu proses kompilasi ataupun linter, bisa diberlakukan sebagai gerbang integrasi. Walhasil, kalau ada engineer yang membuat pull request (permintaan tarik, atau adakah istilah bahasa Indonesia yang lebih bagus?) tetapi isinya berantakan (gagal compile, unit test nggak lolos, dll), sudah pasti cabang fitur tersebut harus dibenahi dulu, tidak bisa langsung diintegrasikan ke cabang utama. Dengan kata lain, bisa diyakinkan bahwa cabang utama akan selalu sehat sentosa karena terlindungi dari masuknya fitur-fitur baru yang sebenarnya belum siap.
#2: Jaminan Konsistensi
Yang namanya laptop si developer, kadang nggak jelas lagi isinya apa. Instal sana, instal sini. Perawatannya suka dinomorduakan (atau lebih parah, entah nomor berapa). Bahkan terkadang pustaka sistem atau sistem operasinya pun termutakhirkan, baik dengan sengaja maupun otomatis di belakang layar. Karenanya, sesekali terjadi situasi yang menyebabkan ketidaksinkronan dengan setup yang dikehendaki. Bayangkan kalau aplikasi yang lagi di-compile bagus-bagus aja kalau dicoba di laptop, tapi begitu mau deploy, ternyata parah luar biasa. Bagaimana kita berupaya menghindarkan situasi seperti ini?
Untunglah ada sistem CI yang akan memastikan bahwa apa yang jalan lancar jaya di laptop seorang engineer juga bisa dikerjakan di lingkungan bersih dan murni, karena lazimnya, apapun proses integrasi otomatis yang dimandatkan harus bisa dieksekusi oleh agen CI di sandbox yang relatif sangat terawat. Kalau terjadi ketidaksepakatan antara laptop developer dan sistem CI, hampir bisa dipastikan masalahnya ada di laptop si developer. Lepas dari gejala ini, situasinya patut diselidiki karena kalau sudah tidak konsisten antara dua sistem yang berbeda tapi mestinya sama (laptop vs CI), ada kemungkinan besar kekacauan dan tidak terjadi rujuk antara satu laptop dengan laptop yang lainnya juga.
#3. Rujukan Resmi
Karena integrasi berkesinambungan memaksa berbagai macam otomatisasi, termasuk proses menyiapkan dan melakukan kompilasi, hal ini cocok sekali dijadikan rujukan resmi. Misalnya ada developer baru yang bergabung untuk mengerjakan proyek tersebut, tidak akan terlalu repot lagi mengarahkan dan mengajarkan developer tersebut proses build-nya seperti apa, menjalankan tes bagaimana, dan seterusnya. Si developer baru bisa melongok si agen CI, melihat log-nya, dan mencoba menduplikat prosesnya di laptop dia sendiri.
Cara ini bahkan dapat menggantikan dokumentasi yang terpisah. Masalah terbesar dokumentasi yang diletakkan jauh dari repository (misalnya di Google Docs, wiki, ataupun sistem lainnya) adalah keakuratannya menurun seiring perjalanan waktu. Kadang ada dependency baru yang berubah atau ditambah, tapi dokumentasi belum sempat diperbaharui. Sementara itu, proses dari CI yang selalu aktual dan berjalan setiap saat dijamin lebih resmi.
Bila ada teman-teman yang ingin mengeksplorasi sebuah proyek open-source di luar sana yang sedang populer, akan sangat membantuk begitu konfigurasi CI-nya diamati dengan seksama. Karena, si berkas konfigurasi tersebut akan menayangkan proses kompilasi, tes, pengemasan, dan lain sebagainya. Jadi kalau baru pertama kali akan ngoprek, kita tiru saja mentah-mentah. Kalau itu sudah jalan, nah mudah bagi kita untuk beranjak ke langkap pengoprekan berikutnya. Tapi kalau dokumentasi tidak lengkap atau tidak ada yang bisa menjelaskan cara terjun ngopreknya, akan berat sekali!
#4. Pengecekan yang Intensif
Meningkatkan kualitas sebuah perangkat lunak dapat dikerjakan dengan memaksa agar standarnya benar-benar tinggi, dari sejak dini. Contohnya, tidak cukup UT harus ada tiap kali fitur baru dilahirkan, tapi bisa nggak kita ukur dan lacak terus code coverage-nya sehingga tidak pernah kurang dari batasan tertentu (sesuai kesepakatan). Ada lagi tim yang mewajibkan coding style yang baku sehingga tidak ada kepusingan di mana mesti meletakkan tanda kurung, tanda koma, spasi, dll, supaya menghasilkan keseragaman.
Dalam keseharian dan kesibukan mengembangkan satu fitur baru, mungkin yang seperti tidak selalu sempat terkerjakan oleh si engineer. Akan tetapi, dengan adanya integrasi berkesinambungan, berbagai parameter kualitas kodenya bisa selalu dipantau.
Ada aplikasi yang sifat lintasnya platform, walaupun developernya sedang asyik pakai Linux, tapi jangan sampai rusak compile kalau di Windows. Demikiannya halnya situasi untuk pengembangan mobile app, Android vs iOS. Kadang si developer terlalu fokus mengerjakan bagian Android-nya(dan tidak selalu memeriksa apakah jalan mulus di iOS (atau sebaliknya). Hal ini bisa diatasi dengan integrasi berkesinambungan yang dipersenjatai dengan berbagai macam pengecekan dan pengukuhan kualitas secara intensif.
#5. Arsip dan Riwayat
Kemarin jalan kok sekarang berantakan lagi? Hal seperti ini sering terjadi dan sulit dihindari. Tanpa sistem CI yang bisa menyimpan semua riwayat proses integrasi (tiap commit dan bahkan juga tiap PR), akan berat untuk melacak akar masalahnya. Dengan penyimpanan rinci hasil proses integrasi tiap revisi, maka langkah-langkah untuk mengidentifikasi penyebab kasus yang berantakan itu akan dimudahkan.
Juga bila sistem CI dirancang agar hasil integrasi, misalnya artefak proses kompilasi, bisa diarsipkan dan diambil sewaktu-waktu. Misalnya rekan QA bingung karena fitur baru sudah jalan bagus di build 42 tapi kok crash terus di build 51, nah simpan artefak yang lama, baik build 42 ataupun semua build antara 42 dan 51, bisa dimanfaatkan untuk mengisolasi asal muasal crash tersebut. Bayangkan kalau artefaknya tidak disimpan, repot kan harus compile lagi satu per satu!
Moga-moga tulisan ringkas ini sanggup memberikan wacana tentang pentingnya memikirkan, menjalankan, dan memelihara filosofi integrasi berkesinambungan untuk mendongkrak proses pengembangan perangkat lunak yang serius dan profesional. Mari kita terus berkarya!
P.S. Jika teman-teman menyukai artikel semacam ini, silakan subscribe ke newsletter kita dan dapatkan notifikasi artikel terbaru langsung di inbox kamu!
