Demo Systems

The GitLab Demo Systems provide infrastructure for the GitLab Customer Success, Marketing, Sales, and Training teams to demonstrate GitLab features, value propositions, and workflows in a variety of asynchronous and live capacities.

Overview of Demo Systems

The GitLab Demo Systems provide infrastructure for the GitLab Customer Success, Marketing, Sales, and Training teams to demonstrate GitLab features, value propositions, and workflows in a variety of asynchronous and live capacities.

The Demo Systems were originally architected by Jeff Martin starting in October 2019 when he was a Senior Demo Systems Engineer. Since Jeff moved to the IT team in June 2021, Logan Stucker (Demo Architecture) and Scott Cosentino (GitLab University) have taken over as the primary maintainers of the Demo Systems, including supporting training instructors and students with GitLab Learn Labs.

For questions about what demo sample projects are available or peer assistance with troubleshooting your failed pipeline job, please ask in the #demo-architect-partners Slack channel.

Please tag @Jeff Martin in one of the following Slack channels with any questions or requests related to infrastructure or access requests.

  • #demo-systems is for SA, CSM, and PSE team members with questions or needing technical assistance. No longer for training/workshop related posts.
  • #demo-architect-partners is for workshop-related discussions.
  • #demo-systems-ps-education is for ILT/SPT/etc related discussions for Professional Services.
  • #sandbox-cloud-questions is for help and support with the Sandbox Cloud (AWS Accounts and GCP Projects).

Please consider this handbook documentation to be the single source of truth (“SSOT”) for all resources that use the gitlabdemo.com, gitlabdemo.cloud, and gitlabtraining.cloud domain names.

Why do we have demo systems?

  • Why shouldn’t we just use GitLab.com? Although you can use GitLab.com for showing most of the value of GitLab use cases, there are some administrative features that require the deployment of GitLab Omnibus infrastructure in AWS, GCP, or local VM/container. Many of our enterprise customers opt for self-managed over GitLab.com so we are mindful of “showing the customer what they’ll see in production”.

  • What’s special about our infrastructure? The demo systems infrastructure doesn’t do anything special that a customer or partner company couldn’t do themselves with the appropriate staffing and engineering investment. We have open sourced our infrastructure-as-code methods, scripts and tools for the wider community to use to streamline their deployment of Omnibus infrastructure. See the gitlab-com/demo-systems repositories to explore our open source projects.

  • Are there special engineering or scalability considerations with training classes and workshops? Yes. The GitLab product was designed for users to be doing different activities throughout the day and the smaller reference architectures are not designed for dozens or hundreds of users to click the same button and running the same background jobs or pipeline jobs at the same time. Our users are also ephemeral and have automated garbage collection requirements that are not customary for conventional GitLab product use cases. This requires special scalability considerations, notably with the Container Registry, Sidekiq, and Kubernetes that we have to accommodate for. Here’s some of the things we’re looking for with scalability challenges.

    • Autoscaling runners for 500 simultaneous pipelines started in 10 seconds
    • Autoscaling Kubernetes nodes for 500 simultaneous review apps/deployments in 60 seconds
    • Auto DevOps pipelines that consume lots of wasted resources
    • Kubernetes services that are not needed (ex. Postgres database)
    • Intensive test jobs that are not needed during workshop (ex. Code Quality, Dependency Scanning, etc.)
    • Project export/import queued job fails with 500 simultaneous project imports
    • Features in your project that have known issues with import/export process (ex. wikis)
    • Administrative access for students (alternative use cases)
    • Package registry caching and garbage collection
    • Container registry caching and garbage collection
    • CI images pulling from Docker Hub with rate limits
    • CI image versions that are incompatible or have been upgraded with bug fixes
    • Using templates in .gitlab-ci.yml without realizing the underlying job load.
    • Using custom .gitlab-ci.yml files without comments of the actions being performed
    • Dependency proxy configuration (particularly for npm and maven dependencies)
    • Lack of step-by-step instructions that leads to student misconfigurations and errors

Shared Environments

These shared environments are referred to as the Demo Cloud or Training Cloud. Historically, training users used the Demo Cloud so the names are used interchangably in some conversations.

