BigW Consortium Gitlab

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

3
NOTE: This is a guide for GitLab developers.
4

5
# **7 workdays before release - Code Freeze & Release Manager**
6

7
### **1. Stop merging in code, except for important bug fixes**
8

9
### **2. Release Manager**
10 11 12

A release manager is selected that coordinates the entire release of this version. 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.

13
### **3. Create an overall issue**
Valery Sizov committed
14

15
Create issue for GitLab CE project(internal). Name it "Release x.x.x" for easier searching.
16
Replace the dates with actual dates based on the number of workdays before the release.
17 18

```
19
Xth:
20

Sytse Sijbrandij committed
21
* Update the changelog (#LINK)
22
* Triage the omnibus-gitlab milestone
23

24
Xth:
25 26

* Merge CE in to EE (#LINK)
27
* Close the omnibus-gitlab milestone
28

29
Xth:
30

Sytse Sijbrandij committed
31
* Create x.x.0.rc1 (#LINK)
32
* Build package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package)
33

34
Xth:
35

36
* Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package)
Sytse Sijbrandij committed
37 38
* Regression issue and tweet about rc1 (#LINK)
* Start blog post (#LINK)
39

40
Xth:
41

Sytse Sijbrandij committed
42
* Do QA and fix anything coming out of it (#LINK)
43 44 45

22nd:

Sytse Sijbrandij committed
46
* Release CE and EE (#LINK)
47

48
Xth:
49

50
* * Deploy to GitLab.com (#LINK)
51 52 53

```

54
### **4. Update changelog**
55 56 57

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.

58 59 60 61
### **5. Take weekend and vacations into account**

Ensure that there is enough time to incorporate the findings of the release candidate, etc.

62
# **6 workdays before release- Merge the CE into EE**
63

64
Do this via a merge request.
65

66
# **5 workdays before release - Create RC1**
67

68
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.
Marin Jankovski committed
69

70
### **1. Update the installation guide**
71 72

