Kenapa Tidak Perlu Membangun Semuanya Sekaligus

Ketika sebuah tim mulai membahas CI/CD, gambaran pertama yang sering muncul adalah transformasi besar-besaran. Setiap aplikasi harus punya pipeline. Database harus diotomatisasi. Infrastruktur harus dideklarasikan sebagai kode. Semua lingkungan harus identik. Dan semuanya harus selesai pada waktu yang sama.

Gambaran itu memang mengintimidasi, dan memang seharusnya begitu. Karena ketika Anda mencoba melakukan semuanya sekaligus, hasil yang paling mungkin bukanlah transformasi, melainkan kekacauan.

Coba pikirkan apa yang perlu diubah dalam satu dorongan: cara developer mengirim kode, cara tim database menangani migrasi skema, cara infrastruktur menyediakan server, cara QA menjalankan pengujian, cara release manager menyetujui deployment, dan cara semua orang melacak perubahan. Semua ini terjadi sementara aplikasi Anda yang sudah ada terus melayani pengguna.

Ini yang disebut transformasi big bang. Namanya terdengar monumental, tetapi dalam praktiknya biasanya berakhir sebagai kegagalan besar. Terlalu banyak hal berubah sekaligus. Terlalu banyak variabel yang tidak terkendali. Dan ketika ada yang rusak, tidak ada yang tahu harus mencari dari mana karena semuanya baru.

Pendekatan bertahap terdengar kurang glamor, tetapi jauh lebih realistis. Alih-alih mengubah semuanya sekaligus, Anda memilih satu bagian yang memiliki peluang sukses tertinggi, menyelesaikannya, belajar darinya, lalu beralih ke bagian berikutnya.

Perbedaan antara kedua jalur ini terlihat jelas ketika Anda melihatnya berdampingan:

flowchart TD Start([Mulai]) --> Choice{Pendekatan} Choice -->|Big Bang| BB[Mengubah semuanya sekaligus] BB --> Chaos[Kekacauan] Chaos --> Fail[Gagal] Choice -->|Bertahap| G1[Pilih satu bagian] G1 --> G2[Selesaikan] G2 --> G3[Belajar darinya] G3 --> G4[Lanjut ke bagian berikutnya] G4 --> G2 G3 --> Success[Sukses]

Kenapa Bertahap Lebih Baik daripada Big Bang

Setiap tim memiliki titik awal yang berbeda. Satu tim mungkin memiliki aplikasi yang berjalan di produksi tetapi masih melakukan deployment secara manual. Tim lain mungkin sudah memiliki pipeline untuk aplikasi mereka tetapi masih mengelola database dengan SSH langsung ke server. Tim ketiga mungkin sudah memiliki infrastruktur otomatis tetapi belum pernah menulis pengujian otomatis untuk aplikasi mereka.

Tidak ada cetak biru tunggal yang cocok untuk semua tim. Mencoba menyalin cetak biru tim lain secara mentah-mentah biasanya berakhir dengan penyesuaian yang menyakitkan. Pendekatan bertahap menghormati titik awal tim Anda yang sebenarnya. Ini memungkinkan Anda membangun dari posisi Anda saat ini, bukan dari posisi yang orang lain pikir seharusnya Anda tempati.

Pendekatan bertahap juga memberi Anda ruang untuk belajar. Setiap langkah menghasilkan pengalaman nyata: bagaimana pipeline berperilaku dengan basis kode tim Anda, bagaimana database Anda bereaksi terhadap migrasi otomatis, bagaimana infrastruktur Anda merespons perubahan konfigurasi. Pengalaman itu lebih berharga daripada dokumentasi alat atau teori mana pun, karena berasal langsung dari konteks Anda sendiri.

Risiko adalah alasan lain untuk melangkah selangkah demi selangkah. Ketika hanya satu bagian yang berubah, dan terjadi kesalahan, Anda tahu persis harus mencari di mana. Ketika semuanya berubah sekaligus, masalah bisa datang dari mana saja. Tim Anda menghabiskan waktu untuk mencari penyebab alih-alih memperbaiki dampaknya.

Terakhir, perubahan bertahap lebih mudah diterima orang. Transformasi besar menciptakan resistensi karena orang nyaman dengan alur kerja yang sudah dikenal. Tetapi ketika perubahan terjadi dalam langkah-langkah kecil, setiap langkah terasa lebih ringan. Tim melihat hasilnya, merasakan manfaatnya, dan menjadi lebih terbuka terhadap langkah berikutnya.

