Mulai dengan Satu Aplikasi yang Benar-Benar Berarti

Anda memiliki daftar semua yang dikelola tim. Aplikasi, database, komponen infrastruktur, skrip, cron job. Mungkin Anda menghabiskan seminggu untuk melakukan inventarisasi, atau mungkin Anda hanya mencoret-coretnya di papan tulis saat rapat. Sekarang Anda menatap daftar itu, dan pertanyaan muncul: dari mana kita mulai?

Di sinilah sebagian besar tim berhenti. Mereka khawatir memilih hal yang salah. Mereka khawatir melewatkan sesuatu yang lebih penting. Mereka khawatir apa pun yang dipilih tidak akan memberikan hasil yang terlihat. Jadi mereka terus menganalisis, terus berdiskusi, dan terus menunda tindakan.

Triknya bukan memilih titik awal yang sempurna. Triknya adalah memilih sesuatu yang memiliki kemungkinan besar untuk berhasil dan kemungkinan besar untuk diperhatikan ketika berhasil.

Mulai dengan Aplikasi, Bukan Infrastruktur atau Database

Sangat menggoda untuk memulai dengan infrastruktur karena infrastruktur terasa fundamental. Atau memulai dengan database karena perubahan database terasa menakutkan. Namun tempat terbaik untuk memulai adalah aplikasi.

Ini bukan karena aplikasi lebih penting. Ini karena aplikasi paling sering berubah, dan perubahannya paling terlihat oleh pengguna. Ketika Anda membangun pipeline untuk sebuah aplikasi, hasilnya langsung terasa. Build menjadi otomatis. Tes berjalan pada setiap perubahan. Deployment tidak lagi menjadi ritual manual yang membutuhkan tiga orang dalam panggilan video pada jam 10 malam.

Pengalaman itu membangun kepercayaan diri. Anda melihat pipeline bekerja. Anda melihat tim mulai percaya padanya. Dan kepercayaan diri itulah yang Anda butuhkan sebelum menangani bagian yang lebih sulit seperti migrasi database atau provisioning infrastruktur.

Tiga Kriteria Memilih Aplikasi yang Tepat

Lihat inventaris Anda dan pilih satu aplikasi yang memenuhi ketiga kondisi ini.

Diagram alur berikut memandu Anda melalui tiga kriteria untuk membantu memutuskan:

flowchart TD A[Mulai: Daftar semua aplikasi] --> B{Dikembangkan secara aktif?} B -- Tidak --> C[Lewati aplikasi ini] B -- Ya --> D{Punya pengguna nyata?} D -- Tidak --> C D -- Ya --> E{Tim bersedia berkolaborasi?} E -- Tidak --> C E -- Ya --> F[Pilih aplikasi ini] F --> G[Bangun pipeline golden path] G --> H[Perluas ke aplikasi lain]

Pertama, aplikasi dikembangkan secara aktif atau sering diubah. Aplikasi yang tidak disentuh siapa pun tidak akan mengajarkan apa pun. Anda membutuhkan perubahan nyata yang mengalir melalui pipeline untuk menemukan masalah nyata. Jika aplikasi hanya diperbarui setiap beberapa bulan, Anda akan lebih banyak menghabiskan waktu menunggu daripada belajar.

Kedua, aplikasi memiliki pengguna nyata. Bukan prototipe. Bukan proof-of-concept yang berjalan di laptop seseorang. Pengguna nyata berarti dampak nyata. Ketika pipeline berfungsi, pengguna mendapatkan pembaruan lebih cepat. Ketika pipeline menangkap bug sebelum deployment, pengguna tidak mengalami gangguan. Tim merasakan perbedaannya, dan perasaan itulah yang menjual fase pekerjaan berikutnya kepada pemangku kepentingan.

Ketiga, tim yang memiliki aplikasi bersedia berkolaborasi. Ini adalah kriteria terpenting. Anda bisa memiliki rencana teknis terbaik di dunia, tetapi jika tim kewalahan, kelelahan, atau tidak tertarik, pipeline tidak akan bertahan. Temukan tim yang memiliki kapasitas dan rasa ingin tahu. Bekerjalah dengan mereka. Jangan memaksakan proses baru ke tim yang sudah berjuang.

Buat Keputusan dengan Cepat

