BigW Consortium Gitlab

monthly.md 8.42 KB
Newer Older
1
# Monthly Release
2

3
NOTE: This is a guide used by the GitLab B.V. developers.
4

5 6 7 8
It starts 7 working days before the release.
The release manager doesn't have to perform all the work but must ensure someone is assigned.
The current release manager must schedule the appointment of the next release manager.
The new release manager should create overall issue to track the progress.
9

10
## Release Manager
11

12
A release manager is selected that coordinates all releases the coming month, including the patch releases for previous releases.
13 14
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.
15

16
## Take vacations into account
17

18
The time is measured in weekdays to compensate for weekends.
19 20 21
Do everything on time to prevent problems due to rush jobs or too little testing time.
Make sure that you take into account any vacations of maintainers.
If the release is falling behind immediately warn the team.
22 23

## Create an overall issue and follow it
Valery Sizov committed
24

25
Create issue for GitLab CE project(internal). Name it "Release x.x.x" for easier searching.
26
Replace the dates with actual dates based on the number of workdays before the release.
27
All steps from issue template are explained below
28 29

```
30
Xth: (7 working days before the 22nd)
31

32
- [ ] Code freeze
33 34 35
- [ ] Update the CE changelog (#LINK)
- [ ] Update the EE changelog (#LINK)
- [ ] Update the CI changelog (#LINK)
36
- [ ] Triage the omnibus-gitlab milestone
37

38
Xth: (6 working days before the 22nd)
39

40
- [ ] Merge CE master in to EE master via merge request (#LINK)
41
- [ ] Determine QA person and notify this person
42 43
- [ ] Check the tasks in [how to rc1 guide](howto_rc1.md) and delegate tasks if necessary
- [ ] Create CE, EE, CI RC1 versions (#LINK)
44

45
Xth: (5 working days before the 22nd)
46

47
- [ ] Do QA and fix anything coming out of it (#LINK)
48
- [ ] Close the omnibus-gitlab milestone
49
- [ ] Prepare the blog post (#LINK)
50

51
Xth: (4 working days before the 22nd)
52

53
- [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package)
54
- [ ] Update ci.gitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package)
55 56
- [ ] Create regression issues (CE, CI) (#LINK)
- [ ] Tweet about rc1 (#LINK)
57

58
Xth: (3 working days before the 22nd)
59

60
- [ ] Merge CE stable branch into EE stable branch
61

62
Xth: (2 working days before the 22nd)
63

64
- [ ] Check that everyone is mentioned on the blog post (the reviewer should have done this one working day ago)
65
- [ ] Check that MVP is added to the mvp page (source/mvp/index.html in www-gitlab-com)
66

67
Xth: (1 working day before the 22nd)
68 69 70

- [ ] Create CE, EE, CI stable versions (#LINK)
- [ ] Create Omnibus tags and build packages
71
- [ ] Update GitLab.com with the stable version (#LINK)
72
- [ ] Update ci.gitLab.com with the stable version (#LINK)
73

74 75
22nd:

76
- [ ] Release CE, EE and CI (#LINK)
77 78 79

```

80
- - -
81

82
## Code Freeze
83

84
Stop merging code in master, except for important bug fixes
85

86
## Update changelog
87

88 89
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.
90

91
There are three changelogs that need to be updated: CE, EE and CI.
92

93
## Create RC1 (CE, EE, CI)
94

95
[Follow this How-to guide](howto_rc1.md) to create RC1.
Valery Sizov committed
96

97 98
## Prepare CHANGELOG for next release

99
Once the stable branches have been created, update the CHANGELOG in `master` with the upcoming version, usually X.X.X.pre.
100

101 102 103 104
## QA

Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress.

105
Use the omnibus packages created for RC1 of Enterprise Edition using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md).
106 107 108 109 110 111 112 113 114 115

**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.

#### 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.

116
## Update GitLab.com with RC1
117

118
Use the omnibus EE packages created for RC1.
119
If there are big database migrations consider testing them with the production db on a VM.
120
Try to deploy in the morning.
121 122
It is important to do this as soon as possible, so we can catch any errors before we release the full version.

123
## Create a regressions issue
124 125 126 127 128 129 130 131

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.

132
Assign the issue to the release manager and at mention all members of gitlab core team. If there are any known bugs in the release add them immediately.
133

134
## Tweet about RC1
135 136 137

Tweet about the RC release:

Sytse Sijbrandij committed
138
> GitLab x.x.0.rc1 is out. This release candidate is only suitable for testing. Please link regressions issues from LINK_TO_REGRESSION_ISSUE
139

140
## Prepare the blog post
141

142 143 144 145 146 147
1. 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.
1. Make sure the blog post contains information about the GitLab CI release.
1. Check the changelog of CE and EE for important changes.
1. Also check the CI changelog
1. Add a proposed tweet text to the blog post WIP MR description.
1. Create a WIP MR for the blog post
148 149
1. Ask Dmitriy (or a team member with OS X) to add screenshots to the WIP MR.
1. Decide with core team who will be the MVP user.
150 151 152 153 154
1. Create WIP MR for adding MVP to MVP page on website
1. Add a note if there are security fixes: This release fixes an important security issue and we advise everyone to upgrade as soon as possible.
1. Create a merge request on [GitLab.com](https://gitlab.com/gitlab-com/www-gitlab-com/tree/master)
1. Assign to one reviewer who will fix spelling issues by editing the branch (either with a git client or by using the online editor)
1. Comment to the reviewer: '@person Please mention the whole team as soon as you are done (3 workdays before release at the latest)'
155

156
## Create CE, EE, CI stable versions
157

158
Get release tools
159

160
```
161 162
git clone git@dev.gitlab.org:gitlab/release-tools.git
cd release-tools
163 164
```

165
Bump version, create release tag and push to remotes:
166 167

```
168
bundle exec rake release["x.x.0"]
169 170
```

171
This will create correct version and tag and push to all CE, EE and CI remotes.
172

173
Update [installation.md](/doc/install/installation.md) to the newest version in master.
174 175


176
## Create Omnibus tags and build packages
177 178 179

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.
Jacob Vosmaer committed
180

181 182 183 184
## Update GitLab.com with the stable version

- Deploy the package (should not need downtime because of the small difference with RC1)
- Deploy the package for ci.gitlab.com
185

186
## Release CE, EE and CI
187

188
__1. Publish packages for new release__
189 190 191

Update `downloads/index.html` and `downloads/archive/index.html` in `www-gitlab-com` repository.

192
__2. Publish blog for new release__
193

194
Doublecheck the everyone has been mentioned in the blog post.
195 196
Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository.

197
__3. Tweet to blog__
198

Sytse Sijbrandij committed
199 200
Send out a tweet to share the good news with the world.
List the most important features and link to the blog post.
201

202
Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE <link-to-blog-post> #gitlab"
203 204

Consider creating a post on Hacker News.
205

206 207 208
## Release new AMIs

[Follow this guide](https://dev.gitlab.org/gitlab/AMI/blob/master/README.md)
209 210 211 212

## Create a WIP blogpost for the next release

Create a WIP blogpost using [release blog template](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/doc/release_blog_template.md).