Merge branch 'dm-application-worker' into 'master'

Add ApplicationWorker and make every worker include it

See merge request gitlab-org/gitlab-ce!15632

2 files changed, 19 insertions, 22 deletions

diff --git a/doc/development/background_migrations.md b/doc/development/background_migrations.md
index 5452b0e7a2f..fd2b9d0e908 100644
--- a/doc/development/background_migrations.md
+++ b/doc/development/background_migrations.md
@@ -68,10 +68,10 @@ BackgroundMigrationWorker.perform_async('BackgroundMigrationClassName', [arg1, a
 ```
 
 Usually it's better to enqueue jobs in bulk, for this you can use
-`BackgroundMigrationWorker.perform_bulk`:
+`BackgroundMigrationWorker.bulk_perform_async`:
 
 ```ruby
-BackgroundMigrationWorker.perform_bulk(
+BackgroundMigrationWorker.bulk_perform_async(
   [['BackgroundMigrationClassName', [1]],
    ['BackgroundMigrationClassName', [2]]]
 )
@@ -85,13 +85,13 @@ updates. Removals in turn can be handled by simply defining foreign keys with
 cascading deletes.
 
 If you would like to schedule jobs in bulk with a delay, you can use
-`BackgroundMigrationWorker.perform_bulk_in`:
+`BackgroundMigrationWorker.bulk_perform_in`:
 
 ```ruby
 jobs = [['BackgroundMigrationClassName', [1]],
         ['BackgroundMigrationClassName', [2]]]
 
-BackgroundMigrationWorker.perform_bulk_in(5.minutes, jobs)
+BackgroundMigrationWorker.bulk_perform_in(5.minutes, jobs)
 ```
 
 ## Cleaning Up
@@ -201,7 +201,7 @@ class ScheduleExtractServicesUrl < ActiveRecord::Migration
         ['ExtractServicesUrl', [id]]
       end
 
-      BackgroundMigrationWorker.perform_bulk(jobs)
+      BackgroundMigrationWorker.bulk_perform_async(jobs)
     end
   end
 
diff --git a/doc/development/sidekiq_style_guide.md b/doc/development/sidekiq_style_guide.md
index 1e9fdbc65e2..085fb8f902c 100644
--- a/doc/development/sidekiq_style_guide.md
+++ b/doc/development/sidekiq_style_guide.md
@@ -3,6 +3,12 @@
 This document outlines various guidelines that should be followed when adding or
 modifying Sidekiq workers.
 
+## ApplicationWorker
+
+All workers should include `ApplicationWorker` instead of `Sidekiq::Worker`,
+which adds some convenience methods and automatically sets the queue based on
+the worker's name.
+
 ## Default Queue
 
 Use of the "default" queue is not allowed. Every worker should use a queue that
@@ -13,19 +19,10 @@ A list of all available queues can be found in `config/sidekiq_queues.yml`.
 
 ## Dedicated Queues
 
-Most workers should use their own queue. To ease this process a worker can
-include the `DedicatedSidekiqQueue` concern as follows:
-
-```ruby
-class ProcessSomethingWorker
-  include Sidekiq::Worker
-  include DedicatedSidekiqQueue
-end
-```
-
-This will set the queue name based on the class' name, minus the `Worker`
-suffix. In the above example this would lead to the queue being
-`process_something`.
+Most workers should use their own queue, which is automatically set based on the
+worker class name. For a worker named `ProcessSomethingWorker`, the queue name
+would be `process_something`. If you're not sure what a worker's queue name is,
+you can find it using `SomeWorker.queue`.
 
 In some cases multiple workers do use the same queue. For example, the various
 workers for updating CI pipelines all use the `pipeline` queue. Adding workers
@@ -39,7 +36,7 @@ tests should be placed in `spec/workers`.
 
 ## Removing or renaming queues
 
-Try to avoid renaming or removing queues in minor and patch releases. 
-During online update instance can have pending jobs and removing the queue can 
-lead to those jobs being stuck forever. If you can't write migration for those 
-Sidekiq jobs, please consider doing rename or remove queue in major release only. 
\ No newline at end of file
+Try to avoid renaming or removing queues in minor and patch releases.
+During online update instance can have pending jobs and removing the queue can
+lead to those jobs being stuck forever. If you can't write migration for those
+Sidekiq jobs, please consider doing rename or remove queue in major release only.