12 KiB
Monthly Release
NOTE: This is a guide for GitLab developers.
7 workdays before release - Code Freeze & Release Manager
1. Stop merging in code, except for important bug fixes
2. 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
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.
Xth:
- [ ] Update the CE changelog (#LINK)
- [ ] Update the EE changelog (#LINK)
- [ ] Update the CI changelog (#LINK)
- [ ] Triage the omnibus-gitlab milestone
Xth:
- [ ] Merge CE in to EE (#LINK)
- [ ] Close the omnibus-gitlab milestone
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:
- [ ] 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)
- [ ] Start blog post (#LINK)
Xth:
- [ ] Do QA and fix anything coming out of it (#LINK)
22nd:
- [ ] Release CE, EE and CI (#LINK)
Xth:
- [ ] Deploy to GitLab.com (#LINK)
4. 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
Ensure that there is enough time to incorporate the findings of the release candidate, etc.
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
- Check if it references the correct branch
x-x-stable(doesn't exist yet, but that is okay) - Check the GitLab Shell version
- Check the Git version
- There might be other changes. Ask around.
2. Create update guides
- Create: CE update guide from previous version. Like
7.3-to-7.4.md - Create: CE to EE update guide in EE repository for latest version.
- Update:
6.x-or-7.x-to-7.x.mdto latest version. - 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 changed since the last release.
-
Check if the Git version 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-ssl
- https://gitlab.com/gitlab-org/gitlab-shell/commits/master/config.yml.example
- config/gitlab.yml.example
- config/unicorn.rb.example
- config/database.yml.mysql
- config/database.yml.postgresql
- config/initializers/rack_attack.rb.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
9. Start application
10. Check application status
3. Code quality indicators
Make sure the code quality indicators are green / good.
-
on ci.gitlab.org (master branch) -
(master branch) -
-
this button can be yellow (small updates are available) but must not be red (a security fix or an important update is available) -
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
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.
3. Prepare the blog post
- Start with a complete copy of the release blog template 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
- 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 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
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.
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
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
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
2. Update installation.md
Update installation.md to the newest version in master.
3. Build the Omnibus packages
Follow the release doc in the Omnibus repository. 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
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
Merge the blog merge request 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 #gitlab"
Consider creating a post on Hacker News.
1 workday after release - Update GitLab.com
- 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)