Cara Menemukan Langkah Pertama Anda

Bagian tersulit adalah memutuskan dari mana harus memulai. Banyak tim terjebak di sini karena mereka mencoba merencanakan seluruh peta jalan sebelum mengambil tindakan. Itu adalah kesalahan. Anda tidak perlu peta yang lengkap. Anda hanya perlu satu langkah jelas yang memberikan nilai.

Mulailah dengan melihat proses pengiriman Anda saat ini. Temukan bagian yang paling menyakitkan atau memakan waktu paling lama. Itu biasanya kandidat yang baik untuk langkah pertama Anda.

Berikut beberapa titik awal yang umum:

  • Jika deployment ke produksi memerlukan daftar periksa manual yang memakan waktu berjam-jam, mulailah dengan mengotomatiskan deployment satu layanan non-kritis.
  • Jika perubahan database dilakukan secara manual dan sering menyebabkan insiden produksi, mulailah dengan mengotomatiskan migrasi skema untuk database berisiko rendah.
  • Jika tim Anda menghabiskan waktu berhari-hari untuk menguji setiap rilis secara manual, mulailah dengan menulis pengujian otomatis untuk alur pengguna yang paling kritis.
  • Jika perubahan infrastruktur dilakukan melalui permintaan tiket yang memakan waktu berminggu-minggu, mulailah dengan mendeklarasikan satu bagian infrastruktur sebagai kode.

Kuncinya adalah memilih sesuatu yang cukup kecil untuk diselesaikan dalam waktu yang wajar, tetapi cukup berarti sehingga tim merasakan perbaikannya.

Seperti Apa Peta Jalan Bertahap yang Khas

Peta jalan bertahap tidak berarti Anda merencanakan setiap langkah di muka. Ini berarti Anda tahu arah Anda dan Anda mengambil satu langkah pada satu waktu.

Urutan khas mungkin terlihat seperti ini:

  1. Otomatiskan build dan deployment satu aplikasi. Biarkan yang lainnya tetap manual.
  2. Tambahkan pengujian otomatis untuk jalur paling kritis dari aplikasi tersebut.
  3. Perluas pipeline untuk menyertakan migrasi database untuk aplikasi tersebut.
  4. Terapkan pola yang sama ke aplikasi kedua, sesuaikan berdasarkan apa yang Anda pelajari.
  5. Secara bertahap pindahkan penyediaan infrastruktur ke dalam pipeline.
  6. Tambahkan kemampuan pemantauan dan rollback.
  7. Perluas ke aplikasi yang tersisa.

Perhatikan bahwa setiap langkah dibangun di atas langkah sebelumnya. Anda tidak melompat dari deployment manual ke otomatisasi infrastruktur penuh dalam satu kali. Anda membiarkan setiap langkah menginformasikan langkah berikutnya.

Daftar Periksa Praktis untuk Langkah Pertama Anda

Sebelum memulai, jalankan daftar periksa singkat ini:

  • Dapatkah Anda mengidentifikasi satu aplikasi atau layanan yang berisiko rendah dan tidak kritis?
  • Apakah Anda memiliki definisi yang jelas tentang seperti apa "selesai" untuk langkah ini?
  • Apakah ada seseorang di tim yang dapat memiliki langkah ini dan memastikannya selesai?
  • Sudahkah Anda mengomunikasikan kepada tim bahwa ini adalah eksperimen, bukan perubahan proses permanen?
  • Apakah Anda memiliki cara untuk melakukan rollback jika terjadi kesalahan?

Jika Anda bisa menjawab ya untuk pertanyaan-pertanyaan ini, Anda siap untuk memulai. Jika tidak, luangkan waktu untuk mengklarifikasi poin-poin tersebut terlebih dahulu.

Intisari

Anda tidak perlu mengubah semuanya sekaligus. Anda hanya perlu satu langkah yang berfungsi yang dapat dilihat, disentuh, dan dipelajari oleh tim Anda. Mulailah dari sana. Biarkan langkah berikutnya muncul dari apa yang Anda temukan. Tim yang belajar secara bertahap membangun praktik yang bertahan lama. Tim yang mencoba mengubah semuanya sekaligus biasanya berakhir membangun dari awal lagi.