diff --git a/general/deploy/auto-deploy.md b/general/deploy/auto-deploy.md new file mode 100644 index 0000000000000000000000000000000000000000..90f6fed9d5f6dd1b782873180414df917cc1453f --- /dev/null +++ b/general/deploy/auto-deploy.md @@ -0,0 +1,391 @@ +# Overview + +GitLab auto-deploy deployments allow us to increase the frequency +of deployments to GitLab.com from the master branch of +[gitlab-ee](https://gitlab.com/gitlab-org/gitlab-ee) +and [omnibus-gitlab](https://gitlab.com/gitlab-org/omnibus-gitlab). + +Due to the fact that this process is a shift from the monthly release cycle that is in place for self-managed customers, and is generally a disruptive workflow change, below you can find the transition plan details as well as more details on the parts process consists of. + +## Transition plan + +With the current process highlighting two special days, the 7th and 22nd of the month, it is important to have an understanding of how the transition period will look like and what that means for everyone accustomed to the existing workflow. +Below you can find two overviews: + +* Overview per stakeholder lists important changes for different roles involved in releasing GitLab and to GitLab.com +* Process overview provides a timeline breakdown per day for all stakeholders, and is a more detailed overview + +### Overview per stakeholder + +The change in frequency of deployments to GitLab.com impacts the self-managed public releases, and stakeholders in a different areas: + +* Developers +* Release Managers +* Product Managers + +### Process overview + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DateProcessChange
2019-05-01Start of the new release cycle + + * No change from the currently established process + * Release managers will create the `11-11-stable` branches, tag `11.11.0-rc1` and deploy to the staging server + * QA issue is created and the 24 hour deadline for checking of the items in the QA checklist is running + +
2019-05-02Deployment to GitLab.com environments + + * No change from the currently established process + * Release managers will deploy `11.11.0-rc1` to production canaries and GitLab.com + +
2019-05-06Repeat the RC process + + * No change from the currently established process + * Release managers will deploy as many RCs as necessary to get GitLab.com running the latest code in the `master` branch + +
2019-05-07Feature freeze day + + * No change from the currently established process + * Changes merged in `master` on this day will be included it the next deployment to GitLab.com + * Changes merged in `master` on this day will be included in the final 11.11.0 public release + * `11-11-stable` branches will contain changes merged into `master` on this day + +
2019-05-08Post feature freeze day + + * *Change from the currently established process* + * A branch named `11-11-auto-deploy-0001` is created in gitlab-ce, gitlab-ee and omnibus-gitlab projects + * This branch is created from the latest commit on the `master` branch found on this day + * The latest commit with the passing pipeline in the `gitlab-ee` project will be selected from the `11-11-auto-deploy-0001` branch + * A new omnibus-gitlab package is created with the version `11.11.xxx+aaaa.ffff`. See below for explanation of what significance do the letters have + * This package will be automatically deployed to the staging environment + * GitLab.com has `11.11.0-rcN`running at this time + +
2019-05-08/2019-05-12First auto-deploy week + + * *Change from the currently established process* + * In case of an issue observed on staging, the developers will create a MR and label it with `Pick into 11.11` + * An automated job will automatically pick any change into `11-11-auto-deploy-0001` branch + * In case of a failure to pick automatically, a standard message will be left asking for manual intervention + * If manual intervention is needed, developer needs to join the #releases channel on slack, check the latest pinned message containing the name of the auto-deploy branch, create a MR against this branch and assign to the release manager + * A new omnibus-gitlab package is created with the version `11.11.yyy+bbbb.gggg` and is automatically deployed to the staging environment + * Release managers deploy `11.11.yyy+bbbb.gggg` to Canary at their discretion once it is confirmed that the version running is sufficiently stable + * GitLab.com has `11.11.0-rcN`running at this time + * In case of a P1/S1 problem requiring an urgent fix on a running rcN version in production environments, developer will need to inform the release managers + * Release managers will pick this change manually into the `11-11-stable` branch, create a new `11.11.-rcN` package and deploy to GitLab.com + * Changes committed to the `master` branch during this period will be a part of `11.11.0` final release + +
2019-05-12New staging deployment + + * *Change from the currently established process* + * A branch named `11-11-auto-deploy-0002` is created in gitlab-ce, gitlab-ee and omnibus-gitlab projects + * This branch is created from the latest commit on the `master` branch + * The latest commit with the passing pipeline in the `gitlab-ee` project will be selected from the `11-11-auto-deploy-0002` branch + * A new omnibus-gitlab package is created with the version `11.11.zzz+cccc.hhhh` + * This package will be automatically deployed to the staging environment + +
2019-05-13Deployment to GitLab.com + + * *Change from the currently established process* + * Release managers deploy to the package running on Canary at that moment, to GitLab.com + +
2019-05-13/2019-05-19Second auto-deploy week + + * *Change from the currently established process* + * Branch `11-11-auto-deploy-0002` is the currently active branch, and staging is being deployed from commits on this branch + * In case of an issue observed on staging, the developers will create an MR and label it with `Pick into 11.11`, which will then be automatically picked and deployed to staging + * In case of of a P1/S1 problem observed on GitLab.com, the developers will create an MR and label it with `Pick into 11.11`, and will inform the release manager that a change is addressing a current issue on GitLab.com + * Release managers will pick the change manually to `11-11-auto-deploy-0001`, and create a package that will be manually deployed to Pre environment and then GitLab.com + * Release managers deploy `11.11.zzz+cccc.hhhh` to Canary at their discretion once it is confirmed that the version running is sufficiently stable + +
2019-05-19New staging deployment + + * *Change from the currently established process* + * A branch named `11-11-auto-deploy-0003` is created in gitlab-ce, gitlab-ee and omnibus-gitlab projects + * This branch is created from the latest commit on the `master` branch + * The latest commit with the passing pipeline in the `gitlab-ee` project will be selected from the `11-11-auto-deploy-0003` branch + * A new omnibus-gitlab package is created with the version `11.11.xxx+dddd.iiii` + * This package will be automatically deployed to the staging environment + +
2019-05-20Deploy to GitLab.com + + * *Change from the currently established process* + * Release managers deploy to the package running on Canary at that moment, to GitLab.com + * Changes currently contained in the `11-11-auto-deploy-0002` branch (from which the deploy to GitLab.com was just completed) are included in the final 11.11.0 release + * Changes contained in the `11-11-auto-deploy-0003`, will be a part of `12.0.0` release + +
2019-05-20/2019-05-26Second auto-deploy week + + * *Change from the currently established process* + * Branch `11-11-auto-deploy-0003` is the currently active branch, and staging is being deployed from commits on this branch + +
+ +## Process details + +The general deployment process on GitLab.com has a couple of important new terms: + +* Auto-deploy branches +* Auto-deploy tags +* Auto-deploy schedule + +`Auto-deploy` is used to make a clear distinction between the process that has been used for years at GitLab. This will be revisited when the process is in place and stake-holders are more used to changes. + +### Auto-deploy branches + +Approximately once a week, up until the release date on the 22nd, auto-deploy +branches are created with the following format: + +``` +--auto-deploy- +``` + +example: `11-10-auto-deploy-0000001` + + +* `MAJOR.MINOR`: This comes from the currently active milestone on the gitlab-ce + project. It generally tracks to the release month and has the following + requirements: + * It must be an _active_ milestone + * The start date must be in the _past_ + * The end date must be in the _future_ +* `ID`: The pipeline `$CI_PIPELINE_IID` of the release-tools job that + created the branch. This ID is guaranteed to increment on every auto-deploy + branch. + +Auto-deploy branches are created for the following projects: + +* gitlab-ee +* gitlab-ce +* omnibus-gitlab + + +As soon as these branches are created, the latest green (passing) commit on the branch +will be tagged for an auto-deployment. + +When omnibus-gitlab is tagged, it will result in a new EE omnibus-gitlab package and a +deployment to a pre-production environment with a deployer pipeline extending to +production. + +Auto-deploy branches are _protected branches_, meaning that they require special +permission for merging and pushing and also will be mirrored on dev.gitlab.org. + +### Auto-deploy tagging + +For every auto-deploy deployment, there is a git tag that matches the version of +what is deployed. The auto-deploy tag has the following format: + +``` +..+. +``` + + +* `MAJOR.MINOR`: This is the currently active milestone in the `gitlab-org` + group on gitlab.com and follows the same requirements + for the auto-deploy branch (see above). +* `ID`: The pipeline `$CI_PIPELINE_IID` of the release-tools job that + created the tag. This ID is guaranteed to increment on every tag job. +* `gitlab-ee sha`: The sha of gitlab-ee for auto-deploy, it corresponds to a + green (passing) ref on the gitlab-ee auto-deploy branch. +* `omnibus-gitlab sha`: The sha of omnibus-gitlab that will be used for the next + auto-deploy, it corresponds to a green (passing) ref on the omnibus-gitab + auto-deploy branch + + +When the repositories are tagged, an omnibus-gitlab pipeline on dev.gitlab.org +builds the package. This pipeline will trigger a deployment +of the auto-deploy package to a pre-production environment. + +### Auto-deploy schedule + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
DayDescription
23rd + + * A new milestone is manually created named **11.12** with a start date of the 23rd and a due date of the 22nd + * A CI job creates a branch named **11-12-auto-deploy-00001** in gitlab-ce, omnibus-gitlab and + gitlab-ee from **master** + * The merge train ensures that ce is merged into ee + * The latest green commit of gitlab-ee is used to update versions GitLab + services in omnibus-gitlab. + * The commits in gitlab-ee and omnibus-gitlab are tagged with **11.12.100+aaaa.ffff** + * The resulting auto-deploy package is deployed to a pre-production environment with a deployer + pipeline extending to production + +
23rd..1st + + * MRs that are merged to master are targeted for auto-deploy by manually adding a **Pick into 11.12** tag + * A CI job picks these MRs for auto-deploy + * Labeled MRs are picked automatically into the **11-12-auto-deploy-00001** branch + * The merge train ensures that ce is merged into ee + * The next green commit on the auto-deploy branch is tagged with **11.12.101+bbbb.ffff** + * The resulting auto-deploy package is deployed to a pre-production environment with a deployer + pipeline extending to production + * MRs are updated to let the MR author know that the change has been deployed + * This process is repeated on a frequent interval, with multiple deployments + to pre-production environments and production + +
1st + + * Branch **11-12-auto-deploy-00002** created in gitlab-ce, omnibus-gitlab and + gitlab-ee from **master** + * The same automated process happens for the new auto-deploy brach, the merge + train ensures the ce->ee merge, a green commit found, tagged and deployed + to a pre-proudction environment with a deployer pipeline extending to + production + * The same picking and deploying process is now done for the new auto-deploy + branch, **11-12-auto-deploy-00002** +
8th + + * Branch **11-12-auto-deploy-00003** created in gitlab-ce, omnibus-gitlab and + gitlab-ee from **master** + * The same picking and deploying process is now done for the new auto-deploy + branch, **11-12-auto-deploy-00003** + +
15th + + * Branch **11-12-auto-deploy-00004** created in gitlab-ce, omnibus-gitlab and + gitlab-ee from **master** + * The same picking and deploying process is now done for the new auto-deploy + branch, **11-12-auto-deploy-00004** + +
22nd RELEASE DAY + + * The commit that is currently on production will be used for the official + release + * Changes that are released on production will be part of the release blog + post + * Not all picked changes will be deployed and included in the final release + as it is possible that not all MRs that are picked will have been deployed + to production in time to make the release + +
23rd + + * A new milestone is manually created named **11.13** with a start date of the 23rd and a due date of the 22nd + * The process auto-deploy cycle repeats + +
+ +## FAQ + +### How does this change the existing code freeze on the 7th? +### How often do we auto-deploy? +### What about registry, workhorse, gitaly, pages and other components? +### How do I mark an MR so that will be picked into the auto-deploy branch? +### Does auto-deploy change how we release software to the self-managed community? +### How are auto-deploy branches different than the stable branch? +### Why are we not deploying directly from the master branch? +### How do I query what ref is running on gitlab.com or a pre-production environment? +### How will marketing know what features to put in the release blog post?