Skip to main content
BlogDevOps

Renovate: Update Dependency Otomatis yang Dilakukan dengan Benar

Panduan praktis mengonfigurasi Renovate agar update dependency berjalan lancar, mencakup pengelompokan, aturan automerge, penjadwalan, dan pemeliharaan lockfile agar pull request tetap berguna, bukan berisik.

Matthews Wong

Software Engineer

Juli 20268 menit baca
Renovate: Update Dependency Otomatis yang Dilakukan dengan Benar

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.

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 updateRisiko umumRekomendasi
Patch (devDependencies)RendahAutomerge setelah CI lolos
Minor (dependency runtime)SedangAutomerge dengan jeda pengamatan singkat, atau wajibkan satu persetujuan
Major (dependency apa pun)TinggiJangan 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"]
    }
  ]
}
  1. 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.
  2. Batasi automerge dengan packageRules yang mencocokkan depType dan updateType, bukan satu flag automerge global, sehingga update major dan paket runtime tetap dikecualikan.
  3. 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.

FAQ

Pertanyaan Umum

Jawaban singkat untuk pertanyaan yang paling sering diajukan pembaca tentang topik ini.

Apa itu Renovate dan bagaimana bedanya dengan update dependency manual?

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.

Mengapa saya harus mengelompokkan update dependency daripada membiarkan Renovate membuka satu pull request per paket?

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.

Bagaimana cara mengaktifkan automerge pada pull request Renovate dengan aman tanpa berisiko merusak build?

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.

Apakah Renovate bisa memperbarui lockfile meskipun tidak ada versi dependency yang berubah?

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.

Bagaimana cara mengurangi jumlah pull request yang dibuka Renovate tanpa melewatkan update penting?

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.