Sebelum Merencanakan Roadmap CI/CD, Lakukan Inventarisasi Terlebih Dahulu

Anda duduk bersama tim untuk merencanakan implementasi CI/CD. Seseorang mengusulkan memulai dari aplikasi yang paling kritis. Orang lain ingin memperbaiki proses deployment yang paling menyakitkan. Orang ketiga berpendapat untuk membangun pipeline baru dari awal. Semua orang punya argumen yang valid, tapi tidak ada yang benar-benar tahu apa yang dimiliki tim saat ini.

Di sinilah sebagian besar roadmap CI/CD gagal. Mereka memulai dengan keputusan sebelum memahami kondisi saat ini. Anda tidak bisa memprioritaskan apa yang harus diubah jika tidak tahu apa yang sudah ada. Langkah pertama bukanlah perencanaan. Langkah pertama adalah inventarisasi.

Apa yang Perlu Anda Katalogkan

Inventarisasi terdengar administratif, tapi ini adalah fondasi untuk setiap keputusan selanjutnya. Tanpa inventarisasi, Anda hanya menebak perubahan mana yang paling penting. Dengan inventarisasi, Anda melihat pola, celah, dan dependensi yang sebelumnya tidak terlihat hingga menghambat kemajuan.

Aplikasi

Mulailah dengan setiap aplikasi yang dikelola tim Anda. Sertakan aplikasi yang jarang berubah, alat internal yang tidak pernah dibicarakan, dan sistem lawas yang semua orang hindari. Untuk setiap aplikasi, catat:

  • Bahasa pemrograman dan framework
  • Lokasi kode sumber (repositori, strategi branch)
  • Cara kerja proses build saat ini (perintah manual, skrip, otomatisasi yang sudah ada)
  • Siapa yang paling memahami aplikasi tersebut

Poin terakhir lebih penting dari yang terlihat. Saat Anda mulai memodifikasi pipeline untuk aplikasi tertentu, Anda akan membutuhkan seseorang yang memahami keunikan aplikasi tersebut. Orang itu adalah sumber daya utama Anda. Tanpa mereka, Anda akan membuat asumsi yang bisa merusak segalanya.

Basis Data

Banyak tim lupa bahwa basis data adalah bagian dari proses pengiriman. Pipeline CI/CD yang menangani kode aplikasi tapi mengabaikan perubahan basis data akan gagal saat migrasi berjalan di produksi. Untuk setiap basis data yang terhubung ke aplikasi Anda, catat:

  • Tipe dan versi basis data
  • Bagaimana perubahan skema dikelola saat ini (skrip manual, alat migrasi, atau tidak sama sekali)
  • Siapa yang menangani perubahan basis data dan siapa yang merespons saat migrasi gagal
  • Apakah perubahan basis data diuji sebelum mencapai produksi

Perubahan basis data memiliki risiko yang berbeda dari perubahan kode aplikasi. Deployment yang buruk sering bisa di-rollback dengan cepat. Migrasi yang buruk bisa merusak data atau membutuhkan waktu pemulihan berjam-jam. Mengetahui lanskap basis data Anda membantu memutuskan seberapa banyak otomatisasi dan pengujian yang perlu diterapkan.

Infrastruktur

Aplikasi dan basis data berjalan di suatu tempat. Catat di mana tempat itu untuk setiap komponen:

  • Server fisik, mesin virtual, atau layanan cloud
  • Bagaimana lingkungan dibuat dan dikonfigurasi
  • Apakah konfigurasi didokumentasikan atau dikelola melalui sesi SSH manual
  • Siapa yang memiliki akses ke lingkungan produksi
  • Siapa yang biasanya menangani masalah infrastruktur

Infrastruktur yang dikelola secara manual akan membatasi seberapa banyak otomatisasi yang bisa Anda perkenalkan. Jika setiap server adalah snowflake dengan konfigurasi unik, pipeline Anda tidak bisa diandalkan untuk melakukan deployment ke salah satu dari mereka. Inventarisasi akan menunjukkan bagian infrastruktur mana yang siap untuk otomatisasi dan mana yang perlu dibersihkan terlebih dahulu.

Pipeline yang Ada

Tim Anda mungkin sudah memiliki beberapa otomatisasi, meskipun tidak sempurna. Dokumentasikan apa yang sudah ada:

  • Aplikasi mana yang memiliki proses build, test, atau deployment otomatis
  • Apa yang sebenarnya dilakukan setiap pipeline (build saja, build dan test, deployment penuh)
  • Apa yang hilang (tidak ada pemindaian keamanan, tidak ada migrasi basis data, langkah persetujuan manual)
  • Seberapa andal pipeline yang ada (sering gagal, tes yang tidak stabil, waktu eksekusi lama)

Pipeline yang ada tidak berguna hanya karena tidak sempurna. Mereka menunjukkan apa yang sudah dipahami tim dan di mana celahnya. Pipeline yang melakukan build dan test tapi deployment manual memberi tahu Anda di mana harus fokus selanjutnya.

Kepemilikan

