Dependabot'tan Renovate Bot'a Gectim: 8 Repo'da 60 Gunluk Notlar

Dependabot ile bir buçuk yıl idare ettim. Sekiz aktif repo'da haftada ortalama 18-22 PR açıyor, hafta sonu Pazartesi sabahları gelen "23 unread Dependabot PR" bildirimleri rutinim olmuştu. Çoğunu körü körüne mergeliyordum, bazılarını kapatıyordum, bir kısmının da CI'da çakılıp kaldığını fark ediyordum. Bu yazı, neden Renovate Bot'a geçtiğimi, 60 gün sonraki tablo nasıl ve hangi tercihlerden vazgeçtiğimle ilgili.

Hemen söyleyeyim: Dependabot kötü bir araç değil. Sadece benim ihtiyaç duyduğum üç şeyi yapmıyor: agresif gruplama, monorepo'da workspace farkındalığı ve "patch'leri otomatik mergele, minor'ı bana sor, major'ı bekletme listesine al" gibi sofistike politikalar. Geçişimin sebebi de bu üç eksiklik.

Başlangıç Tablosu: Dependabot ile Hafta

Sekiz repo'mun dağılımı şöyleydi:

• 1 Python monorepo (Poetry + 3 ayrı service)
• 2 Astro/Node static site (devopself.com dahil)
• 1 Electron uygulama (npm + native deps)
• 2 küçük Go CLI tool
• 1 Terraform IaC repo
• 1 Docker Compose self-hosted services repo

Tipik bir hafta (Şubat 2026 ortalamasi):

| Metrik | Dependabot | |---|---| | Açılan PR sayısı | ~20 | | Manuel mergelenen | ~12 | | Auto-mergelenen (patch security only) | ~3 | | CI fail olup kapatılan | ~3-4 | | İncelenmeden 1 haftadan fazla bekleyen | ~5-7 |

PR yığını sürekli "şişiyordu". Özellikle Astro siteler için her Tailwind v4 alt-sürümü, her küçük PostCSS plugin güncellemesi ayrı PR olarak geliyordu. Bunları teker teker mergelemek anlamsızdı; ama Dependabot'un groups desteği o zamanlar (2024 sonu) hâlâ kabaca gelmiş, npm dev dependency'ler için tatmin edici bir gruplama yapmıyordu.

Renovate'ı Devreye Almak: İlk Yarım Saat

Renovate'ın GitHub App'ini onayladıktan sonra otomatik olarak her repo için "Configure Renovate" başlıklı bir onboarding PR'ı açıldı. Bu PR'da Renovate, repo'yu tarayıp önerdiği başlangıç konfigürasyonunu renovate.json olarak ekliyor ve "şu güncellemeleri görüyorum" diye uzun bir önizleme veriyor.

Benim için bu önizleme PR'ı tek başına kıymetliydi. Sekiz repo'da toplam 187 potansiyel güncelleme olduğunu söyledi — Dependabot'un haftalardır bana göstermediği transitive dep bump'ları dahil. Dependabot, yalnızca top-level package.json / pyproject.toml deklarasyonlarına bakıyordu; Renovate, lock dosyalarına da bakıp transitive update'leri öneriyordu.

Onboarding sonrası ilk işim base config'i config:recommended yerine kendi config:base türevime almak oldu:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    ":dependencyDashboard",
    ":semanticCommits",
    "group:allNonMajor"
  ],
  "timezone": "Europe/Istanbul",
  "schedule": ["after 6am and before 9am on monday"],
  "prHourlyLimit": 4,
  "prConcurrentLimit": 8,
  "packageRules": [
    {
      "matchUpdateTypes": ["patch", "pin", "digest"],
      "automerge": true,
      "platformAutomerge": true
    },
    {
      "matchDepTypes": ["devDependencies"],
      "matchUpdateTypes": ["minor", "patch"],
      "groupName": "dev-dependencies (non-major)"
    },
    {
      "matchPackagePatterns": ["^@astrojs/", "^astro"],
      "groupName": "astro stack"
    }
  ]
}

Üç şeyi anında değiştirdi:

1. Saat penceresi. Sadece Pazartesi sabah 06:00-09:00 arası PR açıyor. Hafta içi ortasında sürpriz Dependabot bildirimi yok.
2. PR limiti. Saatte 4, eş zamanlı 8. Bir göçük olsa bile boğulmuyorum.
3. Patch'leri otomatik mergele. GitHub'ın native auto-merge'ü ile birleştirildiğinde, CI yeşilse PR açıldığı saatte mergeleniyor; gelen kutuma hiç düşmüyor.

İlk hafta sonu, Pazartesi sabahı saat 09:30'da telefonuma 9 mergelendi bildirimi geldi — ve 4 tane review beklediğim PR vardı. Dependabot'tan beklediğim 22 yerine, kafam dağılmadan halledebileceğim 4 PR. Tek başına bu fark, geçişe değdi.

