Renovate dapat mengotomatisasi update dependency tanpa menghasilkan puluhan pull request sekaligus. Kuncinya adalah membatasi kapan PR dibuat, mengelompokkan update yang memang berkaitan, dan hanya mengaktifkan auto-merge untuk perubahan berisiko rendah setelah seluruh pemeriksaan CI yang diwajibkan berhasil.

Guardrail tidak cukup diterapkan melalui renovate.json. Branch protection, required status checks, kualitas test suite, dan prosedur rollback tetap menjadi lapisan pengaman utama. Renovate mengatur alur pembaruan, sedangkan platform Git dan CI menentukan apakah perubahan benar-benar aman untuk digabungkan.

Alur onboarding Renovate

Renovate dapat dijalankan melalui aplikasi yang disediakan untuk platform Git tertentu atau sebagai bot yang di-host sendiri. Pada kedua model tersebut, proses awal yang disarankan adalah:

  1. Pasang aplikasi Renovate atau siapkan bot dengan izin minimum yang diperlukan untuk membaca repository dan membuat branch serta pull request.
  2. Biarkan Renovate membuat onboarding PR. PR ini biasanya berisi konfigurasi awal dan ringkasan dependency yang terdeteksi.
  3. Tambahkan atau sesuaikan renovate.json di root repository.
  4. Pastikan CI berjalan pada branch Renovate, bukan hanya pada branch yang dibuat manusia.
  5. Aktifkan branch protection dan tandai pemeriksaan penting sebagai required status checks.
  6. Merge onboarding PR setelah konfigurasi, izin bot, dan hasil deteksi dependency ditinjau.

Sebelum konfigurasi diaktifkan, validasi sintaks dan nama opsinya:

npx --yes renovate-config-validator renovate.json

Validator membantu menemukan JSON yang tidak valid, nama opsi yang salah, atau nilai konfigurasi yang tidak didukung. Untuk instalasi self-hosted, jalankan dry run pada repository uji dan periksa log debug sebelum memberi bot akses ke banyak repository.

Konfigurasi renovate.json dengan guardrail

Konfigurasi berikut merupakan titik awal yang konservatif. Ia membatasi jumlah PR, menjalankan update rutin pada jendela waktu tertentu, menunda rilis yang masih terlalu baru, memisahkan major dari minor dan patch, serta hanya melakukan auto-merge pada patch tooling yang telah dimasukkan ke allowlist.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended"],
  "timezone": "Asia/Jakarta",
  "dependencyDashboard": true,
  "prConcurrentLimit": 5,
  "prHourlyLimit": 2,
  "schedule": ["before 6am on monday"],
  "minimumReleaseAge": "3 days",
  "internalChecksFilter": "strict",
  "separateMajorMinor": true,
  "separateMinorPatch": true,
  "rebaseWhen": "behind-base-branch",
  "vulnerabilityAlerts": {
    "enabled": true,
    "labels": ["security"]
  },
  "lockFileMaintenance": {
    "enabled": true,
    "schedule": ["before 5am on monday"],
    "automerge": false
  },
  "packageRules": [
    {
      "description": "Major update memerlukan persetujuan eksplisit",
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true,
      "automerge": false,
      "labels": ["dependencies", "major-update"]
    },
    {
      "description": "Kelompokkan patch dan minor type definitions",
      "matchManagers": ["npm"],
      "matchDepTypes": ["devDependencies"],
      "matchPackageNames": ["@types/*"],
      "matchUpdateTypes": ["patch", "minor"],
      "groupName": "TypeScript type definitions",
      "automerge": false
    },
    {
      "description": "Auto-merge hanya untuk patch lint tooling yang diizinkan",
      "matchManagers": ["npm"],
      "matchDepTypes": ["devDependencies"],
      "matchPackageNames": ["eslint", "@eslint/*", "eslint-*"],
      "matchUpdateTypes": ["patch"],
      "groupName": "Low-risk lint tooling patches",
      "automerge": true,
      "automergeType": "pr",
      "platformAutomerge": true,
      "labels": ["dependencies", "automerge-candidate"]
    },
    {
      "description": "Minor lint tooling tetap memerlukan review",
      "matchManagers": ["npm"],
      "matchDepTypes": ["devDependencies"],
      "matchPackageNames": ["eslint", "@eslint/*", "eslint-*"],
      "matchUpdateTypes": ["minor"],
      "groupName": "Lint tooling minor updates",
      "automerge": false
    }
  ]
}

