diff --git a/README.md b/README.md index b99390072fc77b0592c06e7a6865bab45c9ad1f1..ef09bafb8213ecaba5e1c591cce8ee6a12d2e645 100644 --- a/README.md +++ b/README.md @@ -46,7 +46,9 @@ does not apply when going over the deadline, so do not be late! ## Guides -- [How to release new minor versions of GitLab each month](general/monthly.md) +Below is the list of guides that can be useful while the new process documentation +is being migrated: + - [How to release patch versions of GitLab](general/patch.md) - [How to release security fixes for GitLab](general/security.md) - [How to pick specific changes into `stable` branches](general/pick-changes-into-stable.md) diff --git a/general/monthly.md b/general/monthly.md index eb423fc39168b133244be85ba236dbb08e8d2fc0..805ce2888e0629f3e9820910679077e8fac53363 100644 --- a/general/monthly.md +++ b/general/monthly.md @@ -1,67 +1 @@ -# Monthly Release - -GitLab releases a new minor version (`X.Y`) every month on the 22nd. The history -and reasoning behind this schedule can be found [on the blog]. - -The [release manager] should begin the monthly release process *no earlier than* the 8th (Pacific time, midnight is the start of the workday in Europe). -The last day to reliably get your code in the release is the 7th (Pacific time). - -For an idea of the release process please see the [monthly template](https://gitlab.com/gitlab-org/release-tools/blob/master/templates/monthly.md.erb). - -The release manager should make sure there's a work in progress blog post -available for the next release the moment the previous release has been -published. This allows other developers to leave comments about the release, -instead of having to note them down elsewhere. - -[on the blog]: https://about.gitlab.com/2015/12/07/why-we-shift-objectives-and-not-release-dates-at-gitlab/ -[release manager]: ../../quickstart/release-manager.md - -## Process - -### 1. Create an issue to track the release - -In order to keep track of the various tasks that need to happen each day leading -up to the final release, we create an issue on the [GitLab CE issue tracker] and -update it as we progress. - -1. Set up [API access for rake tasks](rake-tasks.md#setup) - -1. Create the issue using the - [`monthly_issue`](rake-tasks.md#monthly_issueversion) Rake task: - - ```sh - # NOTE: This command is an example! Update it to reflect new version numbers. - bundle exec rake "monthly_issue[8.2.0]" - ``` - -1. You may want to **bookmark** the issue until it's closed at the end of the - release cycle. - -[GitLab CE issue tracker]: https://gitlab.com/gitlab-org/gitlab-ce/issues - -### 2. Complete the daily release tasks - -Once the release schedule begins, each work day has something that needs to be -done. Perform the tasks and mark them as complete in the issue as you progress. - -If you're not sure what to do for any task, [check the guides](../README.md#guides). - -## Getting Help - -Completing release tasks on time is very important. If you experience problems with any of -release tasks and you don't know who to ask then you should contact someone from this list: - -* Build Lead [@marin](https://gitlab.com/marin) -* VP of Engineering [@edjdev](https://gitlab.com/edjdev) -* CTO [@dzaporozhets](https://gitlab.com/dzaporozhets) - -The earlier we determine problem or delay in release - the easier it is to fix it. - -## Priorities - -Keep up with the release schedule. It's better to ship less but on time. -Revert code that delays the release. - ---- - -[Return to Guides](../README.md#guides) +Moved to [monthly process doc](monthly/process.md) diff --git a/general/monthly/process.md b/general/monthly/process.md index 034d2388d3c6ebc3b55f2984551c62aec250a27c..ab5794ae164cb4ddeed913f2087f58da92960e74 100644 --- a/general/monthly/process.md +++ b/general/monthly/process.md @@ -1 +1,38 @@ -To be added. +# Monthly Release + +GitLab releases a new minor version (`X.Y`) every month on the 22nd. The history +and reasoning behind this schedule can be found [on the blog]. + +The [release manager] should begin preparing the monthly release process before +the [feature freeze]. Others involved in this process include [developer], +[quality engineer] and [product managers]. + +## General process + +This overview is there to give an idea of the flow, each party involved has their +own detailed process. + +In short: + +1. Release managers make sure that ce-to-ee merge is done on time +1. Release managers start preparing RCs before the [feature freeze] +1. Release managers deploy to one of staging environments and create QA issues +1. Quality Engineer drives the QA issues and makes sure that the deadlines are followed +1. Developers and Product Managers verify their features and bug fixes +1. Release managers progress to production deploys after the QA deadlines have passed +1. When the feature free +ze starts, developers can only include features by +raising an issue and pinging the responsible people +1. Release managers create as many release candidates needed before the release on +the 22nd +1. Product managers prepare the release blog post +1. When the release is ready for public, release manager and product managers +syncronise package promotion and blog release. + + +[on the blog]: https://about.gitlab.com/2015/12/07/why-we-shift-objectives-and-not-release-dates-at-gitlab/ +[release manager]: ../../../quickstart/release-manager.md +[feature freeze]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md#feature-freeze-on-the-7th-for-the-release-on-the-22nd +[developer]: developer.md +[quality engineer]: quality.md +[product managers]: release-manager.md diff --git a/general/monthly/release-manager.md b/general/monthly/release-manager.md index 034d2388d3c6ebc3b55f2984551c62aec250a27c..4a59ab9dab60a3265bba9f8902e3192189f8675a 100644 --- a/general/monthly/release-manager.md +++ b/general/monthly/release-manager.md @@ -1 +1,51 @@ -To be added. +# Monthly release as Release Manager + +Before proceeding further, make sure that you read the [release manager quickstart] +document. It contains a high level overview of what tasks Release manager needs +to deliver. + +## Priorities + +Keep up with the release schedule. It's better to ship less but on time. +Revert code that delays the release. Escalate on time if you observe that the +deadlines will be slipping. See [Getting Help section](#getting-help) for +an escalation path. + +## Process + +### Create a meta issue to track the release + +In order to keep track of the various tasks that need to happen each day leading +up to the final release, we create issues on the [release/tasks issue tracker] and +update them as we progress. + +As a release trainee, you should have received all of your access through your +onboarding task. + +1. Create the release meta issue to track the monthly release using the `RM-Stable-Release-Meta` issue template. See the [example release meta issue]. +1. In the meta issue, define the 2 deadlines: final release candidate deadline and the 22nd task list. +1. You may want to **bookmark** the issue until it's closed at the end of the + release cycle. + +[release/tasks issue tracker]: https://gitlab.com/gitlab-org/release/tasks/ +[example release meta issue]: https://gitlab.com/gitlab-org/release/tasks/issues/146 + +### Complete the daily release tasks + +Once the release schedule begins, each work day has something that needs to be +done. Perform the tasks and mark them as complete in the issue as you progress. + +If you're not sure what to do for any task, [check the guides](../README.md#guides). + +## Getting Help + +Completing release tasks on time is very important. If you experience problems with any of +release tasks and you don't know who to ask then you should contact someone from this list: + +* Distribution Lead [@marin](https://gitlab.com/marin) +* VP of Engineering [@edjdev](https://gitlab.com/edjdev) +* CTO [@dzaporozhets](https://gitlab.com/dzaporozhets) + +The earlier we determine problem or delay in release - the easier it is to fix it. + +[release manager quickstart]: ../../quickstart/release-manager.md