Ruby on Rails'te Cron Job Whenever ve Zamanlanmış Görevler

Ruby on Rails ekosisteminde periyodik görevler; kullanıcı verilerinin temizlenmesi, e-posta bildirimlerinin toplu gönderimi, gece saatlerinde finansal mutabakatların hesaplanması ve veritabanı yedeklerinin arşivlenmesi gibi arka plan operasyonlarında kritik bir role sahiptir. Linux sunucularda zamanlanmış görevleri yürütmenin köklü standardı sistem düzeyindeki cron servisidir. Ancak Rails projelerinde ham crontab satırlarını elle yönetmek; Ruby sürüm yöneticileri (rbenv, RVM), Bundler ortamı, Rails çalışma ortamı (production/staging) ve ortam değişkenleri nedeniyle karmaşık ve hata yapmaya açık bir süreçtir.

Whenever gem'i, Ruby dilinin zarif alan dili (DSL) sözdizimini kullanarak config/schedule.rb dosyasında crontab kuralları tanımlamanıza olanak tanır. Yazdığınız Ruby kodları, dağıtım (deployment) sırasında derlenerek doğrudan işletim sisteminin crontab tablosuna aktarılır. Diğer yandan modern Rails 8 sürümüyle birlikte gelen Solid Queue ve config/recurring.yml mimarisi, harici sistem servislerine bağımlı olmadan veritabanı üzerinden periyodik iş yönetimi sağlayarak yeni bir dönemi başlatmıştır.

Bu kapsamlı rehberde, Ruby on Rails projelerinizde Whenever gem kurulumunu, farklı görev türlerini, Capistrano entegrasyonu ile otomatik crontab senkronizasyonunu, Rails 8 Solid Queue yapılandırmasını ve karşılaşılan yaygın PATH ile veritabanı bağlantı hatalarını ayrıntılı olarak ele alacağız. Ayrıca konteyner tabanlı ortamlarda sunucuya crontab yüklemeden HTTP webhook üzerinden tetikleme mimarisini inceleyeceğiz.

Ruby on Rails Uygulamalarında Cron İhtiyacı ve Çözüm Mimarileri

Rails'te doğru zamanlayıcı, görevin süresi ve çalıştığı altyapıya göre seçilir: seyrek sistem işleri için Whenever, sık çalışan ve kuyrukta izlenmesi gereken işler için Solid Queue, yalnızca HTTPS ile tetiklenebilen uç noktalar için harici HTTP zamanlayıcı uygundur. Whenever sunucuda cron gerektirir; Solid Queue scheduler ve worker süreçlerine, HTTP modeli ise genel ağdan erişilebilen güvenli bir rotaya ihtiyaç duyar. Bu üç modelden yalnızca birini aynı işin sahibi yapmak mükerrer yürütmeyi önler.

Birden fazla framework işleten ekipler aynı ayrımı başka ekosistemlerde de uygulayabilir. Örneğin Django Celery Beat veritabanı zamanlayıcısı, Solid Queue gibi periyotları bir uygulama süreci üzerinden yönetir; ancak görevlerin yürütülmesi için Celery worker ve beat süreçlerinin birlikte çalışması gerekir.

1. İşletim Sistemi Seviyesinde Cron (Whenever): Klasik sanal sunucu (VPS) veya tahsisli (dedicated) makinelerde en yaygın kullanılan modeldir. Görev zamanı geldiğinde Linux cron arka plan programı (crond) tetiklenir, bundle exec rails runner veya ilgili Rake görevini başlatır. Görev bittiğinde süreç bellekten tamamen çıkar. Bu model, boşta bekleyen bir worker sürecine ihtiyaç duymadığı için RAM tüketimini minimumda tutar. Temel Linux crontab kurallarını derinlemesine öğrenmek için Linux cron job kılavuzumuzu inceleyebilirsiniz.
2. Uygulama İçi Kuyruk Zamanlayıcıları (Sidekiq-Cron, GoodJob, Solid Queue): Sürekli çalışan bir worker sürecinin (daemon) arka planda periyodik aralıklarla Redis veya ilişkisel veritabanını sorgulayarak işleri kuyruğa aktardığı modeldir. Rails 8 ile varsayılan hale gelen Solid Queue, ayrı bir Redis kurulumu gerektirmeden PostgreSQL, MySQL veya SQLite üzerinde yinelenen görevleri (recurring tasks) koşturabilir. Her çalıştırmada Rails ortamının yeniden yüklenmesi (boot süresi) gerekmediği için sık aralıklarla çalışan işlerde oldukça verimlidir.
3. Harici HTTP Webhook Tabanlı Tetikleyiciler: Docker, Kubernetes, AWS ECS, Heroku veya Render gibi geçici dosya sistemine (ephemeral container) sahip modern bulut altyapılarında kalıcı crontab kullanımı platformun süreç ve depolama yapılandırmasına bağlıdır. Bu tür mimarilerde en sağlıklı yöntem, Rails uygulamasında gizli bir token ile korunan webhook uç noktası açmak ve ücretsiz cron job servisi cronjob.com.tr üzerinden periyodik HTTP istekleriyle görevi tetiklemektir.

