CI/CD Standar: Pipeline Sama, Tapi Masih Banyak Pekerjaan Manual

Pipeline sudah ada. Semua tim memakainya. Kode masuk, build berjalan, testing dijalankan, dan deployment terjadi. Tapi entah kenapa, mengirim perubahan ke produksi masih terasa berat. Pipeline sudah siap, tapi prosesnya lambat. Seseorang harus menyetujui setiap perubahan. QA harus menguji staging secara manual. Deployment ke produksi butuh seseorang untuk duduk dan menjalankan perintah atau mengklik tombol di waktu tertentu.

Ini adalah Level 2 dalam model maturity CI/CD: Standardized (Tersandar). Organisasi Anda sudah melewati kekacauan di mana setiap tim bekerja dengan caranya sendiri. Ada pipeline bersama. Ada konsistensi. Tapi masih banyak pekerjaan manual yang membuat pengiriman lambat.

Seperti Apa Level Standardized

Di level ini, pipeline bukan lagi misteri. Setiap tim mengikuti alur yang sama: commit, build, test, deploy ke staging, dan akhirnya ke produksi. Tidak ada lagi yang membangun dari laptop dengan alat atau konfigurasi berbeda. Lingkungan build konsisten. Langkah-langkah pengujian sudah ditentukan. Proses deployment sudah didokumentasikan.

Tapi ada masalahnya: pipeline berhenti di staging. Atau butuh persetujuan manual untuk melanjutkan. Atau perlu seseorang menjalankan skrip. Otomatisasi sudah ada, tapi belum lengkap. Manusia masih terlibat di langkah-langkah kritis.

Diagram di bawah menunjukkan alur pipeline tipikal di level ini, dengan langkah manual yang disorot merah.

Hambatan Persetujuan

Salah satu penyebab utama lambat di level ini adalah proses persetujuan. Setiap perubahan yang ingin sampai ke produksi butuh tanda tangan dari orang atau grup tertentu. Persetujuan itu mungkin datang lewat email, pesan chat, atau rapat singkat. Tapi jarang datang dengan cepat.

Orang yang harus menyetujui mungkin sedang rapat lain. Mungkin sedang cuti. Mungkin sibuk menangani insiden. Atau mungkin saja tidak mau menjadi pihak yang bertanggung jawab jika terjadi masalah. Akibatnya, perubahan menganggur di pipeline, menunggu. Jam berubah menjadi hari. Pipeline sendiri sudah siap, tapi prosesnya tidak.

Ini bukan masalah alat. Anda bisa memiliki platform CI/CD terbaik di dunia, tapi jika setiap deployment butuh manusia untuk mengatakan "ya", Anda tetap terhambat oleh ketersediaan manusia.

Pengujian Manual Masih Ada

Tanda lain dari level Standardized adalah tidak semua pengujian terotomatisasi. Unit test dan integration test mungkin berjalan di pipeline. Tapi untuk skenario tertentu, QA masih harus login ke lingkungan staging, menjalankan test case secara manual, dan menulis laporan.

Ini menciptakan siklus. Developer mengirim perubahan. Automated test lolos. Tapi QA harus memverifikasi fitur secara manual. Jika menemukan masalah, perubahan dikembalikan ke developer. Developer memperbaikinya, mengirim ulang, dan QA mengulangi pengujian manual. Setiap iterasi memakan waktu.

Masalahnya bukan karena pengujian manual tidak berguna. Beberapa hal memang sulit diotomatisasi, terutama alur pengguna yang kompleks atau kasus tepi. Masalahnya adalah pengujian manual diperlakukan sebagai gerbang yang harus dilewati sebelum setiap deployment, bahkan untuk perubahan kecil. Ini memperlambat seluruh proses pengiriman.

Deployment Masih Langkah Manual

Bahkan dengan pipeline yang terstandarisasi, deployment ke produksi seringkali tetap menjadi tindakan manual. Pipeline mungkin membangun dan menguji secara otomatis, tapi saat mendorong ke produksi, seseorang harus menjalankan perintah atau mengklik tombol di dashboard.

Beberapa organisasi masih mengikuti jadwal rilis. Mereka melakukan deployment seminggu sekali atau sebulan sekali, padahal pipeline siap untuk melakukan deployment kapan saja. Alasannya seringkali karena ketakutan. Tanpa otomatisasi penuh dan kepercayaan pada proses, tim lebih suka mengumpulkan perubahan dan melakukan deployment dalam jendela terjadwal ketika semua orang siap menangani masalah.

Ini bisa dimengerti, tapi ini mengalahkan tujuan memiliki pipeline. Pipeline memberi Anda kemampuan untuk melakukan deployment dengan cepat, tapi proses mencegah Anda menggunakan kemampuan itu.

