Prepare for zero downtime migrationszero-downtime-migrations

Starting with GitLab 9.1.0 we will no longer allow downtime migrations
unless absolutely necessary. This commit updates the various developer
guides and adds code that is necessary to make zero downtime migrations
less painful.

1 files changed, 17 insertions, 0 deletions

diff --git a/doc/update/README.md b/doc/update/README.md
index 837b31abb97..7921d03d611 100644
--- a/doc/update/README.md
+++ b/doc/update/README.md
@@ -48,6 +48,23 @@ GitLab provides official Docker images for both Community and Enterprise
 editions. They are based on the Omnibus package and instructions on how to
 update them are in [a separate document][omnidocker].
 
+## Upgrading without downtime
+
+Starting with GitLab 9.1.0 it's possible to upgrade to a newer version of GitLab
+without having to take your GitLab instance offline. However, for this to work
+there are the following requirements:
+
+1. You can only upgrade 1 release at a time. For example, if 9.1.15 is the last
+   release of 9.1 then you can safely upgrade from that version to 9.2.0.
+   However, if you are running 9.1.14 you first need to upgrade to 9.1.15.
+2. You have to use [post-deployment
+   migrations](../development/post_deployment_migrations.md).
+3. You are using PostgreSQL. If you are using MySQL you will still need downtime
+   when upgrading.
+
+This applies to major, minor, and patch releases unless stated otherwise in a
+release post.
+
 ## Upgrading between editions
 
 GitLab comes in two flavors: [Community Edition][ce] which is MIT licensed,