CI/CD, Dijelaskan untuk Orang yang Membayar Proyeknya

Kalau Anda melihat "CI/CD" di penawaran teknis, yang dimaksud adalah pengecekan dan pengiriman otomatis. Setiap kali developer menyimpan perubahan ke kode bersama, serangkaian pemeriksaan jalan sendiri. Kalau pemeriksaannya lolos, perubahan itu langsung naik ke server dan bisa dibuka lewat link.

Yang berubah untuk Anda adalah apa yang bisa Anda lihat sendiri. Tanpa pengaturan ini, kemajuan proyek hanya bisa dibaca dari laporan status. Dengan pengaturan ini, Anda membuka link dan mencobanya.

Arti dua istilah itu

Integration, bagian CI, artinya penggabungan kode. Misalnya dua developer mengerjakan satu aplikasi pemesanan. Yang satu memperbaiki form booking, yang lain mengubah cara hitung total tagihan. Setiap kali salah satu menyimpan pekerjaannya ke kode bersama, komputer menjalankan pemeriksaan untuk memastikan perubahan itu tidak merusak bagian yang sudah jalan.

Delivery, bagian CD, artinya jalan dari pemeriksaan yang lolos sampai software benar-benar berjalan di server. Perubahan di form booking tadi tidak menunggu siapa pun mengunggahnya secara manual. Begitu lolos, perubahan itu ada di alamat yang bisa Anda buka beberapa menit kemudian.

Dua hal ini biasanya disiapkan sekali di awal proyek, lalu jalan terus tanpa diurus lagi. Di penawaran, rangkaiannya kadang disebut pipeline.

Hari rilis yang digantikan

Dulu pekerjaan menumpuk lebih dulu. Developer mengerjakan banyak hal selama beberapa minggu di komputer masing-masing. Semuanya disatukan mendekati tanggal rilis, lalu diunggah ke server dalam satu malam panjang.

Kalau ada yang rusak pada malam itu, tidak ada yang tahu bagian mana penyebabnya. Puluhan perubahan masuk bersamaan dan semuanya tersangka. Menelusurinya memakan waktu berhari-hari, dan selama itu software Anda tidak bisa dipakai.

Ongkosnya untuk Anda muncul lebih awal dari itu. Selama berminggu-minggu tidak ada apa pun yang bisa dicoba. Lalu hal pertama yang Anda lihat juga hal pertama yang gagal, di depan staf yang sudah dikumpulkan untuk pelatihan. Dari situ Anda terpaksa memutuskan buru-buru: ditunda, atau dipakai apa adanya.

Apa yang jalan setiap kali ada perubahan

Urutannya kurang lebih tiga langkah, dan semuanya otomatis.

Pertama, tes pada logikanya. Kalau aturannya "diskon hanya berlaku di atas nilai pesanan tertentu", ada pemeriksaan yang mencoba beberapa angka dan memastikan hasilnya sesuai aturan. Kedua, pemeriksaan bahwa aplikasinya masih bisa dirakit utuh. Kode yang salah ketik satu baris saja bisa membuat seluruh halaman tidak muncul. Ketiga, pengiriman ke link preview privat, yaitu salinan aplikasi yang hanya bisa dibuka oleh Anda dan tim.

Kalau salah satu pemeriksaan gagal, perubahan itu berhenti di situ. Pelanggan tidak pernah melihatnya, dan admin Anda tidak menemukannya pada jam sibuk. Yang sama pentingnya, kegagalannya tercatat di tempat yang bisa Anda lihat juga, bukan hanya di laptop developer. Jadi "masih ada yang perlu dibereskan" bisa Anda cek sendiri.

Kenapa ini yang membuat demo mingguan jadi nyata

Kami mengirim software yang sudah jalan setiap minggu, dan link preview privat sudah ada sejak minggu pertama. Keduanya hanya mungkin kalau mengirim perubahan ke server itu murah dan otomatis.

