From 1230209304913e37d904c8c5356ba383a54364a9 Mon Sep 17 00:00:00 2001 From: Reuben Pereira Date: Thu, 17 Feb 2022 20:25:26 +0530 Subject: [PATCH] Add an overview of how deployment pipelines are created --- README.md | 1 + general/deploy/overview.md | 13 +++++++++++++ 2 files changed, 14 insertions(+) create mode 100644 general/deploy/overview.md diff --git a/README.md b/README.md index 2bd7e910..4212c2d0 100644 --- a/README.md +++ b/README.md @@ -40,6 +40,7 @@ general process overview and specific documentation for different stakeholders. ## Deployment +- [Overview](general/deploy/overview.md) - [Traffic Generation](general/deploy/traffic-generation.md) - [Post Deployment Patches](general/deploy/post-deployment-patches.md) - [Auto-deploy process](general/deploy/auto-deploy.md) diff --git a/general/deploy/overview.md b/general/deploy/overview.md new file mode 100644 index 00000000..922bc289 --- /dev/null +++ b/general/deploy/overview.md @@ -0,0 +1,13 @@ +# Overview of deployment pipelines + +* A new auto deploy branch (ex: [14-8-auto-deploy-2022021712](https://gitlab.com/gitlab-org/security/gitlab/-/tree/14-8-auto-deploy-2022021712)) is created in , at regular intervals by the [auto_deploy:prepare scheduled pipeline](https://ops.gitlab.net/gitlab-org/release/tools/-/pipeline_schedules). Release managers usually adjust the schedule at the start of their rotation. + +* A tag is created in after a new auto deploy branch is created. This is done by the [auto_deploy:tag scheduled pipeline](https://ops.gitlab.net/gitlab-org/release/tools/-/pipeline_schedules). + +* A new tag starts a new [deployment pipeline](https://ops.gitlab.net/gitlab-org/release/tools/-/pipelines?scope=tags) (also called a coordinator pipeline). + +* The coordinator pipeline triggers child pipelines in to deploy the package to each environment. + +* The deployment pipelines in and are only accessible on a need-to-know basis to reduce the blast radius of an incident like the leakage of a production token in job logs. Additionally, we need to be compliant with SOC/ISO standards. If everyone had access to deployment job logs, it would move us into a different compliance control that would require us to have additional processes in place to deal with incidents.[1] + +\[1\]: It is currently not possible to give people access to pipelines without giving them access to job logs. If that becomes possible in the future, we could explore giving all engineers access to deployment pipelines while keeping the job logs private. -- GitLab