Cleanup and refactor release doc. Follow issue as a todo list
This commit is contained in:
parent
bc95576e2c
commit
3c19929c75
2 changed files with 194 additions and 203 deletions
126
doc/release/howto_rc1.md
Normal file
126
doc/release/howto_rc1.md
Normal file
|
@ -0,0 +1,126 @@
|
|||
# How to create RC1
|
||||
|
||||
The RC1 release comes with the task to update the installation and upgrade docs. Be mindful that there might already be merge requests for this on GitLab or GitHub.
|
||||
|
||||
### **1. Update the installation guide**
|
||||
|
||||
1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay)
|
||||
1. Check the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782)
|
||||
1. Check the [Git version](/lib/tasks/gitlab/check.rake#L794)
|
||||
1. There might be other changes. Ask around.
|
||||
|
||||
### **2. Create update guides**
|
||||
|
||||
1. Create: CE update guide from previous version. Like `7.3-to-7.4.md`
|
||||
1. Create: CE to EE update guide in EE repository for latest version.
|
||||
1. Update: `6.x-or-7.x-to-7.x.md` to latest version.
|
||||
1. Create: CI update guide from previous version
|
||||
|
||||
It's best to copy paste the previous guide and make changes where necessary.
|
||||
The typical steps are listed below with any points you should specifically look at.
|
||||
|
||||
#### 0. Any major changes?
|
||||
|
||||
List any major changes here, so the user is aware of them before starting to upgrade. For instance:
|
||||
|
||||
- Database updates
|
||||
- Web server changes
|
||||
- File structure changes
|
||||
|
||||
#### 1. Stop server
|
||||
|
||||
#### 2. Make backup
|
||||
|
||||
#### 3. Do users need to update dependencies like `git`?
|
||||
|
||||
- Check if the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) changed since the last release.
|
||||
|
||||
- Check if the [Git version](/lib/tasks/gitlab/check.rake#L794) changed since the last release.
|
||||
|
||||
#### 4. Get latest code
|
||||
|
||||
#### 5. Does GitLab shell need to be updated?
|
||||
|
||||
#### 6. Install libs, migrations, etc.
|
||||
|
||||
#### 7. Any config files updated since last release?
|
||||
|
||||
Check if any of these changed since last release:
|
||||
|
||||
- [lib/support/nginx/gitlab](/lib/support/nginx/gitlab)
|
||||
- [lib/support/nginx/gitlab-ssl](/lib/support/nginx/gitlab-ssl)
|
||||
- <https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example>
|
||||
- [config/gitlab.yml.example](/config/gitlab.yml.example)
|
||||
- [config/unicorn.rb.example](/config/unicorn.rb.example)
|
||||
- [config/database.yml.mysql](/config/database.yml.mysql)
|
||||
- [config/database.yml.postgresql](/config/database.yml.postgresql)
|
||||
- [config/initializers/rack_attack.rb.example](/config/initializers/rack_attack.rb.example)
|
||||
- [config/resque.yml.example](/config/resque.yml.example)
|
||||
|
||||
#### 8. Need to update init script?
|
||||
|
||||
Check if the `init.d/gitlab` script changed since last release: [lib/support/init.d/gitlab](/lib/support/init.d/gitlab)
|
||||
|
||||
#### 9. Start application
|
||||
|
||||
#### 10. Check application status
|
||||
|
||||
### **3. Code quality indicators**
|
||||
|
||||
Make sure the code quality indicators are green / good.
|
||||
|
||||
- [![Build status](http://ci.gitlab.org/projects/1/status.png?ref=master)](http://ci.gitlab.org/projects/1?ref=master) on ci.gitlab.org (master branch)
|
||||
|
||||
- [![Build Status](https://semaphoreapp.com/api/v1/projects/2f1a5809-418b-4cc2-a1f4-819607579fe7/243338/badge.png)](https://semaphoreapp.com/gitlabhq/gitlabhq) (master branch)
|
||||
|
||||
- [![Code Climate](https://codeclimate.com/github/gitlabhq/gitlabhq.png)](https://codeclimate.com/github/gitlabhq/gitlabhq)
|
||||
|
||||
- [![Dependency Status](https://gemnasium.com/gitlabhq/gitlabhq.png)](https://gemnasium.com/gitlabhq/gitlabhq) this button can be yellow (small updates are available) but must not be red (a security fix or an important update is available)
|
||||
|
||||
- [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq)
|
||||
|
||||
### 4. Run release tool for CE and EE
|
||||
|
||||
**Make sure EE `master` has latest changes from CE `master`**
|
||||
|
||||
Get release tools
|
||||
|
||||
```
|
||||
git clone git@dev.gitlab.org:gitlab/release-tools.git
|
||||
cd release-tools
|
||||
```
|
||||
|
||||
Release candidate creates stable branch from master.
|
||||
So we need to sync master branch between all CE remotes. Also do same for EE.
|
||||
|
||||
```
|
||||
bundle exec rake sync
|
||||
```
|
||||
|
||||
Create release candidate and stable branch:
|
||||
|
||||
```
|
||||
bundle exec rake release["x.x.0.rc1"]
|
||||
```
|
||||
|
||||
Now developers can use master for merging new features.
|
||||
So you should use stable branch for future code chages related to release.
|
||||
|
||||
|
||||
### 5. Release GitLab CI RC1
|
||||
|
||||
Add to your local `gitlab-ci/.git/config`:
|
||||
|
||||
```
|
||||
[remote "public"]
|
||||
url = none
|
||||
pushurl = git@dev.gitlab.org:gitlab/gitlab-ci.git
|
||||
pushurl = git@gitlab.com:gitlab-org/gitlab-ci.git
|
||||
pushurl = git@github.com:gitlabhq/gitlab-ci.git
|
||||
```
|
||||
|
||||
* Create a stable branch `x-y-stable`
|
||||
* Bump VERSION to `x.y.0.rc1`
|
||||
* `git tag -a v$(cat VERSION) -m "Version $(cat VERSION)"
|
||||
* `git push public x-y-stable v$(cat VERSION)`
|
||||
|
|
@ -2,209 +2,90 @@
|
|||
|
||||
NOTE: This is a guide for GitLab developers.
|
||||
|
||||
# **7 workdays before release - Code Freeze & Release Manager**
|
||||
It starts 7 days before release. Current release manager must choose next release manager.
|
||||
New release manager should create overall issue at GitLab
|
||||
|
||||
### **1. Stop merging in code, except for important bug fixes**
|
||||
|
||||
### **2. Release Manager**
|
||||
## Release Manager
|
||||
|
||||
A release manager is selected that coordinates all releases the coming month, including the patch releases for previous releases.
|
||||
The release manager has to make sure all the steps below are done and delegated where necessary.
|
||||
This person should also make sure this document is kept up to date and issues are created and updated.
|
||||
|
||||
### **3. Create an overall issue**
|
||||
## Take weekend and vacations into account
|
||||
|
||||
Ensure that there is enough time to incorporate the findings of the release candidate, etc.
|
||||
|
||||
## Create an overall issue and follow it
|
||||
|
||||
Create issue for GitLab CE project(internal). Name it "Release x.x.x" for easier searching.
|
||||
Replace the dates with actual dates based on the number of workdays before the release.
|
||||
All steps from issue template are explained below
|
||||
|
||||
```
|
||||
Xth:
|
||||
Xth: (7 working days befor 22th)
|
||||
|
||||
- [ ] Code freeze
|
||||
- [ ] Update the CE changelog (#LINK)
|
||||
- [ ] Update the EE changelog (#LINK)
|
||||
- [ ] Update the CI changelog (#LINK)
|
||||
- [ ] Triage the omnibus-gitlab milestone
|
||||
|
||||
Xth:
|
||||
Xth: (6 working days befor 22th)
|
||||
|
||||
- [ ] Merge CE master in to EE master via merge request (#LINK)
|
||||
- [ ] Create CE, EE, CI RC1 versions (#LINK)
|
||||
|
||||
Xth: (5 working days befor 22th)
|
||||
|
||||
- [ ] Merge CE in to EE (#LINK)
|
||||
- [ ] Close the omnibus-gitlab milestone
|
||||
- [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package)
|
||||
|
||||
Xth:
|
||||
|
||||
- [ ] Create x.x.0.rc1 (#LINK)
|
||||
- [ ] Create x.x.0.rc1-ee (#LINK)
|
||||
- [ ] Create CI y.y.0.rc1 (#LINK)
|
||||
- [ ] Build package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package)
|
||||
|
||||
Xth:
|
||||
Xth: (4 working days befor 22th)
|
||||
|
||||
- [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package)
|
||||
- [ ] Regression issues (CE, CI) and tweet about rc1 (#LINK)
|
||||
- [ ] Create regression issues (CE, CI) (#LINK)
|
||||
- [ ] Tweet about rc1 (#LINK)
|
||||
- [ ] Start blog post (#LINK)
|
||||
- [ ] Determine QA person and notify him
|
||||
|
||||
Xth:
|
||||
Xth: (2 working days befor 22th)
|
||||
|
||||
- [ ] Merge CE stable branch into EE stable branch
|
||||
- [ ] Do QA and fix anything coming out of it (#LINK)
|
||||
|
||||
Xth: (1 working day befor 22th)
|
||||
|
||||
- [ ] Create CE, EE, CI stable versions (#LINK)
|
||||
- [ ] Create Omnibus tags and build packages
|
||||
|
||||
22nd:
|
||||
|
||||
- [ ] Release CE, EE and CI (#LINK)
|
||||
|
||||
Xth:
|
||||
Xth: (1 working day after 22th)
|
||||
|
||||
- [ ] Deploy to GitLab.com (#LINK)
|
||||
|
||||
```
|
||||
|
||||
### **4. Update changelog**
|
||||
- - -
|
||||
|
||||
## Code Freeze
|
||||
|
||||
Stop merging code in master, except for important bug fixes
|
||||
|
||||
## Update changelog
|
||||
|
||||
Any changes not yet added to the changelog are added by lead developer and in that merge request the complete team is asked if there is anything missing.
|
||||
|
||||
There are three changelogs that need to be updated: CE, EE and CI.
|
||||
|
||||
### **5. Take weekend and vacations into account**
|
||||
## Create RC1 (CE, EE, CI)
|
||||
|
||||
Ensure that there is enough time to incorporate the findings of the release candidate, etc.
|
||||
[Follow this How-to guide](howto_rc1.md) to create RC1.
|
||||
|
||||
# **6 workdays before release- Merge the CE into EE**
|
||||
|
||||
Do this via a merge request.
|
||||
|
||||
# **5 workdays before release - Create RC1**
|
||||
|
||||
The RC1 release comes with the task to update the installation and upgrade docs. Be mindful that there might already be merge requests for this on GitLab or GitHub.
|
||||
|
||||
### **1. Update the installation guide**
|
||||
|
||||
1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay)
|
||||
1. Check the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782)
|
||||
1. Check the [Git version](/lib/tasks/gitlab/check.rake#L794)
|
||||
1. There might be other changes. Ask around.
|
||||
|
||||
### **2. Create update guides**
|
||||
|
||||
1. Create: CE update guide from previous version. Like `7.3-to-7.4.md`
|
||||
1. Create: CE to EE update guide in EE repository for latest version.
|
||||
1. Update: `6.x-or-7.x-to-7.x.md` to latest version.
|
||||
1. Create: CI update guide from previous version
|
||||
|
||||
It's best to copy paste the previous guide and make changes where necessary.
|
||||
The typical steps are listed below with any points you should specifically look at.
|
||||
|
||||
#### 0. Any major changes?
|
||||
|
||||
List any major changes here, so the user is aware of them before starting to upgrade. For instance:
|
||||
|
||||
- Database updates
|
||||
- Web server changes
|
||||
- File structure changes
|
||||
|
||||
#### 1. Stop server
|
||||
|
||||
#### 2. Make backup
|
||||
|
||||
#### 3. Do users need to update dependencies like `git`?
|
||||
|
||||
- Check if the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) changed since the last release.
|
||||
|
||||
- Check if the [Git version](/lib/tasks/gitlab/check.rake#L794) changed since the last release.
|
||||
|
||||
#### 4. Get latest code
|
||||
|
||||
#### 5. Does GitLab shell need to be updated?
|
||||
|
||||
#### 6. Install libs, migrations, etc.
|
||||
|
||||
#### 7. Any config files updated since last release?
|
||||
|
||||
Check if any of these changed since last release:
|
||||
|
||||
- [lib/support/nginx/gitlab](/lib/support/nginx/gitlab)
|
||||
- [lib/support/nginx/gitlab-ssl](/lib/support/nginx/gitlab-ssl)
|
||||
- <https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example>
|
||||
- [config/gitlab.yml.example](/config/gitlab.yml.example)
|
||||
- [config/unicorn.rb.example](/config/unicorn.rb.example)
|
||||
- [config/database.yml.mysql](/config/database.yml.mysql)
|
||||
- [config/database.yml.postgresql](/config/database.yml.postgresql)
|
||||
- [config/initializers/rack_attack.rb.example](/config/initializers/rack_attack.rb.example)
|
||||
- [config/resque.yml.example](/config/resque.yml.example)
|
||||
|
||||
#### 8. Need to update init script?
|
||||
|
||||
Check if the `init.d/gitlab` script changed since last release: [lib/support/init.d/gitlab](/lib/support/init.d/gitlab)
|
||||
|
||||
#### 9. Start application
|
||||
|
||||
#### 10. Check application status
|
||||
|
||||
### **3. Code quality indicators**
|
||||
|
||||
Make sure the code quality indicators are green / good.
|
||||
|
||||
- [![Build status](http://ci.gitlab.org/projects/1/status.png?ref=master)](http://ci.gitlab.org/projects/1?ref=master) on ci.gitlab.org (master branch)
|
||||
|
||||
- [![Build Status](https://semaphoreapp.com/api/v1/projects/2f1a5809-418b-4cc2-a1f4-819607579fe7/243338/badge.png)](https://semaphoreapp.com/gitlabhq/gitlabhq) (master branch)
|
||||
|
||||
- [![Code Climate](https://codeclimate.com/github/gitlabhq/gitlabhq.png)](https://codeclimate.com/github/gitlabhq/gitlabhq)
|
||||
|
||||
- [![Dependency Status](https://gemnasium.com/gitlabhq/gitlabhq.png)](https://gemnasium.com/gitlabhq/gitlabhq) this button can be yellow (small updates are available) but must not be red (a security fix or an important update is available)
|
||||
|
||||
- [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq)
|
||||
|
||||
### **4. Run release tool**
|
||||
|
||||
**Make sure EE `master` has latest changes from CE `master`**
|
||||
|
||||
Get release tools
|
||||
|
||||
```
|
||||
git clone git@dev.gitlab.org:gitlab/release-tools.git
|
||||
cd release-tools
|
||||
```
|
||||
|
||||
Release candidate creates stable branch from master.
|
||||
So we need to sync master branch between all CE remotes. Also do same for EE.
|
||||
|
||||
```
|
||||
bundle exec rake sync
|
||||
```
|
||||
|
||||
Create release candidate and stable branch:
|
||||
|
||||
```
|
||||
bundle exec rake release["x.x.0.rc1"]
|
||||
```
|
||||
|
||||
Now developers can use master for merging new features.
|
||||
So you should use stable branch for future code chages related to release.
|
||||
|
||||
|
||||
### 5. Release GitLab CI RC1
|
||||
|
||||
Add to your local `gitlab-ci/.git/config`:
|
||||
|
||||
```
|
||||
[remote "public"]
|
||||
url = none
|
||||
pushurl = git@dev.gitlab.org:gitlab/gitlab-ci.git
|
||||
pushurl = git@gitlab.com:gitlab-org/gitlab-ci.git
|
||||
pushurl = git@github.com:gitlabhq/gitlab-ci.git
|
||||
```
|
||||
|
||||
* Create a stable branch `x-y-stable`
|
||||
* Bump VERSION to `x.y.0.rc1`
|
||||
* `git tag -a v$(cat VERSION) -m "Version $(cat VERSION)"
|
||||
* `git push public x-y-stable v$(cat VERSION)`
|
||||
|
||||
|
||||
# **4 workdays before release - Release RC1**
|
||||
|
||||
### **1. Determine QA person**
|
||||
|
||||
Notify person of QA day.
|
||||
|
||||
### **2. Update GitLab.com**
|
||||
## Update GitLab.com with RC1
|
||||
|
||||
Merge the RC1 EE code into GitLab.com.
|
||||
Once the build is green, create a package.
|
||||
|
@ -212,7 +93,24 @@ If there are big database migrations consider testing them with the production d
|
|||
Try to deploy in the morning.
|
||||
It is important to do this as soon as possible, so we can catch any errors before we release the full version.
|
||||
|
||||
### **3. Prepare the blog post**
|
||||
## Create a regressions issue
|
||||
|
||||
On [the GitLab CE issue tracker on GitLab.com](https://gitlab.com/gitlab-org/gitlab-ce/issues/) create an issue titled "GitLab X.X regressions" add the following text:
|
||||
|
||||
This is a meta issue to discuss possible regressions in this monthly release and any patch versions.
|
||||
Please do not raise issues directly in this issue but link to issues that might warrant a patch release.
|
||||
The decision to create a patch release or not is with the release manager who is assigned to this issue.
|
||||
The release manager will comment here about the plans for patch releases.
|
||||
|
||||
Assign the issue to the release manager and /cc all the core-team members active on the issue tracker. If there are any known bugs in the release add them immediately.
|
||||
|
||||
## Tweet about RC1
|
||||
|
||||
Tweet about the RC release:
|
||||
|
||||
> GitLab x.x.0.rc1 is out. This release candidate is only suitable for testing. Please link regressions issues from LINK_TO_REGRESSION_ISSUE
|
||||
|
||||
## Prepare the blog post
|
||||
|
||||
- Start with a complete copy of the [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md) and fill it out.
|
||||
- Make sure the blog post contains information about the GitLab CI release.
|
||||
|
@ -228,34 +126,7 @@ It is important to do this as soon as possible, so we can catch any errors befor
|
|||
- Assign to one reviewer who will fix spelling issues by editing the branch (either with a git client or by using the online editor)
|
||||
- Comment to the reviewer: '@person Please mention the whole team as soon as you are done (3 workdays before release at the latest)'
|
||||
|
||||
### **4. Create a regressions issue**
|
||||
|
||||
On [the GitLab CE issue tracker on GitLab.com](https://gitlab.com/gitlab-org/gitlab-ce/issues/) create an issue titled "GitLab X.X regressions" add the following text:
|
||||
|
||||
This is a meta issue to discuss possible regressions in this monthly release and any patch versions.
|
||||
Please do not raise issues directly in this issue but link to issues that might warrant a patch release.
|
||||
The decision to create a patch release or not is with the release manager who is assigned to this issue.
|
||||
The release manager will comment here about the plans for patch releases.
|
||||
|
||||
Assign the issue to the release manager and /cc all the core-team members active on the issue tracker. If there are any known bugs in the release add them immediately.
|
||||
|
||||
### **5. Tweet**
|
||||
|
||||
Tweet about the RC release:
|
||||
|
||||
> GitLab x.x.0.rc1 is out. This release candidate is only suitable for testing. Please link regressions issues from LINK_TO_REGRESSION_ISSUE
|
||||
|
||||
# **1 workdays before release - Preparation**
|
||||
|
||||
### **0. Doublecheck blog post**
|
||||
|
||||
Doublecheck the everyone has been mentioned in the blog post.
|
||||
|
||||
### **1. Pre QA merge**
|
||||
|
||||
Merge CE into EE before doing the QA.
|
||||
|
||||
### **2. QA**
|
||||
## QA
|
||||
|
||||
Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress.
|
||||
|
||||
|
@ -263,19 +134,14 @@ Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gi
|
|||
|
||||
**NOTE** Upgrader can only be tested when tags are pushed to all repositories. Do not forget to confirm it is working before releasing. Note that in the issue.
|
||||
|
||||
### **3. Fix anything coming out of the QA**
|
||||
#### Fix anything coming out of the QA
|
||||
|
||||
Create an issue with description of a problem, if it is quick fix fix it yourself otherwise contact the team for advice.
|
||||
|
||||
**NOTE** If there is a problem that cannot be fixed in a timely manner, reverting the feature is an option! If the feature is reverted,
|
||||
create an issue about it in order to discuss the next steps after the release.
|
||||
|
||||
# **Workday before release - Create Omnibus tags and build packages**
|
||||
|
||||
**Make sure EE `x-x-stable-ee` has latest changes from CE `x-x-stable`**
|
||||
|
||||
|
||||
### **1. Release code**
|
||||
## Create CE, EE, CI stable versions
|
||||
|
||||
Get release tools
|
||||
|
||||
|
@ -296,28 +162,27 @@ Also perform these steps for GitLab CI:
|
|||
- create annotated tag
|
||||
- push the stable branch and the annotated tag to the public repositories
|
||||
|
||||
### **2. Update installation.md**
|
||||
|
||||
Update [installation.md](/doc/install/installation.md) to the newest version in master.
|
||||
|
||||
|
||||
### **3. Build the Omnibus packages**
|
||||
## Create Omnibus tags and build 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.
|
||||
|
||||
|
||||
# **22nd - Release CE, EE and CI**
|
||||
## Release CE, EE and CI
|
||||
|
||||
### **1. Publish packages for new release**
|
||||
### 1. Publish packages for new release
|
||||
|
||||
Update `downloads/index.html` and `downloads/archive/index.html` in `www-gitlab-com` repository.
|
||||
|
||||
### **2. Publish blog for new release**
|
||||
### 2. Publish blog for new release
|
||||
|
||||
Doublecheck the everyone has been mentioned in the blog post.
|
||||
Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository.
|
||||
|
||||
### **3. Tweet to blog**
|
||||
### 3. 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.
|
||||
|
@ -326,7 +191,7 @@ Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE <li
|
|||
|
||||
Consider creating a post on Hacker News.
|
||||
|
||||
# **1 workday after release - Update GitLab.com**
|
||||
## Update GitLab.com with stable version
|
||||
|
||||
- Build a package for gitlab.com based on the official release instead of RC1
|
||||
- Deploy the package (should not need downtime because of the small difference with RC1)
|
||||
|
|
Loading…
Reference in a new issue