I2P Onboarding/adoption

mentioned in issue gitlab-foss#32639 (moved)

changed the description

@tauriedavis This is still a grab bag of ideas, but I'd like your thoughts on what we can do to make this coherent and focused. What are the few things we can do to make a real difference.

In the end, it feels like the natural conclusion is that the flow is something like:

User creates project
User pushes code to repo
User gets notification that CI passed, and staging/production app was created deployed to
User creates topic branch and pushes code
User gets notification that CI passed and review app was created

i.e. zero configuration, CI/CD is enabled by default for all projects, with implied configuration based on Auto Deploy (Herokuish and Kubernetes), and GitLab.com provides enough pipeline runner minutes and k8s compute minutes that they can get started with near-zero effort.

When they hit a limit, they'll be asked to provide a credit card and select a paid tier for more minutes, or provide their own k8s cluster (and we'll make it easy with a few clicks and OAuth with Google).

So working backwards, how do we get there? What are the steps?

The interesting thing is that the end goal is very clean and simple. There's almost thing to demo. But nothing is truly that simple. People will need to add variables, resources, tweak the pipeline, manage the k8s cluster, etc. So a complete solution actually has a lot of management capability. So does it make sense to flesh out those incremental steps? Make .gitlab-ci.yml editing easier. Make k8s cluster admin easier. Then put it all together into the magic described above. Rather than trying to make the magic first, and have it fail in so many ways that nobody uses it until we finally flesh it out enough to be usable. What's the best iterative story; what's the most boring bang-for-buck. I have a feeling, it involves taking what we already have and making it easier to use, in small increments.

changed the description

/cc @bikebilly @ayufan @dimitrieh

I've characterized this as I2P adoption, but most items are related to CI/CD. There are a few minor things we could do with ChatOps, for example. But I can't really think of many things outside CI/CD or that don't depend on CI/CD (like monitoring).

/cc @joshlambert

assigned to @tauriedavis

mentioned in issue gitlab-foss#28908 (closed)

For ChatOps onboarding, we need:

Instance-wide chat integration: https://gitlab.com/gitlab-org/gitlab-ce/issues/32713
Group-wide chat integration
Support multiple projects with single chat trigger word: https://gitlab.com/gitlab-org/gitlab-ce/issues/24770

changed the description

mentioned in issue gitlab-foss#32732 (moved)

On the monitoring front, I think the stretch goals we have in 9.3 (so maybe 9.4) will align really well.

Single click deploy of Prometheus to k8s cluster: https://gitlab.com/gitlab-org/gitlab-ce/issues/28916
Leveraging proxy API to seamlessly connect to internal k8s resources (like Prometheus) https://gitlab.com/gitlab-org/gitlab-ce/issues/30480
Then of course the 9.3 main deliverable of autodetecting and adding metrics: https://gitlab.com/gitlab-org/gitlab-ce/issues/30369

We should push this up to groups as well, however we will need to update the queries to look for not just CI_ENVIRONMENT_SLUG but also the proper namespace which they don't do today. (https://gitlab.com/gitlab-org/gitlab-ce/issues/32751, https://gitlab.com/gitlab-org/gitlab-ce/issues/32752)

More broadly speaking, I was trying to think of the biggest hurdles to getting started with CI/CD. What came to mind to me was:

Creation of gitlab-ci.yml.
- GUI builder comes to mind immediately to help here, with perhaps an integrated samples library that could eventually have intelligence to suggest steps or even a full YML.
- Long shot, but could we have an importer for other CI tools? Detect a Travis CI file and convert?
Creation of Docker containers
- Since we are starting from (I think) an assumption we are running on a cloud provider here, could we help people create Dockerfiles? If we do this, CI may still be manual but CD could get really easy?

mentioned in issue gitlab-foss#32820 (moved)

Single click deploy of Prometheus to k8s cluster: https://gitlab.com/gitlab-org/gitlab-ce/issues/28916

Reminds me that we need an issue for single-click deploy of autoscaling runner to k8s cluster.

@joshlambert FYI, we now have Dockerfile templates for many languages. https://gitlab.com/gitlab-org/Dockerfile

@joshlambert Can you add your Prometheus items to the description? Perhaps to their own section, or intermingle as you see fit.

changed the description