Adım Adım Whenever Gem Kurulumu ve schedule.rb Yapılandırması

Whenever kurulumu; gem'i Gemfile'a eklemek, config/schedule.rb oluşturmak ve derlenen kuralları ilgili kullanıcının crontab'ına yazmak adımlarından oluşur. Gem yalnızca zamanlama tanımı ile crontab üretiminde kullanıldığı için require: false ile yüklenmeden tutulabilir. Kurulumdan sonra bundle exec whenever çıktısını inceleyin; dosyayı yazmak için bundle exec whenever --update-crontab komutunu kullanın.

1. Gemfile Tanımı: Projenizin Gemfile dosyasına gem'i ekleyin:

   # Gemfile
   gem 'whenever', require: false

2. Gem Kurulumu ve Başlatma: Terminalde Bundler komutlarını çalıştırarak yapılandırma dosyasını oluşturun:

   bundle install
   bundle exec wheneverize .

   Bu komut projenizin kök dizininde config/schedule.rb adında bir dosya oluşturur. Zamanlama kurallarınız bu dosya içine yazılacaktır.

3. Ortam ve Günlük Dosyası Belirtme: config/schedule.rb dosyanızın en başında görev çıktılarını kaydedecek log dosyasını ve çalışma ortamını tanımlayın.

Görev Türleri: runner, rake ve command Tanımları

Whenever içerisinde üç ana görev türü bulunur:

• runner: Rails ortamını (ActiveRecord modelleri, servis sınıfları) yükleyerek doğrudan Ruby kodu çalıştırır. Örneğin runner 'User.cleanup_expired_sessions' satırı, arka planda rails runner mekanizmasını tetikler.
• rake: lib/tasks dizini altında tanımlanan Rake görevlerini yürütür. Örneğin rake 'db:backup' veya rake 'sitemap:refresh'.
• command: Rails ortamını yüklemeden, doğrudan Linux kabuğunda (shell) bir sistem komutu veya betik çalıştırır. Örneğin command '/usr/bin/certbot renew' veya log arşivleme betikleri.

Çalışma Aralıkları: Zaman İfadeleri ve Cron Sözdizimi Geçişi

Whenever, okunabilir İngilizce zaman ifadelerini standart Linux crontab sözdizimine dönüştürür. Örneğin:

• every 1.day, at: '3:00 am': Her gece saat 03:00'te çalışır (0 3 * * *).
• every :monday, at: '9:00 am': Her Pazartesi sabah 09:00'da çalışır (0 9 * * 1).
• every 30.minutes: Her 30 dakikada bir çalışır (0,30 * * * *).
• every '0 2 1 * *': Doğrudan 5 haneli cron dizesi yazılmasına da izin verir. İfadelerin matematiksel detayları ve zaman desenleri için crontab sözdizimi referans tablosuna göz atabilirsiniz.

Capistrano ile Otomatik Crontab Güncellemesi

Uygulamanızı sunuculara Capistrano kullanarak dağıtıyorsanız, crontab güncellemelerini manuel yapmak yerine dağıtım hattına (pipeline) entegre edebilirsiniz. Capistrano v3 ile Whenever entegrasyonu için aşağıdaki adımları izleyin:

# Capfile
require 'whenever/capistrano'

Ardından config/deploy.rb dosyasında Whenever yapılandırma değişkenlerini belirleyin:

# config/deploy.rb
set :whenever_identifier, ->{ "#{fetch(:application)}_#{fetch(:stage)}" }
set :whenever_roles, ->{ :db }
set :whenever_environment, ->{ fetch(:stage) }

