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.
Memulai dari dasar yang masuk akal
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.
Mengelompokkan update agar review lebih masuk akal
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.
- Kelompokkan paket tooling yang berbagi format konfigurasi, seperti semua plugin dan konfigurasi ESLint, karena biasanya rusak bersamaan ketika versi major baru dirilis.
- Kelompokkan paket framework yang dirilis serentak, seperti sebuah framework frontend beserta definisi tipe resminya, sehingga ketidaksesuaian versi tidak pernah menyusup lewat update sebagian.
- Kelompokkan semua update minor dan patch yang tersisa ke dalam satu ringkasan mingguan, sambil menyisakan update major dalam pull request tersendiri yang mendapat pemeriksaan lebih ketat.
{
"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"]
}
]
}Memilih aturan automerge yang aman
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.
Menyiapkan automerge dengan aman
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"]
}
]
}- Pastikan pipeline CI Anda menjalankan pemeriksaan yang sama untuk pull request dependency seperti untuk pull request biasa, jika tidak, automerge tidak sedang memvalidasi apa pun.
- Batasi automerge dengan packageRules yang mencocokkan depType dan updateType, bukan satu flag automerge global, sehingga update major dan paket runtime tetap dikecualikan.
- Berikan Renovate jeda sekitar dua jam sebelum mengharapkan penggabungan terjadi, karena branch perlu diperbarui sesuai base branch dan pemeriksaan perlu sudah selesai lebih dulu.
Menjaga lockfile tetap segar dengan lockFileMaintenance
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.
Mengendalikan keramaian pull request dalam jangka panjang
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.
- Review dan gabungkan pull request patch serta minor yang sudah dikelompokkan setiap minggu, meskipun hanya sekadar membaca tautan changelog yang disertakan Renovate di isi pull request.
- Gunakan issue dependency dashboard, yang dapat dikelola otomatis oleh Renovate, sebagai satu tempat untuk melihat semua update yang tertunda daripada menyisir daftar pull request yang panjang.
- Batasi frekuensi pull request versi major dengan jadwal tersendiri agar muncul lebih jarang dan mendapat perhatian khusus, bukan tenggelam di antara update minor rutin.
- Secara berkala bersihkan packageRules yang merujuk pada dependency yang sudah tidak lagi Anda gunakan, karena aturan usang diam-diam berhenti cocok dengan apa pun dan hanya memenuhi berkas konfigurasi.
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.