@joshlambert I've commented elsewhere, but I wonder if the easy path to .gitlab-ci.yml creation is just a simple wizard that asks you if you want tests, review apps, staging, etc. and generates a configuration using Herokuish buildpacks, Heroku CI, etc. Then you can customize as you grow, but it forms a great starter position. That's a far cry away from an editor or GUI builder, but might be the best bang-for-buck.

changed the description

Moved all the Auto Deploy issues to their own meta issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/32829

@markpundsack Yep! Agree, was just mainly trying to note that creation of the CI YML file seems like one of the major hurdles (at least to me) to attack.

I didn't know the Dockerfile repo existed, which is cool. To your point elsewhere, would be great if we can group these things up a bit better, as we also have the gitlab-ci-yml repo as well. Which upon looking at it, I just realized we have a Maven example! https://gitlab.com/gitlab-org/gitlab-ci-yml/blob/master/Maven.gitlab-ci.yml

changed the description

On the discussion of .gitlab-ci.yml configuration, there's a spectrum from zero-click (enabled by default), to wizard, to GUI builder, to templates, to blog posts.

Zero-click seems to be an awesome goal, but assuming our "coverage" of automated CI is low-ish, say below 90% and likely much lower (like 40%), and especially as we're likely to start out low and build capability over time, I wonder if it makes sense to not focus on zero-click for now. Focus on generating .gitlab-ci.yml files for people, so that it's more opt-in. This has the obvious downside that a lot of people won't even know it exists and so won't benefit. But the upside of less people being disappointed. It's a more conservative approach. Maybe a hybrid approach would be to start with a wizard, and then after some months of stability, turn on implied, zero-click configuration.

Alternatively, start with zero-click just for CI (if/when we support Testpacks), but not CD (especially since not all projects are even deployable).

Current Auto Deploy is so limited, it's not recommended for any production usage. But I could still see a wizard based on it because it's such a great place to start.

Your flow makes sense to me, get experience with improving the .gitlab-ci.yml creation process and as that improves should become more and more one click. Should improve the experience for more users, and get more feedback, than addressing one-click with 10% of the market and trying to expand from there.

Auto Deploy really hits its stride it seems when there is a Dockerfile or soon a Helm chart (and Compose via Kompose?). I was working on a slightly improved I2P demo app, and the easiest path forward was to just write up a quick Dockerfile and use AutoDeploy. (The only hurdle was that the port is currently hardcoded to 5000, but that is an easy fix.)

@joshlambert Also, why did you need a Dockerfile as opposed to using buildpacks?

@markpundsack It was a static site, but for some reason the build pack wouldn't recognize that. I tried to dig into https://github.com/pearkes/heroku-buildpack-static, created the file that is supposed to flag it as such, but still couldn't get it to identify.

added UX in GitLab FOSS label

@markpundsack We should create a separate issue that relates directly to the wizard we discussed last week if there isn't one already. https://gitlab.com/gitlab-org/gitlab-ce/issues/32553 seems different and I didn't find anything else in the description that really matches.

The UI for this should be really straightforward. The hard part is drilling down what we need to ask in order to get the information we need from the user to create the file. It should be in as least steps as possible. I envision walking the user through the basics in order to create and then guiding them through recommendations in the visual editor.

mentioned in issue gitlab-foss#33165 (closed)

~~Created issue specifically for the wizard and added it to the issue description.~~

Grzegorz linked me to https://gitlab.com/gitlab-org/gitlab-ce/issues/14266 which looks like what we discussed and is already in the description, so lets use that.

changed the description

removed assignee

changed the description

The main problem I see with gitlab-foss#32553 (moved) is that it's not immediate, so even if it enables CI/CD in a simple way maybe users will not be aware and so the entire scope is compromised.

@bikebilly I'm not sure I understand that comment. My assumption is that if we default to enabling all this CI/CD, users will get email notifications of pipelines, see the pipeline status on merge requests, etc. so it will be pretty obvious.

changed the description

mentioned in issue gitlab-foss#25986 (closed)

Random thoughts:

Is Auto DevOps the most important thing to work on next? Or is making existing functionality easier to discover the most important thing?

