Renovate: Update Dependency Otomatis yang Dilakukan dengan Benar

Foto oleh Brickset on flickr
Renovate adalah bot open-source yang memindai berkas manifes repository dan membuka pull request setiap kali versi baru sebuah dependency tersedia. Berbeda dengan update manual, Renovate berjalan sesuai jadwal yang Anda tentukan, memeriksa setiap dependency secara terus-menerus, dan dapat menggabungkan secara otomatis update berisiko rendah setelah pengujian lolos, sehingga tidak ada lagi yang perlu mengingat untuk memeriksa paket yang sudah usang.
Satu pull request per dependency tidak akan efisien begitu sebuah repository memiliki puluhan paket, karena reviewer akan menyetujui banyak diff yang hampir identik. Mengelompokkan dengan packageRules dan groupName menggabungkan paket-paket terkait, misalnya seluruh ekosistem tooling atau sebuah framework beserta definisi tipenya, ke dalam satu pull request, membuat review lebih cepat dan mengurangi risiko update sebagian meninggalkan versi yang tidak sesuai.
Batasi automerge hanya pada jenis update berisiko rendah menggunakan packageRules yang mencocokkan depType dan updateType, misalnya mengaktifkan automerge hanya untuk update patch dan minor pada devDependencies setelah CI lolos. Sisakan update versi major dan perubahan dependency runtime untuk review manual, karena semantic versioning hanya menandakan niat, bukan menjamin keamanan, dan aktifkan platformAutomerge agar penggabungan native dari platform hosting Anda tetap menghormati aturan branch protection yang ada.
Ya, opsi lockFileMaintenance memberi tahu Renovate untuk secara berkala membangun ulang lockfile sesuai jadwalnya sendiri, yang menangkap update dependency transitif dan patch keamanan yang sebaliknya akan dibiarkan sampai update dependency langsung berikutnya. Menjalankannya setiap minggu, terpisah dari jadwal update utama, membuat setiap penyegaran lockfile menjadi pull request kecil yang mudah direview.
Tetapkan jadwal mingguan yang eksplisit dikombinasikan dengan prConcurrentLimit dan prHourlyLimit untuk mengendalikan kecepatan pull request baru, kelompokkan paket-paket terkait agar beberapa update datang sebagai satu diff, dan gunakan issue dependency dashboard milik Renovate untuk melacak semua yang tertunda di satu tempat. Membatasi frekuensi update versi major dengan jadwal tersendiri juga menjaga perubahan berisiko lebih tinggi yang jarang terjadi agar tidak tenggelam di antara update minor rutin.