Gerçek Kod Örnekleri: schedule.rb ve Rails 8 recurring.yml

schedule.rb sistem cron'unu Ruby DSL ile yönetirken recurring.yml, Solid Queue scheduler'ının Active Job kuyruğuna ekleyeceği görevleri tanımlar. İlk örnekte loglama, PATH aktarımı, oturum temizliği ve yedekleme; ikinci örnekte ise kuyruk adlarıyla birlikte yinelenen işler yer alır. Aynı görevi iki dosyada birden tanımlamayın.

# config/schedule.rb
env :PATH, ENV['PATH']
set :output, 'log/cron.log'
set :environment, 'production'

# Her gece 03:00'te süresi dolmuş kullanıcı oturumlarını temizle
every 1.day, at: '3:00 am' do
  runner 'Session.where("updated_at < ?", 30.days.ago).delete_all'
end

# Her saat başı veritabanı yedeği al
every :hour do
  rake 'maintenance:backup_database'
end

# Her Pazartesi sabah 09:00'da haftalık analitik özeti hazırla
every :monday, at: '9:00 am' do
  runner 'WeeklyReportService.generate_and_dispatch'
end

Yukarıdaki konfigürasyonda çağrılan Rake görevinin lib/tasks/maintenance.rake dosyasındaki tanımı ise şu şekildedir:

# lib/tasks/maintenance.rake
namespace :maintenance do
  desc 'Veritabanı yedeğini sıkıştırarak arşive kaydeder'
  task backup_database: :environment do
    zaman = Time.current.strftime('%Y%m%d_%H%M%S')
    db = ActiveRecord::Base.connection_db_config.database
    hedef = Rails.root.join('backups', "#{db}_#{zaman}.sql.gz")

    FileUtils.mkdir_p(Rails.root.join('backups'))
    require 'shellwords'
    system('/bin/bash', '-o', 'pipefail', '-c',
           "pg_dump -Fp #{Shellwords.escape(db)} | gzip > #{Shellwords.escape(hedef.to_s)}") || raise('Veritabanı yedeği alınamadı')
    Rails.logger.info("Yedek tamamlandı: #{hedef}")

    # 14 günden eski yedek dosyalarını sil
    Dir.glob(Rails.root.join('backups', '*.sql.gz')).each do |dosya|
      File.delete(dosya) if File.mtime(dosya) < 14.days.ago
    end
  end
end

Rails 8 ile birlikte gelen Solid Queue recurring tasks mimarisinde ise crontab yerine doğrudan config/recurring.yml dosyasında görev tanımlanır:

# config/recurring.yml
production:
  clear_expired_sessions:
    class: ClearExpiredSessionsJob
    queue: background
    schedule: every day at 3am

  refresh_exchange_rates:
    class: FetchExchangeRatesJob
    queue: default
    schedule: every 30 minutes

  weekly_summary:
    class: DispatchWeeklySummaryJob
    queue: mailers
    schedule: every monday at 9am

Gerçek Senaryo: Solid Queue ile Saat Dilimine Bağlı Mutabakat

Bir finans uygulamasında önceki günün hesap hareketlerini her gece 02:30'da mutabakat servisine göndermek istediğinizi varsayın. Sunucu UTC kullansa bile zamanlamayı doğrudan Europe/Istanbul ile yazmak, uygulama sunucusunun yerel saat ayarına bağımlılığı azaltır. Aşağıdaki kurulum ayrıca aynı mutabakatın üst üste çalışmasını sınırlar ve sonucun iş günü bazında idempotent üretilmesini gerektirir.

1. Zaman dilimini schedule satırında belirtin. Solid Queue, Fugit tarafından ayrıştırılan cron ifadesinin sonunda IANA saat dilimini kabul eder:

   # config/recurring.yml
   production:
     daily_reconciliation:
       class: DailyReconciliationJob
       queue: background
       schedule: 30 2 * * * Europe/Istanbul

   Saat dilimi yazılmazsa ifade varsayılan olarak Rails'in config.time_zone değeriyle yorumlanır. config.solid_queue.time_zone ayrıca ayarlanabilir; nil yapılması sistemin yerel saatine dönmek anlamına gelir. Bu nedenle dağıtım ortamlarında aynı takvimi korumak için saat dilimini açıkça yazmak daha güvenlidir.