Python Monorepo: İşin Karıştığı Yer

Poetry tabanlı bir monorepo'da üç service var: api, worker, scheduler. Her birinin kendi pyproject.toml'u, ortak bir kök pyproject.toml'u ve tek bir poetry.lock dosyası. Dependabot bu yapıyı zar zor anlıyordu; her service için ayrı ayrı PR açıp aynı transitive dep'i 3 kere bump'lıyordu.

Renovate'da lockFileMaintenance + path-aware paket kuralları:

{
  "packageRules": [
    {
      "matchManagers": ["poetry"],
      "matchFileNames": ["api/**", "worker/**", "scheduler/**"],
      "groupName": "python services - {{depName}}",
      "groupSlug": "python-{{depName}}"
    },
    {
      "matchPackageNames": ["fastapi", "pydantic", "sqlalchemy"],
      "matchUpdateTypes": ["minor", "major"],
      "automerge": false,
      "labels": ["needs-manual-test"]
    }
  ],
  "lockFileMaintenance": {
    "enabled": true,
    "schedule": ["before 5am on the first day of the month"]
  }
}

lockFileMaintenance özellikle hoşuma gitti: ayda bir kere, manifest dosyalarda değişiklik olmasa bile poetry.lock ve package-lock.json dosyalarını yeniden çözüyor. Transitive güvenlik patch'lerini bu sayede ayda bir tek PR'da toplu alıyorum. Dependabot bunu doğrudan yapmıyor; sadece bir bağımlılık değiştiğinde lock'u günceller.

Kritik FastAPI/Pydantic upgrade'lerini manuel-test etiketiyle ayırmak da hayat kurtardı. pydantic v2'nin minor versiyon bir bump'ında bir CronJob'umda sessizce şema validasyonu kırıldı; çünkü auto-merge etmiş olsaydım, hafta içi bir öğleden sonra fark edecektim. Etiket sayesinde önce staging'de denedim.

Auto-Merge Politikası: Ne Korkmadan Otomatize Edilebilir?

60 gün boyunca elimde tuttuğum kural seti:

• patch (0.0.X): auto-merge — eğer CI yeşilse
• digest (Docker image / GitHub Actions SHA pin'i): auto-merge
• dev dependency minor: auto-merge — sadece test/build/lint paketleri
• runtime minor: manuel review
• major: dependency dashboard'da bekletme, opsiyonel manuel açma

Bu kuralı packageRules ile şöyle ifade ettim:

{
  "packageRules": [
    {
      "matchDepTypes": ["devDependencies"],
      "matchUpdateTypes": ["minor", "patch"],
      "matchPackageNames": [
        "eslint", "prettier", "vitest", "jest", "@types/**",
        "typescript", "tsx", "tsup", "vite"
      ],
      "automerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true
    }
  ]
}

dependencyDashboardApproval mucize bir özellik: major güncellemeler PR olarak açılmıyor, yalnızca repo'daki "Dependency Dashboard" adlı issue içinde "approve" tıklamamı bekliyor. Böylece 8 repo için 47 major güncelleme önerisi bir issue'da listelendi, hangisini ne zaman alacağıma kendim karar veriyorum. Dependabot'ta bunun karşılığı yok — bekletmek için PR'ı açıp kapatmak ya da dependabot.yml'de ignore eklemek gerekiyor.

60 Gün Sonra Sayılar

Aynı 8 repo, aynı geliştirici (ben). Mart-Nisan 2026 ortalaması:

| Metrik | Dependabot (önce) | Renovate (sonra) | |---|---|---| | Haftalık PR sayısı | ~20 | ~7 | | Auto-mergelenen oran | ~%15 | ~%55 | | Manuel review gereken | ~12 | ~3 | | CI fail olup kapatılan | ~3-4 | ~1 | | 1 haftadan eski bekleyen | ~5-7 | ~0-1 | | Aylık PR review süresi (kişisel ölçüm) | ~2.5 saat | ~45 dk |

PR sayısının azalması, daha az güncelleme aldığımdan değil — daha fazla gruplandığından. Renovate, Tailwind ekosistemi için tek PR, Astro core+integrations için tek PR, ESLint plugin'leri için tek PR açıyor. Mergeleme kararını paket başına değil, ekosistem başına veriyorum.

Vazgeçtiğim ve Sevmediğim 2 Şey

Her geçiş tatlı değil. İki yerde Renovate'tan vazgeçtim ya da geri adım attım.

1. Schedule String'leri Cron'dan Daha Sevimsiz

Renovate'ın schedule sözdizimi cron değil, kendi "later.js"-türevi bir DSL. "after 6am and before 9am on monday" okumak güzel ama yazmak hatalara açık. İki kere "every weekday" yazdım sandım, gerçekte hiçbir gün açılmadı. Sonunda bir cheat sheet'i renovate.json'un yorum satırına yapıştırmak zorunda kaldım (JSON'da yorum yok, JSON5 modu açtım):

