1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
|
# Monthly Release
NOTE: This is a guide for GitLab developers.
It starts 7 days before release. Current release manager must choose next release manager.
New release manager should create overall issue at GitLab
## 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.
## Take weekend and vacations into account
The time is measured in weekdays to compensate for weekends.
Do things on time to prevent problems due to rush jobs or too little testing time.
Make sure that you take into account vacations of maintainers.
## 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: (7 working days before 22th)
- [ ] Code freeze
- [ ] Update the CE changelog (#LINK)
- [ ] Update the EE changelog (#LINK)
- [ ] Update the CI changelog (#LINK)
- [ ] Triage the omnibus-gitlab milestone
Xth: (6 working days before 22th)
- [ ] Merge CE master in to EE master via merge request (#LINK)
- [ ] Create CE, EE, CI RC1 versions (#LINK)
- [ ] Determine QA person and notify this person
Xth: (5 working days before 22th)
- [ ] Do QA and fix anything coming out of it (#LINK)
- [ ] Close the omnibus-gitlab milestone
Xth: (4 working days before 22th)
- [ ] Build rc1 package for GitLab.com (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#build-a-package)
- [ ] Update GitLab.com with rc1 (#LINK) (https://dev.gitlab.org/cookbooks/chef-repo/blob/master/doc/administration.md#deploy-the-package)
Xth: (3 working days before 22th)
- [ ] Create regression issues (CE, CI) (#LINK)
- [ ] Tweet about rc1 (#LINK)
- [ ] Prepare the blog post (#LINK)
Xth: (2 working days before 22th)
- [ ] Merge CE stable branch into EE stable branch
- [ ] Check that everyone is mentioned on the blog post (the reviewer should have done this one working day ago)
Xth: (1 working day before 22th)
- [ ] Create CE, EE, CI stable versions (#LINK)
- [ ] Create Omnibus tags and build packages
22nd:
- [ ] Release CE, EE and CI (#LINK)
Xth: (1 working day after 22th)
- [ ] Deploy to GitLab.com (#LINK)
```
- - -
## 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.
## Create RC1 (CE, EE, CI)
[Follow this How-to guide](howto_rc1.md) to create RC1.
## QA
Create issue on dev.gitlab.org `gitlab` repository, named "GitLab X.X QA" in order to keep track of the progress.
Use the omnibus packages of Enterprise Edition using [this guide](https://dev.gitlab.org/gitlab/gitlab-ee/blob/master/doc/release/manual_testing.md).
**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.
## Update GitLab.com with RC1
Merge the RC1 EE code into GitLab.com.
Once the build is green, create a package.
If there are big database migrations consider testing them with the production db on a VM.
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.
## 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.
- Check the changelog of CE and EE for important changes.
- Also check the CI changelog
- Add a proposed tweet text to the blog post WIP MR description.
- Create a WIP MR for the blog post
- Ask Dmitriy to add screenshots to the WIP MR.
- Decide with team who will be the MVP user.
- Create WIP MR for adding MVP to MVP page on website
- 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.
- Create a merge request on [GitLab.com](https://gitlab.com/gitlab-com/www-gitlab-com/tree/master)
- 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)'
## Create CE, EE, CI stable versions
Get release tools
```
git clone git@dev.gitlab.org:gitlab/release-tools.git
cd release-tools
```
Bump version, create release tag and push to remotes:
```
bundle exec rake release["x.x.0"]
```
Also perform these steps for GitLab CI:
- bump version in the stable branch
- create annotated tag
- push the stable branch and the annotated tag to the public repositories
Update [installation.md](/doc/install/installation.md) to the newest version in master.
## 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.
## Release CE, EE and CI
### 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
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
Send out a tweet to share the good news with the world.
List the most important features and link to the blog post.
Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE <link-to-blogpost> #gitlab"
Consider creating a post on Hacker News.
## Update GitLab.com with stable version
- Deploy the package (should not need downtime because of the small difference with RC1)
|