1. Check if it references the correct branch `x-x-stable` (doesn't exist yet, but that is okay)
73 74
1. Check the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782)
1. Check the [Git version](/lib/tasks/gitlab/check.rake#L794)
75
1. There might be other changes. Ask around.
76

77
### **2. Create update guides**
78

79
1. Create: CE update guide from previous version. Like `7.3-to-7.4.md`
80
1. Create: CE to EE update guide in EE repository for latest version.
81
1. Update: `6.x-or-7.x-to-7.x.md` to latest version.
82

83
It's best to copy paste the previous guide and make changes where necessary.
84
The typical steps are listed below with any points you should specifically look at.
85

86
#### 0. Any major changes?
87 88 89

List any major changes here, so the user is aware of them before starting to upgrade. For instance:

90 91 92
- Database updates
- Web server changes
- File structure changes
93 94 95 96 97 98 99

#### 1. Make backup

#### 2. Stop server

#### 3. Do users need to update dependencies like `git`?

100
- Check if the [GitLab Shell version](/lib/tasks/gitlab/check.rake#L782) changed since the last release.
101

102
- Check if the [Git version](/lib/tasks/gitlab/check.rake#L794) changed since the last release.
103

104 105 106 107 108 109 110 111
#### 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?

112
Check if any of these changed since last release:
113

114 115
- [lib/support/nginx/gitlab](/lib/support/nginx/gitlab)
- [lib/support/nginx/gitlab-ssl](/lib/support/nginx/gitlab-ssl)
116
- <https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example>
117 118 119 120 121 122
- [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)
123 124 125

#### 8. Need to update init script?

126
Check if the `init.d/gitlab` script changed since last release: [lib/support/init.d/gitlab](/lib/support/init.d/gitlab)
127 128 129 130 131

#### 9. Start application

#### 10. Check application status

132
### **3. Code quality indicators**
133

134
Make sure the code quality indicators are green / good.
135

136
- [![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)
137

138
- [![Build Status](https://semaphoreapp.com/api/v1/projects/2f1a5809-418b-4cc2-a1f4-819607579fe7/243338/badge.png)](https://semaphoreapp.com/gitlabhq/gitlabhq) (master branch)
139

140
- [![Code Climate](https://codeclimate.com/github/gitlabhq/gitlabhq.png)](https://codeclimate.com/github/gitlabhq/gitlabhq)
141

142
- [![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)
143

144
- [![Coverage Status](https://coveralls.io/repos/gitlabhq/gitlabhq/badge.png?branch=master)](https://coveralls.io/r/gitlabhq/gitlabhq)
145

146
### **4. Run release tool**
147

148 149
**Make sure EE `master` has latest changes from CE `master`**

150
Get release tools
151

152
```
153 154
git clone git@dev.gitlab.org:gitlab/release-tools.git
cd release-tools
155 156
```

157 158 159 160 161 162 163
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
```

164
Create release candidate and stable branch:
165 166

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

170
Now developers can use master for merging new features.
171 172 173
So you should use stable branch for future code chages related to release.


174
# **4 workdays before release - Release RC1**
175

Valery Sizov committed
176
### **1. Determine QA person
177

Valery Sizov committed
178 179 180
Notify person of QA day.

### **2. Update GitLab.com**
181

182 183
Merge the RC1 EE code into GitLab.com.
Once the build is green, create a package.
184
If there are big database migrations consider testing them with the production db on a VM.
185
Try to deploy in the morning.
186 187
It is important to do this as soon as possible, so we can catch any errors before we release the full version.

Valery Sizov committed
188
### **3. Prepare the blog post**
189

190 191 192
- 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.
- Check the changelog of CE and EE for important changes.
- Create a WIP MR for the blog post
193
- Ask Dmitriy to add screenshots to the WIP MR.
Valery Sizov committed
194 195
- Decide with team who will be the MVP user. 
- Create WIP MR for adding MVP to MVP page on website
196
- 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.
197
- Create a merge request on [GitLab.com](https://gitlab.com/gitlab-com/www-gitlab-com/tree/master)
198 199
- Assign to one reviewer who will fix spelling issues by editing the branch (can use the online editor)
- After the reviewer is finished the whole team will be mentioned to give their suggestions via line comments
200

Valery Sizov committed
201
### **4. Create a regressions issue**
202 203 204 205 206 207 208 209 210 211

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.

212
### **4. Tweet**
213 214 215

Tweet about the RC release:

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

218
# **1 workdays before release - Preparation**
219

220 221 222 223 224
### **1. Pre QA merge**

Merge CE into EE before doing the QA.

### **2. QA**
225

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

228
Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md).
229 230 231

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

232
### **3. Fix anything coming out of the QA**
233

234 235 236 237
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.
238

239
# **22nd - Release CE and EE**
240

241
**Make sure EE `x-x-stable-ee` has latest changes from CE `x-x-stable`**
242

243

244
### **1. Release code**
245

246
Get release tools
247

248
```
249 250
git clone git@dev.gitlab.org:gitlab/release-tools.git
cd release-tools
251 252
```

253
Bump version, create release tag and push to remotes:
254 255

```
256
bundle exec rake release["x.x.0"]
257 258
```

259

260
### **2. Update installation.md**
261

262
Update [installation.md](/doc/install/installation.md) to the newest version in master.
263 264


265 266 267 268
### **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.
Jacob Vosmaer committed
269

270

271
### **4. Publish packages for new release**
272 273 274

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

275
### **5. Publish blog for new release**
276

277 278
Merge the [blog merge request](#1-prepare-the-blog-post) in `www-gitlab-com` repository.

279
### **6. Tweet to blog**
280

Sytse Sijbrandij committed
281 282
Send out a tweet to share the good news with the world.
List the most important features and link to the blog post.
283

Sytse Sijbrandij committed
284
Proposed tweet for CE "GitLab X.X is released! It brings *** <link-to-blogpost>"
285

286
# **1 workday after release - Update GitLab.com**
287

288 289
- Build a package for gitlab.com based on the official release instead of RC1
- Deploy the package
290

291
# **25th - Release GitLab CI**
292

Valery Sizov committed
293 294 295 296 297 298 299 300
- Create the update guid `doc/x.x-to-x.x.md`.
- Update CHANGELOG
- Bump version
- Create annotated tags `git tag -a vx.x.0 -m 'Version x.x.0' xxxxx`
- Create stable branch `x-x-stable`
- Create GitHub release post
- Post to blog about release
- Post to twitter
301 302