4 files changed, 173 insertions, 0 deletions
diff --git a/doc/development/README.md b/doc/development/README.md
index b624aa37c70..12cca9f84b7 100644
--- a/doc/development/README.md
+++ b/doc/development/README.md
@@ -27,6 +27,7 @@ comments: false
 
 ## Backend guides
 
+- [GitLab utilities](utilities.md)
 - [API styleguide](api_styleguide.md) Use this styleguide if you are
   contributing to the API.
 - [Sidekiq guidelines](sidekiq_style_guide.md) for working with Sidekiq workers
diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md
index ca2048c7019..26abf967dcf 100644
--- a/doc/development/gitaly.md
+++ b/doc/development/gitaly.md
@@ -97,6 +97,29 @@ describe 'Gitaly Request count tests' do
 end
 ```
 
+## Running tests with a locally modified version of Gitaly
+
+Normally, gitlab-ce/ee tests use a local clone of Gitaly in `tmp/tests/gitaly`
+pinned at the version specified in GITALY_SERVER_VERSION. If you want
+to run tests locally against a modified version of Gitaly you can
+replace `tmp/tests/gitaly` with a symlink.
+
+```shell
+rm -rf tmp/tests/gitaly
+ln -s /path/to/gitaly tmp/tests/gitaly
+```
+
+Make sure you run `make` in your local Gitaly directory before running
+tests. Otherwise, Gitaly will fail to boot.
+
+If you make changes to your local Gitaly in between test runs you need
+to manually run `make` again.
+
+Note that CI tests will not use your locally modified version of
+Gitaly. To use a custom Gitaly version in CI you need to update
+GITALY_SERVER_VERSION. You can use the format `=revision` to use a
+non-tagged commit from https://gitlab.com/gitlab-org/gitaly in CI.
+
 ---
 
 [Return to Development documentation](README.md)
diff --git a/doc/development/utilities.md b/doc/development/utilities.md
new file mode 100644
index 00000000000..951c3ef85ce
--- /dev/null
+++ b/doc/development/utilities.md
@@ -0,0 +1,92 @@
+# GitLab utilities
+
+We developed a number of utilities to ease development.
+
+## [`MergeHash`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/merge_hash.rb)
+
+* Deep merges an array of hashes:
+
+    ``` ruby
+    Gitlab::Utils::MergeHash.merge(
+      [{ hello: ["world"] },
+       { hello: "Everyone" },
+       { hello: { greetings: ['Bonjour', 'Hello', 'Hallo', 'Dzien dobry'] } },
+        "Goodbye", "Hallo"]
+    )
+    ```
+
+    Gives:
+
+    ``` ruby
+    [
+      {
+        hello:
+          [
+            "world",
+            "Everyone",
+            { greetings: ['Bonjour', 'Hello', 'Hallo', 'Dzien dobry'] }
+          ]
+      },
+      "Goodbye"
+    ]
+    ```
+
+* Extracts all keys and values from a hash into an array:
+
+    ``` ruby
+    Gitlab::Utils::MergeHash.crush(
+      { hello: "world", this: { crushes: ["an entire", "hash"] } }
+    )
+    ```
+
+    Gives:
+
+    ``` ruby
+    [:hello, "world", :this, :crushes, "an entire", "hash"]
+    ```
+
+## [`StrongMemoize`](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/utils/strong_memoize.rb)
+
+* Memoize the value even if it is `nil` or `false`.
+
+    We often do `@value ||= compute`, however this doesn't work well if
+    `compute` might eventually give `nil` and we don't want to compute again.
+    Instead we could use `defined?` to check if the value is set or not.
+    However it's tedious to write such pattern, and `StrongMemoize` would
+    help us use such pattern.
+
+    Instead of writing patterns like this:
+
+    ``` ruby
+    class Find
+      def result
+        return @result if defined?(@result)
+
+        @result = search
+      end
+    end
+    ```
+
+    We could write it like:
+
+    ``` ruby
+    class Find
+      include Gitlab::Utils::StrongMemoize
+
+      def result
+        strong_memoize(:result) do
+          search
+        end
+      end
+    end
+    ```
+
+* Clear memoization
+
+    ``` ruby
+    class Find
+      include Gitlab::Utils::StrongMemoize
+    end
+
+    Find.new.clear_memoization(:result)
+    ```
diff --git a/doc/development/what_requires_downtime.md b/doc/development/what_requires_downtime.md
index 05e0a64af18..9d0c62ecc35 100644
--- a/doc/development/what_requires_downtime.md
+++ b/doc/development/what_requires_downtime.md
@@ -195,6 +195,63 @@ end
 
 And that's it, we're done!
 
+## Changing Column Types For Large Tables
+
+While `change_column_type_concurrently` can be used for changing the type of a
+column without downtime it doesn't work very well for large tables. Because all
+of the work happens in sequence the migration can take a very long time to
+complete, preventing a deployment from proceeding.
+`change_column_type_concurrently` can also produce a lot of pressure on the
+database due to it rapidly updating many rows in sequence.
+
+To reduce database pressure you should instead use
+`change_column_type_using_background_migration` when migrating a column in a
+large table (e.g. `issues`). This method works similar to
+`change_column_type_concurrently` but uses background migration to spread the
+work / load over a longer time period, without slowing down deployments.
+
+Usage of this method is fairly simple:
+
+```ruby
+class ExampleMigration < ActiveRecord::Migration
+  include Gitlab::Database::MigrationHelpers
+
+  disable_ddl_transaction!
+
+  class Issue < ActiveRecord::Base
+    self.table_name = 'issues'
+
+    include EachBatch
+
+    def self.to_migrate
+      where('closed_at IS NOT NULL')
+    end
+  end
+
+  def up
+    change_column_type_using_background_migration(
+      Issue.to_migrate,
+      :closed_at,
+      :datetime_with_timezone
+    )
+  end
+
+  def down
+    change_column_type_using_background_migration(
+      Issue.to_migrate,
+      :closed_at,
+      :datetime
+    )
+  end
+end
+```
+
+This would change the type of `issues.closed_at` to `timestamp with time zone`.
+
+Keep in mind that the relation passed to
+`change_column_type_using_background_migration` _must_ include `EachBatch`,
+otherwise it will raise a `TypeError`.
+
 ## Adding Indexes
 
 Adding indexes is an expensive process that blocks INSERT and UPDATE queries for