Setiap komponen membutuhkan pemilik. Catat siapa yang bertanggung jawab untuk setiap aplikasi, basis data, dan bagian infrastruktur. Kepemilikan penting karena perubahan pipeline memerlukan koordinasi. Anda tidak bisa memodifikasi pipeline untuk aplikasi yang dimiliki tim lain tanpa melibatkan mereka. Anda tidak bisa mengubah cara migrasi basis data berjalan tanpa berbicara dengan orang yang menangani perubahan basis data.

Catat juga siapa yang bisa mengambil keputusan tentang perubahan. Orang yang memelihara komponen mungkin bukan orang yang menyetujui perubahan pada komponen tersebut. Mengetahui rantai keputusan mencegah keterlambatan di kemudian hari.

Cara Membangun Inventarisasi

Jangan bertujuan untuk kesempurnaan. Inventarisasi yang lengkap tapi kasar lebih baik daripada inventarisasi yang rapi tapi parsial. Gunakan alat apa pun yang nyaman bagi tim: spreadsheet, dokumen bersama, papan tulis digital. Formatnya tidak terlalu penting dibandingkan isinya.

Diagram alur berikut menguraikan proses inventarisasi yang direkomendasikan:

flowchart TD A[Mulai Inventarisasi] --> B[Daftar Aplikasi] B --> C[Daftar Basis Data] C --> D[Daftar Infrastruktur] D --> E[Daftar Pipeline yang Ada] E --> F[Tetapkan Kepemilikan] F --> G[Tinjau dengan Tim] G --> H[Identifikasi Celah] H --> I[Analisis Pola] I --> J[Rencanakan Roadmap]

Mulailah dengan apa yang Anda ketahui. Isi entri yang jelas terlebih dahulu, lalu minta anggota tim untuk memverifikasi dan melengkapi area mereka. Jadwalkan pertemuan singkat di mana semua orang meninjau inventarisasi bersama. Ini sering mengungkap komponen yang terlupakan atau dependensi yang diasumsikan tapi tidak pernah dikonfirmasi.

Perkirakan akan ada celah. Beberapa aplikasi mungkin tidak memiliki pemilik yang jelas. Beberapa basis data mungkin memiliki proses migrasi yang tidak terdokumentasi. Beberapa infrastruktur mungkin berjalan dengan kredensial yang tidak diingat siapa pun. Celah-celah ini bukanlah kegagalan. Mereka adalah informasi persis yang Anda butuhkan untuk merencanakan langkah selanjutnya.

Apa yang Diungkapkan oleh Inventarisasi

Setelah inventarisasi selesai, pola-pola akan muncul. Anda mungkin melihat bahwa satu tim memiliki pipeline yang matang sementara tim lain masih melakukan deployment manual. Anda mungkin menemukan bahwa perubahan basis data ditangani dengan hati-hati tapi provisioning infrastruktur kacau. Anda mungkin menemukan bahwa aplikasi paling kritis Anda memiliki otomatisasi paling sedikit.

Pola-pola ini memberi tahu Anda di mana harus memulai. Tim dengan pipeline yang matang bisa menjadi model. Aplikasi dengan deployment manual tapi kepemilikan yang jelas adalah kandidat yang baik untuk otomatisasi. Basis data yang sudah memiliki skrip migrasi lebih mudah diintegrasikan ke dalam pipeline daripada yang belum pernah di-versioning.

Inventarisasi juga mengungkap dependensi yang tidak bisa Anda abaikan. Aplikasi yang bergantung pada basis data tanpa proses migrasi tidak bisa sepenuhnya diotomatisasi sampai sisi basis data ditangani. Aplikasi yang berjalan di infrastruktur yang dikonfigurasi manual akan membutuhkan perubahan infrastruktur sebelum pipeline bisa melakukan deployment dengan andal.

Daftar Periksa Praktis

Gunakan daftar periksa ini untuk memandu upaya inventarisasi Anda:

  • Daftar setiap aplikasi yang dikelola tim Anda, termasuk sistem internal dan lawas
  • Untuk setiap aplikasi, catat bahasa, repositori, proses build, dan kontak utama
  • Daftar setiap basis data yang terhubung ke aplikasi tersebut
  • Untuk setiap basis data, catat tipe, versi, proses migrasi, dan penanggung jawab
  • Dokumentasikan di mana setiap aplikasi dan basis data berjalan (server, VM, cloud)
  • Catat bagaimana lingkungan dibuat dan dikonfigurasi
  • Dokumentasikan pipeline yang ada: apa yang mereka lakukan, apa yang mereka lewatkan, seberapa andal mereka
  • Catat kepemilikan untuk setiap komponen
  • Identifikasi siapa yang bisa menyetujui perubahan untuk setiap komponen

Intisari Konkret

Inventarisasi bukanlah latihan birokratis. Ini adalah hal paling berguna yang bisa Anda lakukan sebelum merencanakan perbaikan CI/CD apa pun. Tim yang tahu persis apa yang mereka miliki bisa membuat keputusan berdasarkan fakta, bukan tebakan. Tim yang melewatkan inventarisasi akan terus menemukan kejutan di tengah implementasi, dan kejutan-kejutan itu akan memakan waktu, kepercayaan, dan momentum.

Mulailah roadmap Anda dengan mengetahui apa yang sudah Anda miliki. Pola-pola dalam inventarisasi Anda akan memberi tahu ke mana harus melangkah selanjutnya.