One of the really great things about GitLab, and especially CI/CD, is that it's constructed of smaller features that you can put together in tons of different ways to do pretty much anything. We can automate a bunch of things, but if we're not careful, those things can be pretty rigid. Working from automagic towards flexibility is challenging. Perhaps we're better off starting with our strength of flexibility and making it easier.

We have a stated vision of convention over configuration, yet CI/CD has pretty much done the opposite there. People do love GitLab CI/CD, so its success might indicate that customers have different values, or the power of the solution is succeeding despite not having good conventions. Perhaps spending some times providing good conventions for CI/CD is one of the most important things to work on next.

There's two basic flows of concern:

New user getting started
Intermediate/advanced user

Improving things for new users increases the number of users trying out CI/CD, while improving things for intermediate/advanced users increases the number of users sticking with CI/CD, and indirectly through word-of-mouth, increasing other users trying out CI/CD.

The assumption is that a new user getting started wants the easiest path to their first green test or their first production deploy. And Auto Deploy provides that.

But if their project is more than a simple rails new app, does Auto Deploy really work? How many new users are starting with small projects vs a user being new to GitLab, but coming with a very complex app with complex build, test, and deploy requirements? In the latter case, if Auto Deploy fails for them, it's worse than not having it at all, because it will have wasted their time and provided no value. But, does Auto Deploy help them get started anyway, with some reasonable defaults, that they then just need to tweak/enhance? They can customize the Dockerfile and helm chart as needed, and the base Auto Deploy provides is still pretty solid. Yet, it seems that real production use of CI/CD is all over the map. We use the GitLab container registry by default, but some teams already have their preferred container registry. We provide a deploy strategy involving review apps, staging, and production, but a team already has their QA and load testing strategy figured out, and it's not the same.

Another angle is how things fail. If Auto DevOps succeeds, it can feel like magic. If it fails without being a waste of time or inundate you with error notifications, perhaps it's not so bad. Especially if it gives actionable advice for how to fix things. e.g. if the buildpack-based build works, but you're using a custom test framework, it's not so bad if we give advice to that effect. But if they have to pour through job logs to figure out what went wrong, that could suck.

In a different direction; the challenges an intermediate user have are sometimes around optimization. They get a basic build, test, deploy configuration working, but it takes hours to run. How do they parallelize? How do they use caching and artifacts? How do they pre-build efficient docker images?

mentioned in issue gitlab-foss#33707 (moved)

mentioned in issue gitlab-foss#32829 (closed)

mentioned in issue gitlab-foss#14483 (moved)

marked this issue as related to gitlab-foss#32639 (moved)

marked this issue as related to gitlab-foss#35616 (moved)

marked this issue as related to gitlab-foss#35712 (moved)

Get notification on first run of a branch (success or failure). (Also get notification on each failure and on first success after failure)

Building on https://gitlab.com/gitlab-org/gitlab-ce/issues/32638#note_30173105, the current thinking for flow is something like:

User creates project
User pushes code to repo
User gets notification that CI passed, code quality report
User gets message to add k8s cluster to enable review apps and production app
User clicks button to connect to Google and create GKE cluster, enable Prometheus and Helm tiller.
User gets notification that production app is deployed
User creates topic branch and pushes code
User gets notification that CI passed, code quality delta, and review app was created

The minimal first iteration is in https://gitlab.com/gitlab-org/gitlab-ce/issues/35712#flow.

mentioned in issue gitlab-foss#35788 (moved)

marked this issue as related to gitlab-foss#35788 (moved)

changed the description

mentioned in issue gitlab-foss#31166 (closed)

mentioned in issue gitlab-foss#35712 (moved)

marked this issue as related to gitlab-foss#35616 (moved)

marked this issue as related to gitlab-foss#32829 (closed)

@sarahod I would love some UX research here! There's a lot we can do, but prioritizing what is most important, and uncovering unknown areas for improvement would be great.

mentioned in issue gitlab-foss#37042

mentioned in issue gitlab-foss#37046

mentioned in issue gitlab-foss#32640 (moved)

mentioned in issue gitlab-foss#38366

marked this issue as related to gitlab-foss#38366

changed the description

moved from gitlab-foss#32638 (moved)

I2P Onboarding/adoption

Links

Designs

Child items ...

Activity

Admin message

Admin message

I2P Onboarding/adoption

Links

Relates to

Activity