Skip to content

[Epic] UX demo: Idea to Production

We have a first iteration of a slideware demo. This issue tracks the next iteration with the goal of making the demo look more real and compelling, but still not be actually functional.

Why are we doing this?

It’s about communicating a compelling vision that helps align us internally and with partners, so we’re building towards the same thing, and understanding the complete context; not just individual parts.

For example, our direction page already lists the scope, but it’s hard to see the big picture from that.

What are we doing? / Scope

  • Start with screenshots and mockups, polish them a bit more than my hacked together images.
  • Mock up a few of the flows, perhaps to the point of being able to do a video screencast like a real demo.
  • e.g. make a COG plugin for Slack so we can talk to it and tell it to create an issue and deploy to staging, and have it respond with text, but not actually do anything on the backend.
  • Create a branch on gitlab-ce with buttons for some of the integrations that might have hardcoded pages in it or other faked interactions.
  • Maybe piece it all together so it looks like a live demo.
  • A big part of it will be thinking through the user experience. What should we actually have developers do at each stage?
  • Think about what we could do with the current products, but also what could we do long-term. Like don’t just link to Koding, but integrate the IDE into GitLab itself.

Team

Links

Proof of concept / Mocked interfaces / Other steps to pull the demo together

  • Demo project: #20295 (closed)
  • Demo script: #20296 (moved)
    • Add reviews apps
    • Add environment variables for production secrets
    • Remove redundancy, for example revisiting the container registry
  • Velociraptor logo in GitLab style/colors: #20348 (closed)
    • Place somewhere easily installable via Koding CLI
  • Write GitLab bot for Slack @markpundsack (https://gitlab.com/markpundsack/gitlab-bot)
  • Dummy issue board: #19952 (closed)
  • Mockup of Koding integration: #19953 (closed)
    • Install Koding on some cloud (DO) @zj
    • Give Koding AWS creds to spin up stacks
  • Flesh out velocity analytics: https://gitlab.com/gitlab-org/gitlab-ce/issues/18687
  • Deployment statuses for MRs: #20359 (closed)
  • One-click deploy of GitLab to OpenShift: #19839 (closed)
    • Set up new template to look like it's installing GitLab CE on Openshift online (remove 2 persistent data stores) @twk3
    • Install GitLab CE on some cloud (DO), with Mattermost @zj
    • Install 2 shared runners on some cloud (DO), and configure in GitLab CE instance @zj
  • Autoscale CI runners on OpenShift: #19840 (closed)
    • Create Openshift app for fake runner, scale=2
  • Create demo branch, including Koding MR, Issue Board, and Velocity Analytics
    • Install demo branch on GitLab CE running on DO
    • Connect GitLab CE with Koding
  • Integrate staging and production Velociraptor with Openshift
    • Set up new template to look like production and staging environments of Velociraptor app
    • Either change demo to use .apps.origin.gitlap.com domain, or explain how to configure variables to set custom domains, or explain custom DNS
    • Add kubernetes configuration to template app, or
    • Add kubernetes templates to GitLab as another special file type, or
    • Write a kubernetes file on the fly, or
    • Demo automatic configuration of Openshift/kubernetes production/staging/review apps in project settings

Cut

  • Cog stubbed plugin: #19838 (moved)
  • Install Cog on some cloud (DO?), connect to Mattermost
  • Create Cog bundle for GitLab
  • Configure Mattermost and Cog
  • Enter container scheduler credentials, used for CI autoscaling (can this be automatically configured at install time?)

Timeline for real demo (for reference, out of scope for this issue)

Just for reference, out of scope of this issue, but also part of real vision

  • Run GitLab with one click on all major Container Schedulers: #20199 (moved)