Daftar paket pada aturan auto-merge harus disesuaikan dengan repository. Jangan menyalin allowlist secara buta: patch formatter, compiler, linter, atau generator kode tetap dapat mengubah hasil build dan perilaku pipeline.

Mengapa pembatasan PR diperlukan?

  • prConcurrentLimit membatasi jumlah PR Renovate yang terbuka pada saat bersamaan.
  • prHourlyLimit mencegah lonjakan PR saat Renovate pertama kali dijalankan atau setelah periode tidak aktif.
  • schedule membatasi waktu pembuatan atau pembaruan branch oleh Renovate. Eksekusi aktual tetap bergantung pada seberapa sering bot dijalankan.
  • minimumReleaseAge memberi waktu agar rilis baru mengalami penggunaan lebih luas sebelum masuk ke repository.
  • internalChecksFilter dengan nilai strict membantu menahan update yang belum melewati pemeriksaan internal seperti umur minimum rilis.

Jadwal bukan jaminan bahwa PR akan langsung tersedia pada awal jendela waktu. Runner Renovate harus benar-benar berjalan ketika jadwal tersebut aktif.

Dependency Dashboard sebagai pintu kontrol

Dependency Dashboard adalah issue yang dikelola Renovate untuk menampilkan update tertunda, error konfigurasi, dan pembaruan yang memerlukan persetujuan. Pada contoh di atas, major update tidak langsung dibuatkan PR sebelum disetujui melalui dashboard.

Persetujuan di Dependency Dashboard hanya mengizinkan Renovate membuat branch atau PR. Tindakan tersebut bukan pengganti code review dan bukan persetujuan deployment. Major update tetap perlu ditinjau untuk perubahan API, migrasi konfigurasi, perubahan format data, dan dampak operasional.

Strategi grouping patch dan minor update

Grouping mengurangi jumlah PR dan eksekusi CI, tetapi satu grup yang terlalu besar dapat menyamarkan sumber kegagalan. Jika 20 dependency digabung dalam satu branch lalu integration test gagal, tim harus melakukan bisect untuk mengetahui paket penyebabnya.

Gunakan grouping berdasarkan hubungan teknis, bukan sekadar karena semuanya berjenis patch atau minor. Contoh grup yang relatif mudah dipahami adalah:

  • Paket dalam keluarga yang sama, seperti type definitions atau plugin linter.
  • Tooling build yang diuji oleh rangkaian CI yang sama.
  • Dependency dalam satu area monorepo dengan pemilik dan pipeline yang sama.
  • Paket framework yang memang harus bergerak bersama menurut dokumentasi upstream.

Hindari satu grup global bernama seperti all non-major dependencies untuk repository besar. Update database driver, SDK cloud, framework frontend, dan test runner memiliki domain kegagalan yang berbeda meskipun semuanya hanya patch.

Mencegah grouping menyamarkan kegagalan

  1. Batasi jumlah paket dalam satu keluarga melalui matchPackageNames, matchDepTypes, atau area file yang relevan.
  2. Pisahkan patch dan minor bila tingkat risikonya berbeda. separateMinorPatch membantu mencegah keduanya tercampur secara tidak sengaja.
  3. Jangan melakukan auto-merge pada grup yang mencakup dependency runtime kritis.
  4. Jika grup berulang kali gagal, pecah menjadi PR individual dan jalankan ulang CI untuk setiap paket.
  5. Periksa manifest dan lock file. Kegagalan dapat berasal dari dependency transitif yang ikut berubah, bukan dependency langsung yang terlihat di judul PR.