2. İşi ve eşzamanlılık sınırını tanımlayın. Aşağıdaki anahtar, bu görevin aynı anda tek yürütmesini hedefler; Reconciliation.call ise aynı business_date için benzersiz çalışma kaydı kullanacak şekilde uygulanmalıdır. İş günü ActiveSupport::TimeZone["Europe/Istanbul"] üzerinden seçilir; uygulamanın config.time_zone değeri UTC olsa bile iş günü İstanbul'a göre belirlenir:

   # app/jobs/daily_reconciliation_job.rb
   class DailyReconciliationJob < ApplicationJob
     queue_as :background
     limits_concurrency to: 1, key: -> { "daily-reconciliation" }, duration: 45.minutes
     retry_on ActiveRecord::Deadlocked, wait: 1.minute, attempts: 3
   
     def perform
       Reconciliation.call(business_date: ActiveSupport::TimeZone["Europe/Istanbul"].yesterday)
     end
   end

   duration: 45.minutes görevi 45 dakika sonra durdurmaz; eşzamanlılık kilidinin süresini belirler. Süre dolarsa yeni bir yürütme başlayabileceğinden, bu değeri beklenen en uzun çalışmaya göre seçin ve dış servise yazan işlemleri tekrar güvenli tasarlayın.

3. Scheduler ile worker'ı birlikte başlatın. Yalnızca web sunucusunu veya worker'ı çalıştırmak statik zamanlamayı işletmek için yeterli değildir; bin/jobs varsayılan kurulumda gerekli Solid Queue süreçlerini scheduler ile birlikte başlatır:

   cd /var/www/app
   RAILS_ENV=production bin/jobs

   recurring.yml değiştiğinde dağıtım sürecinizde bin/jobs ile yönetilen süreçleri yeniden başlatın. Puma'nın yeniden başlaması, ayrı çalışan scheduler sürecine yeni dosyayı kendiliğinden yüklemez.

4. Önce işi, sonra scheduler kaydını doğrulayın. İş mantığını zamanlayıcıdan bağımsız çalıştırın; ardından gerçek tetikleme sonrasında recurring execution kayıtlarını inceleyin:

   RAILS_ENV=production bin/rails runner 'DailyReconciliationJob.perform_now'
   RAILS_ENV=production bin/rails runner 'puts SolidQueue::RecurringExecution.order(run_at: :desc).limit(3).pluck(:task_key, :run_at)'

Yedeklilik için aynı recurring.yml yapılandırmasıyla birden fazla scheduler çalıştırılabilir. Solid Queue, görevi kuyruğa eklerken aynı işlemde task_key ve run_at için benzersiz bir recurring execution kaydı oluşturur; bu mekanizma aynı zamanlanmış görevin iki scheduler tarafından kuyruğa eklenmesini engeller. Koruma preserve_finished_jobs etkin ve ilgili kayıtlar korunurken geçerlidir. Kuyruğa tek eklenme, kuyruk sonrası yeniden denemeleri veya dış API'nin tekrar çağrılmasını ortadan kaldırmaz; uygulama tarafındaki benzersiz iş anahtarı yine gereklidir.

Sık Karşılaşılan Hatalar ve Çözümleri

Rails cron hatalarında önce üretilen crontab satırını, ardından cron günlüğünü ve son olarak uygulama logunu inceleyin. bundle: command not found genellikle PATH veya Ruby sürüm yöneticisini, ActiveRecord::ConnectionNotEstablished ise eksik üretim ortamını işaret eder. Aşağıdaki dört hata sınıfı, komutun hiç başlamamasıyla Rails içinde başarısız olmasını ayırmanızı sağlar.

whenever: command not found ve Bundler PATH Eksikliği

Linux cron arka plan servisi, kullanıcının interaktif kabuk oturumunu (.bashrc veya .zshrc) yüklemez; varsayılan olarak yalnızca /usr/bin:/bin gibi kısıtlı bir PATH ortam değişkenine sahiptir. Bu nedenle whenever veya bundle çalıştırılamaz. Çözüm için config/schedule.rb dosyasının en başına env :PATH, ENV['PATH'] satırını ekleyin ya da tam binary yolunu belirtin.

ActiveRecord::ConnectionNotEstablished ve Eksik Ortam Değişkenleri

