Launch Windows Shared Runner beta

Launch Tasks

  • Create blog post for beta launch.
  • Create or update end user documentation.
  • Finalize interim pricing for beta launch. 30834
  • Confirm that the Windows Shared Runners will be included in the standard billing model.
  • Create video for GitLab YouTube channel.

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

Proposal

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.

Intended users

Software Developer - Specifically developers that are developing software for the Windows ecosystem.

Motivations:

  • 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.

Further details

Overview:

  • 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.

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.

Beta Features:

  • VM based Windows Shared Runners
  • Isolated Windows VMs for each project
  • VM Windows OS version: (placeholder for details)
  • VM specs: placeholder for details)
  • Default shell: Powershell
  • Software on Windows VM:(placeholder for details)

Pricing:

  • We will go out with Linux pricing for the beta.
  • We will go with 2x for Windows at GA.

User Experience:

  • 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: windows-shared-runners-mock
  • Users will have to specify a tag 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

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.

Documentation

Documentation requirements Notes
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.

Testing

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
  • Manager
  • Director
  • Executive

Links / references

&1768 (closed) #30834 (closed)

Edited by Darren Eastman