Demo Systems v1 Deprecation

The gitlab-core.us.gitlabdemo.cloud instance was deprecated on 2021-04-20 and destroyed on 2021-06-03. No data back up is available. See Access Shared Omnibus Instances instructions for accessing the cs.gitlabdemo.cloud instance (direct replacement).

  • cs.gitlabdemo.cloud - This is the primary GitLab Omnibus instance that all team members have access to for creating groups, projects, and sandbox purposes on a self-managed Omnibus instance. Please keep in mind that this is a shared environment across all team members and you should treat the Admin areas as read-only.
  • ilt.gitlabtraining.cloud - This is used for instructor-led training classes. You should generate credentials for this instance if you are an instructor and need admin access to be able to import sample projects and/or see the groups for all of the students in a class.
  • spt.gitlabtraining.cloud - This is used for self-paced training classes that are published in EdCast. You should only generate credentials for this instance if you are involved with instructional design or certification grading of self-paced student courses. If you are enrolled in a self-paced training class, you should follow the instructions for redeeming an invitation code to generate temporary credentials that can be used for accessing the instance that has been pre-configured for the training lab guide steps.
  • workshop.gitlabtraining.cloud - This is used for enablement and field marketing workshops that are delivered on a routine basis. You should generate credentials for this instance if you are involved creating lab sample projects, lab guides, presenting, or supporting a workshop.

Isolated Environments

  • AWS Account: See the instructions for provisioning your own isolated AWS account with the GitLab Sandbox Cloud.
  • GCP Project: See the instructions for provisioning your own isolated GCP project with the GitLab Sandbox Cloud.
  • AWS Elastic Kubernetes Service (EKS) Cluster: You can use your AWS account to provision an EKS cluster using the Adding EKS clusters GitLab documentation.
  • GCP Google Kubernetes Enginge (GKE) Cluster: Send a message to Jeff Martin with questions about clusters that are in the group-cs GCP project. See the tutorial for configuring GitLab with group-level Kubernetes cluster to add your cluster to your GitLab group.

How to Get Started

These instructions are for Demo Systems v2 that uses the gitlabdemo.cloud Portal. The Demo Systems v1 infrastructure that used gitlabdemo.com has been deprecated except for training class invitation codes.

Access Shared Omnibus Instances

These instructions provide you access to one or more of our shared environments (Omnibus self-managed instances).