Foto oleh Brickset on flickr
Ringkasan Utama
Renovate menjaga dependency tetap terkini dengan membuka pull request terjadwal, tapi konfigurasi bawaannya cepat menjadi berisik. Menetapkan jadwal eksplisit dan batas PR, mengelompokkan paket terkait, membatasi automerge berdasarkan risiko, serta menjalankan lockFileMaintenance mingguan mengubah Renovate menjadi pipeline yang tenang dan bisa dipercaya, bukan sumber kelelahan notifikasi.
Setiap repository pada akhirnya akan menumpuk puluhan dependency, dan setiap dependency tersebut pada akhirnya perlu diperbarui. Jika dibiarkan, hal ini akan berubah menjadi kumpulan peringatan keamanan, perubahan yang merusak yang tidak disadari siapa pun, serta lockfile yang tidak tersentuh selama berbulan-bulan. Renovate mengatasi masalah ini dengan membuka pull request untuk dependency yang sudah ketinggalan versi sesuai jadwal yang Anda tentukan, tetapi konfigurasi bawaannya jarang menjadi konfigurasi yang benar-benar Anda inginkan.
Panduan ini membahas pengaturan Renovate yang paling penting dalam praktik nyata: mengelompokkan paket-paket terkait agar reviewer tidak kebanjiran pull request satu paket, memilih aturan automerge yang aman, menjadwalkan update agar tidak bertabrakan dengan rilis, dan menjaga lockfile tetap segar tanpa kerja manual tambahan. Contoh-contoh yang dibahas berasal dari konfigurasi repository produksi nyata, bukan sekadar bawaan default.
Renovate hadir dengan preset rekomendasi yang sudah cukup baik menutupi kebanyakan default, tetapi tiga pengaturan berikut layak diatur secara eksplisit sejak awal: timezone, schedule, dan batas jumlah pull request. Tanpa jadwal eksplisit, Renovate akan membuka pull request kapan saja, sehingga tim Anda bangun dan menemukan tumpukan notifikasi. Menetapkan jendela mingguan membuat update lebih terprediksi, dan membatasi jumlah pull request bersamaan serta per jam mencegah Renovate membanjiri runner CI Anda begitu ia mulai bekerja di sebuah repository baru. Pengaturan timezone lebih penting daripada yang terlihat, karena string schedule seperti before six on Monday dievaluasi berdasarkan timezone tersebut, dan timezone yang tidak sesuai secara diam-diam menggeser setiap jendela waktu beberapa jam, membingungkan siapa pun yang mencoba memahami kapan pull request sebenarnya akan muncul.
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["config:recommended"],
"timezone": "Asia/Jakarta",
"schedule": ["before 6am on monday"],
"labels": ["dependencies"],
"prConcurrentLimit": 5,
"prHourlyLimit": 2,
"lockFileMaintenance": {
"enabled": true,
"schedule": ["before 6am on monday"]
}
}Tetapkan prConcurrentLimit dan prHourlyLimit meskipun pada repository kecil. Tanpa pembatasan ini, proses onboarding pertama pada repository dengan lockfile yang sudah usang bisa membuka tiga puluh pull request atau lebih dalam satu kali proses, yang membanjiri CI dan membuat review menjadi mustahil.
Secara default, Renovate membuka satu pull request untuk setiap dependency. Ini presisi, tetapi tidak akan efisien begitu jumlah paket bertambah banyak. Solusinya adalah packageRules dengan groupName, yang menggabungkan dependency terkait ke dalam satu pull request. Kelompokkan paket yang dirilis bersamaan atau memiliki dampak yang saling terkait, sehingga reviewer bisa memahami seluruh kelompok dalam satu kali pemeriksaan, bukan menyetujui lima belas diff yang hampir identik satu per satu.
{
"packageRules": [
{
"description": "Group all ESLint packages together",
"matchPackageNames": ["eslint", "eslint-config-*", "eslint-plugin-*"],
"groupName": "eslint"
},
{
"description": "Group Next.js and React together, they ship in lockstep",
"matchPackageNames": ["next", "react", "react-dom", "@types/react", "@types/react-dom"],
"groupName": "next-react"
},
{
"description": "Weekly digest for everything else",
"matchPackagePatterns": ["*"],
"groupName": "all non-major dependencies",
"matchUpdateTypes": ["minor", "patch"]
}
]
}Automerge adalah fitur yang membuat Renovate benar-benar berguna, tetapi hanya jika aturannya sesuai dengan risiko sebenarnya dari setiap jenis update. Update patch dan minor pada tooling pengembangan biasanya aman untuk digabungkan secara otomatis setelah pengujian lolos, karena semantic versioning menjanjikan kompatibilitas ke belakang dan dampak jika terjadi kegagalan terbatas pada pipeline build Anda. Update major dan apa pun yang menyentuh dependency runtime membutuhkan campur tangan manusia, karena semantic versioning hanya menjanjikan niat, bukan keamanan yang terjamin. Tabel di bawah ini mencerminkan titik awal yang dapat diadopsi kebanyakan repository tanpa banyak penyesuaian, meskipun tim dengan cakupan pengujian integrasi yang sangat menyeluruh dapat secara wajar mendorong automerge lebih jauh ke kategori update minor dan bahkan major seiring waktu.
| Jenis update | Risiko umum | Rekomendasi |
|---|---|---|
| Patch (devDependencies) | Rendah | Automerge setelah CI lolos |
| Minor (dependency runtime) | Sedang | Automerge dengan jeda pengamatan singkat, atau wajibkan satu persetujuan |
| Major (dependency apa pun) | Tinggi | Jangan pernah automerge, beri label untuk review manual |
Automerge hanya mencerminkan tingkat kepercayaan terhadap test suite Anda sendiri. Jika pengujian Anda tidak menjangkau jalur kode yang sebenarnya disentuh oleh sebuah dependency, automerge akan dengan senang hati menggabungkan update yang rusak begitu build berubah hijau.
Renovate mendukung dua mekanisme automerge. Dengan automergeType diatur ke pr, Renovate membuka pull request normal, menunggu pemeriksaan wajib lolos, lalu menggabungkannya sendiri. Dengan platformAutomerge diaktifkan, proses penggabungan justru ditangani oleh fitur automerge native dari platform hosting, yang menghormati aturan branch protection dan cocok berjalan bersama reviewer wajib. Kebanyakan tim sebaiknya memilih automerge platform begitu pemeriksaan CI mereka sudah dapat dipercaya, karena ini menjaga satu jejak audit tunggal dalam riwayat merge milik platform itu sendiri.
{
"packageRules": [
{
"description": "Automerge devDependencies minor/patch after CI passes",
"matchDepTypes": ["devDependencies"],
"matchUpdateTypes": ["minor", "patch"],
"automerge": true,
"automergeType": "pr",
"platformAutomerge": true
},
{
"description": "Never automerge majors, always require manual review",
"matchUpdateTypes": ["major"],
"automerge": false,
"labels": ["dependencies", "needs-review"]
}
]
}Bahkan ketika tidak ada versi dependency di manifes Anda yang berubah, dependency transitif tetap bergeser seiring waktu seiring paket upstream merilis versi patch baru. lockFileMaintenance memberi tahu Renovate untuk secara berkala membangun ulang lockfile sesuai jadwalnya sendiri, menangkap update transitif dan patch keamanan yang sebaliknya akan dibiarkan begitu saja sampai update dependency langsung berikutnya. Menjalankannya dengan jadwal mingguan, terpisah dari jadwal update reguler Anda, membuat diff tetap kecil dan mudah direview. Hal ini paling penting bagi tim yang mengandalkan audit lockfile atau pemindai kerentanan, karena dependency transitif dengan advisory yang sudah diketahui bisa saja tertanam di lockfile selama berbulan-bulan jika tidak ada yang mendorong Renovate menyentuh bagian pohon dependency tersebut.
Menggabungkan lockFileMaintenance dengan jadwal mingguan dan groupName tersendiri membuat penyegaran lockfile tetap menjadi satu pull request kecil yang terprediksi, bukan diff besar yang muncul sekali dalam satu kuartal.
Kegagalan terbesar dengan Renovate bukanlah kesalahan konfigurasi, melainkan pengabaian. Antrean pull request yang tidak pernah direview oleh siapa pun melatih tim untuk mengabaikan Renovate sepenuhnya, sehingga menggagalkan tujuannya. Beberapa kebiasaan berikut menjaga rasio sinyal terhadap gangguan tetap tinggi bahkan berbulan-bulan setelah pengaturan awal.
Pull request onboarding milik Renovate sendiri menyertakan pratinjau setiap konfigurasi yang akan diterapkan. Baca dengan teliti sebelum menggabungkannya, karena inilah kesempatan paling murah untuk menangkap kesalahan pengelompokan atau penjadwalan sebelum menghasilkan pull request sungguhan.
Tidak satu pun dari pengaturan ini bersifat eksotis. Pengelompokan, aturan automerge yang terbatas ruang lingkupnya, jadwal eksplisit, dan pemeliharaan lockfile semuanya adalah default yang sudah terdokumentasi namun kebanyakan tim tidak pernah sempat menyesuaikannya. Hasilnya adalah pipeline dependency yang diam-diam menjaga repository tetap terkini tanpa berubah menjadi pekerjaan sampingan bagi siapa pun yang mereview pull request. Mulailah dari konfigurasi dasar pada panduan ini, amati bagaimana pull request pada bulan pertama berperilaku, lalu sesuaikan aturan pengelompokan dan automerge berdasarkan apa yang benar-benar muncul, bukan sekadar menerka-nerka di awal.