Kalau setiap rilis butuh satu orang, satu malam, dan daftar langkah manual yang panjang, tidak ada tim yang mau melakukannya setiap minggu. Demo mingguan lalu berubah jadi presentasi: screenshot, daftar progres, dan janji bahwa nanti bisa dicoba. Anda kembali ke posisi harus percaya laporan.

Ritme mingguan dan cara kerjanya kami bahas lebih luas di panduan pembangunan yang bisa Anda awasi. Kalau Anda ingin melihat di tahap mana link preview dan demo ini muncul dalam satu proyek utuh, urutannya ada di dari ide sampai peluncuran.

Artinya untuk Anda setelah handover

Pengaturan rilis ini ada di akun Anda, sama seperti kode, server, dan domain. Semuanya atas nama Anda sejak hari pertama. Di tahap handover kepemilikannya dipastikan, bukan baru diserahkan.

Pengaruhnya terasa saat Anda mempekerjakan developer berikutnya. Pengaturannya tersimpan sebagai file di dalam proyek, bukan sebagai kebiasaan di kepala orang. Developer itu bisa membaca sendiri bagaimana software Anda diuji dan dirilis. Alasan di balik tiap keputusan juga dicatat di sebelah kodenya, jadi yang ia warisi termasuk pemikirannya.

Teknologi yang kami pakai juga umum dan sudah terbukti, bukan yang aneh-aneh. Developer baru tidak perlu menebak urutan rilis dari riwayat chat atau belajar alat yang hampir tidak dipakai orang lain.

Pertanyaan yang wajar ditanyakan

Empat pertanyaan ini bisa Anda ajukan ke vendor mana pun, dan jawabannya bisa dinilai tanpa membaca kode.

• Di mana link preview-nya, dan sejak minggu berapa saya bisa membukanya.
• Apa saja yang jalan otomatis sebelum satu perubahan naik ke pengguna.
• Berapa lama dari saya menyetujui satu perubahan sampai perubahan itu benar-benar jalan.
• Akun siapa yang menyimpan pengaturan rilis itu.

Bentuk jawabannya sudah cukup memberi tahu. Vendor yang sudah menyiapkan ini akan menyebut alamat, nama layanan, dan hitungan waktu, sedangkan yang belum menjawab dengan kata sifat. Apa lagi yang pantas Anda minta dari sebuah kerja sama kami uraikan di yang wajar Anda harapkan dari software house.

Kapan pengaturan ini berlebihan untuk proyek Anda

Terus terang saja, tidak semua proyek butuh perlengkapan yang sama. Website profil perusahaan yang isinya diubah beberapa kali setahun tidak perlu pengaturan seketat sistem booking yang memegang uang pelanggan dan dipakai setiap hari.

Yang menentukan adalah seberapa sering software Anda akan berubah. Kalau jawabannya hampir setiap minggu sepanjang tahun, pengaturan otomatis ini menghemat lebih banyak daripada biaya menyiapkannya. Kalau jawabannya dua kali setahun, pengaturan yang lebih sederhana sudah cukup, dan sisa anggarannya lebih berguna di tempat lain.

Kemungkinan ketiga sering terlewat. Kalau prosesnya sebenarnya sudah selesai dengan alat siap pakai yang dijual bulanan, kami akan bilang begitu. Anda tidak mengeluarkan anggaran build, dan seluruh pertanyaan soal rilis hilang bersamanya.

Ceritakan seberapa sering software Anda akan berubah

Tidak perlu menyiapkan daftar kebutuhan teknis. Ceritakan saja proses yang ingin Anda pindahkan ke software, lalu perkiraan Anda soal seberapa sering aturannya berubah: harga, jam operasional, cara hitung ongkos kirim. Dari situ kita bahas seperti apa proses rilisnya sebaiknya dibuat. Obrolan pertamanya gratis dan tanpa deck.

Kalau ternyata ada alat siap pakai yang sudah menyelesaikannya, kami akan bilang begitu. Kalau memang perlu dibangun, discovery memberi rencana tertulis dan harga tetap, dan dokumen itu milik Anda apa pun keputusan Anda setelahnya. Gunakan formulir kontak yang membuka WhatsApp, atau kirim email ke hello@arktik.id.