Grouping juga dapat menimbulkan konflik aturan. Beberapa packageRules dapat cocok dengan dependency yang sama, lalu hasilnya digabung menurut konfigurasi Renovate. Karena itu, buat aturan sespesifik mungkin dan validasi perilaku pada repository uji.

Auto-merge yang benar-benar bergantung pada CI

automerge: true bukan satu-satunya syarat keamanan. Repository harus memiliki branch protection dengan status checks yang diwajibkan. Setidaknya, pilih pemeriksaan yang merepresentasikan risiko aplikasi:

  • Unit test dan integration test.
  • Type checking dan kompilasi produksi.
  • Lint atau validasi statis yang relevan.
  • Build image atau artefak deployable.
  • Migration test jika dependency dapat memengaruhi database.
  • Security scanning bila merupakan bagian wajib dari kebijakan repository.

Tanpa required checks, tidak adanya hasil CI dapat dianggap berbeda dari kegagalan CI. Karena itu, guardrail terkuat harus berada pada platform Git: branch tidak boleh digabung sebelum seluruh pemeriksaan wajib berstatus sukses. platformAutomerge meminta mekanisme auto-merge platform menangani proses tersebut dan menghormati proteksi branch yang dikonfigurasi.

Gunakan auto-merge hanya untuk kombinasi yang eksplisit, misalnya dependency pengembangan, update patch, dan package allowlist. Jangan membuat aturan umum yang mengaktifkan auto-merge untuk semua patch karena nomor versi tidak menjamin tidak adanya regresi.

Major update, patch keamanan, dan lock file

Major update

Major update sebaiknya selalu dipisahkan dan memerlukan persetujuan eksplisit. Sebelum merge, periksa:

  • Changelog dan panduan migrasi upstream.
  • API yang dihapus atau berubah.
  • Perubahan konfigurasi default.
  • Kompatibilitas runtime, plugin, database, dan dependency sejawat.
  • Rencana deployment bertahap dan rollback.

Untuk major update besar, lebih aman membuat branch migrasi khusus daripada terus memperbarui PR otomatis yang telah bercampur dengan perubahan aplikasi lain.

Patch keamanan

Patch tidak otomatis berarti aman, dan update keamanan tidak selalu berbentuk patch. Gunakan advisory dari platform, registry, atau pemindai keamanan sebagai sumber klasifikasi. Opsi vulnerabilityAlerts dapat membantu Renovate membuat PR dari alert yang tersedia pada platform atau layanan yang digunakan.

PR keamanan sebaiknya diberi prioritas dan label khusus, tetapi tidak harus langsung di-auto-merge. Tinjau apakah versi perbaikan kompatibel, apakah exploit relevan dengan cara aplikasi menggunakan paket tersebut, dan apakah ada mitigasi sementara. Untuk kerentanan kritis, tim dapat sementara mengubah jadwal atau minimumReleaseAge bagi paket dan versi yang spesifik, lalu menghapus pengecualian setelah insiden selesai.

Jangan mendeteksi patch keamanan hanya dengan matchUpdateTypes: ["patch"]. Jenis perubahan versi tidak membawa informasi apakah sebuah rilis memperbaiki kerentanan.

Lock file maintenance

Lock file maintenance menyegarkan dependency transitif dalam batas yang diizinkan manifest tanpa harus mengubah setiap constraint dependency langsung. Ini berguna untuk memperoleh perbaikan transitif, membersihkan entri lama, atau menyelaraskan hasil resolver setelah perubahan tooling.

