Research: Deploy freezes for releases
What’s this issue all about?
Offering the ability in GitLab to set up change freeze windows/blackout periods: https://gitlab.com/gitlab-org/gitlab-ce/issues/51738
What questions are you trying to answer?
- Are blackout periods the right terminology? Change freeze? Production freeze? Something else?
- We learned that Deploy Freeze is the more common term from the Survey
- What are the controls you would need to set these up?
- Permissions to environments, permissions to release scheduled date at the project level
- If you can in theory add them at the group, project, or instance level - what is the priority of having each of these?
- Project is top priority followed by group and then instance - this follows the Releases support
- How fine must the period be? Per day? Per hour? Per minute? Per second?
- Xebia looks to support Per minute deploy freezes - this would be a common ask and we should support that.
- Are recurring change freezes needed (on day x each year, each weekend?) If so, what are these options?
- Many cited holiday hours, every Friday, or once a month. We would want to support all those levels of control to include a time and date span.
- Do you want these features in GitLab, or do you want to point to an external source like ServiceNow for blackout periods?
- MVC will be to support in GitLab with second to use a Webhook to set the time and date of a deploy freeze
What assumptions do you have?
- UI and API are going to be equally as important, with the need to support both
What decisions will you make based on the research findings?
- Where will the deploy freeze be set by, what can have a deploy freeze, who can set and administer deploy freeze
What's the latest milestone that the research will still be useful to you?
- 12.9
Edited by Jackie Porter