Langkah CI/CD Pertama Anda: Apa yang Harus Dilakukan Besok Pagi
Anda sudah membaca tentang level kematangan CI/CD. Anda paham teorinya. Sekarang Anda duduk di meja dan bertanya-tanya apa yang sebenarnya harus dilakukan Senin pagi. Jawabannya bukan memasang alat atau mendesain ulang seluruh pipeline. Jawabannya jauh lebih sederhana.
Mulailah dengan selembar kertas dan pulpen. Gambarkan bagaimana sebuah perubahan bergerak dari laptop pengembang ke produksi. Siapa yang menulis kode? Ke mana selanjutnya? Siapa yang memeriksanya? Bagaimana cara di-deploy? Apa yang terjadi setelah deployment? Jangan khawatir jika prosesnya sebagian besar manual. Tujuannya bukan untuk memiliki diagram yang sempurna. Tujuannya adalah agar semua orang di tim melihat gambaran yang sama tentang bagaimana perangkat lunak benar-benar sampai ke pengguna.
Latihan sederhana ini sering mengungkapkan kejutan. Pengembang mengira prosesnya memakan waktu sepuluh menit. Orang operasional tahu butuh dua jam karena pemeriksaan manual. Orang QA ingat bahwa seseorang selalu lupa memperbarui file konfigurasi. Menggambar alur ini membuat celah-celah tersebut terlihat.
Temukan Titik Sakit
Setelah alur tergambar di kertas, cari satu langkah yang paling sering menimbulkan masalah. Mungkin itu adalah build yang dijalankan seseorang secara manual di laptop mereka. Mungkin itu adalah migrasi database yang selalu ditunda karena takut merusak sesuatu. Mungkin itu adalah pemeriksaan manual untuk memastikan versi baru berjalan dengan benar.
Berikut contoh bagaimana alur tersebut mungkin terlihat untuk tim pada umumnya:
Pilih perubahan paling sederhana yang bisa Anda otomatisasi. Jangan mencoba mengotomatisasi seluruh pipeline deployment di hari pertama. Pilih satu jenis perubahan yang sering terjadi dan berisiko rendah. Mungkin itu adalah proses build untuk alat internal kecil. Mungkin itu adalah deployment layanan non-kritis. Tujuannya adalah menciptakan kemenangan kecil yang membangun kepercayaan diri.
Tulis Daftar Periksa Rilis
Ambil lagi kertas itu. Tulis tiga hingga lima baris yang menjawab pertanyaan-pertanyaan ini:
- Apa yang harus diperiksa sebelum versi baru diluncurkan?
- Bagaimana cara memeriksanya?
- Apa yang dilakukan jika ada yang salah?
Buatlah singkat. Daftar periksa yang baik untuk tim kecil mungkin terlihat seperti ini:
- Apakah versi baru sudah lulus tes dasar?
- Apakah database siap untuk perubahan?
- Apakah kita sudah mengomunikasikan perubahan ke tim lain?
- Apakah kita tahu cara roll back jika ada yang rusak?
Tulis ini di papan tulis, di dokumen bersama, atau di chat tim. Formatnya tidak penting. Yang penting adalah kebiasaan memeriksanya sebelum setiap rilis. Seiring waktu, pemeriksaan manual ini menjadi kandidat untuk otomatisasi. Tapi besok pagi, mulailah dengan menuliskan apa yang perlu diperiksa.
Tunjuk Satu Orang per Rilis
Tunjuk satu orang yang bertanggung jawab untuk setiap rilis. Ini bukan berarti mereka melakukan semua pekerjaan. Ini berarti mereka memastikan daftar periksa diikuti, mereka tahu kapan versi baru diluncurkan, dan mereka siap merespons jika ada yang salah. Rotasi peran ini setiap minggu atau setiap rilis. Tujuannya sederhana: tidak ada rilis yang terjadi tanpa seseorang yang bertanggung jawab penuh.
Peran ini bukan tentang otoritas. Ini tentang visibilitas. Ketika satu orang memiliki rilis, tidak ada kebingungan tentang siapa yang mengawasi deployment. Tidak ada asumsi bahwa orang lain akan menangkap masalah. Ada satu titik kontak ketika pertanyaan muncul.
Mengapa Langkah Kecil Ini Penting
Langkah-langkah ini terlihat kecil. Menggambar alur, menulis daftar periksa, menunjuk pemilik rilis. Kedengarannya tidak seperti transformasi CI/CD yang Anda baca di blog. Tapi ini adalah fondasi yang membuat segalanya mungkin.
Ketika Anda menggambar alur, Anda melihat di mana otomatisasi akan memberikan dampak terbesar. Ketika Anda menulis daftar periksa, Anda mendefinisikan apa yang harus diperiksa oleh otomatisasi. Ketika Anda menunjuk pemilik rilis, Anda menciptakan akuntabilitas yang tidak bisa digantikan oleh otomatisasi.
Langkah-langkah ini juga membangun kebiasaan berpikir tentang pengiriman sebagai sebuah proses. Banyak tim langsung melompat ke alat. Mereka menginstal Jenkins atau GitHub Actions dan mulai membangun pipeline tanpa memahami alur mereka saat ini. Hasilnya adalah otomatisasi yang mencerminkan proses yang rusak. Build berjalan lebih cepat, tapi rilis masih gagal karena tidak ada yang memeriksa migrasi database.
Memulai dengan alur dan daftar periksa berarti Anda mengotomatisasi hal yang benar. Anda mengotomatisasi pemeriksaan yang penting, bukan pemeriksaan yang mudah di-script.
Apa Selanjutnya
Setelah beberapa rilis dengan proses sederhana ini, pola akan muncul. Anda akan melihat pemeriksaan mana yang selalu sama. Anda akan melihat langkah mana yang paling memakan waktu. Anda akan melihat bagian alur mana yang paling sering menyebabkan kesalahan. Pola-pola ini memberi tahu Anda apa yang harus diotomatisasi selanjutnya.
Mungkin langkah build selalu sama, jadi Anda menulis skrip untuk menjalankannya di server bersama. Mungkin pemeriksaan migrasi database selalu terlupakan, jadi Anda menambahkannya ke skrip deployment. Mungkin prosedur rollback tidak pernah diuji, jadi Anda menjadwalkan latihan.
Beginilah cara CI/CD tumbuh secara organik. Dimulai dengan memahami proses Anda saat ini, bukan dengan menginstal alat. Dimulai dengan daftar periksa, bukan dengan konfigurasi pipeline. Dimulai dengan satu orang yang bertanggung jawab, bukan dengan tim insinyur platform.
Intisari Konkret
Besok pagi, lakukan tiga hal:
- Gambarkan alur pengiriman Anda saat ini di kertas bersama tim.
- Tulis daftar periksa rilis lima baris berdasarkan apa yang Anda lihat.
- Tunjuk satu orang untuk memiliki rilis berikutnya.
Itu adalah langkah pertama Anda. Tidak memerlukan biaya. Hanya butuh satu jam. Dan itu memberi Anda fondasi yang tidak bisa digantikan oleh alat apa pun.