// renovate.json5
{
  // Cheat: "after 6am and before 9am on monday"
  // Cheat: "every weekend"
  // Cheat: "before 5am on the first day of the month"
  "schedule": ["after 6am and before 9am on monday"]
}

Bu sürekli unuttuğum bir şey ve tatil dönüşü "neden Renovate hiç PR açmıyor" diye 20 dakika debug ettim.

2. Self-Hosted Renovate Runner'a Geçmeye Çalıştım, Vazgeçtim

GitHub App'i kullanmak yerine kendi GitHub Actions self-hosted runner'ım üzerinde Renovate'ı çalıştırmayı denedim. Sebep: private GitLab mirror'larım da var ve hepsi tek yerden yönetilsin istedim. Workflow şuna benziyordu:

# .github/workflows/renovate.yml
name: Renovate
on:
  schedule:
    - cron: '0 6 * * 1'
  workflow_dispatch:
jobs:
  renovate:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4
      - uses: renovatebot/github-action@v40
        with:
          configurationFile: .github/renovate-global.json
          token: ${{ secrets.RENOVATE_TOKEN }}

İki hafta uğraştım: secret yönetimi, GitLab token rotasyonu, runner'da Node sürümü, cache invalidation... GitHub App'in 5 dakikalık kurulumla verdiği konforu, self-hosted runner ile haftalarca tutturamadım. Sonunda Hosted App'e geri döndüm; GitLab repo'larını şimdilik manuel takip ediyorum. Bu, "yapabildiğim için yapma" tuzağına düşmemin tipik örneği.

Dependabot'un Hâlâ Tek Olduğu Bir Alan: Security Advisory

Renovate'a tamamen geçmedim. GitHub Security Advisory tabanlı security update'leri için Dependabot'u açık bıraktım. Sebep: GitHub'ın Advisory veritabanı GitHub'a entegre; Dependabot bir CVE açıklanır açıklanmaz dakikalar içinde PR atıyor. Renovate de güvenlik PR'ları açıyor ama Advisory feed entegrasyonu o kadar yakın değil.

dependabot.yml minimuma indirildi:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 0  # sadece security update'ler

open-pull-requests-limit: 0 numarası, Dependabot'u "yalnızca security alert" moduna alıyor. Rutin update'leri Renovate yapıyor, kritik CVE'leri Dependabot anında yakalıyor. İki bot çakışmıyor çünkü farklı paket aralıklarına bakıyorlar.

Notlar (Aklımda Tutmaya Değer 5 Madde)

1. Auto-merge için CI'ınızın güvenilir olduğundan emin olun. Sızdıran bir test suite ile auto-merge açmak, herhangi bir bot türünden bağımsız olarak felakettir. Geçişten önce flaky testleri bir hafta düzelttim.
2. Major güncellemeleri PR olarak değil dashboard'da tutun. Bekletme listesi olarak "Dependency Dashboard" issue'su, Slack'ten daha iyi bir prioritization aracı oldu.
3. lockFileMaintenance ayda bir kez transitive dep güvenlik patch'lerini topluyor. Dependabot'tan beklemediğiniz en değerli özellik bu.
4. Schedule DSL'ini bir cheat sheet ile sabitleyin. Cron alışkanlığınız varsa, ilk hafta sık hata yapacaksınız.
5. Hibrit kalın. Security için Dependabot, routine için Renovate. İkisini birden açmak çakışma değil, savunma derinliği veriyor.

Sonuç: ben bu 60 gün boyunca dependency review için harcadığım zamanı yaklaşık üçte bire düşürdüm, ekosistem-bazlı kararlar almaya başladım ve gelen kutuma yansıyan PR sayısı %65 azaldı. Renovate "her şeyi otomatize edelim" bir araç değil; otomasyon ile kontrol arasındaki dengeyi sizin yerinize değil, sizin için modelleyen bir araç. Bunu fark ettiğimde, her gece bir packageRule daha eklemek yerine, ayda bir kez kuralları gözden geçirmek yetmeye başladı.

Bir sonraki yazıda muhtemelen dependencyDashboardApproval workflow'unu Linear/GitHub Project entegrasyonu ile birleştirmeyi anlatacağım — onu da denedim, üçte ikisi çalışıyor, üçte biri komik şekilde kırık. Eğer kendi Renovate config'inizi paylaşmak isterseniz, GitHub'dan bana yazın; başkasının packageRules listesini okumak benim için her zaman ilham verici.