Proses seleksi harus memakan waktu satu atau dua sesi diskusi. Kumpulkan inventaris. Lihat aplikasi mana yang paling sering berubah. Bicaralah dengan tim. Tanyakan apakah mereka punya ruang untuk mencoba sesuatu yang baru. Lalu putuskan.

Jangan biarkan ini berlarut-larut selama berminggu-minggu. Analisis yang berlebihan adalah musuh kemajuan. Lebih baik memilih kandidat yang layak dan mulai membangun daripada menghabiskan sebulan menganalisis setiap opsi dan berakhir dengan tidak ada apa-apa.

Aplikasi Ini Menjadi Golden Path Anda

Setelah Anda memilih aplikasi, aplikasi itu menjadi golden path Anda. Ini adalah istilah untuk pipeline pengiriman standar pertama yang didokumentasikan, dibangun, dan diperlakukan sebagai referensi untuk semua hal lainnya oleh tim Anda.

Setiap keputusan tentang pipeline, pengujian, dan deployment diterapkan di sini terlebih dahulu. Bagaimana Anda menyusun skrip build? Tes apa yang berjalan di CI? Bagaimana Anda menangani secret? Bagaimana Anda melakukan deployment ke staging versus production? Semua pertanyaan ini dijawab untuk satu aplikasi ini.

Ketika golden path berjalan dengan baik, Anda memiliki template yang berfungsi. Aplikasi berikutnya dapat mengikuti pola yang sama. Lalu berikutnya. Kemudian Anda dapat mengadaptasi pola untuk perubahan database. Lalu untuk infrastruktur. Setiap langkah menjadi lebih mudah karena Anda tidak memulai dari awal.

Golden Path Bukanlah Hal yang Istimewa

Penting untuk memahami apa yang bukan golden path. Ini bukan pernyataan bahwa aplikasi ini lebih penting dari yang lain. Ini bukan hak istimewa permanen. Ini adalah eksperimen yang disengaja yang dirancang untuk memiliki risiko terkecil dan peluang sukses tertinggi.

Jika ada yang salah, kerusakan terbatas pada satu aplikasi. Jika keputusan ternyata salah, Anda memperbaikinya untuk satu aplikasi dan belajar darinya. Pelajaran itu kemudian diterapkan ke semua hal lainnya.

Anggap saja sebagai test bed. Anda sedang menguji kemampuan tim untuk membangun pipeline, menguji asumsi Anda tentang otomatisasi, dan membuktikan bahwa pendekatan itu berhasil sebelum menskalakannya.

Pastikan Semua Orang Sependapat

Sebelum Anda menulis satu baris kode pipeline pun, pastikan semua orang tahu aplikasi mana yang menjadi golden path dan mengapa dipilih. Kesepakatan ini mencegah kebingungan di kemudian hari. Ketika seseorang bertanya mengapa aplikasi lain belum disentuh, jawabannya jelas: kami membuktikan polanya pada aplikasi ini terlebih dahulu, lalu kami akan menerapkannya ke sisanya.

Tuliskan. Tempatkan di tempat yang terlihat. Sebutkan dalam standup. Tujuannya bukan untuk menciptakan birokrasi. Tujuannya adalah untuk menghindari pertanyaan "mengapa kita mengerjakan ini, bukan itu?" yang mengganggu momentum.

Daftar Periksa Praktis Sebelum Memulai

  • Satu aplikasi telah dipilih yang dikembangkan secara aktif, memiliki pengguna nyata, dan memiliki tim yang bersedia
  • Keputusan telah didokumentasikan dan dibagikan ke tim
  • Semua orang memahami bahwa ini adalah golden path, bukan prioritas permanen
  • Tim yang memiliki aplikasi telah setuju untuk berkolaborasi
  • Garis waktu kasar telah ditetapkan untuk pipeline pertama yang berfungsi (tidak perlu sempurna, hanya berfungsi)

Intisari Konkret

Pilih satu aplikasi yang sering berubah, memiliki pengguna nyata, dan memiliki tim yang ingin bekerja sama dengan Anda. Bangun pipeline untuk aplikasi itu terlebih dahulu. Buatlah berfungsi. Belajarlah darinya. Lalu lakukan lagi untuk aplikasi berikutnya. Itulah cara Anda beralih dari daftar semua yang Anda miliki ke sistem pengiriman yang benar-benar mengirimkan.