Merge branch 'doc-release-tools' into 'master'

Update release documentation to use release tools

See merge request !1245

doc/release/monthly.md

@@ -143,35 +143,21 @@ Make sure the code quality indicators are green / good.
 
 - [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq)
 
-### **4. Set VERSION**
+### **4. Run release tool**
 
-Change version in VERSION to `x.x.0.rc1`.
+**Make sure EE `master` has latest changes from CE `master`**
 
-### **5. Tag**
+Get release tools
 
-Create an annotated tag that points to the version change commit:
-
-```
-git tag -a vx.x.0.rc1 -m 'Version x.x.0.rc1'
 ```
-
-Tags should be created for both GitLab CE and GitLab EE. Don't forget to push tags to all remotes.
-
+git clone git@dev.gitlab.org:gitlab/release-tools.git
+cd release-tools
 ```
-git push remote_name vx.x.0.rc1
-```
-
-### **6. Create stable branches**
-
-For GitLab EE, append `-ee` to the branch.
 
-`x-x-stable-ee`
+Create release candidate and stable branch:
 
 ```
-git checkout master
-git pull
-git checkout -b x-x-stable
-git push <remote> x-x-stable
+bundle exec rake release["x.x.0.rc1"]
 ```
 
 Now developers can use master for merging new features.
@@ -245,69 +231,45 @@ create an issue about it in order to discuss the next steps after the release.
 
 # **22nd - Release CE and EE**
 
-For GitLab EE, append `-ee` to the branches and tags.
+**Make sure EE `x-x-stable-ee` has latest changes from CE `x-x-stable`**
 
-`x-x-stable-ee`
-
-`v.x.x.0-ee`
-
-Note: Merge CE into EE if needed.
-
-### **1. Set VERSION to x.x.x and push**
-
-- Change the GITLAB_SHELL_VERSION file in `master` of the CE repository if the version changed.
-- Change the GITLAB_SHELL_VERSION file in `master` of the EE repository if the version changed.
-- Change the VERSION file in `master` branch of the CE repository and commit and push to origin.
-- Change the VERSION file in `master` branch of the EE repository and commit and push to origin.
-
-### **2. Update installation.md**
 
-Update [installation.md](/doc/install/installation.md) to the newest version in master.
+### **1. Release code**
 
-### **3. Push latest changes from x-x-stable branch to dev.gitlab.org**
+Get release tools
 
 ```
-git checkout -b x-x-stable
-git push origin x-x-stable
+git clone git@dev.gitlab.org:gitlab/release-tools.git
+cd release-tools
 ```
 
-### **4. Build the Omnibus packages**
-
-Follow the [release doc in the Omnibus repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md).
-This can happen before tagging because Omnibus uses tags in its own repo and SHA1's to refer to the GitLab codebase.
-
-### **5. Create annotated tag vx.x.x**
-
-In `x-x-stable` branch check for the SHA-1 of the commit with VERSION file changed. Tag that commit,
+Bump version, create release tag and push to remotes:
 
 ```
-git tag -a vx.x.0 -m 'Version x.x.0' xxxxx
+bundle exec rake release["x.x.0"]
 ```
 
-where `xxxxx` is SHA-1.
 
-### **6. Push the tag and x-x-stable branch to the remotes**
+### **2. Update installation.md**
 
-For GitLab CE, push to dev, GitLab.com and GitHub.
+Update [installation.md](/doc/install/installation.md) to the newest version in master.
 
-For GitLab EE, push to the subscribers repo.
 
-Make sure the branch is marked 'protected' on each of the remotes you pushed to.
+### **3. Build the Omnibus packages**
+
+Follow the [release doc in the Omnibus repository](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md).
+This can happen before tagging because Omnibus uses tags in its own repo and SHA1's to refer to the GitLab codebase.
 
-```
-git push <remote> x-x-stable(-ee)
-git push <remote> vx.x.0
-```
 
-### **7. Publish packages for new release**
+### **4. Publish packages for new release**
 
 Update `downloads/index.html` and `downloads/archive/index.html` in `www-gitlab-com` repository.
 
-### **8. Publish blog for new release**
+### **5. Publish blog for new release**
 
 Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository.
 
-### **9. Tweet to blog**
+### **6. Tweet to blog**
 
 Send out a tweet to share the good news with the world.
 List the most important features and link to the blog post.

doc/release/patch.md

@@ -10,6 +10,8 @@ Otherwise include it in the monthly release and note there was a regression fix
 
 ## Release Procedure
 
+### Preparation
+
 1. Verify that the issue can be reproduced
 1. Note in the 'GitLab X.X regressions' that you will create a patch
 1. Create an issue on private GitLab development server
@@ -17,12 +19,33 @@ Otherwise include it in the monthly release and note there was a regression fix
 1. Fix the issue on a feature branch, do this on the private GitLab development server
 1. Consider creating and testing workarounds
 1. After the branch is merged into master, cherry pick the commit(s) into the current stable branch
+1. Make sure that the build has passed and all tests are passing
 1. In a separate commit in the stable branch update the CHANGELOG
 1. For EE, update the CHANGELOG-EE if it is EE specific fix. Otherwise, merge the stable CE branch and add to CHANGELOG-EE "Merge community edition changes for version X.X.X"
-1. In a separate commit in the stable branch update the VERSION
-1. Create an annotated tag vX.X.X for CE and another patch release for EE `git tag -a vx.x.x -m 'Version x.x.x'`
-1. Make sure that the build has passed and all tests are passing
-1. Push the code and the tags to all the CE and EE repositories
+
+### Bump version 
+
+Get release tools
+
+```
+git clone git@dev.gitlab.org:gitlab/release-tools.git
+cd release-tools
+```
+
+Bump version in stable branch, create release tag and push to remotes:
+
+```
+bundle exec rake release["x.x.x"]
+```
+
+Or if you need to release only EE:
+
+```
+CE=false be rake release['x.x.x']
+```
+
+### Release
+
 1. Apply the patch to GitLab Cloud and the private GitLab development server
 1. [Build new packages with the latest version](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/release.md)
 1. Cherry-pick the changelog update back into master