Dokumentasi Ada, Tapi Apakah Berguna?

Di level Standardized, dokumentasi mulai muncul. Mungkin ada halaman wiki yang menjelaskan cara melakukan deployment, rollback, atau menangani error umum. Tapi dokumentasi ini seringkali kedaluwarsa. Atau tidak lengkap. Atau orang lebih suka bertanya ke rekan kerja daripada membacanya.

Masalahnya adalah dokumentasi diperlakukan sebagai artefak terpisah, bukan sebagai bagian dari proses. Dokumentasi ditulis sekali lalu dilupakan. Ketika sesuatu berubah, dokumentasi tidak diperbarui. Ketika anggota baru bergabung, mereka harus belajar dari orang lain, bukan dari dokumentasi.

Sisi Baiknya: Konsistensi

Terlepas dari semua masalah ini, level Standardized adalah peningkatan signifikan dari level sebelumnya. Manfaat terbesarnya adalah konsistensi. Karena setiap tim menggunakan pipeline yang sama, hasil build dan test dapat diandalkan. Jika build gagal, build gagal untuk semua orang dengan cara yang sama. Tidak ada lagi "di laptop saya berfungsi" karena setiap perubahan melewati jalur yang sama.

Konsistensi ini memudahkan debugging. Ketika terjadi masalah, tim tahu harus mencari di mana. Log pipeline terstandarisasi. Konfigurasi lingkungan sama. Langkah-langkah pengujian dapat diprediksi. Ini mengurangi waktu yang dihabiskan untuk pemecahan masalah dan meningkatkan kepercayaan pada proses.

Sisi Buruknya: Masih Lambat

Tapi sisi negatifnya jelas: terlalu banyak pekerjaan manual memperlambat segalanya. Setiap langkah manual adalah titik tunggu. Persetujuan, pengujian manual, deployment manual, dokumentasi yang kedaluwarsa — semua ini menambah waktu antara menulis kode dan memberikan nilai kepada pengguna.

Tim di level ini sering merasa sudah membuat kemajuan. Mereka punya pipeline. Mereka punya konsistensi. Tapi mereka juga frustrasi karena pengiriman masih belum cepat. Mereka tahu bisa berbuat lebih baik, tapi tidak yakin bagaimana cara mencapainya.

Daftar Periksa Praktis untuk Level 2

Jika Anda berada di level ini, berikut beberapa hal yang perlu diperiksa:

• Apakah setiap langkah persetujuan benar-benar diperlukan, atau bisakah beberapa diotomatiskan berdasarkan hasil test?
• Pengujian manual mana yang bisa diotomatisasi dan ditambahkan ke pipeline?
• Bisakah deployment ke produksi dipicu secara otomatis jika semua test lolos?
• Apakah dokumentasi diperbarui sebagai bagian dari proses deployment, bukan sebagai tugas terpisah?
• Apakah tim menunggu orang lain sebelum bisa melakukan deployment?

Pertanyaan-pertanyaan ini membantu mengidentifikasi hambatan terbesar. Tujuannya bukan untuk menghilangkan semua pekerjaan manual sekaligus. Tujuannya adalah menemukan langkah-langkah yang menyebabkan penundaan paling besar dan menguranginya satu per satu.

Langkah Selanjutnya: Self-Service

Level Standardized adalah jembatan. Organisasi Anda memiliki fondasi yang tepat. Pipeline sudah ada. Prosesnya konsisten. Tapi Anda belum menggunakannya secara maksimal. Langkah selanjutnya adalah mengurangi pekerjaan manual hingga tim dapat mengelola deployment mereka sendiri tanpa menunggu orang lain.

Itulah level self-service. Tim dapat melakukan deployment saat mereka perlu, dengan pemeriksaan otomatis menggantikan gerbang manual. Persetujuan menjadi berbasis pengecualian, bukan default. Pengujian diotomatisasi sebanyak mungkin. Dokumentasi dihasilkan dari proses, bukan ditulis terpisah.

Tapi sebelum Anda bisa sampai ke sana, Anda perlu menyadari bahwa memiliki pipeline tidak sama dengan memiliki pengiriman yang cepat. Standardisasi memberi Anda konsistensi. Langkah selanjutnya memberi Anda kecepatan.

Kesimpulan

Pipeline yang terstandarisasi adalah awal yang baik, tapi bukan garis akhir. Jika tim Anda memiliki pipeline bersama tetapi masih berjuang dengan persetujuan yang lambat, pengujian manual, dan deployment terjadwal, Anda berada di Level 2. Pipeline sudah siap. Prosesnya belum. Pekerjaan sekarang adalah menghilangkan langkah-langkah manual yang membuat pengiriman Anda lambat.