Cron alt kabuğu, üretim ortam değişkenlerini (örneğin DATABASE_URL, RAILS_MASTER_KEY) barındırmadığından rails runner başlatıldığında veritabanına bağlanılamaz. Çözüm olarak crontab oluştururken whenever --update-crontab --set 'environment=production' parametresini kullanın ve gerekli ortam değişkenlerini cron sürecine aktarın; .env dosyası ancak onu yükleyen bir araç yapılandırılmışsa okunur, şifreli credentials için de şifre çözme anahtarı sağlanmalıdır.

Could not find gem 'bundler' (rbenv ve RVM Shims Uyuşmazlığı)

Sunucuda rbenv veya RVM gibi sürüm yöneticileri kullanılıyorsa, subshell rbenv shims yolunu bulamaz ve bundler gem'inin yüklü olmadığını iddia eder. Çözüm olarak config/schedule.rb dosyası içinde bundler komutunu doğrudan rbenv yoluyla tanımlayın:

# config/schedule.rb
set :bundle_command, '/home/deploy/.rbenv/shims/bundle exec'

crontab: error on previous lines ve Sözdizimi Çakışmaları

Whenever tarafından üretilen metin içinde geçersiz kaçış karakterleri veya hatalı tırnak işaretleri bulunması Linux crontab aracının hata vermesine yol açar. Sunucu crontab dosyasını bozmamak için önce bundle exec whenever komutunu çalıştırarak üretilen ham çıktıyı ekranda inceleyin. Eğer göreviniz hiç tetiklenmiyorsa, sistem günlüklerini incelemek için cron job çalışmıyor rehberimizdeki adımları izleyebilirsiniz.

Doğrulama ve Sorun Giderme

Bir Rails görevini doğrulamanın en kısa yolu, cron'un komutu başlattığını ve uygulamanın işi tamamladığını ayrı ayrı kanıtlamaktır. Sistem günlüğündeki CMD kaydı yalnızca başlangıcı gösterir; başarı için uygulama logunu, kuyruk kaydını veya beklenen veri değişikliğini kontrol edin. Aşağıdaki tablo, belirtiden kontrol komutuna ve düzeltmeye aynı sırayla ilerler.

Aşağıdaki örnekte ilk iki satır uygulamanın mutabakatı tamamladığını, son satır ise başka bir çalışmada kabuğun bundle yolunu bulamadığını gösterir. Cron'un CMD kaydı bu iki durumu tek başına ayırt edemez:

$ grep -F 'Daily reconciliation' /var/www/app/log/cron.log
I, [2026-10-28T03:00:02.184321 #2421]  INFO -- : Daily reconciliation started
I, [2026-10-28T03:00:04.912445 #2421]  INFO -- : Daily reconciliation finished status=ok
$ grep -F 'not found' /var/www/app/log/cron.log
/bin/sh: 1: /home/deploy/.rbenv/shims/bundle: not found

cronjob.com.tr ile HTTP Tabanlı Alternatif Kurulum (Rails Webhook Endpoint)

Docker, Kubernetes, AWS ECS, Heroku veya Render gibi ortamlarda Whenever kullanımı, cron servisinin çalıştırılabilmesine ve crontab yapılandırmasının dağıtımda korunmasına bağlıdır. Bu ortamlarda Rails uygulamanıza bir webhook controller ekleyerek dışarıdan HTTP isteği ile periyodik iş tetiklemek en modern ve dayanıklı çözümdür.

İlk olarak Rails uygulamanızda gizli bir Bearer token doğrulayan bir controller tanımlayın:

# app/controllers/internal/cron_controller.rb
module Internal
  class CronController < ActionController::API
    before_action :authenticate_cron_request

    def daily_cleanup
      # Uzun süren işleri ActiveJob ile arka plana atın
      MaintenanceCleanupJob.perform_later
      render json: { status: 'success', message: 'Temizlik görevi kuyruğa eklendi' }, status: :ok
    end

    private

    def authenticate_cron_request
      secret = ENV.fetch('INTERNAL_CRON_SECRET')
      auth_header = request.headers['Authorization']
      unless auth_header.present? && ActiveSupport::SecurityUtils.secure_compare(auth_header, "Bearer #{secret}")
        render json: { error: 'Yetkisiz erişim' }, status: :unauthorized
      end
    end
  end
end

Ardından config/routes.rb dosyasında ilgili rotayı tanımlayın:

# config/routes.rb
namespace :internal do
  post 'cron/daily-cleanup', to: 'cron#daily_cleanup'
end

Bu yapıyı kurduktan sonra cronjob.com.tr yönetim panelinde aşağıdaki adımlarla görevinizi oluşturabilirsiniz:

• Hedef URL: https://api.siteniz.com/internal/cron/daily-cleanup adresini girin.
• HTTP Metodu: POST seçeneğini işaretleyin.
• Özel Header: Authorization: Bearer guvenli-gizli-token-degeri başlığını ekleyin.
• Zamanlama: Hazır aralıklardan birini seçin ya da standart 5 alanlı cron ifadesi (örneğin 0 3 * * *) girin. Saat dilimini Europe/Istanbul olarak belirleyin.
• Yanıt Bekleme (Timeout): Cron ifadeli işlerde sistem 290 saniyeye kadar yanıt bekler. Controller içinde iş ActiveJob'a devredilip HTTP 200 dönüldüğünde yalnızca kuyruğa ekleme doğrulanır; görevin tamamlanması worker tarafından izlenmelidir.
• İzleme ve Bildirim: Sunucunuzda geçici bir kesinti yaşanırsa, ardışık 3 başarısız istek sonrasında e-posta ile erişim sorunu uyarısı alırsınız. Sistem düzeldiğinde kesinti süresiyle birlikte bilgilendirilirsiniz.

Sunucuda ek bir cron daemon çalıştırmadan, kuyruktaki işleri işleyen worker süreçleriyle görevleri yürütmenin alternatiflerini cron alternatifleri sayfamızdan karşılaştırabilirsiniz.

Sıkça Sorulan Sorular (SSS)

Whenever gem sunucuda bir arka plan servisi çalıştırır mı?

Hayır, Whenever sunucuda sürekli çalışan bir arka plan servisi (daemon) başlatmaz. Yalnızca Ruby DSL formatında yazılmış kuralları derleyerek ilgili kullanıcının crontab tablosuna standart cron satırları olarak yazar.

Rails 8'de Whenever yerine ne kullanılmalıdır?

Rails 8'de varsayılan Active Job arka ucu olan Solid Queue'nun Recurring Tasks mekanizması kullanılabilir. Solid Queue yapılandırılıp worker ve scheduler süreçleri çalıştırıldığında config/recurring.yml üzerinden veritabanı destekli zamanlanmış görevler tanımlanabilir.

Heroku ve Render gibi geçici dosya sistemli (ephemeral) ortamlarda Whenever çalışır mı?

Whenever'ın ürettiği crontab kayıtlarının yürütülmesi için çalışan bir cron servisi gerekir; geçici dosya sistemi tek başına çalışmasına engel değildir. Bu platformlarda desteklenen süreç modeline göre harici HTTP tetikleyicileri veya kuyruk tabanlı zamanlayıcılar tercih edilebilir.

Whenever mevcut crontab kayıtlarımı siler mi?

Hayır, Whenever mevcut crontab dosyasındaki diğer kayıtları silmez. whenever --update-crontab komutu çalıştırıldığında yalnızca belirtilen tanımlayıcı etiket (identifier) arasındaki satırları günceller, diğer kullanıcı veya sistem cron girdilerine dokunmaz.

Solid Queue recurring.yml değişikliği neden hemen çalışmaya başlamaz?

Statik zamanlamayı yöneten scheduler, recurring.yml yapılandırmasını süreç başlangıcında yükler. Değişiklikten sonra bin/jobs ile çalışan süreçleri dağıtım düzeninize uygun şekilde yeniden başlatın; yalnızca web sürecini yeniden başlatmak ayrı çalışan scheduler'ı etkilemeyebilir.

Whenever ile Solid Queue aynı görevi birlikte çalıştırabilir mi?

Teknik olarak çalıştırabilir ancak aynı işi iki zamanlayıcıya tanımlamak mükerrer kuyruk kaydı veya tekrarlanan yan etki yaratabilir. Geçiş sırasında birini devre dışı bırakın; kaçınılmaz çakışmalar için Active Job eşzamanlılık sınırı ve iş kuralına özgü benzersiz anahtar kullanın.

İlgili Rehberler