gitlab-org--gitlab-foss/doc/release/howto_rc1.md

# 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)`
Cleanup and refactor release doc. Follow issue as a todo list 2015-01-09 15:29:48 -05:00			`# 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.`

Remove bold text 2015-01-14 20:44:59 -05:00			`### 1. Update the installation guide`
Cleanup and refactor release doc. Follow issue as a todo list 2015-01-09 15:29:48 -05:00
			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.`

Remove bold text 2015-01-14 20:44:59 -05:00			`### 2. Create update guides`
Cleanup and refactor release doc. Follow issue as a todo list 2015-01-09 15:29:48 -05:00
			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`

Remove bold text 2015-01-14 20:44:59 -05:00			`### 3. Code quality indicators`
Cleanup and refactor release doc. Follow issue as a todo list 2015-01-09 15:29:48 -05:00
			`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`
Fix code block in rc1 doc 2015-01-14 21:07:42 -05:00			* `git tag -a v$(cat VERSION) -m "Version $(cat VERSION)"`
Cleanup and refactor release doc. Follow issue as a todo list 2015-01-09 15:29:48 -05:00			* `git push public x-y-stable v$(cat VERSION)`