Kustomisasi Odoo Tanpa Merusak Upgrade: 5 Prinsip

Banyak tim yang membenci proses upgrade Odoo sebenarnya tidak sedang bayar untuk “upgrade”. Mereka bayar untuk membereskan tiga tahun keputusan kustomisasi yang buruk, dibuat oleh orang yang sudah lama tidak di perusahaan. Skrip migrasinya berubah jadi pekerjaan arkeologi.

Ini sebenarnya bisa dihindari. Kalau lima prinsip berikut diterapkan sejak awal, pindah dari Odoo 17 ke 18 ke 19 tetap jadi pekerjaan akhir pekan biasa, bukan krisis kuartalan. Berikut prinsipnya, lengkap dengan trade-off yang biasanya baru kelihatan setelah terlambat.

1. Jangan pernah utak-atik core. Selalu inherit.

Penyebab utama upgrade yang menyakitkan adalah edit langsung ke file inti Odoo — patch di sale.py, ubah view di folder addons/, ganti isi method karena “cuma satu baris”. Setiap edit seperti itu jadi konflik manual saat upgrade.

Disiplinnya begini: semua modifikasi tinggal di module kustom milik Anda sendiri (kami biasa pakai prefix ts_). Model di-extend lewat _inherit. View di-extend pakai XPath. Method di-override lewat super(). Laporan, security rule, data — semuanya hidup di module Anda, tidak pernah di core.

Kalau ini dijalankan benar, pertanyaan “apa saja yang sudah dikustomisasi” dijawab cukup dengan melihat isi folder addons milik Anda. Kalau dijalankan salah, jawabannya adalah git diff melawan Odoo vanilla di ribuan file.

2. Pakai Studio seperlunya, dan version-control hasilnya.

Studio aman untuk hal-hal yang benar-benar kecil — tambah field di form, sembunyikan kolom, ubah label. Masalahnya muncul ketika Studio jadi alat utama untuk logika yang non-trivial. Computed field dengan ekspresi Python, automated action yang multi-step, visibility kondisional yang nyambung ke lima field lain — semua itu bisa dilakukan di Studio, dan semuanya jadi tak terlihat oleh developer Anda.

Aturan kami: apapun yang lebih kompleks dari sekadar tambah field atau ganti label, pindahkan ke module. Untuk perubahan Studio yang memang dipertahankan, export sebagai file .xml dan commit ke Git. Kalau kustomisasi Studio cuma hidup di dalam database, satu restore yang salah sudah cukup untuk menghilangkannya, dan setiap upgrade artinya harus ulang manual.

3. Pin semua dependency.

Kustomisasi Odoo jarang berdiri sendiri. Ada library Python untuk generate PDF, module OCA dari komunitas, fork dari fork yang dipasang tahun 2022 karena “kebetulan jalan”. Saat waktunya upgrade, separuh dari itu belum punya versi yang kompatibel dengan 18, dan tidak ada yang tahu mana yang krusial.

Pegang satu requirements.txt untuk Python, dan daftar eksplisit module OCA beserta tag versinya. Lebih baik lagi: vendor semuanya ke repository Anda sendiri supaya kecepatan upgrade-nya Anda yang kontrol. Saat memutuskan pindah dari Odoo 17 ke 18, satu file harus cukup untuk tahu apa saja yang ikut pindah.

4. Tulis data migration, bukan tambal-sulam manual.

Cepat atau lambat, ada upgrade yang menuntut transformasi data — tipe field berubah, model dipecah, nilai selection di-rename. Ada dua jalan. Pertama, perbaiki manual di production setelah upgrade (“jalankan SQL ini, lalu script Python ini”). Kedua, tulis migration script yang hidup di folder migrations/ modul Anda dan jalan otomatis.

Tambal-sulam manual kelihatan lebih cepat di kali pertama. Sampai upgrade ketiga, ia berubah jadi rawa berisi skrip-skrip satu-kali yang tidak ada dokumentasinya dan tidak ada yang berani sentuh. Migration script di migrations/<version>/pre-migration.py dan post-migration.py ter-version, ter-review, dan bisa dijalankan ulang. Pertama kali nulis terasa repot. Upgrade ketiga, terasa seperti hadiah dari diri Anda yang dulu.

5. Tes di copy. Selalu. Sebelum komit ke jadwal upgrade.

Hampir tidak ada yang melakukan ini dengan benar. Pola standarnya: jadwalkan upgrade Sabtu pagi, jalankan Sabtu pagi, ketemu module rusak jam dua siang, panik. Pola profesionalnya: clone production tiga minggu sebelumnya, jalankan upgrade lengkap di clone itu, perbaiki semua masalah di hari kerja yang tenang, lalu jadwalkan upgrade asli hanya setelah gladi resik berhasil.

Di Odoo.sh, hal ini built-in lewat staging branch. Di self-hosted butuh effort lebih, tapi tetap jadi pembeda antara go-live yang terkontrol dan yang kacau. Satu manufaktur di Surabaya yang kami tangani punya tiga puluh dua modul kustom; gladi resik pertama mereka menangkap sembilan bug nyata yang seandainya tidak ketahuan akan meledak di cutover production. Tiap bug butuh lima belas menit untuk diperbaiki di awal — kalau di tengah tekanan, bisa berjam-jam.

Seperti apa hasilnya setelah dua tahun

Kalau prinsip-prinsip ini dijalankan, gambaran dua tahun ke depan terlihat begini. Semua kode kustom Anda ada di satu repository, di bawah namespace sendiri. Upgrade jadi prosedur yang terdokumentasi, bukan bahan debat. Developer baru bisa baca folder addons dan langsung paham apa yang berubah dan kenapa. Percakapan dengan vendor atau tim internal jadi “upgrade ini akan butuh 8–16 jam kerja” — sebuah quote, bukan tebakan.

Kalau Odoo Anda hari ini terasa kebalikannya, perbaikannya bukan satu kali bersih-bersih. Ini soal perubahan kebiasaan, yang diterapkan ke setiap permintaan kustomisasi mulai sekarang. Kami senang kalau bisa membantu melihat kondisi codebase Anda dan menunjuk pembersihan mana yang paling berdampak — gratis satu jam, tanpa slide, langsung lihat kode.