PR lock file dapat mengandung banyak perubahan yang sulit ditinjau. Jalankan secara terjadwal, jangan auto-merge pada tahap awal, dan pastikan CI menginstal dependency menggunakan mode yang menghormati lock file. Jika hasil lock file berbeda antara lokal dan CI, periksa versi package manager, konfigurasi registry, platform runtime, serta apakah lock file dibuat ulang dengan tooling yang konsisten.

Rollout bertahap, rollback, dan metrik

Strategi rollout

  1. Tahap observasi: aktifkan Dependency Dashboard, jadwal, dan batas PR tanpa auto-merge.
  2. Tahap grouping: kelompokkan satu atau dua keluarga dependency yang memiliki cakupan test jelas.
  3. Tahap auto-merge terbatas: izinkan patch untuk package allowlist berisiko rendah.
  4. Tahap perluasan: tambahkan paket hanya jika data menunjukkan CI stabil dan rollback jarang diperlukan.
  5. Tahap standardisasi: buat preset organisasi setelah pola yang sama terbukti bekerja pada beberapa repository.

Mulailah dari repository dengan test suite kuat dan deployment yang dapat dipulihkan. Jangan menjadikan repository kritis dengan cakupan test rendah sebagai tempat eksperimen pertama.

Prosedur rollback

Jika update yang telah digabung menyebabkan regresi:

  1. Hentikan atau rollback deployment sesuai prosedur layanan.
  2. Revert commit merge agar manifest dan lock file kembali bersama-sama.
  3. Nonaktifkan sementara aturan auto-merge yang terkait atau kecualikan paket bermasalah.
  4. Buat issue dengan versi buruk, gejala, log, dan cakupan dampak.
  5. Uji versi pengganti atau tunggu rilis upstream sebelum mengaktifkan kembali otomatisasi.

Revert tanpa mengubah kebijakan Renovate dapat menyebabkan update yang sama diusulkan kembali. Gunakan pengecualian yang spesifik dan catat alasan serta kapan pengecualian harus dihapus agar dependency tidak tertinggal tanpa batas waktu.

Metrik yang perlu dipantau

  • Jumlah PR Renovate per minggu: menunjukkan apakah grouping dan batas PR bekerja.
  • Waktu median hingga merge: PR yang terlalu lama terbuka dapat menandakan antrean review, CI lambat, atau grouping terlalu kompleks.
  • Tingkat kegagalan build: ukur proporsi branch Renovate yang gagal pada required checks.
  • Tingkat rollback atau revert: indikator langsung bahwa allowlist auto-merge terlalu agresif atau test suite belum memadai.
  • Umur dependency tertunda: membantu mendeteksi backlog yang tersembunyi oleh batas PR.
  • Durasi CI per PR dependency: berguna untuk menilai apakah grouping benar-benar mengurangi biaya tanpa menyulitkan diagnosis.

Tinjau metrik berdasarkan jenis update dan kelompok dependency. Angka total dapat menyesatkan: tooling patch mungkin sangat stabil, sedangkan update SDK atau driver database memiliki tingkat kegagalan yang jauh lebih tinggi.

Checklist implementasi

  • Konfigurasi lolos renovate-config-validator.
  • Dependency Dashboard aktif dan memiliki pemilik operasional.
  • Jumlah PR dan jadwal disesuaikan dengan kapasitas review.
  • Major update memerlukan persetujuan eksplisit.
  • Grouping dibatasi berdasarkan keluarga atau area teknis.
  • Auto-merge hanya berlaku untuk package allowlist dan update patch berisiko rendah.
  • Branch protection mewajibkan seluruh status CI yang relevan.
  • Vulnerability alert memiliki jalur penanganan yang lebih cepat.
  • Lock file maintenance dijadwalkan dan diuji seperti perubahan dependency lain.
  • Tim memiliki prosedur revert, pengecualian sementara, dan evaluasi metrik.

Dengan konfigurasi bertahap seperti ini, Renovate tetap menjaga dependency diperbarui tanpa memindahkan risiko dari pekerjaan manual ke auto-merge yang tidak terkontrol.