Launch Windows Shared Runner beta
Problem to solve
In the 12.5 release we are launching the Windows runner shared fleet, in beta status. The problem that we need to solve is ensuring that we have identified and completed any work required to have a successful launch of the Windows Shared Runners beta on GitLab.com
We will offer Windows Shared Runners on GitLab.com in beta. This issue will be used to capture any tasks required to support the beta launch.
- The development work that's being delivered in the MVC will deliver the ability to autoscale Windows Runners on GitLab.com
- The Windows Shared Runners will be virtual machines (VM's) running on Google Cloud Platform (GCP).
- As is the case today with our Linux Shared Runners, each job that's executed on GitLab.com, and that makes use of a Shared Windows Runner will instantiate a new VM, therefore ensuring that each job is fully isolated.
- Even though the corresponding epic is a MVC, and we will have a viable solution when the MVC is released, we are opting to release this as a Beta version due to the need to validate usage patterns and scaling of this important feature.
- The Beta period will run from November 22, 2019 through February 22, 2020.
- Number of shared Windows runners in fleet: For Beta launch, the configured autoscale limit for the shared Windows Runners fleet will be set to ~15% of the actual max number of Linux Shared Runners in use on GitLab.com for the last 90 days.
- VM Windows OS version: Windows Server 2019 Core Datacenter Edition
windows-server-2019-dc-core-for-containers-v20190827as a base image from GCP
- VM specs: n1-standard-2 2 vCPU, 7.5GB RAM can be easily bumped.
- Default shell: Powershell
- Software on Windows VM: Single source of truth can be found in https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md
- We will go out with Linux pricing for the beta.
- Pricing will likely be higher when the feature is generally available.
- Windows Shared Runners will be visible to users on GitLab.Com. Users will navigate to Settings/CI/CD in the left navigation menu.
- Windows Shared Runners will be displayed with a tag that identifies the Runner as Windows. Draft mockup attached:
- Users will have to specify the
windowstag in their project's .gitlab-ci.yml file in order to ensure that a job executes on a Windows Shared Runner hosted on Gitlab.com. TODO @DarrenEastman - add a brief
Beta Testing Feedback
- We will recruit users that have shown interest in this feature and request that they actively participate in testing the feature out during the beta period.
- A beta kickoff call will be held with the identified users. The purpose of that call is to..
- Gather a baseline set of data from the users in regards use cases, expectations for the capabilities available in the feature.
- Answer any questions that the users may have prior to the start of testing and to nail down a timeline of when they plan to pilot a test in their org to use the Windows Shared Runners.
- Schedule a follow up call to gather in person feedback. The purpose of the follow up call is to gather insights that we may not be able to infer from only the results of a survey.
- We will gather feedback from the recruited beta testers using the following mechanisms:
- User interviews will be conducted at the conclusion of each users planned tests.
- In addition, feedback will be collected from the recruited beta testers by a survey that will be sent to each tester at the conclusion of their initial tests.
- For issues encountered with the feature during testing, users will be instructed to raise an issue for a bug fix or feature enhancement request in the Runner project and tagging with
Note: - As the beta release is not closed, we expect that other users may test out this feature. Their input and feedback is of course extremely valuable as well. All users can use this workflow to provide feedback or suggest a feature enhancement to the Beta version of the Windows Shared Runner fleet:
- Open and issue in the Runner project.
- Describe the feature enhancement and if possible include any links to examples.
- Add these labels to the issue: SharedRunners:Windows, group:runner
- Tag @DarrenEastman on the issue.
Beta success criteria
Engineering success criteria are documented at: TBD
Product success criteria are TBD
- Create blog post for beta launch (coordinate with @williamchia) 1168 related MR for blog post 34599
- Create video for beta launch (coordinate with @williamchia)
- Create or update end user documentation (coordinate with @eread)
- Final end-to-end test that the Windows runners are working as expected (@steveazz)
- Finalize interim pricing for beta launch. 30834
- Confirm that the Windows Shared Runners usage is tracked (coordinate with @steveazz)
- Confirm go-live plan with infrastructure team (@dawsmith) - gitlab-com/gl-infra/readiness!12
- Confirm that support is aware and has the resources they need to support the beta (@lyle)
- Confirm and document the way to get feedback from customers during the period. (@DarrenEastman) 506
- Plan to validate technical success (usage patterns, scaling, etc.) of this important feature, to make sure that it's going to work for GA (coordinate @dawsmith and @tmaczukin)
- Plan to validate product targets for beta. We need to understand what the success criteria are in advance, even if we have partial data and need to guess. (@DarrenEastman)
Software Developer - Specifically developers that are developing software for the Windows ecosystem.
- I need to be able to create a continuous integration pipeline for my Windows projects.
- I like GitLab CI/CD, but setting up GitLab Runner on Windows can be time consuming, and in some cases frustrating.
Customer Value Proposition: Shared Windows Runners gives users the tooling to build their Windows projects on GitLab.com without needing to setup and configure their own Windows build machines.
Permissions and Security
- The current assumption is that the launch of the Windows Shared Runners feature is consistent with existing permissions as documented for users, groups and projects.
- It is also assumed that the user behavior for exposing the Windows Shared Runner in the UI is consistent with the current method for how Linux Shared Runners are exposed to users.
- At this time, we aren't expecting to need any changes to the UI, specifically the CI/CD settings menu and resultant page to support the Windows Shared Runner feature.
|What concepts and procedures should the documentation guide and enable the user to understand or accomplish?||The content in this main paragraph needs to be updated to include details that are specific to the Windows Shared Runner.|
|To this end, what new page(s) are needed, if any? What pages or subsections need updates? Consider user, admin, and API documentation changes and additions.||The content on this page mentions that if you use GitLab.com you can use the Shared Runners provided by GitLab inc. The link "read more on shared runners" links the reader over to another page that covers Configuring GitLab Runners, but it doesn't seem as if we have any additional content describing the Runners on GitLab.com|
|For any guide or instruction set, should it help address a single use case, or be flexible to address a certain range of use cases?||Yes- any guide or instruction sets should be flexible enough the address a range of CI use cases for Windows developers|
|Do we need to update a previously recommended workflow? Should we link the new feature from various relevant locations? Consider all ways documentation should be affected.||We may need to review the documentation here to make sure it's consistent with any new documentation on the Windows Shared Runner.|
|Are there any key terms or task descriptions that should be included so that the documentation is found in relevant searches?||Windows, Shared Runners|
|Include suggested titles of any pages or subsection headings, if applicable.||Pending feedback from tech writing team as to whether additional pages or subsections are required.|
|List any documentation that should be cross-linked, if applicable.||To date - linked docs are identified in the rows above.|
|Item to consider||Notes|
|What risks does this change pose?||Supporting Windows Runners on GitLab.com at scale is of course new, so there could be a potential increase in support requests or issues raised by the community once this feature is launched.|
|Will it require cross-browser testing?||No - the current assumption is that there are no UI changes required in GitLab.com to expose the Windows Shared Runners to users.|
What does success look like, and how can we measure that?
Secondary market research: In the 2019 Stackoverflow developer survey "Linux and Windows are the most common platforms" for development work this year with Windows at 50%.
So to specify a measurable success metric for the beta, we will need to review the current GitLab.com metrics in terms of usage of Shared Linux runners and then set an expected target in terms of usage that we expect in M+1, M+2 and so on. The 50% metric from the Stackoverflow survey is an interesting data point to consider in determining the right target usage goals.
What is the type of buyer?
- Individual Contributors