The Demo Cloud Portal and provisioning system is powered by gitlabdemo-cloud-app, an open source project created by Jeff Martin.

  1. Visit the GitLab Demo Cloud Portal (https://gitlabdemo.cloud) and sign in with your Okta credentials.
  2. Navigate to the Environments top navigation link or click on the View Environments button on the dashboard.
  3. Locate the Environment Instance that you wish to access and click the Generate Credentials button.
  4. After the credentials have been generated, click the View Credentials button.
  5. Create a new record in your 1Password vault with your generated credentials.
  6. Click the Access Instance button to open a new tab with the URL of the GitLab Omnibus instance.
  7. Bookmark the Omnibus instance that you can use to easily access this in the future. You do not need to access the https://gitlabdemo.cloud portal each time you want to access the instance since this is only for access requests (credential generation).
  8. After signing in, a group has been pre-created for you to store your projects under. To help with namespace consistency and security best practices, please do not create other top-level groups with custom names. You can create any subgroups or projects you’d like under your pre-created group or in your personal namespace.
  9. Each instance is pre-configured with shared GitLab Runners and a Kubernetes cluster. These are for consumption purposes when running CI/CD pipelines and you do not have administrative access to these in the shared environments.
  10. You can ask for help from other peers in the #cs-questions Slack channel.

AWS Account or GCP Project (Sandbox Cloud)

See the Sandbox Realm handbook page for instructions on creating your own AWS account and/or GCP project that you can use for deploying your own infrastructure with the benefit of centralized billing.

Invitation Code Creation

Invitations codes are created by the demo systems team and can be requested by following the Workshop Preparation guide.

Invitation Code Redemption

Warning for GitLab team members: This process uses an existing GitLab.com account so please ensure this is set up before hand.

  1. Visit https://gitlabdemo.com and click the Redeem Invitation Code button.
  2. Type in the 8-character invitation code that was provided by your instructor or in your course materials.
  3. Press Redeem and Create Account.
  4. Type in your GitLab username (without the @), then click Redeem and Create Account.
  5. Click the blue My Group button to open a new tab with the URL of the your GitLab group living on Learn Labs.

Workshop Preparation

The workshop process has iterated multiple times. The latest version of the workshop preparation process has been simplified into a self-service model.

As the workshop presenter and supporting team member, you are responsible for importing and testing your sample projects and lab guide content. There is no support provided for misconfigured projects, failing pipelines and jobs, or GitLab Runner error messages specific to projects and jobs.

There is no more peer review or approval process other than scheduling coordination with the field marketing team. These instructions provide best practice guidance. If you need assistance, please ask in the #demo-architect-partners Slack channel to get help from other team members that have delivered similar workshops.

Workshop preparation steps will be linked on the resulting issue after completing the request form here

Workshop lab guide catalog

All of the workshop content that are created officially can be found in the Learn Labs Sample Projects group. Often workshops don’t fit a customers needs out of the box so we support creation of custom customer workshops/labs/demos through the DA Portal

Version Upgrades and Maintenance

We perform version upgrades on the weekend following the monthly release. The weekend upgrades are performed at a random time on Saturday or Sunday based on engineer availablility and lasts for approximately 30 minutes.

We delay the upgrade window for updates that we consider risky or occur during holidays. This occurs during May each year that aligns with the US Memorial Day holiday, in December around the Christmas Holiday, and in January at the end of the fiscal year when we have a configuration freeze until sales demos are completed.

For patch and security updates, we will usually only perform upgrades for critical updates and will announce maintenance windows in the #demo-systems channel on Slack.

Legacy Version Support

We keep our shared environment up-to-date with the latest versions to help showcase the value that the newest features and solutions offer.

For demo and sandbox use cases requiring an older version, you can deploy a GitLab instance in a container in the Container Sandbox or using Omnibus in the Compute Sandbox. We do not offer any data migration or parity configuration support.

Tutorials

Sample Data

Historically, there has not been a consistent set of demo data. Each of our Solutions Architects are responsible for creating their own demo data or forking projects from other team members.

See the handbook page for Demo Readiness and Existing Demonstrations to get started.

Please see the Solutions Architecture Initiatives issue tracker for more information on the crowd sourced OKRs that are in progress and the development of our Communities of Practice.

Projects and Code Repositories

These are the projects that make the Demo Systems possible behind the scenes. You are welcome to study and learn from any of our source code. Each project is classified as Public or Private depenending on the security risk of the source code or information contained within.

Demo Systems v2

The Demo Systems v2 repositories can be found in gitlab.com/gitlab-com/demo-systems.

Demo Systems v1 (Deprecated)

The Demo Systems v1 repositories can be found in gitlab.com/gitlab-com/customer-success/demo-systems.

Help and Support

We use Slack for real-time support and quick fixes. If in doubt of how to get help, ask in #demo-systems. The issue trackers are used for tasks and projects that take longer than 30 minutes. We do not use email for internal team communications.

  • Demo Systems Issue Tracker
  • #demo-systems Slack channel (for Demo Cloud announcements, questions, and technical support with Demo Cloud)
  • #demo-systems-ps-education Slack channel (for ILT/SPT training lab discussions)
  • #demo-systems-workshops Slack channel (for workshop discussions)
  • #sandbox-cloud Slack channel (for Sandbox Cloud announcements)
  • #sandbox-cloud-questions Slack channel (for Sandbox Cloud questions and technical support)
  • demo-systems-admin@gitlab.com (for non-Slack users)
Demo Systems Onboarding
This guide is meant for getting any new hire to the CS Org set up on demo systems and prepaired to start demoing the product
Demo Systems Tutorials
The GitLab Demo Systems tutorials provide step-by-step instructions for accessing and using our infrastructure and related business processes.
Environments
Infrastructure
Last modified July 10, 2024: Fix broken links and spelling (680a0bc8)
View page source - Edit this page - please contribute. Creative Commons License